O ciclo de vida Scrum

Fala a verdade, tá acostumado com ele né? Claro, é o modelo utilizado na grande maioria dos projetos hoje em dia. 

Ao invés de etapas e atividades definidas no início do projeto, o ciclo de vida de um projeto Scrum é composto por iterações de software funcionando. O ciclo de vida é representado pela figura abaixo:

Ciclo de vída Scrum

Quando mais tempo eu demoro para entrega mais tempo eu levo para obter um feedback, portanto quando menor o tempo do sprint mais rápido eu obtenho um feedback. Recomenda-se 2 semanas.

Sprint (15 dias – 10 dias úteis)

Planning – 1 dia

Desenvolvimento – 8 dias

Review – ½ dia

Retrospective – ½ dia

·        Estabelece um limite ao WIP (Work in Progress) – uma vez definido o tempo de um sprint, todos os sprints devem ter o mesmo tempo. Deve ser feito desta forma para medir a capacidade produtiva.

·        Força a priorização – o PO deve priorizar o que ele quer receber como produto de trabalho para cada Sprint.

·        Evitar perfeccionismo desnecessário – O ótimo é inimigo do bom

·        Motiva o encerramento das tarefas – As entregas devem ser feitas dentro do sprint

·        Melhora a previsibilidade – como o tempo do sprint é pouco (geralmente 15 dias), é mais possível prever os términos conforme evolução dos sprints.

·        Transparência – entre os membros do time

·        Inspeção – avalio o que foi feito para adaptar

·        Adaptação – adaptar para evitar cometer os erros cometidos anteriormente

Os Artefatos:

Bom, o Scrum não oferece listas de templates ou modelos de documentos para que você possa sair usando. No entanto existem alguns artefatos que fazem parte do dia-a-dia, vamos falar dos principais:

·         Product Backlog é a lista que contém os requisitos do projeto. Aqui temos todas as necessidades e/ou vontades do Product Owner para o projeto. Este é um artefato "vivo", pois será priorizado e re-priorizado ao longo do projeto de acordo com a visão do P.O. Uma forma ágil de gerenciar e manter seu Product Backlog é por meio das user stories. Utilizando essa abordagem você verá muitos resultados interessantes em seu processo de engenharia. Mas, como já dissemos o Scrum não é um processo de engenharia então você pode utilizar o que quiser pra manter seu Product Backlog (Casos de Uso, Requisitos, Especificação, etc), desde é claro que o P.O reconheça valor nesses documentos e que eles sejam claros para o time.

·         Impediment List é a lista com os impedimentos do Time, na qual o S.M deverá trabalhar.

·         Sprint Backlog possui as atividades nas quais o Time vai atuar dentro de uma Sprint.

Timebox que será executado para executar parte do Product Backlog.

É como se fosse uma corrida. Hora que chegou na linha de chegada, acabou.

É um Ciclo PDCA – Planeja o que será feito, Executa, Verifica e toma uma ação para que o próximo sprint seja melhor. Melhoria continua, ou seja, os sprints devem evoluir conforme andamento.

Essas atividades são planejadas pelo Time durante a reunião de planejamento da Sprint. Este também é conhecido por ser representado pela Kanban, provavelmente um dos símbolos mais associados ao Scrum.

Exemplo de Kanban

Product e Sprint Burndown são gráficos que mostram a tendência planejada para atendimento da Sprint / Product Backlog e como o time está evoluindo diariamente no caso da Sprint e a cada Sprint no caso do projeto.

Cerimônias:

Existem também algumas cerimônias no Scrum, que marcam cada etapa no ciclo de vida. As principais:

·         Sprint Planning Meeting é a reunião de planejamento da Sprint. Nela o Time discutirá com o P.O sobre a meta a ser alcançada naquela Sprint e fará o planejamento de todo o trabalho que será realizado dentro da Sprint.

·         Daily Meeting é a reunião diária que ocorre com todos os membros do Time, S.M e P.O. Preferencialmente deve ter 15 minutos e os integrantes do Time respondem a perguntas como:

·         O que fiz desde a última reunião diária;

·         O que planejo fazer até a próxima;

·         O que está me impedindo?

·         Sprint Review é a reunião de prestação de contas na finalização da Sprint. Nela todos os membros do Time apresentarão o resultado atingido na Sprint ao P.O e outros envolvidos.

·         Sprint Retrospective é a reunião de "lições aprendidas" que ocorre ao final de cada Sprint. Nela os membros do time respondem a perguntas como:

·         O que fizemos de bom e temos que continuar fazendo?

·         O que temos que mudar ou começar a fazer?

·         Quem está no controle?

O que temos que levar em conta é que Scrum ou práticas ágeis em geral não se resumem apenas na utilização de Kanbans ou na realização de reuniões diárias. O mais importante não está em evidência e tem a ver com mudança cultural. É imprescindível que se tenha o foco sempre na mudança cultural e não somente nas práticas. É preciso olhar para os itens do manifesto, entendê-los e praticá-los para conseguir resultados com o processo.

O mais importante é a cultura!

Continua....

Artigo de autoria de Everton Amorim, PMP e edição de Renato Mendes,  seguidores e agora colaborados do blog.