Quando eXtreme Programming (XP) foi apresentado ao mundo, uma série de práticas foram propostas para aplicabilidade dos valores e princípios básicos por trás desta metodologia ágil.
Algumas práticas são muito consolidadas na cultura de empresas, tais como entrega frequente de software funcionando (me corrijam, se estou errado, mas nunca vi ninguém defendendo entregas menos frequentes, nem mesmo em times e organizações com cultura waterfall).
Outras práticas, no entanto, ainda encontram obstáculos para se tornarem definitivas em times que almejam se tornar verdadeiramente ágeis. Em minha trajetória, observei duas práticas muito negligenciadas (por mim inclusive): Pair Programming (PP) e Test-Driven Development (TDD).
As justificativas para deixar essas duas práticas de lado apontam sempre para uma dimensão: tempo.
Muitas pessoas acreditam que Agilidade implica em Correria, levando a crer que, deixando pair-programming e TDD de lado, poderão produzir mais, em menos tempo. Após uma breve análise, encontrei nos princípios do Manifesto Ágil uma possível causa desta deturpação:
"Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos"
"Frequência" não significa "Intensidade"! Abrindo mão de PP e TDD, é possível, mas pouco provável, que você possa entregar mais, porém deixará de lado a qualidade - um dos princípios de XP - e tem como risco não ter um software funcionando (você já leu o Manifesto Ágil e seus princípios? Pois deveria).
Deve-se entregar, com frequência, software funcionando e de alta qualidade, e o tempo consumido em atividades de Pair-Programming e TDD sobre o trabalho como um todo é irrelevante, do ponto de vista ágil.
Se ainda assim, houver obstáculos com tempo (ex: prazos impostos por clientes), negocie o escopo do trabalho. No fim, um trabalho de qualidade, mesmo que com escopo reduzido, terá muito mais valor que um trabalho com escopo mais amplo, mas de menos qualidade.
Muito bom!
ResponderExcluir