Personalizando sua abordagem Ágil: O que você precisa para estimar?

Muitas abordagens ágeis presumem que times farão estimativas em pontos de história (story points) que guiarão o projeto em uma velocidade mensurável. Mas nossa noção intuitiva de velocidade nos diz que a distância é uma medida padrão e repetível. A maioria das equipes não têm pontos de normalização com o time e certamente também não têm entre equipes. Ao invés de velocidade, considere contar as histórias ou utilizar o tempo de iteração para estimar. Pode ser que você não precise medir a velocidade no final das contas.

Este é o terceiro artigo da série que irá ajudar a pensar sobre como podemos personalizar a abordagem ágil para cada contexto. Este artigo é sobre o que e quando estimar.

Em cada projeto que trabalhei, tanto por conta própria, quanto para outras organizações, alguém quis saber quanto tempo a atividade poderia levar. Isso faz sentido se pensarmos sobre uma ordem de grandeza da estimativa. A equipe pode estar pronta para dizer "Fizemos alguns projetos como este no passado, um deles levou três e o outro 13 meses. Pensamos nos requisitos, até onde sabíamos, parecia mais um projeto de três meses. Entretanto, o código mudou e então adivinhe: Seis meses e estávamos prontos para estimar melhor depois das primeiras semanas, uma vez que trabalhamos no código de maneira mais profunda".

Esse é um primeiro passo razoável para a estimativa. Contudo, para muitas equipes pontos de história são um caminho para estimar. Isso pode criar problemas, principalmente porque as pessoas não entendem velocidade.

Velocidade é uma estimativa de capacidade pontual

Velocidade é uma taxa de modificação com uma direção. Pessoas frequentemente confundem velocidade com aceleração. Velocidade não é aceleração.

Imagine que está caminhando ou correndo pelo bairro para se exercitar. A meta do exercício é caminhar ou correr duas milhas todos os dias.

Na primavera, verão e outono, quando o clima está bom, é possível correr em um ritmo aproximado de 4 milhas por hora e finalizar a corrida em 30 minutos.

Entretanto, caminhando ou correndo todos os dias, independente do clima. Quando chove, você não corre; você caminha. E você caminha devagar porque não está usando tênis apropriado para caminhada. Ao invés disso usa botas de borracha para não molhar os pés. A caminhada terá um ritmo diferente: 3 milhas por hora e será finalizada em 45 minutos.

Na neve, não é possível caminhar nem mesmo a 3 milhas por hora. Calçando botas, a caminhada fica ainda mais devagar para não cair na neve ou no gelo que não consegue enxergar. Com isso diminui para 2 milhas por hora e com isso levará uma hora para caminhar a mesma distância.

A caminhada tem a mesma distância de sempre, entretanto, com uma grande diferença: você não estará na mesma velocidade e não atingirá a mesma distância no mesmo tempo que gostaria. Isso depende do clima, do tipo de calçado e das condições do terreno.

Este problema é o mesmo com as equipes de software, a velocidade depende da taxa estável de realização. Os fatores que afetam as taxas da sua equipe são:

1. Tamanho das histórias. Quanto maior a história, mais riscos a equipe terá de enfrentar para concluí-la, quando pensarem que podem realizá-la. Mesmo que o time seja preciso sobre longas histórias, lembre-se, clientes compram histórias e não pontos de história. Veja Customize Your Agile Approach: Start with Results para ver relatórios gráficos de burnup sobre histórias completas ao invés de pontos de história.

2. O estado atual dos códigos e dos testes. Quanto mais testes unitários e de sistemas forem automatizados no código, menos riscos a equipe terá quando adicionarem ou mudarem as funcionalidades.

3. Estabilidade da equipe. Quando uma equipe possui estabilidade podem assumir que as histórias serão levadas adiante. Entretanto, se a equipe muda, mesmo que somente uma pessoa, será difícil manter a mesma velocidade. Novos membros deverão aprender o código e como a equipe trabalha.

