Qual é a diferença essencial entre desenvolvimento ágil e desenvolvimento baseado em plano?

Os processos planejados e ágeis para software podem ser rapidamente caracterizados por alguns pares.

• Cascata vs. iterativa / incremental
• Watts Humphrey vs Kent Beck.
• Dirigido pelo gerenciamento x direcionado pela equipe.
• Manifesto SEI CMM vs. Agile.
• Projeto Microsoft vs. listas de gravação.
• Revisão interina xyz x reunião em pé de scrum.
• Lançamento anual versus versão diária.
• Inspeção de código vs. programação em par.
• Planejamento de horários vs. jogo de planejamento.
• Comitês vs. visionários.

De alguma forma, esta questão já foi respondida pelo Manifesto Ágil , mas em vez de ler da esquerda para a direita, leia da direita para a esquerda.

• Indivíduos e interações sobre processos e ferramentas
• Software de trabalho sobre documentação abrangente
• Colaboração do cliente sobre negociação de contratos
• Respondendo para mudar depois de um plano

Algumas das comparações acima podem ser um pouco severas, porque certamente há muito desenvolvimento orientado a recursos que são práticas planejadas, e os lançamentos podem ser trimestrais (mas provavelmente não mensalmente).

Os melhores pensadores por trás do processo planejado foram influenciados por problemas com abordagens ad-hoc ou inadequadas para softwares, como os descritos no Mythical Man-Month. Já em 1968, a OTAN tinha uma conferência sobre Engenharia de Software para tentar resolver a crise e nesse ponto. Eu acho que eles tiveram algumas grandes inovações. Página 12 de seu relatório da conferência tem um desenho notável que descreve a cachoeira, mas com curvas de caixas. Também inclui material sobre os desafios de estimar projetos de software. Mais tarde, especialistas planejados em processos de software emprestaram e roubaram de pioneiros da QA como Demming e muitos especialistas japoneses que provaram seu valor na fabricação de carros e eletrônicos.

Acho que os melhores pensadores ágeis estavam extremamente familiarizados com o processo planejado e reagiram contra suas limitações, mantendo alguns de seus pontos strongs. O processo planejado não perdeu toda a sua relevância, e alguns argumentam que é essencial para grandes projetos. O planejamento ainda é amplamente utilizado, principalmente em grandes organizações, mas muitos tentam se integrar com técnicas ágeis. Talvez as abordagens de design do System of Systems sejam planejadas, mas elas têm uma boa característica de criar equipes pequenas, o que é um local mais prático para agilidade. A Planned foi sensível à necessidade de alfaiataria local, mas esperava que fosse facilitada por reuniões e comitês.

Grandes referências sobre este tópico incluem livros, artigos e relatórios técnicos de Watts Humphries sobre a equipe organizacional, e processo de software pessoal. Compare as seções introdutórias de Kent Beck com eXtreme Programming Explained .

Um dos meus professores descreveu a história do desenvolvimento de software mais ou menos assim:

• 1970: Tools - uma explosão cambriana de sistemas operacionais, linguagens de programação e ferramentas evolução.
• 1980: Processo - não culpe as pessoas, culpe (e corrija) o processo.
• Década de 1990: pessoas - capacitar a tomada de decisões e as comunicações e interações entre as pessoas.

Teoricamente, o @JVXR está certo. Cachoeira significa que você obtém requisitos, planeja o trabalho, define o preço e o cronograma de entrega. No final, tudo vem junto, muitas vezes os requisitos foram errados ou alterados, o trabalho foi mais do que o esperado e se transforma em uma grande bola de lama. A Agile promete resolver todos os problemas da cascata fazendo pequenos trabalhos em resposta a mudanças de necessidades e aumentando o conhecimento, entregando regularmente algo que agrega valor ao cliente e parando quando o cliente decide que o trabalho é feito (na verdade - quando o dinheiro se esgote).

Os problemas das cascatas são bem conhecidos e documentados e, portanto, fáceis de sugerir soluções para. Agile tem seus problemas também, porém eles são menos conhecidos e ainda menos bem documentados - nós, como uma indústria, tentamos cascata e fracassamos miseravelmente. Agora estamos tentando Agile, e falhando (um pouco menos miserável, mas ainda falhando), e ninguém quer sugerir que não está funcionando até que eles possam ver / vender uma solução melhor.

Como resultado, para cada 100 casas de software, provavelmente há 200 processos 'ágeis' em uso (muitas lojas têm mais de uma equipe, e parte da agilidade é que uma equipe pode fazer do jeito que quiser. Talvez 10 esses processos são realmente ágeis, o resto é melhor descrito como cascata no arrasto (ou seja, cascata sem a documentação)

    

O desenvolvimento com base no plano se concentra na criação de um plano detalhado, enquanto o agile, ou com mais precisão, adia os planos detalhados até que o trabalho esteja prestes a começar e permita que a ordem ou a prioridade do trabalho seja alterada. Isso minimiza o impacto da mudança e significa que decisões (ou seja, planos) podem ser tomadas quando o maior conhecimento está disponível. Considerando que o desenvolvimento baseado em plano requer que o plano seja revisto quando ocorrem mudanças e requer que a maioria das decisões seja tomada antecipadamente quando a equipe sabe o mínimo sobre o problema e as soluções.

    

Por "Planejamento antigo", presumo que você esteja falando de queda d'água. Não há feedback do cliente até que o produto seja desenvolvido e entregue, e geralmente é quando o material atinge o ventilador no processo de cascata. A Waterfall depende muito de "requisitos de documentação" - que o cliente vai jurar que nunca disse nada desse tipo dentro de um mês.

No ágil, teoricamente você produz pequenos incrementos de trabalho e obtém o feedback do cliente e o incorpora no próximo lançamento. Assim, as chances de que as coisas batam no ventilador são reduzidas. Em geral, o cliente sente que está recebendo algo do que está lhe pagando.