Acabei de ler Balancing Agility and Discipline . Pobre título à parte, contrastava uma equipe de projeto orientada a planos que empregava PSP / TSP e uma equipe ágil usando Extreme Programming.
Quando os autores forneceram um exemplo de metodologia orientada a planos, eles usaram o Processo de Software Pessoal / Processo de Software de Equipe. Embora, prontas para uso, sejam metodologias orientadas a planos, elas também são projetadas para serem usadas como estruturas de processo e, em última análise, especificam apenas que tipos de coisas a serem feitas e não como fazê-las, o que as torna potencialmente úteis mesmo em um ambiente ágil. É possível ser ágil e ainda aderir aos princípios do PSP, e eu não estou familiarizado o suficiente com o TSP para ter certeza, mas meu entendimento é que é muito semelhante.
Em um ponto do livro, eles listam várias metodologias e as classificam em termos de agilidade. Métodos como Scrum, Lean, Crystal e XP estão no topo. A parte inferior (do mais ao menos ágil) consiste no Rational Unified Process, no Processo de Software de Equipe, no Desenvolvimento Orientado a Recursos, no CMMI, no CMMI de Software, no Personal Software Process e na Cleanroom.
Watts Humphrey, no PSP: um processo de auto-aperfeiçoamento para engenheiros de software , dedica um capítulo à definição do processo e à modificação específica do processo de software pessoal. O tema comum é que os processos são prescritivos (eles dizem o que fazer) e não descritivos (como fazê-lo). Eu diria que o TSP é da mesma maneira. O CMMI também foi usado em conjunto com métodos ágeis, e o SEI possui um livro (que ainda não li).
O Desenvolvimento Orientado a Recursos é frequentemente apresentado como uma abordagem ágil ao gerenciamento de projetos, mas os autores optam por classificá-lo como uma metodologia menos ágil.
O RUP é uma estrutura iterativa. Embora eu não esteja muito familiarizado com isso, o fato de ser uma estrutura me permite agrupá-la com SW-CMM, CMMI e PSP / TSP, pois ela pode ser implementada como uma metodologia ágil ou orientada a planos.
O único outro exemplo com o qual concordo com o livro é a Engenharia de software de sala limpa . Os principais componentes da sala limpa são o uso de métodos formais, controle estatístico de qualidade e teste estatisticamente correto. Não vejo por que eles não puderam ser usados em um método ágil (iterativo / incremental), com adição de tempo e custo adicional.
Apenas para esclarecer o que estou procurando, a família de métodos ágeis inclui implementações específicas de uma idéia abstrata na forma de Scrum e Extreme Programming. Eles realizam os conceitos de desenvolvimento iterativo e incremental, respondendo a mudanças, pessoas (indivíduos e equipes), entrega frequente de software de trabalho, colaboração com o cliente e assim por diante. Eles especificam claramente funções, artefatos, reuniões, caixas de tempo e outras práticas e "fazer Scrum" ou "fazer Extreme Programming" significa levar o pacote. Mesmo assim, eles permitem a personalização e a criação de novos processos (mas você não está "fazendo Scrum" ou "fazendo XP"). No entanto, eu não encontrei o "do X"
Então, minha pergunta: quais são exemplos de metodologias de desenvolvimento de software mais orientadas a planos? Várias estruturas de processo (PSP / TSP, SW-CMM, CMMI, RUP) também permitem o desenvolvimento ágil ou orientado a planos, mas nenhuma é descritiva. Mas existem metodologias realmente orientadas a planos, que são, por exemplo, contrapartes diretas para Scrum e Extreme Programming?
fonte
Respostas:
Sinceramente, tenho dúvidas sobre a validade de qualquer reivindicação feita em um livro que coloque Agilidade e Disciplina uns contra os outros. Metodologias ágeis exigem muito mais disciplina, na minha experiência, do que outros tipos de desenvolvimento.
Ou seja, se você deseja explorar os benefícios dos processos Agile, deve seguir as práticas facilitadoras que os acompanham (consulte o artigo Is Design Dead, de Martin Fowler ; ele está falando principalmente sobre XP, mas se aplica a toda a agilidade, em minha opinião). Isso requer muita disciplina.
Mas, para responder à sua pergunta, acho que todas as metodologias realmente planejadas são variações do Waterfall, como o Spiral , que leva o desenvolvimento a vários níveis de prototipagem antes de mudar para uma abordagem do Waterfall, e o Cap Gemini SDM , que é o Waterfall com muito fases distintas em que cada uma termina antes que outra comece.
fonte