Podemos pensar se a mesma equipe sempre estima pontos de história ela deveria ser capaz de prever o que podem entregar. Acho a estimativa em pontos de história útil se as histórias são de um, dois ou no máximo três dias.

Entretanto, quanto maiores e mais variados forem seus tamanhos, maior dificuldade as equipes terão para prever pontos de história. Isso porque quanto mais pontos de história, mais o risco relativo aumenta.

Uma equipe tem dados históricos informando que podem entregar 42 pontos de história por interação. Provavelmente existem histórias com 1, 2 e 3 pontos. Estas histórias levam aproximadamente meio dia, um dia ou um dia e meio cada. Isso significa que podem trabalhar relativamente de forma independente e concluir o trabalho.

Contudo, na próxima interação selecionam três histórias de 13 pontos (39 pontos) e uma história de 3 pontos, adicionando 42 pontos. Ainda assim os primeiros 13 pontos de história, mesmo que as equipes utilizem swarm (quando equipes desenvolvem juntas com o objetivo de realizar uma funcionalidade completa) para uma história, levariam 8 dias inteiros.

A equipe não é ineficiente ou preguiçosa, apenas subestimou a complexidade e as áreas de código da história trabalhada. Isso porque quanto maior a unidade de medida estimada, mais as estimativas podem ser anuladas por essas unidades. (Veja Predicting the Unpredictable para uma explicação mais ampla deste fenômeno).

Pontos de história podem ter significado se as histórias têm o mesmo tamanho aproximado. Entretanto, diversas histórias, com um ou dois pontos, não exigem o mesmo esforço de cinco ou oito pontos de história.

Ao invés de pensar na velocidade como capacidade de medição onde você pode, em média, entregar alguns números de histórias, alguns números de correções ou qualquer outra coisa que sua equipe entregue em alguma forma cadenciada. Este é um caminho para estimativa.

Talvez isso não seja o suficiente. Muitas equipes ágeis utilizam estimativa relativa.

Utilização de estimativa relativa enquanto equipe

Utilizando abordagens ágeis por um período tenho certeza de que já ouviu sobre estimativa relativa com planning poker. As equipes se reúnem para estimar o trabalho que irão fazer na próxima iteração. Cada pessoa tem um cartão com números como a sequência fibonacci ou tamanhos de camisetas. O product owner (PO) explica a história, os membros do time levantam um carta para explicar o quão grande é a história.

Pode ser que nem todos os membros da equipe concordem como tamanho relativo. A conversa sobre o tamanho é o importante. Os membros discutem o código, o design, os testes (ou a falta deles), além de outros riscos observados.

A conversa é crítica para a equipe entender a história e quando decidem que a história é maior que "1", a equipe sabe que existe incerteza na estimativa. (Veja Story Points and Velocity: The Good Bits do autor Pawel Brodzinski para mais informações sobre este problema de estimativas.)

Evitando estimativas baseadas em tarefas

Algumas equipes tentam dividir o trabalho em tarefas. Tenho um problema com estimativas baseadas em tarefas. Com frequência vejo equipes tentando utilizar recursos de forma eficiente, otimizando por pessoas ao invés de fluxo eficiente, onde otimizamos por times. Quando as equipes perdem a visão de trabalho do grupo, movendo a história no quadro para pronta, existe muito trabalho em progresso. Eles frequentemente não liberam funcionalidades, ao invés disso, lançam o trabalho parcialmente completo e que não agrega valor. Este trabalho não ajuda os clientes. As equipes começam a contar pontos completos ao invés de contar funcionalidades completas.

Ao invés disso, podemos considerar utilizar histórias maiores que um dia para entender incertezas. Se desejarmos usar a estimativa relativa para entender a incerteza sobre o trabalho aqui estão algumas dicas:

• Lembre-se de que a estimativa será anulada por unidades estimadas. Se, por exemplo, existe uma história de três pontos, a estimativa pode ser mais ou menos três pontos. Isso começa a se transformar em um problema se as histórias são de 8, 13 ou mais pontos. Nesses casos, a história de 8 pontos poderia agora levar o equivalente a 16 pontos.
• Pergunte-se porque acha este trabalho tão grande. Aqui estão algumas possibilidades: o código está uma bagunça; os testes unitários ou o sistema de testes automatizados para checar mudanças são insuficientes para detectar mudanças; o trabalho é muito maior que uma história, é um conjunto de funcionalidades completas.

