Técnicas de estimação ágil

Abstract

Estimar o esforço de trabalho em projectos ágeis é fundamentalmente diferente dos métodos tradicionais de estimação. A abordagem tradicional é estimar usando uma técnica “bottom-up”: detalhar todos os requisitos e estimar cada tarefa para completar esses requisitos em horas/dias, depois usar esses dados para desenvolver o cronograma do projeto. Os projetos ágeis, ao contrário, usam uma abordagem “top-down”, usando técnicas de estimativa de nível bruto em conjuntos de características, depois empregam elaboração progressiva e métodos de planejamento de ondas rolantes para detalhar até o nível de tarefa em uma base “just-in-time”, descobrindo iterativamente mais e mais detalhes a cada nível para baixo. Este trabalho irá desenvolver duas técnicas comuns para uma estimativa ágil (planejamento de poker e agrupamento de afinidades), bem como tocar em como os resultados desses exercícios fornecem informações sobre o cronograma de previsão e orçamento.

Top-down vs. Bottom-up

O método tradicional para estimar projetos é passar várias semanas ou meses no início de um projeto definindo os requisitos detalhados para o produto que está sendo construído. Uma vez que todos os requisitos conhecidos tenham sido elucidados e documentados, um gráfico de Gantt pode ser produzido mostrando todas as tarefas necessárias para completar os requisitos, juntamente com cada estimativa de tarefa. Os recursos podem então ser atribuídos a tarefas e ações como carregamento e nivelamento ajudam a determinar a data final de entrega e o orçamento. Este processo é conhecido como um método bottom-up, pois todos os detalhes relativos ao produto devem ser definidos antes que o cronograma e o custo do projeto possam ser estimados.

Na indústria de software, o uso do método bottom-up tem sérios inconvenientes devido à velocidade atual de mudança. A velocidade da mudança significa que a velocidade das novas ferramentas de desenvolvimento e a velocidade de acesso a novos conhecimentos é tão grande que qualquer atraso na entrega deixa uma aberta a alternativas competitivas e em perigo de entregar um produto obsoleto (Sliger, 2010).

O método top-down aborda esta questão chave, usando a informação actualmente disponível para fornecer estimativas grosseiras. O planejamento de ondas rolantes é então usado para incorporar novas informações à medida que são aprendidas, refinando estimativas e elaborando iterativamente com mais detalhes à medida que o projeto avança. Este método de aprendizagem apenas o suficiente para começar, com um plano para incorporar mais conhecimento à medida que os resultados do trabalho evoluem, permite à equipe do projeto reagir rapidamente às adversidades e mudanças na demanda do mercado.

Técnicas de estimativa

Técnicas de estimativa de nível cruzado estão em uso pelas equipes usando abordagens ágeis como Scrum e Programação Extrema, e este artigo irá cobrir duas das técnicas mais populares: Planejamento de Poker e Agrupamento de Afinidade. As unidades de estimativa usadas também serão examinadas, pois estas unidades devem ser tais que não possam ser confundidas com o tempo.

Planning Poker

A técnica mais popular de estimativa de nível bruto é o Planning Poker, ou o uso da sequência Fibonacci para atribuir um valor de ponto a uma característica ou item (Grenning, 2002). A sequência de Fibonacci é uma série matemática de números que foi introduzida no século XIII e usada para explicar certos aspectos formativos da natureza, tais como a ramificação de árvores. A série é gerada pela soma dos dois números anteriores para obter o próximo valor na sequência: 0, 1, 1, 2, 3, 5, 8, 13, 21, e assim por diante. Para fins de estimação ágil, alguns dos números foram alterados, resultando nas séries seguintes: 1, 2, 3, 5, 8, 13, 20, 40, 100.

Estes números estão representados num conjunto de cartas de jogo (ver Anexo 1). Os membros da equipe jogam “Planejamento de Pôquer” (Anexo 2) para fornecer uma estimativa na forma de um valor em pontos para cada item. Aqui estão os passos:

