Adoção de Scrum

Comments
ddd scrum tdd
23 July 2008

Estamos no atual projeto desde fevereiro, trabalhando em modelo cascata dos brabos. Como era de se esperar tivemos todas as terríveis experiências que esse modelo pode proporcionar:

  • Inexistência da participação do cliente
  • Atraso nas entregas
  • Entregas que não atendem o objetivo do cliente
  • Foco em documentação que fica desatualizada, ou seja, inútil
  • Não cumprimento dos objetivos de ROI
  • Bugs
  • Retrabalho

Enfim... fins de semanas perdidos...

Ta certo que quando iniciamos o projeto nós e o cliente já tinhamos o sentimento de que não iamos concluir tudo no prazo estipulado, mas havia a esperança otimista (falsa, no caso do modelo cascata) de que podiamos superar as expectativas.

Fazem uns 3 meses que eu venho lendo bastante a respeito de agilidade no GUJ e blogs do pessoal de lá e chegou a hora de mudar.

No último sábado participei do Workshop de SCRUM com o Rodrigo. Pouca coisa quanto a teoria (que eu já havia estudado exaustivamente) foi acrescentado, mas MUITO foi agregado nas experiências e na forma de tocar um projeto com SCRUM.

Muito bem. Essa semana eu e o André (GP do projeto) fizemos um workshop de dois dias com toda a equipe e o cliente a fim de mudar radicalmente nossa forma de trabalho. Desde o processo (vamos utilizar SCRUM junto com Team System) até modelagem saindo de um modelo anêmico e com processo de qualidade artesanal para algo próximo de DDD com TDD. Uma revolução para equipe e para o cliente!

O resultado dos dois dias foi: 90% da equipe super entusiasmada com todas as idéias e com o horizonte de ter uma boa parte das funcionalidades entregues dentro de um prazo aceitável. O cliente gostou bastante do processo também, mas ainda tem a falsa percepção de que um projeto sem um calhamaço de documentos não é legal. Conversamos bastante e nesse ponto fizemos um acordo em busca do meio termo. Vamos fazer a documentação que o cliente achar que devemos fazer. Não vamos estipular uma regra-de-prata, mas sim definir durante os sprints o que será mantido como documentação ativa no projeto.

Uma das coisas que particularmente me atrai no SCRUM é o fato do cliente priorizar o que vai ser feito então se ele quiser MUITA documentação vai acabar recebendo poucas histórias implementadas.

Acredito que conforme os sprints forem correndo e o cliente pegar mais segurança com relação a qualidade do trabalho essa noção de documentação melhore e nossa vida venha a ficar mais fácil nesse aspecto.

Conforme conselho do Rodrigo para iniciar com o uso de SCRUM, marcamos nossa primeira reunião de planning e vamos começar a utilizar o processo. Tenho bastante esperança de que o sucesso vai vir, mas tenho consciência de que não virá de uma hora pra outra.

Nesse momento principais pontos que temos a vencer são os débitos ténicos. O projeto depende de algumas integrações que estão meio capengas e os builds são bastante complicados por enquanto. Outro ponto é que o SCRUM é fortemente baseado em modelagem e reuniões com o uso de papel e lousa. O problema é que não temos espaço disponível pra fazer o "deploy" desses objetos (a lousa principalmente) e nem reuniões com a equipe inteira então vamos ter que nos virar com as abstrações dos post-its que o Team System consegue nos fornecer e um espaço meio apertado pra equipe toda. A última fatia que temos que adaptar é o fato de termos diversos casos de uso e a resistência do cliente em transformá-los em histórias. Sendo assim, vamos ter que improvisar a manter a referência das histórias aos casos de uso.

Acho que após superarmos esses aspectos tudo deve decolar! Mesmo que não decole como um foguetão turbinado, só o fato de melhorarmos a modelagem, introduzirmos testes e trabalhar iterativamente já vai nos trazer ganhos.

Conforme formos avançando (ou não) vou postando a respeito da experiência.


<< O papel do Arquiteto...
Scrum Planning!>> 
comments powered by Disqus
tucaz

tucaz

.NET Software Developer
About
All Posts
RSS
@tucaz
GitHub