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.

Anúncios

2 Respostas para “SCRUM com ciclo simples, duplo ou triplo

  1. Ben-Hur Souza

    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.

    • 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/

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 )

Imagem do Twitter

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

Foto do Facebook

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

Foto do Google+

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

Conectando a %s