Falei anteriormente de como é organizada uma equipa Scrum e quais responsabilidades cada elemento desempenha.  Hoje o assunto é a palavra mais querida dos gerentes tradicionais – tarefa – e sua relação com user story.

A tarefa, no pensamento tradicional é qualquer coisa que tem que se fazer. A ideia é que sabendo as tarefas saberemos o quanto o desenvolvedor trabalhou e quanto ele se esforçou nesse trabalho (i.e. quantas horas extra fez). Algumas empresas estabelecem até um sistema de bónus baseado nas tarefas,  quantidade,  grau de dificuldade, etc …

Isto funciona ? Não.  E não funciona porque a granularidade das tarefas não é constante, ou , sequer comparável a maior parte das vezes.

As metodologias ageis, e o Scrum em particular, optaram por criar uma granularidade diferente de forma a podermos comparar coisas que têm a mesma granularidade. Em Scrum temos Estórias (User Stories)  e Tarefas (Tasks). As estorias têm granularidade funcional e são estimadas em Ponto de Estoria (Story Points). As tarefas tem granularidade de implementação e são estimadas em Horas Ideais. A escala para estimar ambas é diferente, mas ambas as escalas são discretas. Isto significa que apenas alguns numeros podem ser usados.  Por exemplo, uma estoria pode ser estimada para 3 ou 5 SP, mas não para 4 (se estivermos usando a escala baseada na sequencia de Fibonnaci). As tarefas podem ser estimadas em múltiplos de 1 hora e não mais que 16 horas. Se uma tarefa é estimada em mais de 16 horas  isso significa que a tarefa precisa ser dividida em tarefas menores.

Não ha nenhuma proporção  entre pontos de estoria da estimativa da historia e as horas estimadas para as tarefas. Não ha formulas para converter entre uma e outra.

Isto choca muitos gerentes tradicionais que estão acostumados a usar a hora como medida de tudo. A primeira razão para que não haja relação é que pontos de estoria são relativos,  enquanto que a estimativa da tarefa é determinada pela tarefa em si mesma.A segunda razão é que as estorias são estimada primeiro e as tarefas apenas quando a estória entra para o sprint.

Entendido isto, é agora hora de explicar a relação entre o esforço da estoria e da tarefa. A relação só faz sentido se incluirmos o conceito de sprint. O Sprint é um constrangimento temporal, é uma caixa de tempo (time box) em que tudo tem que caber. A quantidade de estórias que cabem num sprint é ditada pelos seus tamanhos e pela velocidade da equipa. Mas , simultaneamente espera-se que todas estas estorias do sprint estejam prontas no final do sprint. Portanto, isso significa que todas as tarefas necessárias a todas essas estorias também estejam completas até o final do sprint. O constrangimento de tempo é comum aos dois tipos de granularidade.

As estórias não são realmente executadas/implementadas, são as tarefas que são. Uma estória gera diversas tarefas necessárias que serão alocadas aos desenvolvedores. Em Scrum é obrigatorio que as estorias sejam executadas discretamente ou seja, não se começa uma sem terminar outra. Contudo, isso não significa que todas as tarefas que os desenvolvedores estão fazendo são para essa estoria. Porque as tarefas tem dependências e seguem um fluxo logico-temporal existe um limite ao numero de tarefas de uma estoria que uma equipe pode trabalhar simultaneamente. É por isso que 9 programadores não fazem um sistema 9 vezes mais depressa que 1 unico programador. Mas 2 ou 3 programadores poderiam… Tudo se resume a quantas tarefas independentes são possíveis.

Se a estoria A tem 10 tarefas mas 5 dependem do cumprimento das outras 5, e temos 7 programadores, então , obviamente os 2 programadores que sobram irão começar a fazer tarefas de outra estoria, B. Só que para isto ser possivel a estoria B e suas tarefas têm que ser independentes da estoria A e sua tarefas.

Equilibrar as coisas para ter o máximo de independência é portanto vital. Às vezes uma coisa trivial como um cadastro precisa ser dividida em tarefas menores de forma a distribuir melhor o tempo do sprint pelos desenvolvedores disponíveis.

Estórias têm uma granularidade funcional. Isto significa que elas se parecem muito com requisitos e são escritas e encontradas por pessoas perto dos interessados no software (clientes, usuários…).  A grande diferença é que as métricas para estimar requisitos são normalmente teoricas e aplicadas pelos próprios que elencam os requistos. Coisas como ponto de função ou ponto de caso de uso caem nesta categoria. E o fato é que essas métricas não funcionam.

Não funcionam porque o esforço real é feito pela equipe de desenvolvimento e não pelos levantadores de requisitos. Não apenas isso, mas também, cada equipa de desenvolvimento é diferente e produz funcionalidade a um ritmo diferente. O Scrum entende isto e pega o melhor dos dois mundos. O Dono do Produto (que substitui o funcional tradicional) enche o product backlog com as estorias que equivalem a coisas necessárias no sistema.  E a equipa estima em pontos de estoria o esforço. Entenda-se que neste ponto, a equipa precisa ter uma noção do que vai fazer , mas não necessariamente de como vai fazer ou de quem vai fazer o quê. É por isso que a estimativa em pontos de estoria é por consenso (Planning Poker) e não por maioria ou delegada ao desenvolvedor  sênior.

Algumas equipas perferem esmiuçar a estoria nas tarefas para ter uma melhor noção do que vai ser feito. Normalmente isto é muito util, mas consome muito tempo. Portanto o equilibrio é preciso ser encontrado. Contudo, esta divisão em tarefas não é oficial e não é formal. São apenas pessoas conversando e rabiscando um papel para poderem estimar melhor.

Mais tarde durante a reunião de preparação do sprint, depois que o PO escolheu as estorias que entrarão no sprint, a divisão será revisitada. Agora é para valer. Esta divisão é formal e compõe o Sprint log. Cada tarefa é agora estimada em horas ideias.  Não é feita nenhuma alocação neste momento, do tipo fulano faz A e sicrano faz B. A equipa como um todo se compromente a fazer aquelas tarefas durante o sprint.  A ordem é um pouco irrelevante, mas o Scrum obriga a que a prioridade da estoria seja respeitada, ou seja, tarefas da estoria mais prioritária são alocadas primeiro. Mas a ordem das tarefas em si mesma é irrelevante. Quem faz o quê é decidido pela própria equipa depois, durante o sprint (é por isto que um quadro estilo kanban vai bem).

Scrum divide as coisas a fazer em duas granularidades : estoria e tarefa. Estórias são pedidos de caracteristicas do software. Elas são de granularidade grossa e estimadas em Story Points. Tarefas são de granularidade fina, estimadas em horas ideias e representam coisas que serão realizadas.