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.