Fila Ágil – Episódio 1 (Estimativas e Métricas Ágeis)

O Agilíssimo.com inicia aqui o quadro “Fila Ágil” e a dinâmica funciona da seguinte maneira:

  1. Escolhe-se um assunto do Mundo Ágil e cada um dos integrantes monta seu material;
  2. Ocorre um encontro presencial ou conferência onde cada um dos participantes possui 5 minutos para expor seu ponto e mais 10 minutos para discussão com o Grupo;
  3. Registra-se a discussão e é compilado um texto para publicação no Blog Agilíssimo;
  4. É realizada uma sessão de retrospectiva no início do próximo encontro para melhorar este processo.

 

O assunto desta “Fila Ágil” é Estimativa e Métricas Ágeis. Seguem os tópicos abordados:

  • Story Points – Como estimar de forma rápida? Bem rápida!
  • T-Shirt Sizing – Medir trabalho assim como com sua roupa
  • Horas Ideais
  • Indicadores CPI e SPI
  • Medição da Maturidade de Times Ágeis

Participantes: Luiz H. Lochetti, Cristiano Moraes, Dário Araújo, Daniel Angotti e Evandro Galvão.

 

STORY POINTS – COMO ESTIMAR DE FORMA RÁPIDA? BEM RÁPIDA! (por Luiz H. Lochetti)

Apresentarei aqui o uso prático de como utilizei uma técnica de estimativas que tem por características a #praticidade, #simplicidade e #rapidez, em uma equipe nova que acabara de se formar. Mas antes de contar como fizemos, explicarei um pouco (bem pouco) dessa técnica.

Ela tem como premissa estimar o #esforço do desenvolvimento de um item (pode ser uma estória de usuário, requisito funcional, caso de uso), comparando uns com os outros.

Como diz o Jeff Sutherland em seu livro SCRUM: A ARTE DE FAZER O DOBRO DO TRABALHO NA METADE DO TEMPO, “… Como já mencionei, nós, seres humanos, somos péssimos em fazer esse tipo de previsão”, se referindo a previsões de prazo, ou seja, quanto tempo algum trabalho leva para ser realizado. Continuando, “mas somos bons em dimensionamento relativo, ou seja, em comparar o tamanho de uma coisa com o de outra…

Acho que já basta de explicação, dado que citei que uma das características dessa técnica é a simplicidade.

Voltando para a prática, tínhamos um Backlog definido. Durante a Planning apresentei as estórias e pedi para o time estimá-las, mas não do jeito tradicional em horas e sim em pontos.

Como a formação do time era nova, não tínhamos uma base, portanto foi assim que fizemos:

  1. Dentre as estórias apresentadas elegemos uma que entendemos que fosse a mais completa (leia-se a que representasse uma funcionalidade com leitura de dados, processamento de dados e gravação desses dados). Essa estória seria a base das #comparações.
  2. Como essa técnica é colaborativa e democrática onde todos são ouvidos, fizemos uma dinâmica de votação chamada Planning Poker, onde resumidamente, todos votam usando, por exemplo, os números da sequência de fibonacci (0, 1, 2, 3, 5, 8, 13, 21, 34…), até o time chegar em um consenso. Fazendo essa votação chegamos a um número de pontos, que isoladamente não significa nada, mas não se apresse… Só por curiosidade, esse número de pontos que chegamos foi 5.
  3. Já tínhamos nossa base, nossa referência. Continuamos a realizar as votações de todas as estórias do sprint, sempre com os seguintes questionamentos:
  • Essa estória parece ser mais ou menos complexa comparando com nossa estória base?
  • Essa estória tem mais ou menos itens a serem feitos comparando com nossa estória base?
  • Essa estória parece ser o dobro? Menos que o dobro?
  • Essa estória parece ser a metade? Menos que a metade?

Caso a estória fosse mais complexa ou mais trabalhosa do que a base, naturalmente após a votação os pontos dados a ela eram acima de 5. Caso ela fosse menos complexa ou menos trabalhosa, a pontuação era menor que 5. Tivemos também casos onde a estória era similar a base ou apresentava o mesmo nível de complexidade/trabalho, então ela recebia a pontuação 5.

Depois dessa dinâmica, tínhamos nosso Sprint Backlog estimado em Story Points. Sim, essa técnica se chama Story Points (SP).

Ela ajuda também a refinar o backlog. Quando o time vota e a pontuação é muito alta (2 ou 3 vezes maior que a pontuação base), é um indício de que a estória está muito grande e possivelmente precisa ser melhor quebrada para ter sua complexidade reduzida.

Perceba que ela é simples, não foi necessário muita explicação ou muitos passos/processos para realizá-la. Também é muito prática e rápida, dado que constantemente fazemos comparações entre coisas no nosso dia-a-dia e nem percebemos que fazemos.

É importante ressaltar que os números de SP só fazem sentido para essa equipe. Não adianta levar esses números para outras equipes. Por ela usar o dimensionamento relativo, depende muito dos “olhos de quem vê”, ou seja, da equipe.

