Sprint, Planejamento da Sprint #1, Planejamento da Sprint #2, Sprint Burndown Chart e Execução da Sprint

Oi pessoal,

Este texto faz parte do material da apostila de Scrum do Abu versão 2.0.

Por favor, fiquem a vontade para fazer criticas com relação a ortográfica e a parte técnica. O e-mail de contato é abuzitos@gmail.com

Após a correção técnica e ortográfica o material vai ser disponibilizado para download.

Novo tabuleiro do Processo do Scrum do Abu - http://blogdoabu.blogspot.com/2009/12/novo-tabuleiro-do-processo-do-scrum.html

Abraços,

Abu

A execução do projeto é realizado em períodos de tempo que nós denominamos de Sprint. Uma Sprint tem período maximo de tempo igual a 30 dias e o período menor de tempo igual a uma semana.

Dentro de uma Sprint nos temos que executar o Framework do Scrum, com o planejamento da Sprint, as reuniões diárias, a entrega do que foi realizado no final da Sprint e a Retrospectiva, que é uma reunião de melhoria do processo pela equipe.

Devemos respeitar o período de tempo da Sprint como uma regra inegociável, onde mesmo não tendo realizado todas as atividades necessárias da Sprint nos terminamos a mesma, para que mesmo com uma entrega parcial dos resultados obtidos, seja realizada a entrega.

É importante sempre entregarmos o serviço realizado na Sprint, mesmo que este serviço não tenha sido concluído em sua totalidade.

A quantidade de serviços, isto é, requisitos que vamos implementar dentro de uma Sprint é determinada pela equipe e nunca pelo Product Owner. Quem vai realizar o trabalho deve se comprometer com a quantidade de serviço que vai realizar e nunca se comprometer com o serviço que foi determinado por outra pessoa.

Um dos segredos da Sprint está neste comprometimento, quando a equipe acredita que é possível realizar os requisitos acordados existe uma probabilidade maior de recebermos o que foi combinado.

É melhor trabalharmos com a realidade da velocidade de nossa equipe do que com o desejo que temos de velocidade. Uma equipe que sofre pressão para aumentar a velocidade acaba abrindo mão de alguma coisa e quase sempre o que a equipe abre mão é da qualidade, para que ela possa atender a velocidade esperada.

O problema de abrir mão da qualidade é que os requisitos e suas tarefas acabam não sendo fechados e retornam para a linha de produção. O nosso Product Backlog acaba recebendo os erros gerados durante o desenvolvimento das Sprint e os itens ainda não implementados. Está entrada de serviços com defeito acaba fazendo com que a equipe pare de desenvolver novos requisitos e gaste energia na correção de requisitos já implementados e que estão com defeito, o que pode levar o projeto a um fracasso.

Planejamento da Sprint #1

A reunião de planejamento da Sprint é realizada com a Equipe e o Product Owner e tem o objetivo do Product Owner apresentar a equipe os requisitos que vão ser desenvolvidos na Sprint.

Este planejamento é realizado com todos os integrantes da equipe de desenvolvimento do projeto, onde passamos a ter analistas de sistemas, desenvolvedores, testadores, DBA, web-design e quem mais for necessário.

Com a união de todas estas especialidades passamos a ter um ganho melhor de analise de sistemas e uma visão mais critica de como devemos solucionar os requisitos com a união de todas estás especialidades. O conhecimento também passa a ser compartilhado o que reduz os riscos da perda de uma pessoa na equipe, independente do motivo. Também nesta união de profissionais passamos a distribuidor e potencializar habilidades a todos, onde a ação de analise de sistemas passa a ser aprendida e realizada por todos os profissionais.

Um dos grandes segredos desta reunião é o Product Owner já vir com os requisitos bem definidos, para que a equipe tenha uma compreensão bem abrangente do que deve ser feito com o requisito.

É o que eu chamo de requisitos quadrados e requisitos redondos, onde um requisito quadrado é aquele que não tem uma clareza na sua definição e faz com que a equipe tenha dificuldade de achar as tarefas necessárias para a sua implementação e durante a execução do requisito ele gera vários impedimentos. Estes impedimentos podem levar a equipe inclusive a uma implementação parcial do requisito o que leva a uma não entrega do mesmo.

Já os requisitos redondos a equipe consegue no planejamento um entendimento claro do seu objetivo, o que leva a uma definição muito boa das tarefas a serem realizadas e permite um desenvolvimento sem duvidas. Os requisitos redondos aumentam a velocidade de desenvolvimento do sistema pela equipe, isto é, ao invés de pressionarmos a equipe para uma velocidade maior, devemos entregar a equipe requisitos melhores, que permitira um aumento de velocidade com qualidade do produto gerado.

Planejamento da Sprint #2

O planejamento da Sprint #2 passa a ser realizado apenas pela equipe, sem a necessidade do Product Owner. Este planejamento tem o objetivo de determinar como vamos realizar os requisitos, isto é, como vamos transformar o que foi recebido em forma de requisitos em software.

Nesta reunião definimos de maneira rápido como pode ser a tela de um sistema, o modelo de dados em auto-nível, as classes necessárias a serem desenvolvidas, as regras de negocio, etc.

Cada item identificado como sendo parte da solução do requisito passa a ser chamado de tarefas e estas tarefas recebem uma estimativa de horas.