• Cada membro da equipa recebe um conjunto de cartas.
• O dono da empresa (que NÃO recebe uma estimativa) apresenta o item a ser estimado.
• O item é discutido.
• Cada membro da equipa selecciona privadamente uma carta representando a sua estimativa.
• Quando todos estão prontos, todos os cartões selecionados são revelados ao mesmo tempo.
• Se todos os membros da equipe selecionaram o mesmo cartão, então esse valor de ponto é a estimativa.
• Se os cartões não são os mesmos, a equipe discute a estimativa com ênfase nos valores periféricos:
  • O membro que seleccionou o valor mais baixo explica porque seleccionou o valor.
  • O membro que seleccionou o valor mais alto explica porque seleccionou o valor.
• Seleccionar novamente até as estimativas convergirem.
• Deve resultar conversas longas ou “in-the-weeds”, os membros da equipa podem usar um temporizador de dois minutos para cronometrar a discussão, seleccionando novamente cada vez que o temporizador se esgota, até à conversão.
• Repetição para cada item (Cohn, 2006, pp. 56-57).

Existem várias razões pelas quais os números Fibonacci são utilizados, e utilizados neste formato. Primeiro é a noção de que uma vez que as equipes eliminam o tempo como base de estimativa, é menos provável que elas exijam mais detalhes e estimativas de blocos. Estes números representam, em vez disso, o tamanho relativo e não o tempo. Como resultado, o exercício de estimativa é bastante rápido. As equipas geralmente gastam cerca de dois minutos em cada item, permitindo uma acumulação de 30 itens a serem estimados numa hora. O fato das equipes estarem limitadas a apenas 9 escolhas (ou seja, valores de pontos ou cartões) também ajuda a acelerar o processo.

A seqüência também fornece o nível certo de detalhes para características menores e mais bem compreendidas, enquanto evita uma falsa sensação de precisão para estimativas mais altas. Por exemplo, um item com uma estimativa elevada (20 ou superior) significa que o item é grande e ainda não é bem compreendido. Debater se o item era um 20 ou um 19 ou um 22 seria uma perda de tempo, pois simplesmente não há dados suficientes disponíveis. Quando o item se aproximar da iteração em que será trabalhado, pode ser dividido em peças menores e estimado em números mais granulares (1-13). Itens com estimativas de pontos de 1-13 geralmente podem ser completados em uma única iteração (1-4 semanas).

É importante notar que os pontos não têm o mesmo significado entre equipes; por exemplo, os “cinco” de uma equipe não se igualam aos “cinco” de outra equipe. Assim, a velocidade da equipa, que é derivada dos pontos, não deve ser usada para comparar a produtividade entre equipas.

Affinity Grouping

Uma forma ainda mais rápida de estimar, e uma usada quando o número de itens a estimar é grande, é o affinity grouping. Os membros da equipe simplesmente agrupam itens do mesmo tamanho, resultando em uma configuração similar à do Quadro 3. O método é simples e rápido:

• O primeiro item é lido para os membros da equipe e colocado na parede.
• O segundo item é lido e a equipe é perguntada se ele é menor ou maior que o primeiro item; a colocação na parede corresponde à resposta da equipe (maior é para a direita, menor é para a esquerda).
• O terceiro item é lido e pergunta-se à equipa se é menor ou maior do que o primeiro e/ou segundo item; o item é colocado na parede em conformidade.
• O controlo é então entregue à equipa para terminar o agrupamento de afinidade para o resto dos itens.

As equipas podem escolher continuar da mesma forma, colocando um item de cada vez na parede após a discussão em grupo. Entretanto, uma maneira mais rápida é fazer com que cada membro da equipe selecione um item e o coloque baseado em seu próprio melhor entendimento. Isto é feito com todos os membros da equipe trabalhando em paralelo até que todos os itens tenham sido avaliados e colocados na parede. Várias centenas de itens podem ser estimados em um tempo relativamente curto. Uma vez que todos os itens estejam na parede, a equipe revisa os agrupamentos. Os itens que um membro da equipe acredita estar no grupo errado são discutidos e movidos, se apropriado.

