SCRUM para projetos impossíveis

Hoje começou um novo dia-a-dia no meu trabalho. Implantamos de vez os conceitos de SCRUM para resgatar o projeto. Basicamente, vamos tentar finalizar em UM MÊS o que não fizemos em SEIS MESES. Foi uma reunião de 4h30, mas foi MUITO produtiva e todos que estiveram nela sairam satisfeitos.

Tratei de comprar alguns salgadinhos e água, para já dar uma animada no pessoal. E fizemos uma pausa durante a reunião, para descansarmos também. Aliás, minha idéia era que a reunião continuasse no dia seguinte, mas a equipe quis finalizar tudo hoje. Gostei disso!

Reuni toda a equipe do projeto e o nosso chefe-cliente-especialista, que agora se tornou o "Product Owner". Primeiramente, discutimos a situação atual, de que teríamos UM MÊS (ou seja, dois sprints) para finalizar o melhor que pudermos do projeto. Portanto, o foco era ter alguma coisa, dentro da nossa realidade.

Planejei para que pudessemos hoje levantar todas as funcionalidades que já pensamos para o sistema. Esse seria nosso "Product Backlog". Para facilitar a visualização disso, utilizei um conceito que li em um livro (veja o post acima deste) em que o autor apresenta o que chama de "Index cards". Ele é mais ou menos como o que eu fiz abaixo:

É composto por 6 campos para serem preenchidos. Se você quiser, pode baixar o arquivo em PPT (dois index cards por folha A4) neste link aqui. Os campos são preenchidos da seguinte forma:

Backlog item: Nome da funcionalidade. Ou, no nosso caso, alguns requisitos não-funcionais importantes (que posteriormente podem virar funcionalidades);

Prioridade: Eu estimei com base no livro. De 1 a 150, baixa para alta prioridade. Por que este intervalo? Pois simplesmente definir "alto", "médio", "baixo" pode levar a ter muitas funcionalidades de nível "médio". E daí perder mais tempo decidindo qual é a mais prioritária das "médias". Com este intervalo, conseguimos facilmente identificar.

User stories: o conceito de User Stories é bastante interessante. Aprendi no curso que fiz de SCRUM e achei bem interessante pelo fato de nos fazer pensar de fato em como um ator do sistema teria valor com essa funcionalidade. Basta usar COMO UM QUERO PARA . Então, por exemplo: "como um correntista quero sacar dinheiro do caixa automático para colocar na minha carteira e gastar". Pode ser algo bem neste nível mesmo. Outra coisa boa, é a possibilidade de otimizarmos e identificarmos requisitos "escondidos".

Estimativa: A estimativa é medida em "tamanho da funcionalidade". Usamos a série Fibonacci para mensurá-la: 1, 2, 3, 5, 8, 13, 21, mais do que isso é inviável. Usei o planning poker para estimar. O livro que me baseei usa cartas outros valores como 1/2, "?" e até um "café" para indicar que a pessoa está cansada. Mas preferi ficar só na série mesmo.

Como funcionará: Uma breve descrição do que a funcionalidade fará. Algo bem alto nível: usuário faz isso, depois isso, o sistema verifica isso e retorna isso. Pense em um "diagrama de atividades" BEM resumido. Essa é a idéia.

Notas sobre o item: Espaço para colocar observações. Eu usei bastante quando estávamos debatendo sobre a funcionalidade. Por exemplo, num item que coletava dados do sistema, o pessoal estava discutindo se o sistema teria memória interna para todos os dados... e se a velocidade do veículo influenciaria. Anotei isso ali. Facilitou na hora de fazermos nosso "WBS".

Inicialmente, com essas index cards, cada um que fosse lembrando de alguma funcionalidade preenchia tudo (menos a estimativa). Conseguimos em torno de 12 index cards. Não discutimos prioridades ainda.


Então passamos para a estimativa. Primeiro pegamos a funcionalidade daquelas que seria a mais fácil de ser implementada. E marcamos "2" para ela, por default. O livro que eu usei cita para que se marque "3" e outros falam em "1". Acho que "2" é um bom número, assim temos ainda algo que possa ser MAIS fácil ainda, se decidirmos depois.


