Além do Waterfall, quais são outras metodologias de desenvolvimento de software orientadas a planos?

8

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?

Thomas Owens
fonte
Você escreve que o livro "contrastava uma equipe de projeto orientada a planos que empregava PSP / TSP e uma equipe ágil usando Extreme Programming". Tenho certeza de que usamos muito planejamento para a implementação do XP. Estou um pouco confuso ao presumir que os XP não planejam. Minha experiência é diferente. Meus dois centavos.
Manfred
As metodologias orientadas pelo @John Plan estão centradas na aplicação de técnicas tradicionais de engenharia e na mudança sistemática dos requisitos por meio de, finalmente, um produto de entrega, enquanto a verificação e validação são executadas na etapa. Eles são caracterizados por uma forte documentação e rastreabilidade ao longo da vida útil do sistema. Existem planos detalhados, fluxos de trabalho e produtos de trabalho (que são outras coisas que não software de trabalho).
Thomas Owens

Respostas:

5

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.

pdr
fonte
1
Eu concordo - não gosto da comparação entre "ágil" e "disciplinado". "Ágil" versus "orientado a planos" é muito melhor, e eu li em várias fontes (embora não consiga citar nada) que ser ágil requer equipes dedicadas, conhecedoras e ainda mais experientes, ainda mais do que qualquer método baseado em plano. Quanto ao seu último parágrafo - esses ainda são quadros. Existem muitas estruturas orientadas a planos, mas nada que seja explícito em "this is {insert name here}" da mesma maneira que você pode dizer "this is Scrum" ou "this is Extreme Programming".
Thomas Owens
1
@ Thomashowens: Spiral é uma metodologia, não uma estrutura. Você pode ter uma idéia sobre o modelo em V. Talvez o Cap Gemini SDM seja um exemplo melhor, embora sempre pareça muito com o Spiral. en.wikipedia.org/wiki/System_Development_Methodology
pdr
1
O Spiral está muito mais próximo - define claramente as fases e alguns documentos (requisitos, configurações, planos de desenvolvimento, planos e procedimentos de teste) e resultados técnicos (protótipos, um produto final). Eu diria isso e o Cap Gemini SDM está muito mais próximo do que estou procurando (você poderia adicionar o SDM à sua postagem?). +1.
Thomas Owens
1
@ThomasOwens: Feito e substituído o modelo V.
quer