Scrum - Pontos de história e horas de desenvolvedores

Por Cesar Brod

Data de Publicação: 19 de Novembro de 2014

A transição de atitudes, métodos e processos de formas clássicas de desenvolvimento para as ágeis implica, certamente, em algumas mudanças profundas de paradigmas.

É muito raro - e eu tive essa oportunidade apenas duas vezes em mais de 15 anos trabalhando com Extreme Programming e Scrum - aplicar métodos ágeis com equipes absolutamente novas, com desenvolvedores com pouca experiência prévia e gestores ou patrocinadores com total receptividade em aceitar malucos mudando mobiliário de lugar e colorindo antigas divisórias, paredes e até janelas com etiquetas adesivas, à frente das quais conduzem rápidas e divertidas reuniões diárias.

É muito mais comum que um executivo de uma empresa desenvolvedora de algum tipo de produto resolva adotar, depois de ouvir as boas novas de seus contrapartes em outras companhias, esse novo "framework" - que inclui papéis, ritos e artefatos - chamado Scrum, na esperança que ele aumente assustadoramente a produtividade de equipes.

Jeff Sutherland mostrou em sua apresentação "Scrum, the future of work", de 2012, que o Scrum atingira seu "Tipping Point" naquele ano, mais de dezessete anos depois que seu primeiro artigo sobre o assunto, escrito em parceria com Ken Schwabber, foi apresentado na conferência OOPSLA de 1995 (Jeff iniciou suas experiências com o Scrum em 1993). Ou seja, o Scrum não é uma coisa nova, mas levou quase duas décadas para que o conjunto de casos de sucesso, publicados ou não, e o boca a boca contribuíssem para o crescimento exponencial de sua adoção.

Em 2005, o livro "Agile Estimating and Planning", de Mike Cohn, consolidou as formas pelas quais os agilistas faziam estimativas e planejavam suas entregas. Em resumo, Mike mostrava que somos muito melhores em comparar coisas do que tentar medir algo isoladamente. Tente você mesmo! Uma pessoa entra na sala onde você está. Você consegue dizer, com exatidão, sua altura e peso? Agora, entra uma outra pessoa. Você consegue dizer se ela é mais alta ou mais baixa que a primeira? Mais magra ou mais gorda?

O livro de Mike, há quase dez anos, documentou a estimativa em pontos de histórias (history points), onde é usado o Poker do Planejamento (ou Scrum Poker) para determinar o esforço necessário para o desenvolvimento completo de uma dada história de usuário (user story).

Em resumo, a equipe toma, de seu passado, uma história que considera um nível médio de esforço para o seu desenvolvimento, por exemplo:

Eu, como dono de um cachorro, desejo cadastrar o bicho para beneficiar-me de promoções.

Para desenvolver essa história, a equipe lembra que precisou preparar a base de dados e criar um formulário de cadastro responsivo. Dentre alguns dos requisitos não funcionais estava o fato de que a aplicação deveria ser escalável e com alta disponibilidade, coisas que eram garantidas pelo ambiente adotado para o desenvolvimento. Assim, a equipe concordou que esta história receberia cinco pontos e todas as demais seriam pontuadas em comparação a ela, usando as cartas do Scrum Poker:

0, 1/2, 1, 2, 3, 5, 8, 13, 21, infinito e cafezinho

Tirando fora da equação as horas, os membros da equipe sentem-se mais à vontade de estimar com os valores arbitrários das cartas do Scrum Poker, baseados na sequência de Fibonacci. Mais sobre isso no artigo Scrum - A incrível história da convergência dos History Points. Afinal, eu posso levar quatro horas para desenvolver uma história que considero de dificuldade média, quando comparada com as várias histórias de desenvolvimento de um produto. Você, fazendo a mesma comparação, também concorda que a história tem uma dificuldade média, mesmo que você leve apenas duas horas para desenvolvê-la.

Dessa forma, mesmo que os pontos atribuídos para cada história pareçam arbitrários, eles vão ficando mais significativos na medida em que a equipe vai descobrindo sua velocidade (o número de pontos que consegue realizar em uma Sprint) e passam a balizar a quantidade de histórias que podem ser assumidas em Sprints futuras.