Imagine o seguinte cenário: seu time recebeu uma demanda para desenvolver e entregar em 15 dias.
A equipe analisou, refinou e detalhou o item de trabalho, estabeleceu condições para aceitar o trabalho e então começou a desenvolver.
Ao concluir o desenvolvimento informou para o cliente:
“Está concluído o trabalho, terminamos o desenvolvimento.”
E o cliente então diz:
“A demanda está desenvolvida, mas o trabalho não está concluído. Entendo que deveria estar em produção e com roll out para todas as filiais da empresa”.
O combinado não sai caro. A ausência do combinado sai muito caro.
Definition of Done (DoD) – A importância do item Done no Scrum
Em times que rodam Scrum como framework para desenvolvimento existe um rito chamado Sprint Planning.
Nesse rito espera-se que o Product Owner (PO) – em times que possuem este papel – forneça o escopo que será produzido no Sprint.
Esse escopo deve ser uma “fatia” do Backlog do Produto (Product Backlog) com itens detalhados, priorizados e “preparados o suficiente” para o Dev Team (Devs de um time Scrum) desenvolvê-los.
Cada item de backlog que o PO vai incluir para o time para planejar o trabalho do sprint precisa estar “Ready To Dev” (pronto para ser desenvolvido). Aqui estamos falando da Definition of Ready, que você pode ver mais neste post.
Uma vez que o time aceitou o trabalho a realizar no Sprint, deve haver um “contrato” entre o time para que um item seja dado como Pronto.
Aqui entra a DoD.
A Definition of Done (DoD) é um conjunto de “combinados” entre o Scrum Team (PO + Devs + SM) que cada item de backlog que é produzido no Sprint Planning deve atender para ser dado como pronto (serviço concluído).
Os itens de backlog que atendam a DoD são itens Done.
É comum dizer que “item que entra Ready no sprint sai item Done”.
Mas pouco adianta ter uma boa DoR, apenas itens Ready entrarem no Sprint para construção mas não haver uma boa DoD, pois o Sprint tem como meta entregar software executável ao seu final.
Importante lembrar que entregar software executável não deve ser a melhor medida de sucesso do time. O software executável entregue deve ser alavanca de valor na mão de quem for utilizá-lo. Não adianta entregar em produção um requisito ou feature que não gera valor, isso é desperdício.
É como começar um trabalho e não terminar, mesmo achando que acabou.
DoD por Produto, Item de Backlog, Sprint, Time ou Projeto?
A Definition of Done (DoD) é um check que cada item produzido do backlog do sprint vai passar por ele, para garantir que está no nível que precisa para ser dado como concluído.
Muitos profissionais ficam na dúvida se a DoD deve ser por Produto, Item de Backlog, Sprint, Time ou Projeto.
É mais o menos o seguinte:
- Por Produto: para o Produto A tem uma DoD e para o produto B tem outra DoD.
- Por Item de Backlog: para a User Story X tem uma DoD e para a User Story Y tem outra DoD.
- Por Sprint: para o Sprint 1 tem uma DoD e para o Sprint 2 outra DoD.
- Ou todas essas variações combinadas.
Cada cenário é cada cenário, mas eu acho melhor assim:
- Uma DoD por time, que deve ser reavaliada Sprint a Sprint (melhoria contínua), e no detalhe dela colocamos especificidades por tecnologia, tipo de item de backlog etc. se for necessário.
Exemplos de Definition of Done (DoD)
Vejamos dois exemplos de DoD, em dois contextos diferentes.
Cenário 1 – Time Web de E-Commerce
- User Stories de interface gráfica devem possuir Testes de UI automatizados para 100% dos fluxos principais.
- User Stories de back end com escopo de integração devem possuir testes de integração automatizados em todos os métodos da API.
- Itens do tipo User Story, Débito Técnico ou Habilitador Técnico devem estar implantados no ambiente de produção (mesmo com feature toogle = desligado).
- Itens do tipo Bug devem estar implantados no ambiente de produção e as evidências dos testes devem estar anexadas na ferramenta de ALM.
- Itens do tipo Spike devem ser dados como concluído pelo Dev responsável, que deverá apresentar o resultado na Sprint Review.
- Os artefatos de código tocados no desenvolvimento devem ter cobertura de 80% de testes unitários.
Cenário 2 – Time de BI e Analytics
- Itens do tipo User Story, Débito Técnico ou Habilitador Técnico devem estar implantados no ambiente de produção (mesmo com feature toogle = desligado).
- Itens do tipo Bug devem estar implantados no ambiente de produção e as evidências dos testes devem estar anexadas na ferramenta de ALM.
- Itens do tipo Spike devem ser dados como concluído pelo Dev responsável, que deverá apresentar o resultado na Sprint Review.
- Pacotes ETL devem atender aos Requisitos Não Funcionais de performance estabelecidos pelo time.
- Itens do tipo Relatório não devem possuir mais que 8 filtros para seleção de dados.
- Relatórios Gerenciais devem ter sido validados pelo time, sem a necessidade de envolvimento da área usuária.
- Relatórios Contábeis devem obrigatoriamente ser validados pela área usuária.
De repente você vai pensar assim: puxa Plínio, mas não tem muito rigor nos seus exemplos? Sim, tem um pouco. Mas o combinado não sai caro. Fazendo certo, dá certo. Salvo em times muito maduros (+ 2 anos de perenidade e com mindset ágil já no DNA) a ausência desse rigor sempre causa problemas.
Quem é responsável pela DoD?
Em times Scrum os papeis e responsabilidades precisam estar claros.
Importante lembrar que falamos a todo momento “time”, ou seja, não é um jogo de “acabei minha parte agora é com o outro”.
Garantir que o uso da DoD está funcionando é responsabilidade de todos.
- O PO (Product Owner) tem a responsabilidade de aceitar que apenas itens Done sejam dados como concluídos pelo Dev Team.
- O Dev Team tem a autonomia de somente aceitar itens Ready mas tem também a responsabilidade de entregá-los como itens Done.
- O SM (Scrum Master) tem a responsabilidade de garantir que o Scrum Team saiba do que se trata e está aplicando da forma correta.
- Todo o time tem a responsabilidade de garantir que tem uma DoD que todos estejam de acordo, que ela esteja sendo usada de fato e que a cada Sprint a DoD é revisitada para ajustes necessários.
É isso!
Qualquer dúvida, crítica ou sugestão, fique à vontade nos comentários! 😉