SCRUM para resgatar o projeto!

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Hoje tivemos nossa reunião para começar o sprint. Não foi uma reunião oficial, daquelas em que passamos o dia planejando e tudo mais. Mesmo assim tivemos definições importantes.

Temos 7 semanas até o fim do projeto. Então decidimos fazer 3 sprints de 2 semanas, com mais 1 semana de "pulmão" para ajustes e afins. Temos inicialmente 11 stories para cumprir. No primeiro sprint 4 stories serão "atacadas".

Definimos como será o nosso taskboard. A princípio ele será conforme a figura abaixo:



(1) São as user stories em forma de index cards (veja mais adiante)
(2) Identifica a coluna que acrescentamos, a VERIFY
(3) Indica o nosso burndown chart
(4) As tarefas não planejadas, as famosas "tarefas rosas"
(5) São as informações da sprint, número, data de início e fim e o tamanho em pontos
(6) É o backlog de impedimentos

A coluna VERIFY eu acredito que seja a melhor mudança introduzida. Por quê? Pois ela "força" uma pessoa a dar o aval se a tarefa está pronta ou não. No caso, serei eu (scrum master) que validarei as tarefas para DONE. O processo é bem simples:

SE AS TAREFAS ESTIVEREM PRONTAS, VÃO PARA DONE
SE ALGO NÃO ESTIVER CONFORME, VOLTA PARA DOING

O legal é que todos da equipe aprovaram isso. O Scrum Master começa a se integrar mais com as atividade de fato, sem ficar na esperança de que os caras tenham feito as coisas mesmo.

O nosso gráfico de BURNDOWN seguirá o modelo que usamos anteriormente, o qual não é recomendado, mas devido ao nosso baixo tempo para estimar tarefas e também ao pedido da equipe pelo gráfico, ele será mensurado da seguinte forma:

X-AXIS : dias do sprint (5/5, 6/5, 7/5... 15/5, 16/5).
Y-AXIS : tarefas restantes (número de tarefas. Quando surgirem rosas, o gráfico sobe)

O pessoal recomenda usar horas ou pontos. Como eu disse, não tínhamos tempo (e sinceramente, nem saco) para estimar cada uma das tarefas. Então faremos assim... o gráfico dará apenas uma visão gráfica da taskboard. Servirá apenas como "motivador".

As tarefas não planejadas são todas aquelas que não foram levantadas durante a reunião de hoje (2a feira). Se uma atividade não planejada durar mais do que 1 hora, ela vira uma tarefa rosa. Portanto, "Resetar o computador" não é uma tarefa rosa. Mas "Reinstalar o Windows" já poderia ser considerada :)

O campo das informações do sprint são bem legais. Ali fica visual o dia de início e fim da sprint, o sprint goal (no nosso caso é "Finalizar o sistema de software") e também tem o número de pontos estimados para as 4 stories que colocamos no sprint. Uma de 13 pontos, duas de 8 pontos e uma de 5 pontos. Total 34 pontos.

O backlog de impedimentos será bem simples. Cada impedimento que ocorrer gera um post-it (no nosso caso, será aqueles "reciclados" cor cinza). Marcamos a data que surgiu e quem gerou o impedimento e quando ele for resolvido, será apenas "riscado".

As tarefas planejadas devem conter apenas o nome da pessoa que está realizando, como extra. Se forem 2 pessoas, ou se colocam os dois nomes ou alguém que responderá por ela.

Por fim, as INDEX CARDS. Finalmente usamos o conceito das index cards. Ela está exatamente como a figura abaixo mostra:



Temos o campo "ID" apenas para identificação rápida da story, o nome da story, a sua prioridade (na faixa de 1 a 150), algumas notas (que eu usei para descrever o objetivo e algumas informações extras sobre a story), a estimativa (usando planning poker ou apenas marcando Fibonacci ali 1-2-3-5-8-13-21) e o campo mais importante e útil de todos: o DoD (definition of done, ou definição de finalizado).

O DoD é tão importante e tão útil, que enquanto eu escrevia nele eu percebi o tamanho da ajuda que ele apresenta. Lembram na dinâmica do SCRUM que eu descrevi há algumas semanas atrás, quando mencionei que durante a sprint review eu não havia feito um DoD das stories, e assim eu não sabia o que avaliar nas apresentações? Pois é. Agora temos um "checklist" das coisas importantes que a story deve considerar.

Por exemplo, em uma story chamada "Manual do Usuário", um dos "DoD's" é:

- O documento identifica todas as funcionalidades do sistema
- O documento apresenta passo a passo os procedimentos para as funções
- Os pontos de interação com o usuário estão descritos no documento

E assim por diante. Na story chamada "Criação de uma placa de alimentação" temos alguns "DoD's" como:

- Todos os componentes necessários estão disponíveis
- Foi realizada uma medida de consumo do sistema e a placa atende a isso

Enfim, agora temos alguns critérios para avaliar se as stories estão realmente DONE ou não! Além disso, a utilização dos DoD's facilita (e facilitou mesmo) a definição das tarefas. Cada uma dessas DoD's vira no minimo uma tarefa... geralmente mais de uma até.

Os DoD's podem funcionar até mesmo como casos de teste. Se fosse uma story que descrevesse uma tela de login (usuário e senha), por exemplo. Os DoD's poderiam ser:

- O sistema não aceita menos de 5 caracteres nos campos de usuário e senha
- O sistema não aceita números sequenciais como senha (12345, 67890, etc)

E assim por diante. Eu posso dizer que o DoD realmente é uma das coisas mais importantes que sua story deve possuir. Sem dúvida nenhuma! :)

Pois então é isso. Temos 7 semanas para tocar o projeto. É a chance de recuperar um projeto que parecia morto e transformá-lo em um protótipo interessante e com uma documentação bem completa.

O que falta mudar agora é a atitude da equipe... eles estavam largados nesse meio tempo. Mas agora a pressão vai vir não só de mim... mas do taskboard também ;)

Um abraço!