Existe uma metodologia para axing metodologias?

Question

Como você coleta de lixo ou eliminar metodologias ultrapassadas e pesados ??que são mais prejudicial do que útil para o processo de desenvolvimento de software? Como você pode continuamente agilizar o seu processo para limpar o caminho para programadores para realmente obter algo feito em vez de fechar mil celeiro portas por causa dos cavalos escaparam de tempos passados?

Answer 1

Gostaria de usar retrospectivas para reunir informações sobre o que funciona eo que não funciona. Você pode usar retrospectivas em diferentes pontos do seu ciclo de projeto.

Se você estiver usando uma metodologia iterativa, você deve ter uma retrospectiva no final de cada iteração. Se você estiver usando cachoeira, você deve fazer uma retrospectiva (alguns chamam de pós-morten) uma vez que o produto foi lançado.

Durante a retrospectiva, você precisa responder coletivamente as seguintes perguntas:

1. O que funcionou bem?
2. O que devemos começar a fazer?
3. O que devemos parar de fazer?

Em seguida, você pode trabalhar com sua equipe para priorizar o que é importante para eles. Pergunte-lhes o que é a coisa que eles gostariam de mudar e começar a trabalhar sobre isso.

Answer 2

Em uma palavra: a comunicação. Entre você e colegas de equipe, outras partes interessadas, como gerentes de projeto, etc.

A metáfora GC não é pertinente; não há nada externo ao seu time que pode racionalmente determinar quando uma prática ou metodologia é elegível para a extinção. Isso é uma coisa dinâmica que tem de ser acordado por todas as partes interessadas. É um problema de comunicação.

Answer 3

Os seres humanos são criaturas de hábito. Desenvolvedores, talvez mais que outros.

Os gerentes tendem a querer experimentar a mais recente ferramenta buzzword-compliant / técnica enquanto seus devs vai querer ficar com experimentadas e verdadeiras.

Se você quiser desenvolvedores a deseja para tentar coisas novas, você quer necessidade de desafiá-los constantemente, obter aulas para eles, ou de alguma forma convencê-los de que o gerente-falar não é o que é importante - é a ferramenta que eles deveriam pelo menos investigar.

Você também precisa ter certeza de ouvir suas queixas, e catalogá-las como técnica ou opinião.

Se suas queixas são principalmente opinião, então talvez você precisa de um conjunto diferente de desenvolvedores. Se eles estão técnico, então não importa o quão popular a ferramenta é, provavelmente deve ser evitada nesse cenário.