menu

Explorando a Definição de Pronto

Por

Para quem está chegando agora ao mundo Ágil, especialmente utilizando o framework Scrum para desenvolvimento de software, a Definição de Pronto (ou Definition of Done em inglês) é uma prática interessante que busca orientar o time para que tenha um entendimento comum a respeito do que significa uma entrega pronta. Entretanto, ainda muito se discute na comunidade sobre o que significa estar “pronto” e quem é que faz parte do “time”. Confundindo e criando conflitos desnecessários.

Quem é o Time?

Antes de falarmos sobre as questões envolvendo o “pronto”, vamos falar de time. Segundo o Scrum Guide™ , o Time Scrum (ou Scrum Team em inglês) é composto por três papéis: O Product Owner, o ScrumMaster e o Time de Desenvolvimento. Três papéis fazendo parte de um time maior, chamado Time Scrum.

Creio que já esteja mais que superada a discussão sobre se o Product Owner (PO) e o ScrumMaster (SM) fariam ou não parte do Time. Talvez o fato de haver um papel chamado Time de Desenvolvimento, que traz em seu nome a palavra “Time” possa ter confundido um pouco as coisas. Mas, sim: PO e SM fazem parte do Time Scrum. Logo, toda vez que que nos referirmos ao Time, estamos sempre considerando todos os três papéis.

A Definição de Pronto

Já a Definição de Pronto é mais complexa e ainda gera discussão em alguns contextos.

O Scrum Guide™ 2013 (PDF) aborda, na seção Definição de “Pronto” (não sei por que o pronto está entre aspas), que:

Esta é a “Definição de Pronto” para o Time Scrum e é usada para assegurar quando o trabalho está completado no incremento do produto.

O que nos mostra que a Definição de Pronto (chamado a partir de agora apenas de DoD – Definition of Done) é para o Time Scrum. O Time precisa concordar em como considerar um item efetivamente pronto. Mas, em outro ponto mais a frente no Guia, na mesma seção, diz que quando não houver uma DoD convencionada na empresa ou utilizada por outros Times trabalhando no mesmo produto…

[…] o Time de Desenvolvimento do Time Scrum deve definir uma definição de “pronto” apropriada para o produto.

Ao indicar que a DoD seria concebida, primariamente, pelo Time de Desenvolvimento, o Guia pode influenciar para que apenas conceitos técnicos sejam levados em consideração, como é comum encontrar: teste funcionais com sucesso; cobertura de testes unitários; Integração contínua; Incremento testado com sucesso no ambiente de QA, dentre outros. Mas muitas vezes não se vê a participação do PO, por exemplo, nesta definição.

Uma DoD que leva em consideração estar pronto somente quando o desenvolvimento e ações técnicas estão prontas, promove um distanciamento entre os papéis, causando um prolongamento indesejado nos ciclos de feedback. Quando isso acontece, a DoD parece também falhar no seu propósito raiz, que seria comunicar, de forma única, um sentimento de pronto do Time.

Melhorando a comunicação com a DoD

Algo razoável, pelo menos em termos de ganho de colaboração, comunicação e participação, seria incluir também a validação do Product Owner (PO) na DoD. Essa pequena mudança pode mudar comportamentos e interpretações sobre quem é o responsável pela entrega final, que é, de fato, o Time Scrum. Pode evitar aquele comportamento do Scrum primitivo de se apresentar as histórias ao PO somente na cerimônia da Review, no final da Sprint, o que evitará ciclos de feedback longos e problemas descobertos muito tarde no desenvolvimento. E o Time poderá, como uma unidade, comunicar que algo está realmente Pronto a quem mais possa interessar.

O Scrum Guide™, apesar de indicar o Time de Desenvolvimento para a elaboração da Definição de Pronto, também não diz para não considerar a participação do PO na DoD. De fato, na seção de Transparência diz:

Uma definição comum de “Pronto” deve ser compartilhada por aqueles que realizam o trabalho e por aqueles que aceitam o resultado do trabalho.

Logo, resgatando os conceitos ágeis que transcendem o próprio Scrum, é certo dizer que o Time, quanto mais próximo, colaborativo e transparente for na comunicação e na sua forma de trabalho, mais ágil, rápido e eficiente na entrega de valor ele será. E isso passa também pela forma com que o Time entende e define seus critérios de pronto.


 

Referências:

Definition of Done: A Reference (Scrum Alliance)
http://www.scrumalliance.org/articles/106-definition-of-done-a-reference
https://www.scrum.org/Scrum-Guide
https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-Portuguese-BR.pdf (PDF em português)

4 comments

  1. Leonardo Campos

    Grande Buzon, mais um ótimo texto.

    Acredito que o principal ponto do DoD é a comunicação, apesar de também servir como “checklist” para a equipe de desenvolvimento.
    Quando se diz que algo está pronto, não é necessário perguntar: Você tirou o toogle? A história foi testada? O código foi revisto ou feito em “pair”? Basta que esses itens estejam contemplados no DoD ;-).

    O DoD também deveria funcionar como um contrato entre PO e Dev Team, no sentido de que o PO deveria sim participar da sua elaboração e contribuir com o que ele considere o mínimo em cada item para que seja por ele aceito, obviamente além dos critérios de aceite.

    Algo que pode valer uma boa conversa descontraída em um Lean Coffee é: Se entendemos o DoD como contrato que é, será que essa prática conflitaria (ou não) com o valor ágil “Colaboração com o cliente mais que negociação de contratos” 😉

    Abs e até próximo Lean Coffee.

    Posted on julho 28, 2014
  2. Rafael Buzon

    Show Leo. Vlw pelo comentário!

    Concordo 100% sobre tornar mais transparente e fluída a comunicação entre o time, usando o DoD.
    O lance de ser um contrato, acho que não fere o Agile. Por outro lado, em um contexto em que não é flexível ou é seguido cegamente, ai sim diria que não é Agile.

    Abraços e até lá!

    Posted on julho 30, 2014
  3. Ronald Bolsoni Falcão

    A questão das aspas em “pronto” remete ao significado flexível que damos à essa palavra no contexto do DoD. O pronto para uma equipe pode não ser o pronto para a outra equipe. Por exemplo, uma equipe define que para ela pronto é o sistema testado e em produção, mas para outra equipe o sistema testado já é considerado pronto. Junto com os critérios de aceitação, DoD fazem o papel do contrato entre a equipe (Time Scrum), como já dito, muito mais transparente.

    Posted on outubro 29, 2015
  4. Edilaine Miguel

    Olha só onde eu vim parar… rss… Parabéns pelo artigo Mestre!!! 😉

    Posted on maio 19, 2017

Leave your reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Go to top

O kudoos busca melhorar a gestão ágil no Brasil por meio da criação e promoção de conteúdo e eventos de qualidade. Veja nossos conteúdos e vídeos e participe dos eventos que promovemos para troca de ideias e experiências.

Close