Processos tradicionais de desenvolvimento de software: Pense antes de construir, escreva tudo, siga o plano, e mantenha tudo tão organizado quanto for possível. Isso funciona?

Problemas:
As boas idéias têm que surgir no início do ciclo de desenvolvimento, mas, freqüentemente, elas surgem espontaneamente durante o processo e quando surgem do meio para o fim do ciclo de desenvolvimento não ajudam, elas são consideradas ameaças.
Um documento detalhando uma idéia é uma abstração dessa idéia. Quem lê esse documento cria mais uma abstração em sua cabeça, afastando-se ainda mais da idéia original.
Quando se inicia o uso do novo software sempre surgem novas idéias de como as coisas poderiam ser feitas de maneiras melhores.
Os humanos também são muito ruins em prever o futuro. Quando um concorrente lançar alguma coisa melhor do que está sendo desenvolvido, pode ser tarde para qualquer mudança para combatê-los.
O processo tradicional não é divertido. Pessoas não são robôs e processos que requerem que elas ajam como um fazem as pessoas infelizes.
Como são resistentes a mudanças, normalmente resultam em produtos medíocres que, no máximo, são tão bons quanto as idéias iniciais ao invés de serem o melhor possível com as idéias surgidas durante o processo quando o time conhece melhor as possibilidades.

Solução (?):
Processos ágeis:
Apenas faça acontecer.
Construa software que funcione o mais rápido possível e deixe as pessoas usarem. Use times pequenos e multifuncionais e com total autonomia para decisões.
Use ciclos rápidos de desenvolvimento com total envolvimento dos usuários.
Scrum
É um framework usado para organizar times para realizar um trabalho com produtividade e melhor qualidade. Permite que o time escolha a quantidade de trabalho a ser feito e qual o melhor jeito de fazê-lo, criando um ambiente de trabalho mais produtivo e divertido. Foca em priorizar o trabalho de acordo com valor para o negócio, melhorando a utilidade do que é entregue e a satisfação do usuário.
O Scrum tem três papeis, três cerimônias e três artefatos projetados para entregar software funcionando em repetidos períodos curtos de trabalho intenso (sprints):
Papeis: Dono do produto (Product Owner), Mestre Scrum (ScrumMaster) e Time.
Cerimônias: Planejamento de cada periodo (Sprint Planning), Revisão do período recém finalizado (Sprint Review) e Reuniões diárias (Daily Scrum Meeting)
Artefatos: Funcionalidades do produto (Product Backlog), Funcionalidades do período (Sprint Backlog), Gráfico de acompanhamento do período (Burndown Chart)
Product Owner:
É o responsável por definir as funcionalidades do produto e priorizá-las de acordo com o melhor valor para os usuários. Também pode ser a pessoa que centraliza as demandas de um grupo de clientes. Ele precisa possuir a visão do produto e o plano de negócios. Deve planejar as datas de entrega que atendam as expectativas dos negócios e quais funcionalidades são esperadas. É a pessoa que aceita ou não o resultado dos trabalhos de um Sprint.
ScrumMaster:
É o facilitador. Ele deve remover as barreiras que impedem que o time funcione e seja produtivo. Deve proteger o time de interferências externas e garantir que o processo seja seguido organizando todas as cerimônias. Não é o gerente do time nem é a pessoa que atribui tarefas aos integrantes.
Time:
Grupo multifuncional que implementará as funcionalidades definidas para o Sprint. Pode ter de 5 a 9 pessoas com diferentes especialidades necessárias para os trabalhos definidos para o Sprint. São os integrantes do time que escolhem quais tarefas vão realizar e qual o resultado esperado para o Sprint. Deve se auto organizar e apresentar software funcionando para o Product Onwer.
Product Backlog
Lista todas as funcionalidades desejadas do produto e todas as necessidades técnicas que surgiram durante os vários Sprints. Essas funcionalidades devem ser priorizadas de acordo com critérios de importância do usuário e também critérios técnicos. É dessa lista que são escolhidas as funcionalidades a serem implementadas nos vários Sprints.
Sprint Backlog
Lista todas as tarefas que devem ser executadas no sprint corrente. Os integrantes do time escolhem quais tarefas vão executar e em quanto tempo. Essa lista possui itens do Product Backlog e também itens técnicos que o time necessita para completar as funcionalidades.
Burndown Chart
Gráfico onde e plotado o tempo gasto até o momento e quanto falta para o final do sprint ressaltando se o time está atrasado ou adiantando em relação ao planejado.
Sprint Planning
É a reunião que acontece antes de iniciar um Sprint onde é elaborado o plano para a interação. O Product Owner revê a visão, o roadmap, o plano de releases e o product backlog com o time. O time faz ou ajusta as estimativas para as funcionalidades listadas no Product Backlog e, de acordo com o tamanho do time, o tempo total de trabalho disponível e a produtividade, escolhe os itens que podem ser finalizados no periodo do sprint.
Feito isso, o ScrumMaster lidera o time em uma sessão de planejamento onde todo o trabalho é dividido em tarefas gerando o Sprint Backlog. As tarefas não devem levar mais que 16 horas de trabalhos para serem finalizadas.
Esse planejamento deve ser comparado com o tempo estimado anteriormente e com as funcionalidades desejadas. Ele pode ser refeito de modo que seja possível entregar código funcional no final do sprint.
Daily Scrum meeting
É uma reunião diária de 15 minutos com todos os participantes em pé (stand-up meeting) onde somente as pessoas que tem tarefas devem responder a três perguntas: O que foi feito ontem?, o que vai ser feito hoje?, e quais impedimentos estão no caminho? O ScrumMaster é responsável por plotar essas informações na lista de tarefas e atualizar o Burndown Chart. Ele também deve resolver os impedimentos e dependências. Se houver problemas de ordem pessoal, o ScrumMaster deve endereçá-las com o RH ou discuti-las com os membros do time envolvidos.
Nessa reunião também podem surgir novas tarefas descobertas durante os trabalhos do dia anterior e revisão nas estimativas de tempo para tarefas existentes. O Sprint Backlog deve ser atualizado e uma analise deve ser feita quanto aos impactos no resultado final esperado para o Sprint.
Sprint Review Meeting
É a reunião realizada ao final do Sprint onde o software funcional é exibido para o Product Owner. Ele decide quais funcionalidades do Product Backlog foram completadas. O objetivo para o próximo sprint é definido nesse encontro onde podem participar todos os interessados no produto.
Numa segunda parte da reunião são discutidos problemas (e suas  possíveis soluções) encontrados durante o sprint que se encerrou.

O ciclo se repete até que todas as funcionalidades do Product Backlog tenham sido implementadas ou até que o Product Owner decida que o que já está entregue satisfaz o negócio.