Onde o nosso fluxo de PRs está perdendo tempo?

Os PRs parecem lentos e eu quero saber para onde o tempo realmente vai antes de mudar qualquer coisa. ## Contexto - Squad: [squad]. Repositório: [todos os repositórios do squad] - Período: [últimos 30 dias], comparados com os 30 dias anteriores - Quero um diagnóstico com um primeiro movimento, não uma lista de métricas. - Se eu deixei algo entre [colchetes], mantenha o que for um padrão (um período, um número de dias, a primeira de várias opções) e me pergunte o resto de uma vez só, antes de puxar qualquer dado. - Escreva tudo, inclusive o entregável, no idioma deste prompt. ## Puxe estes dados do DevStats (os dois períodos, mesmos filtros) 1. PR Cycle Time — total e coding / pickup / review / deploy 2. Code Review — reviews concluídos, comentários por review, PRs mergeados sem review, tamanho médio dos PRs 3. Throughput — PRs abertos e mergeados 4. Aging Branches — branches abertas agora, por etapa (coding / pickup / review / merge) e faixa de idade 5. Open PRs — os PRs abertos mais antigos neste momento 6. PR List do período atual: ordene por cycle time decrescente, limit 15, campos title, repository, size_total, cycle_time_pickup, cycle_time_review, cycle_time_deploy, review_count, was_reviewed. São esses PRs que definem a média; a média os esconde. ## Como analisar - Primeiro descubra qual etapa é dona do tempo. Ordene coding / pickup / review / deploy pela participação no cycle time total e pela variação contra o período anterior. Investigue só a primeira ou as duas primeiras. - Pickup é a fila antes de alguém olhar. Pickup longo significa disponibilidade de revisores, ownership pouco claro ou PRs abertos no fim da semana. Não é um problema de qualidade de review. - Review é o tempo em revisão. Review longo com muitos comentários por review significa mudanças realmente disputadas. Review longo com poucos comentários significa que o revisor deixou o PR de lado. Confira o tamanho dos PRs: acima de ~400 linhas, o tempo de review cresce mais rápido que o tamanho. - Deploy é do merge até a produção. Deploy longo é o processo de release, não o PR. Não culpe os revisores por isso. - Coding é do primeiro commit até a abertura do PR. Coding longo com PRs grandes significa que o trabalho não está sendo fatiado. - Olhe os 15 PRs mais lentos. Se três ou quatro deles respondem pela maior parte do excesso, isso são outliers, não um problema de sistema. Diga quais são e por que foram lentos: tamanho, falta de revisor, travados no deploy. - PRs mergeados sem review furam a fila. Se essa parcela subiu enquanto o tempo de review caiu, a "melhora" é review pulado, não review mais rápido. - Aging Branches é o que está parado agora; cycle time é o que já terminou. A etapa em que as branches se acumulam hoje costuma coincidir com a etapa dona do tempo histórico. Diga se as duas concordam. - Uma etapa que volta vazia em um dos períodos (deploy time é a mais comum) não foi medida; ela não levou zero tempo. Os totais dos dois períodos deixam de ser comparáveis: compare as etapas que os dois períodos têm, e diga isso. ## Entregue Um diagnóstico de uma página: 1. **Para onde o tempo vai** — a etapa ou as etapas donas do atraso, com os dois períodos e a participação no total. 2. **Por quê, mais provavelmente** — uma ou duas explicações que a evidência sustenta e uma que ela descarta. 3. **Os outliers** — os PRs específicos que inflam os números, se houver, e o que aconteceu com eles. 4. **Primeiro movimento** — a única mudança a fazer nesta semana, qual número deve se mover e quando devemos ver isso. Depois o segundo e o terceiro movimentos, em ordem. 5. **O que os dados não conseguem me dizer** — uma ou duas perguntas para fazer ao time.