ajudando a vencer os desafios do gerenciamento de projetos

Sempre escutei que metodologias ágeis — na época essa palavra era a mesma coisa que dizer XP — serviam para pequenos projetos onde todos estivem no mesmo ambiente físico. Dois excelentes artigos da SearchSoftwareQuality deram uma sacudida no paradigma de pequenos projetos.

A grande frase do Scott Amber no artigo é que problemas com grandes times não é da metodologia ágil mas da própria natureza de ter várias pessoas trabalhando no mesmo projeto: ‘How does software development scale in general?’ Traditional development doesn’t scale very well anyway; you hear all the time of large projects that were cancelled or delayed. Scaling is independent of methodology”.

Sendo assim, a dúvida é qual dos métodos é o mais adequado para lidar com times de grande escala. O autor do artigo, Colleen Frye, questiona Damon Poole sobre o tema. O fundador e CTO da AccuRev Incc diz acreditar na solução ágil como a melhor, mas deixa uma dúvida no ar.

Does Poole believe agile scales better than traditional methodology? “Absolutely.” However, he added, “There’s a question of proven scalability. There are fewer proof points of agile scalability; that’s just the way it is because there are fewer large projects. But look at the algorithm of agile development. There’s more in it that allows you to scale.”

De qualquer forma, a dica principal para trabalhar com muita gente utilizando agile é componentizar o trabalho, criando sub-times. Aplicamos as técnicas ágeis tradicionais em cada time, adotando instrumentos específicos para integrar engenharia e gestão ao nível global do projeto. Vejam:

At IBM, Ambler said there are other agile projects on the order of 500 to 600 people. To manage large teams, both Ambler and Poole agree the project needs to be broken down into smaller components and sub-teams. “There’s no magic to this,” Ambler said. “The architecture should be a system of subsystems.”

A visão de grandes projetos de software como problemáticos por natureza considero uma verdade, confesso que o me incomoda é a aceitação que times virtuais são uma má idéia e pronto. Naturalmente é melhor ter todos na mesma sala, mas muitas vezes este cenário não é controlado, a distribuição geográfica é uma restrição do projeto. Estou na torcida por uma proposta matadora para o desenvolvimento ágil com times distribuídos, quem sabe alguém aí tem uma sugestão.

Leiam os artigos em Agile development: It isn’t just for small projects e Suggestions for scaling agile.

Bom fim-de-semana à todos.

Tagged as: ágil, desenvolvimento de software, processo

{ 0 comments }