A abordagem ágil é algo similar que vem propor justamente uma maior interação entre TI e usuários ou entre cliente e fornecedor.

Muito louvável, mas esquecem-se dos conflitos resultantes desta tentativa de integração. E quando os conflitos surgem, a reação automática é “Tirar da reta” com pérolas como “Não foi isto que eu disse” ou então “vc entendeu tudo errado”. Formalizações e aprovações formais visam justamente reduzir este conflito.

Diz-se tambem que em TI, a equipe de projeto só descobre o que o usuário queria depois de entregar o que ele pediu. E o usuário só percebe o que ele realmente precisa depois de receber aquilo que ele queria. Enfim, há situações que um pouco mais de braimstorm e planejamento inicial pode-se economizar muito dinheiro mal gasto no futuro (esta é toda a tônica da técnica de Value Improvement Practice em gerenciamento de projetos).

Obviamente que há situações que não conseguimos um braimstorm eficiente no inicio e precisamos de ir definindo gradualmente o escopo detalhado ao longo do projeto. Neste contexto, pode-se usar a técnica de sprint, desde que bem gerenciado os conflitos comportamentais de algo “mal definido”. Deve-se também ficar de olho naqueles recursos e usuários que adoram discutir o sexo dos anjos, mas não chegam a lugar algum. A definição de um escopo inicial detalhado pode reduzir este tipo de risco.

Em projetos grandes ou que competem por recursos, a abordagem ágil também pode conter grandes perigos. Sem uma gestão centralizada, corre-se o risco de 2 projetos ou sub-projetos simultaneos atualizarem o mesmo artefato ou programa. Nestas situações de muitos projetos, é vital termos uma gestão de configuração muito forte e para tanto, a abordagem waterfall pode ser mais interessante, desde que possivel (pois há situações em que Waterfall se torna impraticavel)

E por fim, gostaria de chamar a atenção de que gestão agil não existe (na minha modesta opinião). O PMBoK deixa aberto para usar de mais ou menos formalidade dependendo do projeto. Como projeto lida com pessoas e culturas, não há 2 projetos identicos. Em um projeto, eu posso ter maior necessidade de formalização e em outro pode ser o oposto.

O que estamos na verdade discutindo é o ciclo do projeto (e não o ciclo do gerenciamento de projetos), que em TI chamamos de SDLC. Dentro do SDLC, temos sim 2 abordagens diferentes que são Waterfall e Iterativo. Portanto não é adequado (na minha opinião) falarmos de gerenciamento ágil. Afinal, cada gerente deve definir a regra do jogo que é mais adequado ao seu contexto. Mais ou menos formalismo.

A ideia de um gerenciamento agil com equipes auto-gerenciaveis se assemelha ao ideal defendido por Thomas Morus em seu livro Utopia (descrevendo uma perfeita sociedade socialista). Mas até termos empresas com altissma maturidade e pessoas sem motivações pessoais (apenas motivações do grupo), penso que a presença de um gerente formal é fundamental. E este gerente deve ter responsabilidade (ou seja, accountability) de gerente. Os motivos pessoais sempre existem na grande maioria das pessoas (já dizia Maslow) e portanto, tecnicas de resolução de conflitos é um MUST em qualquer projeto. Sem um responsável mior pelo projeto, como ficaria a gestão dos conflitos?

Ufa, este comentário foi longo. Está aberto a descontrução (rs…)