Podemos encontrar tarefas úteis quando discutimos uma história, lembre-se que os clientes não podem utilizar resultados de tarefas. Clientes compram e utilizam funcionalidades completas.

Especialmente para grandes histórias, tarefas podem ajudar a entender onde existem incerteza neste trabalho. Não recomendo que a equipe divida o trabalho em tarefas. Entretanto, perceba que uma vez iniciada a lista de tarefas pela equipe, os riscos e incertezas para esta história poderão ser melhor avaliados. Além disso histórias menores poderão ser descobertas, melhor estimadas e entregues antes.

Foco exclusivo para esclarecer o trabalho

Normalmente gosto de histórias de um dia, quando equipes as terminam no mesmo dia. Podemos pensar como uma equipe pode terminar uma história em um dia. Quando equipes desenvolvem juntas com o objetivo de realizar uma funcionalidade completa (swarm) ou utilizando uma única estação de trabalho com objetivo de gerar resultado (mob), podem terminar histórias mais rápido do que uma só pessoa. (Veja Pairing, Swarming, and Mobbing para mais detalhes sobre como a equipe pode utilizar o pensamento coletivo com swarm e mob ) Abordagens ágeis não consideram o que uma pessoa pode fazer e sim a habilidade da equipe em mover as funcionalidades para "Feitas".

Podemos pensar sobre a perspectiva de trabalhar em dupla (pairing), swarm, mob versus trabalhos individuais. As abordagens ágeis trabalham bem quando equipes colaboram para mover uma história de "Para fazer" para "Feito", independente das colunas em seu quadro. Poucas equipes tiram vantagens da colaboração interna, muitas equipes colaboram com clientes ou usuários, mas não com os membro da equipe. Pairing, swarming e mobbing ajudam os membros da equipe a aprender detalhes do produto e entregar um produto de maior valor agregado. (Veja How Pairing / Swarming Work / Why They Will Improve Your Products para mais informações.)

Poucos POs e equipes são capazes de criar histórias com um dia de duração. Eles não enxergam como quebrar uma história de um dia inteiro. A equipe pode usar pontos de história mais longos para discutir incerteza, por exemplo, se a equipe pode entender que um uma história com oito ou mais pontos tem muita incerteza, ela pode ter uma política com mais discussão como foco exclusivo na história ou juntando o time para o desenvolvimento em apenas um computador (mobbing). Outra opção seria, a equipe e o PO trabalharem na história e verificar se é uma funcionalidade completa ou uma história composta . Ou ainda, a equipe pode utilizar um dia de foco exclusivo para entender melhor a história.

Aqui está como uma equipe utilizou o foco exclusivo de um dia para explorar, distribuir e entender melhor a história. Jim foi o PO de uma equipe com seis pessoas: Quatro desenvolvedores e duas pessoas para testarem. Ele visitou um cliente e sabia o que este queria, ele podia enxergar somente as as funcionalidades como um todo. Ele teve problemas quebrando todas as funcionalidades em diversas histórias e então solicitou à equipe que se juntassem em um esforço único (swarm) para ajudá-lo na verificação dos riscos.

1. A equipe se reúne às 1:30pm, depois do almoço. (Desde que o time esteja junto para trabalhar não precisam se reunir na parte da manhã, o dia pode começar quando todos estiverem prontos para trabalhar.)

2. A equipe concorda com as entregas: entregar uma pequena funcionalidade e responder às seguintes questões:

1. Quais são todas as histórias deste trabalho?
2. Onde estão os riscos?
3. Qual é o primeiro valor que podemos entregar?

