m 0cm 0pt">Um projeto de software está com sérios problemas e quando acordei percebi que não era um pesadelo. Peguei um livro e li: O mau gerenciamento pode incrementar os custos de um projeto de software mais rapidamente que qualquer outro fator, escreveu Barry Boehm em 1981. Temi pelo meu emprego e pensei: antes de desistir vou contratar muitos desenvolvedores. Peguei outro livro e li: Adicionar pessoas faz um atrasado projeto atrasar ainda mais, escreveu Frederick Brooks em 1995.
Neste cenário assustador questionei-me: o que vou fazer diferente se preciso de resultados diferentes? Como compreender os verdadeiros obstáculos do gerenciamento de um projeto de software?
Procurei por muitos caminhos, mas a resposta que mais gostei me foi ensinada pelos métodos ágeis. Entre muitos aprendizados que tive li que o pensamento ágil reconhece cinco obstáculos no gerenciamento de projetos de software. São eles: pessoas, tempo, funcionalidades, orçamento e recursos (excluindo pessoas). Com isto em mente, coloquei em prática um pouco de quatro propostas ágeis que estudei.
Vamos conhecer um pouco destas propostas ágeis. São elas XP, MSF, SCRUM e FDD. Nesta primeira parte do artigo conheceremos XP e FDD.
Extreme Programming
Métodos ágeis são propostas incomuns de técnicas para projetos de software. XP, como o nome sugere, é algo um pouco mais radical. Propostas estranhas de técnicas esquisitas fazem os gerentes de projetos temerem utilizá-las em grandes projetos. Para atrapalhar ainda mais as poucas iniciativas de se quebrar paradigmas, o radicalismo de alguns pensadores de XP afastam a compreensão sobre as reais vantagens e os benefícios para o negócio que podemos alcançar com estes métodos.
A programação em pares, um dos mais diferentes e originais métodos do XP, traz para o gerente do projeto a necessidade de uma posição sem hipocrisia. Ou você ama, ou você odeia. Até hoje não encontrei um gestor “em cima do muro” sobre esta técnica.
Como exemplo, vamos citar Karl Wiegers, famoso autor de livros técnicos, que afirma em seus ensinamentos que a programação em pares como forma de inspecionar código não é efetiva na redução dos defeitos. Segundo o mesmo, entre 25 % e 35 % é o ganho atingido no aspecto “defect reduction”. Esta afirmativa é questionada por David Anderson, outro grandioso autor, que defende um número percentual em torno de 50%.
...