Com isso, tínhamos uma base para nos basearmos para as próximas estimativas. E começou o planning poker. A cada rodada, se havia uma discrepância grande (sempre acontece algo como alguém colocar 2 e outro colocar 13) os extremos discutiam porque escolheram aquilo. Algumas funcionalidades nós discutimos antes de estimá-la, o que foi o correto. Assim identificamos outras variáveis envolvidas em cada uma... o que pesou nas estimativas. Por exemplo, uma interface gráfica que inicialmente foi estimada em 5, após a discussão passou para 13 por diversos fatores que não dependiam da gente.


Feitas as estimativas, agora discutimos as prioridades. Pudemos ver que haviam "baixas prioridades" importantes e que haviam "altas prioridades" irrelevantes. Isso foi corrigido e aprovado pelo Product Owner.


Aliás, o Product Owner entendeu tanto a complexidade que, pela primeira vez em UM ANO de projeto, ele aceitou que tivéssemos um protótipo ao invés de um produto. Inclusive sugeriu uma solução que nem nós poderíamos sugerir melhor: ao invés de usar um hardware que seria montado, vamos usar um notebook! Isso nos resolveu MUITOS problemas, e fez todo o time quase se abraçar e chorar de emoção!! (ok, essa parte eu exagerei...)


Agora tínhamos o seguinte cenário:


- Itens do backlog (funcionalidades), a maioria com algumas observações relevantes
- Prioridades
- Estimativas iniciais


Faltava criar o escopo de atividades, ou tasks... ou WBS. Colocamos na parede pendurados, lado a lado, usando o seguinte critério:


<----- mais importante ------------menos importante ------>


As folhas ficaram lado a lado para serem quebradas em tasks (como fizemos uma pausa para descansar, notem como as observações foram importantíssimas para nos lembrarmos depois).

Definimos o que seriam tasks. Falei que o ideal, para o gráfico do sprint burndown, era que as tasks fossem atividades pequenas. No nosso caso, que trabalhamos meio-turno, ficaria difícil de fazer uma atividade de meio-turno. Aliás, é preciso lembrar que existem horas produtivas e não-produtivas. Usualmente se usa a idéia de que 25% do tempo de trabalho é usado com bobagens. Então, no nosso caso, temos apenas 3 horas produtivas.


Definimos então que nossas tasks teriam DOIS dias (ou seja, 6 horas). Essa seria nossa medida padrão para todas as tasks que fossemos criando, mesmo que fossem menores do que isso. Eu pretendia depois refinar isso com eles, mas pra falar a verdade, como sei que tarefas não-planejadas irão surgir com o tempo, essa "gordura" será queimada. Então vou manter tudo como 2 dias, para o sprint burndown.


Fizemos toda a quebra, começando pelas menos prioritárias (e menos granularizadas no momento). Quando chegamos na tarefa prioritária, levantamos atividades não só relativas a aquela funcionalidade, como também atividades relativas ao projeto, tais como reavaliar todos nossos códigos, identar, documentar, etc.


Falando em documentar, definimos que teremos DOIS documentos apenas. O de hardware (um dos mais importantes do projeto) que será desenvolvido mais pro final e o de software que será desenvolvido dentro do próprio código usando softwares como o Oxygen, que gera a documentação com base nos comentários do código. Assim evitamos de ter duas fontes para atualizar.


Ainda não decidimos se TODOS da equipe se focarão nas atividades exclusivas daquela funcionalidade, ou se um do time pode começar outra atividade paralela. Eu acredito que o ideal seja todos se focarem numa funcionalidade, assim todos vivenciam o máximo de "teamwork".

Ufa! Finalizamos tudo isso em aproximadamente 4h30. Tivemos nossa experiência com uma primeira "Scrum meeting estratégica" de fato. E aprendemos conforme foi acontecendo. Eu, por exemplo, por diversas vezes me vi não como um "scrum master", mas sim como um "gerente de projetos tradicional": influenciei em alguns resultados e idéias. Em pelo menos duas vezes eu consegui me tocar disso e ainda comentei: "desculpem, estou me metendo e isso é com vocês".

Enfim, posso dizer que foi muito legal. Pudemos ter tudo isso de forma mais tangível e visual. Assim conseguimos tomar diversas decisões.


O comentário, ao final da reunião, foi único entre a equipe: se tivéssemos aplicado isso alguns meses antes, hoje estaríamos apenas mexendo em funcionalidades não prioritárias. Realmente, é difícil de não concordar vivenciando uma metodologia ágil em um ambiente de caos e incertezas.

E você? Já fez seu SCRUM? :)

Abraços