3. A equipe decidiu que poderia trabalhar até às 5pm daquele dia, permitindo que as pessoas saíssem ou verificassem emails. Contudo, deveriam retornar juntos às 10am na manhã do próximo dia. Também poderiam trabalhar até o horário do almoço, 12:30 pm e encontrar Kim às 1:30pm do dia seguinte. Isso caracterizaria um dia de trabalho.

4. A equipe decide primeiro formar duplas com desenvolvedores e testers para entender como todo o conjunto de funcionalidades poderia trabalhar e na sequência verificar o que fazer depois. Eles podem decidir por fazerem swarm ou mob desde o início mas ficaram com muitas dúvidas, então decidiram trabalhar em duplas (pairing) e depois se reunirem em uma hora. Veja como o dia deles ficou:
   1. Às 1:30 pm, Jim explicou os objetivos que desejava para o cliente. Os membros da equipe perguntaram o que ele respondeu. Ele tinha uma ideia superficial do que significava trabalho feito (done), mas não tinha certeza e queria interagir com o time.
   2. Às 2pm, a equipe se dividiu em dois pares de desenvolvedores e um par de testers concordando em se reunir novamente às 3pm.
   3. Às 3pm, os membros retornam para a sala de reuniões, cada par explicou o que havia descoberto e o que haviam finalizado naquela última hora. Além disso, decidiram não trocar os pares naquele momento.
   4. Às 4pm, a equipe se reuniu novamente para ver onde estavam. Um dos pares de desenvolvedores tinha um protótipo e gostaria que Jim e a equipe comentassem. A dupla de testers tinham alguns testes automatizados também queriam feedback. Jim deu seu feedback e comentou os testes, ele ainda refinou o que desejava e os pares permaneceram trabalhando na mesma formação.
   5. Às 5pm, a equipe se reuniu novamente com Jim, agora eles estavam no caminho certo. Algumas pessoas saíram às 5:15pm, normalmente o final do dia para eles, outras organizaram os emails deixando trabalho para o próximo dia.
   6. Às 9:30am da manhã seguinte, cada um retornou ao trabalho após organizarem seus emails e então puderam retornar ao trabalho em time. A equipe teve uma breve reunião para reconectar e se manter em pares, então decidiram se reunir novamente às 10:30 am.
   7. Às 10:30 am, a equipe se reuniu novamente e pediram mais feedback a Jim. Agora ambos os times de desenvolvedores tinham um protótipo que precisavam ser apresentados ao Jim e ao restante da equipe. Os testers tinham mais testes automatizados que ajudaram os desenvolvedores a saberem o que haviam feito. Jim forneceu feedback e agora os pares se transformaram em duas tríades, dois desenvolvedores e um tester cada.
   8. Às 11:30 am, os membros da equipe se reuniram novamente com Jim. Cada tríade havia completado uma pequena história com testes unitários e de sistema automatizado. As equipes puderam ver onde estavam as histórias e usaram os próximos 30 min. trabalhando nas histórias remanescentes com Jim. Eles estavam prontos para responder às questões e explicar que o desempenho para este conjunto de funcionalidades seria um grande risco.

Esta equipe em particular utilizou pares e tríades para swarm. Outras escolhem desenvolver com swarm, mas como indivíduos, onde cada pessoa trabalha por si só em um determinado período de tempo checando com o restante da equipe de hora em hora.

Entretanto poderiam ter decidido utilizar mob e não seriam obrigados a se reunir a cada hora, especialmente se Jim estivesse com eles no escritório.

Quando a equipe trabalha com foco exclusivo em pontos específicos como times, eles aprendem o que podem completar em um dia, aprendem o que precisa ser feito em todo o trabalho e onde podem estar os riscos.

Se a equipe perceber que o trabalho ainda está muito complexo, eles terão as seguintes opções: considerar um novo dia de engajamento total (spike day), se reunirem para detalhar o trabalho com o PO, ou estimar o trabalho normalmente.

Ao invés de estimar pelo tamanho, pegamos a ideia de capacidade do passo seguinte e consideramos contar as histórias.

Contagem de histórias ao invés de estimativas

