Definition of Done (DoD) é uma expressão que muitos que já estiveram envolvidos em projetos Agile reconhecem. Mas afinal o que é e para que serve?

DoD é na realidade uma checklist definida pela equipa de projeto, onde são descritas todas as tarefas necessárias para que uma story (desenvolvimento) seja concluído. Em metodologias Agile obtém-se progresso através de iterações, também chamadas de sprints se estivermos a falar de scrum. Em cada iteração a equipa executa blocos de trabalho ou stories que vão contribuir para a conclusão do projeto (caso se trate de um projeto). Dependendo da metodologia que a equipa estiver a utilizar, poderá estar a registar as atividades num quadro Kanban para que todo o fluxo de trabalho seja mais visual. O Kanban tanto pode ser virtual como físico, ambos funcionam, mas o virtual torna a partilha de informação entre várias equipas mais simples, principalmente se estiverem colocadas em localizações físicas diferentes. Os quadros kanban estão sempre divididos em fluxos de trabalho, que representam todos os estágios que um desenvolvimento tem que ultrapassar até ser dado como concluído. Uma divisão muito simples que normalmente se vê muito é: Por Realizar, Em Curso e Concluído. Esta é a divisão mais simples, sendo que na maioria das empresas acabará por ser um pouco mais complexo, como por exemplo: Backlog, Em Análise, Pronto para desenvolvimento, Em Desenvolvimento, Pronto para testes, Em testes e Concluído.

É justamente na passagem de um desenvolvimento para concluído que uma DoD deverá entrar. Algo que normalmente acontece nas empresas é dar-se uma story como concluída após o seu desenvolvimento ter terminado. Acontece que após o desenvolvimento ter terminado, existem ainda um conjunto de atividades que devem ser asseguradas para que a story se considere bem feita. Dou vários exemplos, a story foi documentada? A story foi testada de uma forma integrada e não apenas unitariamente? Foi realizada uma análise ao código por um colega? Como podem ver, existem muitas atividades que à primeira vista são invisíveis, mas que têm que ser realizadas, o que resulta claro em menos tempo da equipa para a execução de outras tarefas.

Uma DoD correta permite ainda aumentar a qualidade do trabalho entregue, já que cada desenvolvimento deve passar por todas as fases descritas pela equipa até que seja considerada concluída. Para além da qualidade, dá também consistência a todo o trabalho e reduz em muito o rework. Pegando nos exemplos que te dei acima, deixo-te abaixo o que poderia ser uma DoD definida pela equipa:

• Peer review ao código realizada?
• Código testado unitariamente?
• Código testado de forma integrada em ambiente de desenvolvimento?
• Documentação técnica realizada?
• UX (user interface & experience) consistente com solução global?

Quero só deixar a nota que uma DoD nada tem que ver com critérios de aceitação. Muitas vezes existe esta confusão, mas a grande diferença reside no facto dos critérios de aceitação se focarem mais na funcionalidade em si e não na qualidade do processo. Se olharem com atenção para os items que vos mostrei acima, estão mais relacionados com o facto de estarmos ou não a seguir um bom processo de desenvolvimento, testes e documentação, o que se vai refletir claro em aumento de qualidade. Já os critérios de aceitação visam definir se a funcionalidade que foi realizada faz aquilo que é suposto fazer e que foi solicitado pelo cliente. 

Uma DoD deve estar bem visível para todos os membros da equipa, para que quando chegue a altura de dar uma story como concluída se faça uma revisão se todos os pontos são cumpridos. Deixo apenas o alerta para não teres demasiados pontos, é suposto uma metodologia ágil ser...ágil, portanto nada de adicionar demasiada burocracia ao processo. Recomendo que sempre que a equipa faça retrospetivas (analisar a forma como trabalha para melhorar), que se foque também na dimensão da DoD. Devem analisar se todos os items fazem ou não sentido e se é ou não necessário remover ou adicionar novos.

Por hoje é tudo, tens dúvidas sobre algo que escrevi? Fala comigo sem problemas, podes responder a este artigo ou contactar-me diretamente via email.

Até à próxima!