Hoje terminamos nosso quarto sprint. Foram duas semanas intensas e estamos bem satisfeitos com o resultado: não só a nossa velocidade (a referência de execução que o Scrum usa) aumentou significativamente (e ultrapassou as expectativas), como ainda tivemos tempo de experimentar com uma série de técnicas que tínhamos vontade de usar e estabelecemos vários utilitários para o time que ajudaram e vão ajudar ainda mais nos próximos sprints.
Nesse sprint decidimos usar pair-programming e ver qual a diferença isso fazia em nosso processo de desenvolvimento. Não só registramos um aumento de produtividade enorme como a qualidade do código gerado deu um salto impressionante. Um dos pontos fortes do Scrum são as medições realizadas que levam ao gerenciamento de expectativas proposto por metodologias ágeis.
O mais interessante, porém, foi constatar que a velocidade dos times é relativamente constante em relação aos outros, o que indica que pair-programming é uma técnica bem eficiente de disseminação de conhecimento. Como ainda tínhamos pessoas com um contato relativamente recente com Rails, eu acho que esse foi um dos principais fatores para que a equipe pudesse chegar a um ponto de familiarização rápida com a tecnologia sem onerar o desenvolvimento.
O melhor de tudo foi constatar que nenhum dos nossos temores em relação a tempo ou pressão se concretizou. Isso, pelo menos para mim, representa um dos maiores ganhos do processo: conseguir precisar entregas realísticas e cumprir essas estimativas. Que jogue a primeira pedra quem nunca reclamou de gerentes que passam prazos fora da realidade e que depois sofreu com a queda de qualidade. Combinar prazos satisfatórios a todas as partes e ainda conseguir qualidade é algo que nenhum outro tipo de processo exceto os ágeis é capaz de dar.
Obviamente, isso não implica que eu acho o Scrum perfeito. Há algumas coisas, que eu quero explorar aqui no futuro, que me incomodam. Apesar disso, a experiência tem sido bem interessante. E que venha mais um sprint.
Parabens pela iniciativa de postar o sprint. Espero ler no futuro suas criticas ao Scrum.
See ya.
Combinar prazos satisfatórios a todas as partes e ainda conseguir qualidade é algo que nenhum outro tipo de processo exceto os ágeis é capaz de dar.
Ah é? Então como vc me explica o profissional que desmereceu minha abordagem ágil para o cliente, argumentando que para ter esse tipo de benefício basta “melhoras pontuais no modelo _waterfall_”?
E só para constar, ele usou Pareto no argumento. Pareto.