Uma boa pratica e ter tarefas com o tempo de no mínimo de 1 hora e de no maximo um dia de trabalho. Se tivermos tarefas menores de uma hora elas podem ser agrupadas, para chegarem ao tempo de 1 hora. Uma boa dica também é agrupar as tarefas para meio período de trabalho, isto é, em um dia de 8 horas meio período seria de 4 horas. Desta maneira não perdemos tempo com estimativas de tarefas pequenas, deixando elas agrupadas e rotuladas com um conjunto de horas. Também ter agrupamento de tarefas faz com que os integrantes da equipe peguem trabalho sempre para um período de tempo ou um dia inteiro, não sendo necessário o seu deslocamento para pegar trabalhos durante o seu dia de trabalho.

Um requisito passa a ter varias tarefas e cada tarefa passa a receber o tempo necessário para o seu desenvolvimento. A totalização das horas necessárias para a completude dos requisitos selecionados para o desenvolvimento da Sprint faz com que a equipe saiba se os itens selecionados para trabalho são suficientes para o tempo existe ou maior, menor que o tempo que temos de trabalho.

Sprint Burndown Chart

Sprint Burndown Chart é o gráfico que mostra como está a execução das tarefas dentro de uma Sprint.

Nós temos no Eixo Y a quantidade de horas necessárias para a execução da Sprint e no Eixo X o numero de dias da nossa Sprint. A nossa velocidade é a quantidade de horas que a nossa equipe consegue executar por dia.

Sprint Burndown Chart


Calculo de Velocidade da Sprint

Calculo da Velocidade da Equipe na Sprint


A capacidade de produção da nossa equipe é de 110 horas por Sprint e 22 horas por dia. A quantidade de horas das tarefas identificadas no nosso Planejamento de Sprint #2 não deve ser superior a 110 horas. Nós podemos ter mais de 110 horas de tarefas na Sprint, mas isso so ocorre quando a equipe acredita ser capaz de executar às 110 horas mais o excedente.

Exemplo de Tarefas na Sprint



Exemplo de Ciclo de Vida de Uma Sprint

O exemplo do ciclo de vida de uma Sprint apresentado tem o seu inicio em uma segunda feira, mas o inicio da Sprint pode ser em qualquer dia da semana. Também neste exemplo foi definido um período de trabalho de 8 horas, tendo o período da manha e o período da tarde, mas pode ter projetos com períodos noturnos ou de apenas um período.

Também foi colocada a reunião diária no horário da manha, mas ela pode ser realizada em qualquer horário do dia, horário este que tem que ser definido com os integrantes da equipe.

Sprint de 2 Semanas


Sprint de 1 Semana


Executando a Sprint

Após o planejamento da Sprint #1 e #2 a equipe pode iniciar o processo de execução da Sprint. Os requisitos e suas respectivas tarefas são colocados no quadro de Taskboar, também chamado de quadro de Kanban.

Todo dia é realizada uma reunião de alinhamento da Sprint, que vai ser vista no tópico “Reunião Diária”. A execução dos Requisitos deve ser realizada com o conceito “Todos Contra Um”, onde a equipe inteira ataca o primeiro requisito, isto é, suas tarefas.

Caso não tenha serviço para todos, o segundo requisito é aberto e os integrantes da equipe que não estavam trabalhando no primeiro requisito vão para o segundo. Caso não tenha serviço para todos, o terceiro requisito é aberto e assim por diante.

Quando um requisito é terminado ou não existe tarefa para todos, o processo de ajudar no próximo requisito ou abrir um novo requisito deve ser seguido.

A técnica de “Todos Contra Um” faz com que tenhamos ao termino da Sprint sempre requisitos prontos para serem entregues. Quando colocamos uma pessoa em cada requisito, isto é, “Cada um por si” ao termino da Sprint corremos o risco de termos todos os requisitos 90% pronto, mas nenhum realmente pronto.

Um ponto importante do “Todos Contra Um” é que a equipe em Scrum realmente é uma equipe, não buscamos mais o individualismo e sim o coletivo. Não existe mais o melhor desenvolvedor, o melhor arquiteto, o melhor testador, existe a equipe, que vai ser forte ou fraca pela união do grupo.

Todos Contra Um


É comum aparecer requisitos novos durante a execução da Sprint que está sendo executada.

Requisitos novos são ocasionados por uma analise superficial dos requisitos da Sprint, ou por uma necessidade nova do Product Owner. O requisito não planejado ocasionado por uma analise superficial, é um alerta que não devemos jamais deixar de lado o bom trabalho de analise de sistemas. Estes requisitos não planejados vão atrapalhar a execução da Sprint por intermédio de um impedimento de falta de definição de como o sistema deve se comportar.

Mas quando um requisito novo entra na Sprint, independente do motivo, ele deve ser colocado em um espaço visível e bem sinalizado, para que todos os envolvidos no projeto saibam que demandas novas estão consumindo energia da equipe de desenvolvimento. Estas demandas não previstas podem levar a uma entrega parcial dos requisitos acordados pela Equipe com o Product Owner no inicio da Sprint.

Taskbord ou Kanban


A equipe tem autonomia de executar as tarefas do quadro de Taskboard, não sendo necessário uma pessoa ficar atribuindo estas tarefas as pessoas que vão executar.

Está autonomia ocorre porque desde o inicio do projeto todos os integrantes da equipe de execução do projeto estavam juntos entendendo o que deve ser feito. Também estavam juntos no Planejamento da Sprint #1 e #2. Não existe necessidade de um “controle manda faz”, a equipe sabe o que deve ser feito e não ter um controle sobre a equipe neste momento, potencializa a capacidade de execução da mesma.

O controle dentro da Sprint passa a ser compartilhado por todos da equipe, não ficando a responsabilidade para uma pessoa. Isso é o que nos chamamos de auto-gestão.