Scrum para Tradicionalista – Tarefas 

Nov/09
5

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.

2 comentários para “Scrum para Tradicionalista – Tarefas”

  1. Muito legal os seus posts sobre Scrum.

    Parabens

  2. Isso mesmo; a tendência agora não é focar em pessoas (tarefas que fulano de tal fez) e sim RESULTADOS.

    Parabéns,

Comente

Enquete

Sobre quais assuntos gosta de ler neste blog ?

View Results

Loading ... Loading ...

Artigos