Muito tem se discutido sobre a melhor forma de aplicar Scrum em uma empresa. Por não ser uma metodologia prescritiva, definir uma "receita para o sucesso" com Scrum é algo um tanto quanto irônico. O que é feito geralmente é mostar as boas práticas baseadas em fatos e então sugerir caminhos que estão mais propícios a atingir o sucesso.
Uma das boas prática ao se utilizar Scrum é possuir uma definição de pronto - Definition of Done (DoD) - sólida e madura para as tarefas ou as histórias do seu Sprint. Tenha em mente que uma má DoD pode comprometer o futuro do projeto, visto que o seu objetivo é entregar software de qualidade. Mas quando sei que a funcionalidade está pronta? Pronto significa em produção? Rodrigo Yoshima recentemente publicou em seu blog um artigo sobre a definição de pronto onde ele diz:
Definição de pronto é uma premissa que visa garantir que o que está sendo entregue REALMENTE atende as necessidades do projeto, do cliente ou do mercado, levando em consideração as limitações da tecnologia. A Definição de Pronto tem relação com a qualidade, a manutenção futura do sistema e os objetivos do produto.
A definição de pronto é expressada através de critérios, isso é, temos etapas até que uma funcionalidade seja considerada pronta, essas etapas variam de projeto para projeto e geralmente são definidas no seu ínicio. Definir tais critérios não é uma tarefa fácil e deve ser uma concessão entre Product Owner, time e Scrum Master. Guilherme Chapiewski tem uma definição de pronto com os seguintes critérios:
- Desenvolver a funcionalidade
- Testar unitariamente (melhor ainda se for fazendo TDD)
- Testar a integração com outros componentes (quando for o caso)
- Verificar se o build do projeto funciona sem erros e fazer o deploy em uma ambiente de produção simulado
- Testar segundo os critérios de aceitação estabelecidos pelo cliente
- Depois dos testes desenvolvidos e a nova funcionalidade passando em todos eles, avaliar a necessidade de fazer refactoring no novo código
- Com a entrada da nova funcionalidade, avaliar a necessidade de fazer refactoring em algum módulo do sistema
- Atualizar a documentação (quando necessário)
Lembrando que isso é um case onde os critérios de pronto obtiveram sucesso. Esses critérios não dizem que se você os seguir terá sucesso em seu projeto e por muitas vezes pode não ser o adequado. Ao definir critérios para o pronto lembre-se do que a própria Scrum Alliance diz sobre a definição de pronto:
Foque em critérios que adicionem valor para o cliente. Faça com que o time veja o que realmente é necessário evitando perda de tempo e atividades desnecessárias que apenas complicariam o desenvolvimento do projeto.
Recentemente iniciou uma discussão na lista scrum-brasil sobre quais são os critérios para se criar uma DoD sólida e se essa definição pode variar conforme a equipe vai ganhando maturidade. Muitos participantes estavam questionando que esses critérios dependem da maturidade da equipe, o que significa que tais critérios sofrerão mudanças no decorrer do projeto visto que a equipe vai aprendendo e aperfeiçoando sua definição de pronto de acordo com as características do projeto. Yoshima discorda e alerta sobre o fato:
Logicamente o DoD pode variar de projeto para projeto, mas não tem relação alguma com a maturidade da equipe. Se a equipe não consegue atender ao critério definido afrouxar o critério pode ter consequências desastrosas.
Concordando em partes com que Yoshima disse, a Scrum Alliance define 5 características para uma boa DoD, uma dessas caracteristicas diz que a definição não é estática:
A DoD muda ao longo do tempo. Amadurecimento organizacional e a habilidade do time de resolver impedimentos podem fazer com que alguns itens sejam acrescenteados.
Então quer dizer que eu não posso modificar minha definição de pronto? Não, você pode mudar, mas tenha certeza que irá sofrer com algumas consequências. Rodrigo Yoshima cita exemplos de como uma má definição de pronto pode causar consequências ruins ao longo do projeto. Entender o que é pronto não é apenas definir etapas para que uma funcionalidade seja considerada finalizada. Definir pronto é entender as reais necessidades do seu cliente, a curto e longo prazo e chegar a critérios que assegurarão que sua funcionalidade irá agregrar valor para o cliente através da entrega de um software de qualidade.
Para muitos desenvolvedores pronto significa em produção, após ler esse artigo você ainda acha isso?