5 min. de leitura
No nosso capítulo anterior, Projetando para Testabilidade: Quebrando a próxima barreiraexplorámos a forma como a testabilidade se tornou um foco chave depois de resolvermos os estrangulamentos iniciais na configuração da equipa e nos testes manuais. Esse capítulo marcou um ponto de virada em nossa transformação DevOps, quando mudamos a atenção para princípios de design de software mais profundos que permitiram testes mais suaves e rápidos.
Agora, no Capítulo 4, passamos para uma próxima fase crítica: definir e rastrear os KPIs corretos e configurar painéis para medir nosso progresso. Com as práticas fundamentais em vigor e a capacidade de teste melhorando, precisávamos de maneiras objetivas e orientadas por dados para visualizar o fluxo, identificar restrições e melhorar continuamente.
Porque é que os KPIs e os Dashboards são importantes no DevOps
À medida que avançávamos na nossa jornada para agilizar a entrega de ponta a ponta, reconhecemos a necessidade de um mecanismo visual e objetivo para acompanhar o trabalho e descobrir estrangulamentos. Isso significava definir KPIs que não fossem apenas números, mas que destacassem insights acionáveis e conduzissem aos comportamentos certos.
Ao definir KPIs, é essencial reconhecer que as equipas e as organizações tendem a otimizar as métricas que monitorizam. Isto alinha-se com a Lei de Goodhart, que afirma:
"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 encorajar a simplesmente atingir os objectivos. O objetivo destes KPIs é medir o progresso em direção ao nosso objetivo global. Mas qual é exatamente esse objetivo?
Definir o objetivo
Conforme discutido em The Goal, de Eliyahu M. Goldratt, o objetivo de uma empresa é aumentar o lucro líquido e, ao mesmo tempo, melhorar o ROI e o fluxo de caixa. Traduzindo isso para o nosso contexto de desenvolvimento de software, onde estamos atualmente na fase de investimento, identificamos o objetivo como:
"Desenvolver e fornecer um produto de software comercializável que gere receitas sustentáveis."
A consecução deste objetivo exige o cumprimento de várias condições necessárias, nomeadamente
- Time to Market → Fornecer funcionalidades e produtos rapidamente para captar oportunidades de mercado.
- Escalabilidade futura → Assegurar que o software é concebido para crescer com a procura sem comprometer o desempenho.
- Otimização de custos → Equilíbrio entre as despesas de desenvolvimento e a maximização da entrega de valor.
- Retorno sobre o investimento (ROI) → Garantir que o produto proporcione benefícios financeiros a longo prazo que justifiquem o investimento.
Estas condições orientaram a forma como definimos osnossos KPIs - concentrando-nosnão apenas na velocidade e na eficiência, mas também na criação de um produto escalável e económico que proporcione valor comercial a longo prazo.
Visualizando o fluxo: Configurando Dashboards
Conforme descrito em Accelerate por Nicole Forsgren, Jez Humble e Gene Kim, o nosso objetivo era criar um painel que pudesse visualizar e acompanhar as quatro principais métricas DevOps:
- Frequência de implementação → Com que frequência as equipas implementam o código na produção.
- Lead Time for Changes → A rapidez com que o código passa do commit para a produção.
- Taxa de falha de alteração → A porcentagem de implantaçõ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 uma forma significativa foi inicialmente um desafio devido à falta de acompanhamento sistemático do trabalho entre equipas. Foi aqui que a adoção do Azure DevOps como uma solução única e comum de gestão do trabalho para todas as equipas fez uma diferença significativa.
Começámos por criar painéis de controlo específicos para cada equipa:
- Todos os itens de trabalho atribuídos por equipa.
- Trabalhos atualmente em curso.
- Trabalhos concluídos.
- Defeitos categorizados por fase e prioridade.
Primeiro desafio: Utilização inconsistente
Mesmo com orientações 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 dos defeitos, apesar de existirem diretrizes claras. Equipas diferentes utilizavam os estados de forma diferente, o que dificultava a identificação de problemas de fluxo entre equipas. Tornar consistente a forma como o trabalho era monitorizado tornou-se fundamental, garantindo que os painéis de controlo pudessem ser utilizados não só por equipas individuais, mas também para otimizar o fluxo em toda a organização.
Em seguida, concentrámo-nos em definir corretamente os elementos de trabalho, assegurando que pudessem refletir com exatidão o ponto em que o trabalho se encontra na cadeia de valor, sendo ao mesmo tempo suficientemente genéricos para serem utilizados por várias equipas. A maioria das ferramentas fornece categorias de estado predefinidas, mas estas nem sempre eram suficientes. Era importante definir categorias de estado que estivessem de acordo com a estrutura da nossa equipa, a forma como o trabalho fluía e os nossos estrangulamentos conhecidos.
Analisar o fluxo de trabalho para identificar estrangulamentos
Os primeiros painéis foram criados principalmente para visualizar o trabalho em curso - para obter uma imagem clara do que estava a acontecer entre as equipas. Isto incluía histórias de funcionalidades, histórias de utilizadores, defeitos e planos de teste. Estes forneciam uma visão geral do trabalho em curso, mas ainda não forneciam uma imagem clara do fluxo global de trabalho e valor.
Ter visibilidade do trabalho em curso foi um primeiro passo importante, mas o desafio seguinte foi ligar esta visibilidade a métricas baseadas no fluxo que pudessem realçar onde o trabalho estava a ficar bloqueado e onde precisávamos de melhorar.
Utilizando o estado dos work items, criámos métricas para mostrar o número de work items em cada estado. Inicialmente, apenas dispúnhamos de informações sobre a contagem de itens de trabalho em diferentes estados. Uma análise mais avançada - como o controlo do tempo que os itens de trabalho permaneceram em cada estado - exigia ferramentas adicionais, que introduzimos mais tarde. No entanto, nesta fase inicial, começámos a nossa análise utilizando apenas as contagens.
Mesmo com estes dados básicos, os painéis de controlo revelaram-se úteis para identificar os principais estrangulamentos:
- Demasiados itens de trabalho em curso em comparação com o número de itens a serem concluídos num determinado período.
- Uma acumulação crescente de novos itens de trabalho que excedia em muito o que poderíamos realisticamente concluir nos próximos 3 a 6 meses.
- Equipas com a maior acumulação de itens de trabalho inacabados, indicando onde era necessária uma maior atenção e apoio.
Cada um desses insights exigia uma solução diferente, mas a capacidade de visualizar o fluxo de trabalho foi um grande avanço. Esta melhoria levou o aspeto Ferramentas do nosso Triângulo DevOps mais longe, fornecendo o ímpeto para o progresso nos outros dois aspectos - Arquitetura e Pessoas.
Utilizar KPIs para impulsionar a melhoria contínua
Voltámos ao tema dos KPIs em várias fases ao longo da nossa transformação DevOps. À medida que as nossas capacidades de monitorização melhoraram, conseguimos gerar métricas mais detalhadas que us ajudaram a:
- Medir o progresso ao longo do tempo para garantir que estávamos a avançar para o nosso objetivo de desenvolver um produto de software comercializável.
- Identificar as dependências e as transferências que estavam a causar atrasos no fluxo de trabalho.
- Identificar as áreas em que as equipas necessitam de apoio adicional ou de melhorias nos processos.
- Alinhar os nossos KPIs mais de perto com as quatro principais métricas DevOps do Accelerate, fornecendo uma medida objetiva do nosso sucesso.
Ao alinhar ferramentas, arquitetura e pessoas com os KPIs certos, criámos um sistema que proporcionou uma visibilidade clara do nosso progresso, us a identificar e desbloquear gargalos e garantiu que permanecêssemos focados em entregar valor comercial a longo prazo.
O que vem a seguir? Ramificação e implantação contínua
Com os nossos KPIs e painéis implementados, estamos agora prontos para otimizar o fluxo de código através dos ambientes e para a produção. No Capítulo 5, vamos aprofundar a forma como abordámos o Branching e a Implementação Contínua, bem como as mudanças culturais e técnicas que us permitiram us mais rápida e segura.
Fique atento!
