Fluxo de desenvolvimento

Como funciona

A mecânica deste kit, sem rodeios — o que roda e quando, onde os dados ficam, e o que você olha.

• Resumo de desenvolvimento roda manhãs de dia útil · 8h e mantém o painel Fluxo de desenvolvimento atualizado. Manhãs de dia útil — de quem é a vez, e o que envelheceu.
• O que é capturado cai no conjunto de dados Registo de PRs, que fica em Data/PR Log no seu cofre — seu para abrir, buscar e editar como qualquer outro ficheiro.
• O que é capturado cai no conjunto de dados Diário de desenvolvimento, que fica em Data/Dev Log no seu cofre — seu para abrir, buscar e editar como qualquer outro ficheiro.
• O painel Fluxo de desenvolvimento lê do conjunto de dados e mostra, de relance: pRs abertos · mesclados esta semana · revisões que você deve · de quem é a vez · por repositório · todos os PRs abertos · o diário de desenvolvimento.

A ligação entre as peças, em uma frase: Resumo de desenvolvimento escreve em Registo de PRs · Captura de incidentes escreve em Diário de desenvolvimento · Fluxo de desenvolvimento mostra Registo de PRs · Fluxo de desenvolvimento mostra Diário de desenvolvimento · Resumo de desenvolvimento mantém Fluxo de desenvolvimento em dia · Captura de incidentes é entregue a Relay · Retrospectiva de desenvolvimento é entregue a Relay.

A tirar o máximo dele

Um kit merece o seu lugar quando muda o que você olha e o que você diz, não quando é instalado. Este é o ritmo que faz valer a pena.

• Abra o Fluxo de desenvolvimento antes de abrir um separador. O resumo já separou cada PR aberto por de quem é a vez e há quanto tempo ele está parado.
• Diga incidentes e decisões de passagem — “decidimos largar o endpoint antigo”, “a produção caiu vinte minutos, migração ruim” — e a Captura de incidentes põe tudo no registo.
• Chame a Retrospectiva de desenvolvimento quando a discussão começar: “o que foi entregue em junho”, “por que a gente escolheu aquele banco” — respondido a partir do diário.
• Conte a Relay quais repositórios importam e o que conta como parado. O resumo fica mais quieto.
• Lembre do que ele não consegue ver: não há visão de CI aqui, então o painel é o estado dos PRs e nada mais.

Deixe do seu jeito

Nada aqui é fixo. As peças são agentes, rotinas, conjuntos de dados e painéis comuns, então tudo o que você sabe sobre moldá-los se aplica. Aposente o que não render nada.

O que as pessoas costumam mudar primeiro

Diga qualquer uma destas coisas no chat, ou edite-as na página do kit dentro da aplicação.

• Quantos dias contam como parado, separadamente para as revisões que você deve e para o seu próprio trabalho esperando.
• Quais repositórios ele acompanha.
• Quando o resumo chega, ou desligar os cartões e ficar só com o painel.
• O que vale pôr no diário de desenvolvimento — algumas pessoas registam só incidentes, outras registam cada decisão.

A sua primeira execução

Instalar começa uma conversa curta de configuração — não um formulário. Responda por alto, corrija depois.

1. Na primeira manhã de dia útil ele lê os seus repositórios e enche o painel com o que está aberto e de quem é a vez — sem configuração além de conectar o GitHub.
2. Ele conta a você só o que de facto empacou. Uma fila em boa forma não rende cartão nenhum.
3. Mencione um incidente ou uma decisão de passagem e isso cai no diário de desenvolvimento, nas palavras que você usou na hora.
4. Ele não consegue ver o estado das builds — não há ferramenta de CI no conector — então nunca relata se uma build passou ou se a main está verde.

Acompanhe a primeira passagem e depois conte o que você teria feito diferente — essa correção ensina mais do que qualquer configuração.

O essencial

Aprendizagem, preferências e custo de execução funcionam igual em todos os kits — por isso são tratados uma vez só, no guia dos Kits.

A conviver com um Kit — o guia dos Kits →

← Todos os kits