5 min de leitura
No nosso capítulo anterior, Conceber para a Testabilidade: Quebrar a Próxima Barreira, explorámos como a testabilidade se tornou um foco essencial após resolver os estrangulamentos iniciais na configuração da equipa e nos testes manuais. Esse capítulo marcou um ponto de viragem na nossa transformação DevOps, à medida que mudámos a atenção para princípios mais profundos de conceção de software que permitiram testes mais fáceis e rápidos.
Agora, no Capítulo 4, avançamos para uma próxima fase crítica: definir e monitorizar os KPI corretos e configurar painéis de controlo para medir o nosso progresso. Com as práticas fundamentais implementadas e a testabilidade a melhorar, precisávamos de formas objetivas e baseadas em dados para visualizar o fluxo, identificar restrições e melhorar continuamente.
Porque é que os KPI e os painéis de controlo são importantes em DevOps
À medida que avançámos no nosso percurso para otimizar a entrega End-to-end, reconhecemos a necessidade de um mecanismo visual e objetivo para monitorizar o trabalho e identificar gargalhos. Isto implicou definir KPIs que não se limitassem a números, mas que destacassem perspetivas acionáveis e promovessem os comportamentos corretos.
Ao configurar KPI, é essencial reconhecer que as equipas e organizações tendem a otimizar as métricas que monitorizam. Isto está em alinhamento com a Lei de Goodhart, que estabelece:
"Quando uma medida se torna um objetivo, deixa de ser uma boa medida."
Este princípio sublinha a importância de selecionar KPIs que orientem as equipas para os resultados certos, em vez de as incentivarem simplesmente a atingir metas. O objetivo destes KPIs é medir o progresso rumo à nossa meta global. Mas qual é exatamente essa meta?
Definir o Objetivo
Conforme discutido em The Goal por Eliyahu M. Goldratt, o objetivo de uma empresa é aumentar o lucro líquido enquanto melhora simultaneamente o ROI e o fluxo de caixa. Traduzindo isto para o nosso contexto de desenvolvimento de software, onde nos encontramos atualmente na fase de investimento, identificámos o objetivo como:
“Desenvolver e disponibilizar um produto de software comercializável que proporcione receitas sustentáveis.”
A concretização deste objetivo requer o cumprimento de várias condições necessárias, incluindo:
- Time to Market → Disponibilizar rapidamente funcionalidades e produtos para aproveitar as oportunidades de mercado.
- Escalabilidade Futura → Garantir que o software foi concebido para crescer com a procura, sem comprometer o desempenho.
- Otimização de Custos → Equilibrar as despesas de desenvolvimento enquanto se maximiza a entrega de valor.
- Retorno sobre o Investimento (ROI) → Garantir que o produto oferece benefícios financeiros a longo prazo que justificam o investimento.
Estas condições orientaram a forma como definimos os nossos KPIs, focando-nos não apenas na velocidade e eficiência, mas também na criação de um produto escalável e económico que proporcione valor comercial a longo prazo.
Visualizar o Fluxo: Configuração de Painéis
Conforme descrito em Accelerate, por Nicole Forsgren, Jez Humble e Gene Kim, o nosso objetivo era configurar um painel capaz de visualizar e monitorizar as quatro principais métricas de DevOps:
- Frequência de Implementação → A frequência com que as equipas implementam código em produção.
- Tempo de Espera para Alterações → A rapidez com que o código passa da submissão para a produção.
- Taxa de Falhas de Alteração → A percentagem de implementações que causam falhas.
- Tempo Médio de Recuperação (MTTR) → A rapidez com que as equipas recuperam de falhas.
No entanto, gerar estas métricas de forma significativa foi inicialmente difícil devido à falta de monitorização sistemática do trabalho entre as equipas. Foi aqui que a adoção do Azure DevOps como uma solução de gestão de trabalho comum e única para todas as equipas fez uma diferença significativa.
Começámos por configurar painéis específicos para cada equipa para monitorizar:
- Todos os itens de trabalho atribuídos por equipa.
- Trabalho atualmente em curso.
- Trabalho concluído.
- Defeitos categorizados por etapa e prioridade.
Primeiro Desafio: Utilização Inconsistente
Mesmo com diretrizes claras, as equipas utilizavam os estados e as categorias de defeitos de forma diferente. Esta inconsistência tornou a análise do fluxo entre equipas quase impossível.
O primeiro desafio com que nos deparámos foi a utilização inconsistente dos estados dos itens de trabalho e das classificações de defeitos, apesar de existirem diretrizes claras. Diferentes equipas utilizavam os estados de forma distinta, o que dificultava a identificação de problemas de fluxo entre equipas. Tornou-se crucial uniformizar a forma como o trabalho era monitorizado, garantindo que os painéis pudessem ser utilizados não apenas por equipas individuais, mas para otimizar o fluxo em toda a organização.
Em seguida, concentrámo-nos em definir adequadamente os itens de trabalho, garantindo que refletiam com precisão a fase em que o trabalho se encontrava na cadeia de valor, mantendo-se suficientemente genéricos para serem utilizados por várias equipas. A maioria das ferramentas disponibiliza categorias de estado predefinidas, mas estas nem sempre eram suficientes. Era importante definir categorias de estado alinhadas com a estrutura da nossa equipa, a forma como o trabalho fluía e os nossos estrangulamentos conhecidos.
Análise do fluxo de trabalho para identificar estrangulamentos
Os primeiros painéis foram configurados principalmente para visualizar o trabalho em curso, de modo a obter uma imagem clara do que estava a acontecer entre as equipas. Isto incluiu histórias de funcionalidades, histórias de utilizador, defeitos e planos de teste. Estes elementos forneceram um instantâneo do trabalho em curso, mas continuavam a não dar uma imagem clara do fluxo global de trabalho e de valor.
Ter visibilidade do trabalho em curso foi um primeiro passo importante, mas o desafio seguinte consistia em ligar esta visibilidade a métricas baseadas no fluxo que pudessem evidenciar onde o trabalho estava a ficar retido e onde precisávamos de melhorar.
Utilizando o estado dos itens de trabalho, criámos métricas para mostrar o número de itens de trabalho em cada estado. Inicialmente, tínhamos apenas informações sobre a contagem de itens de trabalho em diferentes estados. Uma análise mais avançada, como o acompanhamento do tempo que os itens de trabalho permaneciam em cada estado, exigiu ferramentas adicionais, que introduzimos mais tarde. No entanto, nesta fase inicial, iniciámos a nossa análise utilizando apenas as contagens.
Mesmo com estes dados básicos, os painéis revelaram-se úteis para identificar estrangulamentos fundamentais:
- Demasiados itens de trabalho em curso em comparação com o número de itens concluídos num determinado período.
- Um volume crescente de novos itens de trabalho acumulados que excedia largamente o que podíamos concluir de forma realista nos 3 a 6 meses seguintes.
- Equipas com o maior volume de itens de trabalho inacabados acumulados, indicando onde era necessário foco e apoio adicionais.
Cada uma destas perspetivas exigiu uma solução diferente, mas a capacidade de visualizar o fluxo de trabalho constituiu um grande avanço. Esta melhoria levou o aspeto das Ferramentas do nosso Triângulo DevOps mais longe, servindo de impulso para o progresso nos outros dois aspetos: Arquitetura e Pessoas.
Utilizar KPIs para impulsionar a melhoria contínua
Regressámos ao tópico dos KPI em várias fases ao longo da nossa transformação DevOps. À medida que as nossas capacidades de monitorização melhoravam, conseguimos gerar métricas mais detalhadas que nos ajudaram a:
- Medir o progresso ao longo do tempo para garantir que estávamos a avançar rumo ao nosso objetivo de desenvolver um produto de software comercializável.
- Identificar dependências e transferências que estavam a causar atrasos no fluxo de trabalho.
- Identificar áreas em que as equipas necessitavam de apoio adicional ou de melhorias nos processos.
- Alinhar mais estreitamente os nossos KPIs com as quatro métricas de DevOps principais de Accelerate, fornecendo uma medida objetiva do nosso sucesso.
Ao alinhar Ferramentas, Arquitetura e Pessoas com os KPI corretos, criámos um sistema que proporcionou visibilidade clara sobre o nosso progresso, nos ajudou a identificar e desbloquear estrangulamentos e garantiu que nos mantínhamos focados em entregar valor comercial a longo prazo.
Quais são os passos seguintes? Ramificação e implementação contínua
Com os nossos KPI e painéis implementados, estamos agora prontos para otimizar o fluxo de código através dos ambientes e para produção. No Capítulo 5, vamos aprofundar a forma como abordámos a Criação de Ramos e Implementação Contínua, bem como as mudanças culturais e técnicas que nos permitiram implementar de forma mais rápida e segura.
Fique atento!