– Muito bom! Fantástico! Mas mesmo assim preciso reportar a estimativa em horas. Isso não me serve.

– Calma lá… Não terminei ainda… kkk

Tendo essas estimativas em SP, Sprint a Sprint, você começa a medir e saber quantos pontos sua equipe consegue entregar. Tendo esses números, você consegue prever quanto tempo gastará para entregar um número de itens do Product Backlog estimados em SP.

Veja que essa estimativa por si só não te indica uma previsão em horas, mas aliada ao desempenho real da sua equipe Sprint a Sprint, você pode prever o prazo em horas sempre que preciso, com uma assertividade maior comparando com a estimativa tradicional em horas.
Saiba que ela não é a única técnica de se estimar rapidamente. Existem outras que também usam do dimensionamento relativo.

 

 

T-SHIRT SIZING – MEDIR TRABALHO ASSIM COMO COM SUA ROUPA (por Daniel Angotti)

 

Uma das formas que nos permite evoluir é medirmos nossas ações atuais para provisionar melhorias futuras. Dentro de uma equipe ágil uma das muitas formas de medir o esforço da equipe é utilizando o método T-Shirt.

Tal método consiste simplesmente em classificar o tamanho de uma demanda (seja uma estória, uma atividade técnica, UX, etc …) em P, M ou G. Onde:

  • P – Denota uma demanda que utiliza uma quantia pequena de horas;
  • M – Denota uma demanda que utiliza uma quantia média de horas;
  • G – Denota uma demanda que utiliza uma quantia grande de horas.

Porém antes de classificar uma demanda num período de tempo se faz necessário, e aí entra o Scrum Team (todos os integrantes da equipe Scrum), quantificar as horas que cada classificação representa. Todos devem participar desta ação para que fique claro e entendido por todos o quanto de esforço será necessário para cada item.

Um exemplo de horas por classificação seria:

  • P – Representa uma demanda de 2 horas de trabalho;
  • M – Representa uma demanda de 4 horas de trabalho;
  • G – Representa uma demanda de 8 horas de trabalho.

A escala e a quantidade de esforço devem ser definidas pelo time e podem variar de minutos a dia, o importante é clareza com que a classificação é divulgada entre a equipe.

Podem existir variações na classificação como a inclusão de novas medidas:

  • PP – Denota uma demanda que utiliza uma quantia menor de horas que a classificação P;
  • GG – Denota uma demanda que utiliza uma quantia maior de horas que a classificação GG.

A utilização da métrica T-Shirt pode ser em conjunto com outras, como por exemplo o CPI onde é utilizada para quantificar o trabalho e valores assim como suas variações positivas e negativas. Permitindo assim avaliar o trabalho atual e a capacidade da equipe e proporcionar melhorias no desenvolvimento das sprints.

O ganho maior será para o cliente final que conseguirá ver evoluções rápidas de seu produto, com qualidade e visando sempre a sua melhor utilização.

 

 

HORAS IDEAIS (por Dário Araújo)

 

É cientificamente comprovado que, das oito horas trabalhadas ao dia, as horas realmente produtivas variam de cinco a seis horas, pois as pessoas precisam ler e-mails, atender telefonemas, interagir socialmente com as pessoas, tomar café entre outras atividades que não fazem parte do trabalho do projeto.

O conceito de Horas ideais (Ideal Hours) é utilizado para realizar estimativas de forma ágil, sendo aplicada para planejar o projeto e iterações. MARTINS (2007) faz ênfase a velocidade calculada a partir do número de horas que a equipe gasta para implementar um trabalho equivalente a um Ideal Day (Dia Ideal).

COHN (2005) defende que uma hora ideal corresponde à quantidade de trabalho que um profissional de nível sênior, com fluência nas tecnologias e ferramentas envolvidas consegue realizar em 08 (oito) horas de trabalho dedicadas (sem interrupções). Se tratando de uma estimativa empírica, executada por especialistas para desenvolvimento com base em exploração adaptativa. Por isto o nome de Dia Ideal.

É importante que se compreenda que o “Horas/Dia Ideais”, com 08 (oito) horas de trabalho sem interrupções, de um “desenvolvedor ideal”, raramente irá ocorrer na prática, e, portanto deve ser utilizada unicamente como “moeda” estável para quantificação de tamanho de referência e balizador ideal de produtividade.

 

 

INDICADORES CPI E SPI (por Cristiano Moraes)

 

Existe um universo que acontece fora da do mundo “Sprint”. Com certeza se você pertence a algum Time Scrum isto se aplica a você também. Metodologias ágeis são aplicadas a muitas frentes de projetos, produtos, cada qual com sua necessidade e propósito, alguns com um Scrum puro, outros com modelos híbridos, o maior ponto que pude observar até agora independente da prática utilizada é a redução do Lead Time, onde encurtamos o tempo entre a ideia e o incremento.

