Qcon 2008: Coaching and Scaling Agility

Primeiro relato sobre o Qcon 2008.

Apresentação muito boa de David Hussman pensando já além de como os agilistas normalmente encaram as discussões de processo. Na realidade o que ele disse no início e depois reforçou no final é que é preciso mover o pensamento do como seguir o processo para o porquê seguir o processo. Essa é a maneira sustentável de fazer as pessoas encararem as responsabilidades delas no desenvolvimento, e terem autonomia. Na realidade acho que a visão do porquê ao invés de só o como, deveria servir para todos os processos e boas práticas. Realmente há coisas que são passadas em treinamentos e conferências, e até mesmo praticadas dentro da empresa que não tem razão de ser, ou já tiveram razão de ser algum dia, mas como alguma outra evolui, o procedimento sendo executado se tornou obsoleto. Indo mais além, tudo na vida que é hábito deveria ser entendido o motivo e não só a realização. Tenho impressão que é essa a linha que as escolas construtivistas seguem.  

Em seguida, ele disse para primeiro praticar os métodos ágeis e depois deixá-las em improvisação. A minha visão disso é que cada cultura e contexto tem seu modo de encaixar e premiar as pessoas. Pode ser ruim improvisar inicialmente em um projeto que custe 1 milhão de reias e que esteja sendo esperado para ganhar 4 milhões por ano. Dificilmente uma consultoria terá como bancar isso perante a direção da empresa. Não é só uma questão de ser conservador ou não, é que infelizmente os métodos ágeis não tem como mostrar antecipadamente o resultado de ganho de eficiência na entrega. Todo mundo que participa de desenvolvimento, sabe que não há tubo de ensaio para isso. O que se vê é que as pessoas entregam mais próximas da data combinada um código melhor testado, mas para isso acontecer, os ciclos de entrega têm de ser pequenos, seguindo plan-do-check-act.     

Desenvolvedores, negócio e testes devem trabalhar juntos. Sim, isso é muito importante. Mas acho que ele poderia ter detalhado melhor o que é trabalhar juntos aqui. Embora eu desconfie de como e porquê isso deve acontecer, muitas vezes converso que ainda não praticaram processos ágeis e elas confundem de como os intergrantes do time, área de negócios e testadores têm de trabalhar a favor do desenvolvimento de software.

Segue o site da empresa em que David Hussman trabalha: www.devjam.com .