Once o agrupamento de afinidade está completo, valores de unidade de estimativa, como pontos, podem ser atribuídos. No Quadro 3, o primeiro conjunto na extrema esquerda seria rotulado como tendo um valor de 1 ponto, o segundo conjunto seria 2 pontos, o terceiro conjunto 3 pontos, o quarto conjunto 5 pontos e o último conjunto 8 pontos.

Affinity grouping também pode ser feito para outras unidades de estimação, tais como tamanhos de camisetas. A mostra 4 mostra um exemplo de itens agrupados por afinidade etiquetados com tamanhos de camisetas em vez de pontos.

Unidades de estimativa

O uso de tamanhos de camisetas (Extra Small , Small , Medium , Large , Extra Large ) é outra forma de pensar em tamanhos relativos de características. Esta é uma saída ainda maior do sistema numérico, e como todas as boas unidades de estimativa de nível bruto não podem de forma alguma ser associadas a um período de tempo específico.

Outras fichas de medição arbitrárias incluem Gummi Bears, NUTS (Nebulous Units of Time), e foot-pounds. As equipes podem criar suas próprias unidades de estimativa e, como você pode ver, elas geralmente se divertem um pouco ao fazê-lo.

Este artigo não cobre o uso de unidades baseadas no tempo, tais como dias e/ou horas ideais de desenvolvimento. Estas já são comuns e bem compreendidas, pelo que as suas explicações não foram incluídas. Vale notar, no entanto, que a estimativa gross-level estimating tem o potencial de ser mais bem sucedida quando dissociada da noção de tempo. Como as estimativas de tempo são frequentemente transformadas em compromissos por parte da gerência e dos negócios, os membros da equipe sentem mais pressão para serem o mais precisos possível. Como resultado, eles solicitam cada vez mais detalhes sobre o item que está sendo estimado. Isto transforma a estimativa de nível bruto na estimativa de nível de detalhe mais demorada e derrota a intenção e propósito originais.

Provisão de cronograma e orçamento

Após as estimativas de nível bruto e a velocidade da equipe serem determinadas, o cronograma e o orçamento podem ser previstos. As equipes determinam sua velocidade somando o número total de pontos para todos os itens que completaram em uma iteração. Por exemplo, uma equipe pode ter selecionado cinco itens com um valor total de pontos de 23 pontos (ver Anexo 5). Ao final de sua iteração de duas semanas, eles conseguiram completar apenas quatro dos cinco itens. Sua velocidade é 15, ou seja, a soma dos valores de pontos dos itens 1-4. As equipas não recebem “crédito parcial” por completarem partes de um item, por isso mesmo que tivessem começado no item 5, este não contaria, pois não foi completado.

Determinando o cronograma

A velocidade média da equipe é usada na previsão de um cronograma de longo prazo. A velocidade média é calculada pela soma das medidas de velocidade das três últimas iterações da equipe, e dividindo esse total por três. Assim, se uma equipa completou 15 pontos na sua primeira iteração, e 20 pontos em cada uma das duas iterações seguintes, a velocidade média da equipa é de 18 (15+20+20 / 3). Se uma equipa consegue fazer 18 pontos numa iteração em média, e há 144 pontos de trabalho a completar no projecto, serão necessárias oito iterações para completar o trabalho (144 / 18). Se cada iteração for de duas semanas, então a previsão de conclusão é de 16 semanas. Este método permite-nos responder à pergunta: “Quando vamos terminar todo este trabalho?”

Se a equipa tiver um registo de dados de velocidade, é possível determinar a data de conclusão mais optimista, a mais pessimista, e a mais provável. O número de velocidade média da equipe é usado para calcular o cenário mais provável, enquanto os números de velocidade das iterações de pior desempenho da equipe são usados para calcular a data de conclusão da previsão mais pessimista. Usando a velocidade das iterações em que a equipa foi capaz de completar mais do que o esperado fornece a previsão mais optimista.

