“- Vem filha, vamos almoçar!

– Está pronto, pai?

– Está quase.

– Então não está pronto!

Eu ri-me. Como se fosse o feitiço a virar-se contra o feiticeiro porque a personagem principal deste discurso foi a Pietra, a minha filha quando tinha 4 anos.

Quantas vezes nos deparamos com situações semelhantes? Tentamos acelerar alguns processos, que podem originar esperas desnecessárias e consequentes atrasos, impossibilitando-nos de manter o foco em outros temas que poderiam ser mais importantes.

Estar pronto deixa de ser algo corriqueiro, sem muita importância e passa a ter um papel importante na rotina de quem trabalha com algum método ágil, uma vez que ajuda a garantir a qualidade das entregas. No Scrum, por exemplo, é denominado como “definição de pronto” (definition of done) e é utilizado “para verificar se o (…) produto está concluído” (SCHWABER e SUTHERLAND, 2017, p.20). Para algo ser definido como pronto, seja uma parte, um incremento passível de ser utilizado, ou um produto final completo, é necessário que as pessoas que participem na sua construção (equipa, dev team ou equipa de desenvolvimento) tenham um consenso do que é “estar pronto”, ou cada um vai entender de uma maneira diferente e no fim ainda poderá surgir a expressão “mas eu achei que estava bem assim!”.

Se houver algum padrão interno ou mercadológico do que aquela entrega deva conter, ou então se essa definição de pronto “é parte das convenções, normas ou diretrizes da organização do desenvolvimento” (ibidem), a equipa pode orientar-se por aí. Caso contrário contrário, ela deverá chegar a um consenso e definir. Um bom parâmetro é guiar-se pelos inputs do cliente (no Scrum essa informação chega pelo Product Owner) e esta decisão em conjunto garante transparência ao processo. Vale sempre lembrar que a definição de pronto precisa de ser feita no início do planeamento de cada ciclo de desenvolvimento (na sprint planning) e para cada item a ser trabalhado, mas pode ser revista e aprimorada antes dos desenvolvimentos seguintes.

Uma entrega pronta então é um produto (ou incremento) testado e aprovado? Não pode ter uma vírgula fora do lugar? Depende. Se estivermos a desenvolver um sistema de lançamento de foguetes e não quisermos explodir com tudo, é melhor manter as vírgulas no seu devido lugar, porque caso contrário podemos ser supreendidos com um resultado menos positivo. Mas se não afectar a entrega e for passível de ajustar rapidamente no ciclo seguinte sem comprometê-lo, talvez.

Oriente-se por uma checklist para verificar se todos os pontos pré-estabelecidos foram cumpridos. E, da próxima vez que pensar em como fazer uma entrega, tenha em consideração algum desses pontos abordados – principalmente quando for chamar a sua filha para almoçar!”

Leonardo Magalhães

PROJECT MANAGER

Referência Bibliográfica:

SCHWABER, Ken; SUTHERLAND, Jeff. Scrum Guide: O guia definitivo para o Scrum. 2017. Disponível em: https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf. Acesso em: 14 out. 2020.