2.0 Introdução à Parte 2: Métricas de Fluxo

Se a Parte 1 é a filosofia da medição, a Parte 2 é onde essa filosofia encontra a própria entrega: as métricas que descrevem não apenas com que rapidez e segurança uma equipa move código de uma ideia para um sistema em produção, mas que tipo de valor está a fluir por esse pipeline, de todo. Esta parte está organizada à volta do Flow Framework, um modelo criado por Mik Kersten no seu livro de 2018 Project to Product, que trata a entrega de software como uma cadeia de valor e dá a essa cadeia de valor um vocabulário partilhado: quatro tipos de itens de fluxo e cinco métricas de fluxo que ligam a atividade de engenharia à estratégia de negócio em termos que um interessado não técnico consegue realmente usar.

Essa escolha de estrutura organizadora é deliberada. As métricas DORA, frequência de implementação, tempo de espera, taxa de falha de mudanças, e tempo de recuperação, são genuinamente validadas pela investigação e continuam a ser uma das estruturas de entrega mais bem fundamentadas disponíveis, mas medem a mecânica do pipeline, não o que está a fluir através dele. Uma equipa pode publicar excelentes números DORA enquanto o seu valor realmente entregue derivou silenciosamente em direção ao retrabalho ou para longe do trabalho de dívida e risco que protege o futuro de um sistema. Esta parte cobre o DORA na íntegra, mas como um único tema de referência consolidado no final (tema 2.10), porque a pergunta mais urgente e mais comummente em falta para a maioria das organizações não é “quão rápido é o nosso pipeline” mas “o que o nosso pipeline está realmente a entregar.” Cada tema nesta parte continua a seguir a mesma disciplina estabelecida na Parte 1: declarar a métrica, nomear como é manipulada, e emparelhá-la com a salvaguarda que apanha essa manipulação.

Para equipas grandes, as métricas de fluxo são o que torna possível a comparação entre equipas sem perder de vista o valor. Uma equipa de plataforma, uma equipa móvel, e uma equipa de dados podem ter quase nada em comum no seu trabalho diário, mas a velocidade de fluxo e a distribuição de fluxo, calculadas de forma consistente, permitem à liderança fazer uma pergunta justa às três: esta equipa está a entregar o tipo de valor que a sua fase atual realmente exige. As organizações empresariais e governamentais dependem das métricas desta parte para justificar o investimento em plataformas, para comparar o retorno de esforços concorrentes de modernização, e para demonstrar, com evidência em vez de anedota, que a capacidade de engenharia é alocada da forma que a liderança acredita que é.

Temas nesta parte

2.1 O Flow Framework: A origem da estrutura, o seu modelo de cadeia de valor, e porque este livro o usa, em vez de apenas o DORA, para organizar as métricas de entrega e de fluxo.
2.2 Itens de fluxo: funcionalidades, defeitos, riscos, e dívida: A taxonomia de quatro tipos da estrutura, a sua alocação de capacidade de soma zero, e como a classificação é manipulada se aplicada retroativamente.
2.3 Velocidade de fluxo e distribuição de fluxo: Quanto foi entregue e que tipo de valor era, sempre lidos em conjunto.
2.4 Tempo de fluxo e carga de fluxo: Como a lei de Little prova que uma cadeia de valor sobrecarregada abranda matematicamente, não apenas provavelmente.
2.5 Eficiência de fluxo e trabalho em curso: Porque ocupado não é o mesmo que rápido, e como limitar o trabalho em curso melhora o rendimento de forma contraintuitiva.
2.6 Tempo de ciclo e os seus componentes: Decompor o tempo de engenharia de uma mudança nas suas fases constituintes para que uma equipa saiba exatamente para onde o tempo está realmente a ir.
2.7 Teoria das filas: A matemática por baixo da carga de fluxo, do tempo de fluxo, do tempo de ciclo, e do trabalho em curso, e porque o tempo de espera num recurso partilhado explode à medida que a utilização se aproxima do seu limite.
2.8 Métricas lean de cadeia de valor: O conjunto de ferramentas clássico do Lean, tempo de espera, tempo de processo, tempo de ciclo, percentagem completa e precisa, e tempo takt, do qual descendem as métricas específicas de software desta parte, e como fazer a ponte entre os dois vocabulários.
2.9 Métricas de pull request e revisão de código: As métricas que vivem dentro de uma única fase do pipeline de entrega, e como podem distorcer a qualidade da revisão se usadas descuidadamente.
2.10 O framework de métricas DORA: As quatro métricas DORA na íntegra, colocadas por último deliberadamente porque medem o pipeline, não o valor que flui através dele.

Como estes temas se inter-relacionam

O tema 2.1 introduz o Flow Framework como um todo; o tema 2.2 dá a sua taxonomia de itens de fluxo, e os temas 2.3 e 2.4 cobrem as suas cinco métricas de fluxo entre si, velocidade e distribuição em conjunto, depois tempo e carga em conjunto, com a carga e o tempo ligados diretamente à lei de Little. Os temas 2.5 a 2.7 aproximam-se da mecânica por baixo do tempo de fluxo e do tempo de ciclo especificamente: a eficiência de fluxo e o trabalho em curso explicam porque as fases de engenharia são muitas vezes mais lentas do que parecem, o tempo de ciclo decompõe essa porção de engenharia nas suas fases, e a teoria das filas formaliza, em termos matemáticos demonstráveis, porque as afirmações de todos os temas anteriores sobre carga, tempo de espera, e utilização são verdadeiras. O tema 2.8 recua para traçar tudo isto até à sua origem no mapeamento clássico de cadeia de valor Lean, o vocabulário comum do qual as métricas específicas de software desta parte generalizam. O tema 2.9 cobre a única fase do pipeline que a maioria das equipas consegue melhorar mais depressa. O tema 2.10 encerra a parte com as métricas DORA na íntegra, apresentadas como uma camada de referência bem fundamentada mas mais estreita, uma vez que o quadro mais amplo e voltado para o negócio dos temas anteriores já está à vista.

A disciplina de salvaguarda desta parte liga-se diretamente de volta ao tema 1.2: a velocidade de fluxo nunca é reportada sem a distribuição de fluxo ao lado, e as métricas de velocidade do DORA permanecem emparelhadas com as suas métricas de estabilidade, para que uma equipa não consiga melhorar um número de velocidade entregando silenciosamente código mais arriscado ou uma mistura mais estreita de valor. Esse emparelhamento não é incidental a nenhuma das estruturas; é o insight central de cada uma, e as métricas de fiabilidade da Parte 6 estendem a mesma metade de estabilidade desse emparelhamento às operações de produção uma vez que o código já foi entregue.