Neste artigo vamos falar dos artefatos Incremento e Definição de Pronto, usados por Time Scrum para construção de software de qualidade e frequentemente.
A cada iteração de desenvolvimento o objetivo do time deve ser gerar um Incremento de software potencialmente entregável. Por potencialmente entregável entenda que o software desenvolvido tem plenas condições técnicas de ir para produção, mas que ainda pode ter seu deploy adiado em virtude de questões de mercado, de negócios, etc, cabendo ao Product Owner decidir por colocá-lo em produção ou não.
O Incremento é tratado no Scrum como um artefato gerado pelo Time de Desenvolvimento ao longo da sprint e ele deve ter passado por todas as etapas de desenvolvimento e validação necessárias para ser considerado como DONE (pronto). A esse checklist de etapas que o incremento deve passar chama-se de Definição de Pronto (Definition of Done no original, DoD).
A Definição de Pronto é um artefato do Scrum que reforça a transparência como pilar principal da metodologia uma vez que torna global entre os membros do time o que DONE significa. A DoD define um vocabulário comum, que indica que quando um item está DONE, ele de fato está pronto tecnicamente para ir para produção. Isso evita aquelas famigeradas discussões de “está pronto, só falta testar” ou “mas você me disse que estava pronto!!!”.
No vídeo abaixo, você aprende sobre este tópico também, caso prefira ao invés de ler.
Uma Definição de Pronto bem construída, que tenha envolvido o Time Scrum inteiro, engloba aspectos de construção, teste e homologação de cada item de backlog da sprint. Obviamente ela varia enormemente de um time para outro, uma vez que os aspectos técnicos de desenvolvimento e testes, além de fatores burocráticos inerentes a cada negócio distinguem as etapas de desenvolvimento de um produto para outro em diferentes empresas.
Um exemplo de Definição de Pronto pode ser vista abaixo:
- Codificado;
- Código Revisado (Code Review);
- Testes Unitários passando (Unit Tests);
- Testes Funcionais passando (manuais ou automatizados);
- Versionado (Git, por exemplo);
- Homologado (geralmente pelo Product Owner).
Conforme o time vai trabalhando junto, sprint após sprint, sua Definição de Pronto vai evoluir garantindo que a régua de qualidade do time seja tão alta quanto necessária e que o empirismo inerente aos ciclos de melhoria contínua contribuam para produzir software com cada vez mais qualidade.
Um engano comum, e que vale ser ressaltado aqui, é que muitos times acreditam que o Incremento, uma vez DONE, só pode ser implantado em produção ao término da sprint. Isso não é verdade.Times que tenham desenvolvido pipelines de deploy automatizados com Entrega Contínua (Continuous Delivery ou CD) podem e devem entregar software de qualidade sempre que possível para os clientes, exceto quando alguma questão estratégica disser o contrário. O que o Scrum prega ao dizer que a sprint termina com um Incremento de software potencialmente entregável é que, ao menos uma vez por Sprint, o trabalho do time deve poder ser colocado em produção, ao contrário do modelo Waterfall tradicional em que isso somente seria feito após o projeto ser concluído.
Práticas modernas de desenvolvimento de produtos como Lean Startup e Customer Development trabalham com a ideia de que quanto antes o Product Owner conseguir ter o produto em produção, para testar com clientes reais, antes a empresa irá descobrir o que de fato traz valor para o mercado e com isso realimentar o processo gerando um produto de sucesso.
Referências bibliográficas
Luiz Duarte. Agile Coaching: Um Guia Prático, LuizTools, 2019
Luiz Duarte. Scrum e Métodos Ágeis: Um Guia Prático, LuizTools, 2016
Schwaber, Ken e Sutherland, Jeff. O Guia do Scrum. O Guia Definitivo para o Scrum: As Regras do Jogo. 2020.