Um dos benefícios de contar as histórias é que a equipe tende a padronizá-las em um tamanho confortável para trabalhar. Uma equipe pode preferir histórias de um dia, outras de tres dias. Independente do tamanho, se elas contarem as entregas, as equipes irão trabalhar no tamanho ideal das histórias para si.

Podemos imaginar se a contagem resultará em um padrão de histórias ou se a equipe pode padronizar histórias em um tamanho razoável se as contarem. Não importa qual o primeiro, contagem ou padronização, a chave é que a equipe foque no que deve ser entregue: histórias completas. Uma vez iniciada as contagens, ao invés de pontos de histórias, as equipes mudam de comportamento. (Veja: Customize Your Agile Approach: Start with Results You Want para ver como medir histórias ao invés de pontos.)

Quando a contagem é uma novidade para a equipe, poderia pensar em ignorar o tamanho relativo da história. Uma iteração fornece o que precisam para rever o tamanho da história ou o tempo de iteração.

Contar histórias permitem que a equipe visualize seu desempenho facilmente. Além disso, como a contagem tende a ajudar a equipe na padronização do tamanho das histórias as equipes não precisam realizar muitas estimativas, isso se precisarem.

Ao invés de perder tempo estimando, o PO e sua equipe usam o tempo realizando histórias com mais ou menos o mesmo tamanho. Contudo, uma história pode levar menos tempo que outra. Ao longo do tempo as histórias se transformam adotando um tamanho similar entre si. Outro benefício é que as equipes não se ocupam com estimativas baseadas em tarefas.

Para usar dados na contagem de histórias use o tempo de iteração. Ele é o tempo que a equipe leva para trabalhar e mover uma história para feita. Podemos utilizar uma tabela parecida com esta caso o trabalho possua iterações:

Trabalhando em fluxo, basta medir o ciclo de histórias para as cinco ou seis atividades mais recentes e então teremos uma aproximação razoável do tempo de iteração.

Agora, sabendo que cada história leva em média 2,5 dias, a equipe pode dizer "Podemos concluir quatro histórias em cada iteração". Esta é uma contagem útil.

Considere não estimar

Existe um movimento chamado #NoEstimates (Sem Estimativa). A ideia é que se temos um fluxo constante de trabalho da equipe não é necessário estimar. Para que ela funcione as histórias devem ser pequenas, assim a equipe pode completar o fluxo de trabalho para revisão de forma contínua.

Às vezes as estimativas da equipe não são mais úteis, veja essas experiências:

• O PO deseja alterar as história depois que sua equipe as entregou;
• A equipe percebe que as pequenas histórias não são pequenas;
• A equipe percebe que o código ou os testes não são como esperavam.

A equipe percebe que as estimativas não são úteis e neste caso contar as histórias pode ajudar a equipe mais que as estimativas.

Ao apresentar à gerência ou clientes trabalhos realizados pela equipe no intervalo de cada uma ou duas semanas, pode ser que as estimativas não sejam necessárias.

Resumo

As equipes têm muitas opções para estimar. Não acho útil trabalhar com velocidade de pontos de história como forma de prever o que a equipe pode terminar, a menos que a equipe faça uma história pequena como histórias de um ou dois dias. Acho tempo de iteração mais úteis em todas as circunstâncias porque utilizam dados históricos da equipe.

Para estimar o trabalho da equipe, verifique se é possível criar histórias de um dia e contá-las. Caso não seja, considere o foco exclusivo (spike) para entregar alguma funcionalidade pronta de um dia junto com histórias remanescentes.

Se for possível verificar o fluxo de trabalho da equipe finalizando uma história completa todos os dias. Isso pode eximir de estimar como um todo.

Sobre a autora

Johanna Rothmanconhecida como a "Gerente Pragmática" aconselha francamente em problemas difíceis. Ela ajuda líderes e equipes a enxergar problemas, mitigar riscos, e gerenciar seu produto em desenvolvimento. Rothman é autora de mais de 10 livros, incluindo: Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver, Agile and Lean Program Management: Scaling Collaboration Across the Organization, Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, 2nd ed., para ler mais conteúdos da autora acesse jrothman.com.