BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Métricas de entrega para melhorar a previsibilidade

Métricas de entrega para melhorar a previsibilidade

Favoritos

Pontos Principais

  • As equipes ágeis geralmente estão envolvidas na entrega de metas importantes, que a empresa aguarda para um determinado momento e dentro do orçamento acordado, portanto, será necessário prever este momento ou arriscar ser acusado de ser "ágil e atrasado";

  • A lógica diz que existem seis razões possíveis pelas quais um projeto está atrasado, conhecidas como as “Seis razões lógicas”. Três no controle da equipe de tecnologia: esforço subestimado, falta de talento disponível e falta de produtividade da equipe. Três no controle dos investidores: requisitos não claros, mudança de escopo e falta de contribuição contínua necessária;

  • Existem métricas relacionadas a essas seis potenciais fontes de atraso, sendo essencial medi-las para melhorar a precisão da previsão;

  • Essas métricas precisam de informações de várias fontes de dados e por isso, são difíceis de serem observadas sem uma plataforma de métricas/análises de entrega de ponta a ponta;

  • Essas métricas podem ser usadas para criar um relatório de progresso de causa raiz Red/Amber/Green (RAG), para compartilhar com os patrocinadores uma previsão mais precisa e atenuações claras, com responsabilidades atribuídas para fornecer as atenuações identificadas.

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:
 

  1. Definição de requisitos confusa. Os clientes internos não estão claros o suficiente sobre o que é esperado;
  2. Mudança de escopo. A gestão de negócios modifica as metas (requisitos novos e alterados ou prioridades alteradas);
  3. 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

Métricas de tendência

Relevância

Recurso de engenharia disponível:

  • Engenheiros ativos x plano

Claramente um ponto chave, que mostra se temos o recurso planejado para entregar o trabalho.

Tempo produtivo

  • % De tempo gasto em novos recursos
  • % De tempo gasto em manutenção
  • % de tempo perdido em atividades não relacionadas ao produto

Ponto chave para entender como isso evoluiu ao longo do tempo. Se estamos gastando mais energia em tarefas improdutivas, claramente isso afetará o progresso.

Eficiência do processo

  • Eficiência de fluxo (%)
  • Retrabalho (em dias)
  • WIP/desenvolvedor

Essas métricas analisam o "atrito" no processo de desenvolvimento e como isso evolui ao longo do tempo. A diminuição da eficiência do fluxo é um problema que muitas vezes pode ser resolvido, por isso é uma métrica essencial quando falamos em mitigar as previsões. O retrabalho mostra tendências no tempo acumulado gasto em retrabalho de tarefas que falham no controle de qualidade. Essa é outra forma de atrito que pode ser atenuada, por exemplo, ajudando os novos engenheiros com as bases de código.

Nota: Qualquer métrica coletada no nível individual precisa ser visualizada no contexto por pessoas diretamente envolvidas no projeto. Essas pessoas podem ser retirados de contexto, com efeitos nocivos, se analisados de maneira mais ampla.

Velocidade e tempo para avaliar

  • Chamados de recursos concluídos
  • Tempo do ciclo (dias)
  • Prazo de execução (dias)

As métricas de velocidade são complicadas, mas um entendimento detalhado das tendências dos chamados concluídos, e dos pontos de história/pontos de valor por chamado, é essencial para desafiar as previsões. Também é crítico o entendimento das mudanças no ciclo e nos tempos de entrega. Se estão prolongando, é complicado obter uma previsão precisa.

Precisão do Sprint

  • Taxa geral de conclusão (%)
  • Conclusão geral do sprint x Conclusão da meta do sprint (%)

A incapacidade de cumprir metas quinzenais de sprint, torna muito difícil realizar as previsões de períodos mais longos. Portanto, essas métricas são importantíssimas para a precisão da previsão.

Quant. de feedback da engenharia

  • Moral da equipe
  • Eficácia do sprint
  • Qualidade da definição de chamado e dos requisitos
  • Qualidade da contribuição do patrocinador comercial
  • Esforço identificado como mudança de escopo acordada

Algumas métricas permitem a pesquisa em tempo real de engenheiros por meio de hubs de colaboração. Isso fornece dados quantitativos:

  • Das opiniões dos engenheiros sobre moral e eficiência dos processos;
  • Sobre o impacto da definição de requisitos dos patrocinadores do negócio e a contribuição contínua;
  • Feedback do líder da equipe sobre as histórias incluídas pelos stakeholders que são adicionais ao escopo original.

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.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT