Esses dias estava assistindo o vídeo do debate sobre metodologias ágeis na TDC, onde o principal tópico foi a já conhecida discussão sobre metodologias ágeis X CMMi.

Não quero entrar em detalhes aqui sobre o debate, até porque quem estiver curiosidade pode ver o vídeo, que foi bem interessante, mas sim queria dar minho opinião sobre um ponto de vista que é pouco abordado nessas discussões, que é a utilização de certificaçoes em geral.

O principal ponto em qualquer processo ou metodologia , na minha opinião, é a capacidade que é dada para a equipe de constantemente melhorar o seu desempenho, e isso é um aspecto extremamente importante nas metodologias ágeis, já que um ambiente de melhoria constante é possibilitado devido ao constante feedback recebido (do cliente, da própria equipe, etc.. ).

E o que isso tem a ver com certificações?

Bom, certificações, como o próprio nome diz, certificam que uma equipe segue algum padrão. Elas requerem evidências de que o time está constantemente seguindo certas práticas, e com essa exigência, elas acabam com as possibilidades de inovação de qualquer equipe.

Quero deixar claro que não estou falando só de CMMi ou qualquer outra certificação tradicional, mas sim de qualquer certificação, inclusive idéias de certificações ágeis que vem surgindo. E se a equipe não quiser estimar mais? E se não quiser escrever estórias em cartões?

Um exemplo prático disso está acontecendo em um projeto da ThoughtWorks UK, onde o cliente decidiu que algumas funcionalidades sendo desenvolvidas deveriam ser colocadas em produção sem testes de aceitação, para se obter um feedback rápido do público e depois então testá-las caso fossem aceitas.

Como ficaria essa situação se a equipe fosse certificada em “Agile nível 5″ , onde 100% do código deve ser testado? Certamente o cliente seria prejudicado por regras impostas por alguma organização que quer especificar como desenvolvemos software.

Finalizando, eu também entendo o outro lado da moeda, onde certificações são exigidas por empresas e governos para se poder vender projetos. Acho que nesse caso, a opção é de cada equipe, mas deve-se saber que aceitando-se isso, se estará comprometendo a capacidade de se entregar software.

Um abraco,

Francisco

Sobre o autor:

Francisco Trindade