Métricas de entrega para melhorar a previsibilidade

Trabalhamos com equipes ágeis com formações e tamanhos diferentes, e a previsibilidade é um tema que sempre está em destaque, já que as palavras "Ágil" e "Previsível" nem sempre andam juntas.

Então, como as equipes de desenvolvimento podem manter a agilidade e melhorar a previsibilidade da entrega? Quando os stakeholders fazem a pergunta já esperada, "Estamos dentro do cronograma?", precisamos dar uma resposta plausível.

Abordagens típicas de previsão de uma equipe ágil

As equipes ágeis de desenvolvimento de software baseadas em produtos, que entregam pequenos incrementos com bastante regularidade, talvez gastem pouco tempo se preocupando com a previsão da entrega.

Entretanto, muitas vezes as equipes ágeis são criadas para entregar grandes metas esperadas pela área de negócios em um determinado momento e dentro do orçamento previsto, portanto, é necessário prever com eficácia o que está acontecendo ou correr o risco de ser acusado de ser "ágil e atrasado"!

As previsões das equipes ágeis tendem a ser bastante imprecisas e geralmente se baseiam apenas em uma simples observação das tarefas pendentes, da velocidade do desenvolvimento e de garantias que as próprias equipes oferecem.

Acredito que uma previsão realmente significativa requer um conjunto mais amplo de dados empíricos, refletindo todas as fontes potenciais de atraso no projeto.

* Há um debate à parte, se a metodologia de desenvolvimento ágil de software é apropriada em um contexto de "projeto" como esse, mas isso é uma conversa para outro dia.

"As seis razões lógicas": seis fontes de atrasos nos projetos

A lógica salienta que existem seis razões possíveis pelas quais um projeto está atrasado, conhecidas como as "Seis razões lógicas". Três das seis razões lógicas são diretamente controladas pela equipe de tecnologia:
 

1. O tamanho e a complexidade da tarefa foram subestimados;
2. O grupo de engenheiros apropriados para fazerem o trabalho não está disponível;
3. A equipe de entrega não está finalizando tarefas com a produtividade prevista;

E os outros três que estão sob controle dos patrocinadores dos negócios que interagem com a equipe de tecnologia:
 

4. Definição de requisitos confusa. Os clientes internos não estão claros o suficiente sobre o que é esperado;
5. Mudança de escopo. A gestão de negócios modifica as metas (requisitos novos e alterados ou prioridades alteradas);
6. Entrega contínua adiada. O processo de desenvolvimento é adiado pela falta de entrega de insumos pelos stakeholders quando necessário.

Não seremos capazes de prever com precisão e melhorar a nossa previsibilidade de entrega, a menos que comecemos a coletar métricas que acompanhem todos esses seis pontos.

Somente então, realmente saberemos a probabilidade de que um projeto esteja "atrasado" e o que precisa ser feito para colocá-lo de volta nos trilhos.

As "Seis razões lógicas": fontes principais de atrasos nos projetos.

Desafiando a previsão das equipes com a análise de métricas de entrega que importam para o negócio

Quais são as métricas relacionadas às seis fontes de atraso do projeto, e elas são essenciais para a previsibilidade da entrega e uma melhor precisão desta previsão?

A tabela a seguir mostra as métricas de cada uma das áreas. Incentivamos os gerentes de entrega a se concentrarem nelas ao trabalhar com os líderes de equipe para criar previsões mais realistas referentes ao prazo de entrega.

Em resumo, as métricas são:

1. Disponibilidade das pessoas. Claramente um ponto chave. Se não tivermos os engenheiros previstos, estaremos atrasados;

2. Produtividade da equipe relacionada a:

   a) Tempo produtivo. Outra métrica crítica, considerando a proporção de tempo que os engenheiros têm para se concentrar na criação de novos recursos;
   b) Eficiência do processo. O atrito no processo de desenvolvimento pode prejudicar os melhores planos de entrega. Então, entender as tendências e as causas desse atrito é fundamental;
   c) Velocidade e tempo para avaliação. Entender como a taxa de transferência e o tempo para avaliação mudaram à medida que o projeto progride, é mais uma variável determinante nas previsões.
    