Para tanto é necessário pensarmos na cadeia de valor onde poderemos medir os desperdícios de processos.

Gostaria de aproveitar para apresentar o que acontece no Backoffice da Sprint no mundo “dos dinheiros”, de quem paga a conta.

BAC (Budget at Completion) – A grana inicial para gastar no projeto. Esta grana será distribuída para inception, garantia, incerteza, margem de lucro.

PV (Present Value) – A grana que você pretende gastar por Sprint, por exemplo.

EV (Earned Value) – Grana que você gastou de verdade na Sprint, por exemplo, levando em conta o uma quantidade de pontos. Se teu time entrega 40 pontos, e na real entregou 60, existe uma equivalência monetária que representa isto que é o EV. mostrando lucro ou prejuízo muitas vezes.

AC (Actual Cost) – O gasto real que esta Sprint teve;

CPV = EV- AC, onde você vê financeiramente o como foi a Sprint baseado no trabalho realizado;

SPV = RV-PV, onde você vê financeiramente como foi a Sprint baseado apenas no gasto planejado. Repare que é um índice pobre que não leva em conta a performance.

Com estas informações temo os famosos SPI e CPI, onde:

SPI – indica se mais ou menos pontos foram atingidos.

CPI – indica se gastou maio ou menos que o planejado dado o andamento, avaliando EV e AC.

 

Segue planilha exemplo:

https://docs.google.com/spreadsheets/d/1Z1G_8NcHFTNXOc9x3C-CcF8bYZao-eeI6hPElTui6NY/edit?usp=sharing

 

Vale ressaltar que o executivo que pagou caro pelo projeto, está preocupado e em poucos casos é filantropo. A adoção de Ágil tem muita atuação na redução de desperdício, otimização de performance e lucro, pois no fundo projetos são para isto. Visando ROI que é o Retorno do Investimento.

 

MEDIÇÃO DA MATURIDADE DE TIMES ÁGEIS (por Evandro Galvão)

 

Em busca de uma maior rapidez na evolução e desenvolvimento de novos produtos, está sendo difundido o uso de práticas ágeis nas Organizações. Desta forma, como consequência, surge a necessidade de apresentação dos resultados desta empreitada. Neste momento são feitas muitas perguntas e este pequeno texto busca responder uma destas possíveis perguntas, que poderia ser:

“Se o uso do Ágil é o caminho para a nossa melhoria, qual a maturidade dos meus Times?”

Um modelo inicial para medir o seu time é utilizar como base de medição, os 12 princípios ágeis:

  • Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.
  • Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.
  • Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.
  • Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.
  • Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
  • O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.
  • Software funcional é a medida primária de progresso.
  • Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
  • Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
  • Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
  • As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis.
  • Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

 

Com base no resultado, escolha os 2 princípios mais importantes para o atual momento do seu time é que faça mais sentido para o seu contexto, neste momento. Tome ações para melhorar estes 2 itens e na próxima medição compare novamente, escolha novamente os itens que mais fazem sentido e que promoverão a entrega de valor ao cliente.

Esta medição deve ser realizada de acordo com a sua necessidade também. Se você utiliza o Scrum, pode aplicar sempre como parte da reunião de retrospectiva ou no decorrer das Sprints como uma reunião auxiliar, desde que tenha um período determinado, cada 30 dias, por exemplo.

Após algumas medições, você pode simplificar seus itens, podendo remover itens existentes que não fazem tanto sentido para seu contexto e incluindo novos. A ideia é que este ciclo de melhoria seja o seu indicador de maturidade Ágil do seu time e sua referência para continuar fazendo entregas de valor para o Cliente.

Logo abaixo podemos ver o gráfico de radar com os 12 itens medidos, que podemos chamar de “Roda da Maturidade Ágil”, similar a ferramenta “Roda da Vida”, utilizada por Coachs no mercado, que foca na busca de equilíbrio do que é importante para uma determinada pessoa.

 

Este já é um assunto que pode ser encontrado numa busca simples na Internet com o termo “Roda Ágil”.

Planilha original: http://www.barryovereem.com/wp-content/uploads/How-Agile-is-my-Team.xlsx

Planilha traduzida: https://drive.google.com/open?id=16JeVsYGUhzvAZJfFy1EcVq6ydaBqtvb4

 

 

Evandro Galvão

Evandro Galvão

Formado em Redes de Computadores, MBA em Gerenciamento de Projetos pela FGV e Professional Scrum Master I (PSM I) e PSK I (Professional Scrum com Kanban) pela Scrum.org. Membro atuante na transformação das Organizações através da melhoria contínua de processos, das relações humanas e mudança no Mindset. Fã de filmes e séries. Entusiasta e apoiador do movimento Ágil e busco a quebra de fronteiras para a sua aplicação, sempre visando a cadeia de valor.

You may also like...

1 Response

  1. I know additional ideas that support this. If I may?

Leave a Reply

Your email address will not be published. Required fields are marked *