Também podemos usar estes números para responder à pergunta, “Temos de entregar algo até esta data – destas características, quantas teremos feito até lá? Veja o Quadro 6 para um exemplo da previsão mais provável da quantidade completa, a previsão pessimista e a previsão otimista. Este exemplo é para uma equipe cuja velocidade média é 20, e que tem uma velocidade de pior desempenho de 12 e uma velocidade de melhor desempenho de 25. Tendo em conta isto e apenas seis semanas (três iterações), quanto pode ser completado? A previsão pessimista é que apenas os itens 1-8 serão feitos em seis semanas. A previsão otimista é de que os itens 1-18 serão completados. E a previsão mais provável, baseada na velocidade média da equipe de 20, é que os itens 1-13 serão completados em seis semanas.

Se as equipes estiverem usando unidades de estimativa não-numéricas, como tamanhos de camisetas, os algoritmos de previsão serão mais complexos. Recomenda-se que os tamanhos sejam convertidos para um sistema numérico para gerar mais facilmente dados semelhantes. Por exemplo, um Small poderia ser convertido para um NUT de 3, um Medium para um NUT de 5, e assim por diante. Estes também podem ser convertidos para intervalos de tempo (um Small pode ser de 1-3 dias, por exemplo) mas isto é inerentemente arriscado, devido a questões já citadas na secção Unidades de Estimação.

Orçamento Determinante

Nesta seção nós olhamos para responder: “Nós só temos esse dinheiro – quanto tempo ele vai durar e quanto teremos feito antes de acabarmos?” Primeiro, uma fórmula simples é usada para determinar o custo por ponto:

Σ (salários da equipe carregada para o período n) / pontos completados no período n

Toma a soma dos salários da equipe (carregada) por um período de tempo, digamos três iterações de duas semanas, e divide isso pelo número de pontos que a equipe completou no mesmo período de tempo. Assim, uma equipe cujos salários totais carregados são $240.000 durante seis semanas, e completou 60 pontos de trabalho nessas três iterações, teria um custo por ponto de $4.000. Agora use a seguinte fórmula para determinar o orçamento:

(Custo por ponto x valor total de pontos de itens a serem concluídos) + outras despesas = orçamento previsto

Bastante frequentemente nem todas as características de um produto são definidas no início de um projeto, o que é o esperado para projetos ágeis. Portanto, as estimativas de orçamento são baseadas no que sabemos hoje, mais um algoritmo de previsão que é baseado em dados históricos ou orientação de especialistas. Por exemplo, digamos que existem apenas 20 recursos listados até agora, mas o negócio não será capaz de fornecer nenhum pedido ou refinamento adicional de recursos até que veja como o primeiro lançamento é recebido pelo cliente. O orçamento para o projeto, que está previsto para três versões, teria apenas dados previstos disponíveis para a primeira versão e não para o projeto inteiro. A equipe poderia usar o algoritmo acima para prever o orçamento para a primeira versão, depois assumir 20% adicionais para a segunda versão e 5% adicionais para a última versão, com base na experiência passada.

A velocidade, previsões de orçamento e previsões de cronograma são revistas a cada iteração. Isto é parte do processo de planejamento de ondas rolantes que os projetos ágeis atribuem a.

Palavras Finais

Notavelmente não abordada neste artigo é a falta de técnicas de estimação estruturadas utilizadas em abordagens lean como Kanban. Ao invés de gastar (desperdiçar) tempo estimando itens, o ciclo médio e os tempos de execução são calculados com base nas taxas de produção reais da equipe. Kanban utiliza o teorema matemático da Lei de Little como base para suas fórmulas. Usando cálculos de lead time derivados de diagramas de fluxo acumulados, as equipes prevêem cronogramas de projetos sem gastar nenhum tempo adiantado preparando estimativas. O leitor é encorajado a fazer pesquisas independentes sobre este tópico, que poderia ser um trabalho separado por si só.

Projetos ágeis são destinados a entregar um produto ou incrementos de produto cedo e com freqüência, a fim de incorporar o feedback do cliente e outros aprendizados no próximo lançamento. Ao gastar mais tempo em experiências, execução e aprendizado, e menos tempo em especulações, o tempo de ciclo para entrega é reduzido. As equipes ágeis são mais capazes de competir no mercado e acompanhar a velocidade cada vez maior das mudanças.