3. Precisão de estimativa. Se estamos adotando uma abordagem baseada no Scrum, a conclusão do sprint fornece um indicador muito bom da capacidade de previsão. Se a equipe não consegue atingir as metas de sprint quinzenal, é muito provável que não sejam eficazes em estimar esforços e fazer previsões no futuro;
    
4. A definição de requisitos, a entrega de insumos pelos stakeholders e a alteração do escopo podem ser rastreadas usando o Quant Engineer Feedback coletado de hubs de colaboração como o Slack. Isso é algo que pode ser bastante utilizado internamente para melhorar as previsões, uma vez que utiliza informações quantitativas das pessoas que realmente estão fazendo o trabalho. Muitas vezes, adicionamos confiança a uma previsão de entrega teórica e precisamos estar atentos à três das seis razões lógicas (definição de requisitos, contribuição dos stakeholders e mudança do escopo principal).

Principais métricas para rastrear as seis razões lógicas de atraso do projeto

Coletando as métricas de entrega que são importantes

As principais métricas de entrega exigem a análise de dados de uma infinidade de fontes, incluindo: ferramentas de gerenciamento de fluxo de trabalho, repositórios de código e ferramentas de CI/CD, além de coletar feedback da própria equipe de engenharia, via hubs de colaboração como o Slack.

A complexidade dos dados e as várias fontes tornam esse tipo de coleta muito demorada para ser feita manualmente e realmente exige uma plataforma de métricas de entrega de ponta a ponta para ser feita em escala.

Plataformas de entregas de métrica estão disponíveis e consistem em uma camada de dados para agrupar e compilar métricas de várias fontes e uma camada flexível de interface do usuário para permitir a criação de dashboards personalizados para exibir as métricas no formato desejado.

Usando os relatórios RAG de causa raiz para combinar a previsão de entrega e plano de mitigação

Se usarmos métricas para rastrear e analisar as seis razões lógicas do progresso do projeto, teremos uma imagem muito mais clara do real progresso. Com isso queremos dizer:

A previsão aprimorada e as atenuações relacionadas podem ser apresentadas juntas em um relatório de progresso de causa raiz RAG.

Esses relatórios são muito mais eficazes do que os tradicionais, que muitas vezes possuem pouca informação sobre o motivo pelo qual um projeto, com uma data de entrega estipulada, está atrasado e o que precisa ser feito para voltá-lo ao cronograma proposto.

Em contraste com a abordagem RAG tradicional, o Relatório RAG de causa raiz mostra claramente:

Se bem feito, os relatórios RAG de causa raiz podem ser um meio realmente eficaz de apresentar as previsões, de maneira que as partes interessadas possam entender e, portanto, ter ações para reduzir o atraso e aproximar a equipe de tecnologia ao cliente interno.

Porém, como discutimos, o relatório se baseia no entendimento das métricas que realmente determinam o atraso do projeto e um meio de coletar essas métricas.

Exemplo de relatório RAG de causa raiz

Sobre o autor

Charlie Ponsonby iniciou a carreira como economista no mundo do desenvolvimento, antes de trabalhar na Andersen Consulting. Foi diretor de marketing da Sky até 2007, antes de fundar o Simplifydigital em 2007. O Simplifydigital esteve três vezes no Sunday Times Tech Track 100 e cresceu e se tornou o maior serviço de comparação de banda larga do Reino Unido. Foi adquirida pela Dixons Carphone plc em abril de 2016. Ponsonby co-fundou com Dan Lee, em outubro de 2017, a Plandek, uma plataforma de análise de métricas de entrega e de BI de ponta a ponta que extrai dados dos conjuntos de ferramentas usados pelas equipes de entrega (como as ferramentas Jira, Git e CI/CD), para fornecer métricas com o objetivo de otimizar a previsão de entrega de software, o gerenciamento de riscos e a eficácia da entrega. O Plandek é usado por clientes em todo o mundo, incluindo Reed Elsevier, News Corporation, Autotrader.ca e Secret Escapes.