Gestão de projeto de software

Gestão de Projetos de Software
As Práticas Convencionais

Os métodos de Gestão de Projetos "tradicionais", como o PMI ou o Prince, estão relacionados ao processo de desenvolvimento de software chamado de Cascata. Esta relação, ainda que não seja obrigatória, é concreta, já que as práticas de um suportam as do outro.

Nesta abordagem, o desenvolvimento de software é tratado como uma sequência de atividades encadeadas, onde cada etapa fornece os insumos necessários para a próxima. Cada especialista é engajado no projeto em uma atividade específica e é , depois, liberado para outros projetos, deixando um artefato (um documento com características pré-definidos) que será utilizado pela próxima turma de especialistas.

Assim, Analistas de Requisitos, Arquitetos, Engenheiros, Programadores, Testadores e Documentadores não trabalham em uma equipe unificada, mas em sucessivas "ondas" de contribuição para o projeto, deixando o seu legado na forma de um artefato.

Esta abordagem é defendida em uma metáfora de linha de produção, onde o software é tratado como um produto resultante deste esforço, construído em uma "Fábrica de Software".

O aumento da capacidade de entrega é atingido pelo aumento dos recursos dedicados à cada etapa e a gestão através de métodos gerenciais tradicionais, geralmente de inspiração Taylorista (lembremos da metáfora da Fábrica).

Mesmo quando se utiliza o método unificado UP ou a sua versão comercial, o IRUP), a maioria das empresas despreza sua natureza iterativa e incremental para estruturar o projeto em poucas e longas iterações, tornando sua aplicação muito mais semelhante ao método cascata do que dos chamados métodos ágeis.

Notem que o próprio título do gráfico fala em ciclos iterativos, mas, de acordo com a minha experiência prática, são geralmente encarados como grandes fases de partes significativas do sistema.

Com esta abordagem contínua, as mudanças são tratadas como um problema. Para acompanhá-las, os projetos entram