Discovery, Refinamento e DoR + Delivery, testes e DoD

Na minha visão estes conceitos permitem múltiplas interpretações e o não entendimento dos mesmos pode gerar desperdícios evitáveis. A partir do conceito de pré-game, game e pós-game do SCRUM, entendendo o GAME como os ciclos iterativos-incrementais que chamamos de SPRINTS, o desejável é constituir um modelo que proporcione cadência, consistente e sustentável.

Discovery x Delivery

Qualquer processo criado baseado em SCRUM que não trabalhe com o conceito cíclico concorrente de discovery e delivery para projetos de desenvolvimento de software é um forte indicativo de que a prática é do famoso método Go Horse. Discovery não são novas atividades, mas antecipação daquelas que garantem a definição e entendimento daquilo que queremos para o próximo sprint.

Para que cada sprint de desenvolvimento possa acontecer com produtividade e qualidade de forma sustentável, é preciso que haja antes um trabalho gere o detalhamento necessário para que os desenvolvedores entendam o que precisa ser feito e declare qualidade, para que possam trabalhar com certa tranquilidade e gerem produtividade com satisfação e confiabilidade no que está sendo feito.

No diagrama abaixo temos uma visão dos ciclos de discovery e delivery para um projeto de quatro sprints de duas semanas, cada sprint iniciando com um planning e encerrando após 10 dias úteis em uma review e retrospectiva. Enquanto o PO, analista e QA trabalham no discovery para o próximo planning, a equipe está trabalhando no sprint atual de construção, baseado nas definições e mantendo contato diário com os demais para bom andamento do trabalho.

Para termos um fluxo contínuo e sustentável de projeto, precisamos gerar ciclos cadenciados de entendimento e definição (discovery) prévios aos ciclos de construção. Neste contexto, o critério de sucesso no discovery é acordado no acordo de Definition of Ready (DoR), que é pré-condição para podermos iniciar um novo Delivery, que possui seu próprio critério de sucesso como sendo o Definition of Done (DoD).

DoR – Definition of Ready

No ciclo de discovery, prévio a cada sprint,  temos um conceito fundamental para que o time SCRUM possa realizar o planning e performar a construção de cada sprint. O product owner, analista de sistemas e analista de qualidade precisam atingir um critério mínimo de definição de preparado para que haja suficiente entendimento por parte dos desenvolvedores e assim evitemos ociosidade, retrabalho ou desperdício.

Uma DoR possível é ter todas as user stories daquilo que se pretende seja planejado para o sprint, além da especificação técnica contendo regras de negócios, de interface, prototipação e finalmente os casos de testes. A meta neste DoR é a cada retrospectiva verificar o aprendizado para termos documentação útil, sem deseperdícios nem deficiente, permitindo um planning consistente e desenvolvimento tranquilo e sustentável.

O DoR é a maior garantia de que não teremos um sprint em regime de Go Horse, permitindo um bom planning e que cada tarefa tenha um mínimo de definição, consistente, que permita ao desenvolvedor poder trabalhar sem ter que parar a cada hora para buscar informações e detalhamento necessários. O equilíbrio é o objetivo, não queremos documentação inútil nem deficiente, onde já temos o importante e façamos trocas eventuais de informação e conhecimento.

Refinamento

Refinamento consta no Scrum Guide, sugerindo que antes do próximo planning é produtivo fazer uma reunião de refino do backlog com o principal objetivo de alinhamento sobre as histórias selecionadas para o próximo Sprint. Não tem o status de uma timebox e não consta dos diagramas de ciclo de vida do SCRUM, uma atividade que ocuparia de 5% a 10% da equipe de desenvolvimento em apoio ao PO no entendimento das histórias, foco especial no próximo planning.

Na prática de projetos de desenvolvimento, durante o ciclo de discovery o PO pareia com um analista de sistemas ou requisitos responsável pela especificação técnica, prototipação e também um analista de qualidade ou tester responsável pela construção dos casos de testes que serão utilizados durante o sprint. Diferentes integrantes podem e são envolvidos para melhor entendimento durante todo o discovery e é preciso ter cuidado com o tempo e valor agregados.

