SCRUM com ciclo simples, duplo ou triplo

Qualquer praticante do método SCRUM conhece os conceitos de DoR e DoD, o primeiro para Definition of Ready e o segundo para Definition of Done. O primeiro habilita histórias ou features devidamente priorizadas e detalhadas a serem planejadas no próximo Sprint Planning, o segundo habilita estas histórias após desenvolvidas serem elegíveis para publicação em produção.

Não gosto dos diagramas tradicionais SCRUM, por isso, com o passar dos anos, propus diferentes modelos, até chegar no que consta em todas as minhas apresentações e livros. Para estabelecer visual e claramente os ciclos de Discovery e de Delivery, criei um modelo onde os esforço concomitante de programação e preparação dos próximos a programar ficam explícitos.

Os dois ciclos combinados, concomitantes, de forma a preparar ou detalhar o próximo sprint enquanto o sprint corrente acontece com foco na construção de software de qualidade, atendendo o valor proposto e modelado para atender necessidades de negócio. Este modelo diagramático possui ciclo duplo, complementares, gerando a necessária cadência e fluxo ágil desejado.

Ciclo simples não é uma característica do método SCRUM, mas sim do método KANBAN. No ciclo simples, temos um fluxo contínuo de entrada e saída, muito afeito a equipes de manutenção. Neste formato, histórias ou tarefas são priorizadas e seguem uma sequência de passos, podendo ser de análise, desenvolvimento, review, testes até sua homologação, por exemplo. O desenvolvimento não obedece  planejamento de release e sprint, é contínuo.

Ciclo triplo, que não recomendo, é quando temos o Discovery caracterizado pelo detalhamento e preparação das histórias, temos o Delivery para desenvolvimento e também temos mais um, temos um ciclo adicional para homologação pelo cliente. Esta alternativa, tem o potencial de identificar bugs e não conformidades fora do sprint de construção, que terão que ser corrigidos um, dois ou mais sprints à frente, retroalimentado histórias antigas, entregues fora dos requisitos ou sujeitas a ajustes, produzindo altos riscos e prejuízo.

Ciclo Simples

No ciclo simples, temos um fluxo único e contínuo de priorização, análise, desenvolvimento, testes e homologação, típico em equipes de manutenção ou sustentação. Comum em equipes que praticam Kanban, como por exemplo, uma equipe que na segunda-feira alinha prioridades para a semana e inicia o trabalho de análise até entrega, podendo mudar por incidente, ocorrência ou mesmo por opção. Não é comum para equipes de projeto, que via de regra praticam SCRUM em ciclo duplo e não o ciclo simples do Kanban.

ciclo simples

Ciclo Duplo

É o modelo básico e esperado para equipes SCRUM, com o objetivo de resguardar que bugs e não conformidades encontradas nas histórias de cada sprint sejam corrigidas e entregues dentro da própria sprint. Neste modelo podemos prever um quadro Kanban com etapas de testes e homologação, terminando em Definition of Done (pronto para ir para produção).

Pag 74

kanban

Ciclo Triplo

O ciclo triplo agrega um alto risco, posto que algo definido na primeira quinzena e desenvolvido na segunda terá os testes de aceitação na terceira, no caso de bugs ou ajustes necessários os desenvolvedores terão que resgatar histórias de sprints passadas, que serão trabalhadas e testadas … entregues novamente e na eventual hipótese de novos bugs encontrados, corremos o risco de mais de um mês após seu desenvolvimento, voltará ainda para ajustes.

ciclo triplo

Pior, pois para preparar-se para resolver bugs dos últimos sprints, é necessário prever mais um ou dois ao final, somente assim é possível ser realista, a não ser que a projeção seja de que pode-se errar a vontade em qualquer sprint menos nos últimos, porque se houverem o projeto vai exigir mais algumas semanas só para homologação das últimas correções 😦

ciclo-triplo ii

Há vários argumentos para justificar o porque este modelo de ciclo triplo agrega mais riscos que oportunidades, sugerindo que seja utilizado em ultima instância. Por exemplo, um desenvolvedor ao entregar e ter o sprint concluído terá, consciente ou inconscientemente, perda de tempo e humor ao ter que duas ou quatro semanas depois ter que voltar para corrigir. Há um conceito de buffer e tensão, pois ter que relembrar algo feito a mais tempo para correções geram tensão e desconforto … mesmo que não assumamos isto.

Na imagem abaixo temos um rastro de uma história desenvolvida, com recaídas – ela é definida no momento 1, desenvolvida e testada no momento 2, liberado para homologação (teste de aceitação) no momento 3, no caso de aparecer um bug, é priorizado para correção no próprio sprint corrente (4) ou no seguinte (5), para que seja novamente homologado (esperamos que com sucesso desta vez) no momento 6 … corremos assim o risco de um estoque de semi-acabado só ser homologado dois meses depois de definido e um mês e meio após construído.

ciclo triplo - bugs

O ideal em termos de ciclos SCRUM para projetos ágeis de desenvolvimento de software é que haja cadência, equilibrio, de forma que NÃO tenhamos estoques intermediários … um princípios Lean. Construir histórias e só saber se foram aceitas pelo cliente semanas depois, tendo que retomá-la semanas depois de ter construído devido a bugs ou ajustes é no mínimo temerário.

Muito melhor é o ciclo duplo, onde uma equipe com profissionais nas diferentes funções praticadas consegue ter histórias dimensionadas e detalhadas (DoR) de forma a ser possível em duas semanas entender, desenvolver e ter este trabalho validado por testes e homologação. Desta forma, o que é feito no sprint termina no sprint e tende a não voltar para nos assombrar semanas depois, retroalimentando um sentimento de frustração quando voltam após o fim de cada sprint e temos que relembrar e retomar algo que em hipótese estava pronto.

ciclo

É minha opinião, sujeita a contraposição … mas tenho muita convicção e é assim que tento implantar SCRUM, em pequenas, médias e grandes empresas.

2 comentários

  1. Belo post Audy, e o melhor é que deixa claro que a adoção de um ciclo triplo aproxima as equipes ainda mais de um modelo waterfall. Por aqui o foco é executar ciclo duplos, fazendo as entregas das histórias na própria sprint atendendo a DoD. Qualquer coisa diferente disso nos leva a postergar a realização dos benefícios.

    Grande abraço.

    Curtir

    1. Oi, legal, tem muitas equipes que praticam SCRUM, mas não percebem detalhes que não estão no ScrumGuide.org, mas disponíveis no KANBAN como métricas de fluxo e principalmente ao avô de todos eles, que é o LEAN e seus princípios de eliminação de estoques, cadência, gemba, kaizen, … Agradeço o comentário, eles são beeeeeem raros, a galera prefere fazê-lo em modo privado, via msg ou mesmo pessoalmente por algum motivo, privando os demais de validarem ou invalidarem o que escrevo pela opinião de outros profissionais da área.
      Sucesso aí tchê, interage quando quiser, pois todas as opiniões são bem-vindas, todos aprendemos com elas o/

      Curtir

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s