Na prática, refinamento exige experimentação e análise em retrospectiva, sua evolução deve estar atrelada ao valor agregado e percebido, desperdícios, sustentabilidade, momento, etc. Com certeza variará de acordo com características do cliente, PO, equipe, produto, tecnologia, etc, pela necessidade de envolvimento, grau de complexidade, radicalidade e risco.

Refinar histórias é bom, mas tem que gerar valor real, manter um dia ou mais (já vi refinamentos de até uma semana) todo um time reunido para entender o que irão planejar dali a alguns dias pode ser puro desperdício ou descompressão. É preciso perceber o valor real que isto gerou, o nível de desconhecimento ou inovação tem que justificar esta necessidade, pois o refinamento não dispensa o discovery e seus atores, incluindo o acesso a equipe quando necessário.

DoD – Definition of Done

Se o Definition of Ready (DoR) das histórias desejadas é pré-condição para iniciarmos uma sprint de construção ou delivery, o Definition of Done é a condição necessária para que os desenvolvedores trabalhem e considerem o desenvolvimento realizado em cada história do Sprint concluída.

Um DoD típico pode ser o desenvolvimento da história realizado, versionado, build gerado e publicado em ambiente de testes, caso de testes passado pelo desenvolvedor, zero bugs, dados atualizados na ferramenta ALM e disponível para o testador sem restrições ou conforme acordado pelo time.

Casos de Testes

Um dos principais vícios existentes em equipes de desenvolvimento é a convivência leniente com bugs, a proposta que reitero para equipes que estão adotando SCRUM e passam a trabalhar neste modelo mental é o de que um bom caso de teste ou script baseado nos critérios de aceitação do PO permite ao desenvolvedor a construção e manutenção de um fluxo contínuo e agradável de desenvolvimento.

A pior condição para desenvolvimento de software é a fragmentação do trabalho devido a falta de cadência e clareza das histórias ou de comprometimento com a qualidade, gerando um ping-pong entre PO, analista e desenvolvedor ou pior ainda entre desenvolvedor e testador. O fluxo de uma boa equipe ágil é para ser contínuo e para a frente, devemos nos incomodar com bugs e voltas de tarefas aparentemente já concluídas devido a bugs encontrados pelo tester ou mesmo pelo PO ou usuários.

Segurança e garantias

Costumo dizer que se ficarmos preocupados em criar uma zona de conforto, pouco provável é que consigamos ser realmente ágeis. Se nosso produto são sistemas de informação, seguindo padrões e usando frameworks, salvo exceções é provável que não seja necessário dedicar dias para estimar “certo”. O trabalho do PO e analista durante o discovery, consultando a equipe de desenvolvimento no transcorrer do discovery, com um bom DoR, é suficiente para bem estimar.

Não estou negando o refinamento de todos reunidos por um turno ou dia para entendimento e refino, mas só em situações de inovação e desconhecimento, de riscos ou complexidade atípica. Fora isto, um discovery puxado pelo trabalho de análise é suficiente e as retrospectivas dirão onde estamos errando e quais as opções para melhorar a estimativa, técnica, processo ou método.

Cadência e sustentabilidade

A implementação destes conceitos e acordos não são universais, o importante é entender o modelo mental e valor agregados, para então a cada sprint termos como objetivo perseguir esta cadência e sustentabilidade. Algumas equipes ao adotar SCRUM entendem estes ciclos e combinações com apreensão, mas é exatamente estas combinações e continuum que dão leveza e fluidez aos processos baseados em SCRUM … aqui está a sustentabilidade!

Equipes que queixam-se de stress após vários sprints é porque não entenderam estes conceitos e lhes falta melhor entendimento de sua natureza, facilmente entrando em modo Go Horse, correndo atrás da máquina, apagando pequenos incêndios e interrompendo seu trabalho com frequência indesejada. Algumas, frente a esta situação, optam por gerar refinamento de alguns ou vários dias entre sprints ou mesmo dentro das sprints … as vezes a gente ataca o efeito e não a causa do problema.