Flujo de desarrollo

Cómo funciona

La mecánica de este Kit, sin rodeos: qué se ejecuta y cuándo, dónde acaban los datos y qué miras tú.

• Resumen de desarrollo se ejecuta mañanas entre semana · 8:00 y mantiene al día el panel Flujo de desarrollo. Mañanas entre semana: a quién le toca y qué se ha estancado.
• Lo que se captura acaba en el conjunto de datos Registro de PR, que vive en Data/PR Log dentro de tu bóveda: tuyo para abrir, buscar y editar como cualquier otro archivo.
• Lo que se captura acaba en el conjunto de datos Registro de desarrollo, que vive en Data/Dev Log dentro de tu bóveda: tuyo para abrir, buscar y editar como cualquier otro archivo.
• Lo que se captura acaba en el conjunto de datos Lista de deuda técnica, que vive en Data/Debt List dentro de tu bóveda: tuyo para abrir, buscar y editar como cualquier otro archivo.
• El panel Flujo de desarrollo lee del conjunto de datos y muestra de un vistazo: pR en el registro · fusionadas esta semana · incidencias a tu cargo · revisiones que debes · a quién le toca · por repo · repasar la lista de deuda técnica · la lista de deuda técnica, por estado · lanzado y roto, últimamente · cómo funciona este panel.

Las conexiones, de un vistazo: Resumen de desarrollo escribe en Registro de PR · Resumen de desarrollo escribe en Registro de desarrollo · Captura de incidentes escribe en Registro de desarrollo · Flujo de desarrollo muestra Registro de PR · Flujo de desarrollo muestra Registro de desarrollo · Resumen de desarrollo mantiene al día Flujo de desarrollo · Captura de incidentes se asigna a Relay · Retrospectiva de desarrollo se asigna a Relay · Seguimiento de la deuda técnica escribe en Lista de deuda técnica · Flujo de desarrollo muestra Lista de deuda técnica · Notas e informes lee Registro de desarrollo · Lector de la cola se asigna a Relay · Notas e informes se asigna a Relay · Seguimiento de la deuda técnica se asigna a Relay.

Sacarle el máximo partido

Un Kit se gana su sitio cuando cambia lo que miras y lo que dices, no cuando se instala. Este es el ritmo que hace que valga la pena.

• Abre Flujo de desarrollo antes de abrir una pestaña. El resumen ya ordenó cada pull request abierta según a quién le toca y cuánto tiempo lleva esperando, y contó las incidencias asignadas a ti.
• Espera una tarjeta solo cuando algo se haya quedado estancado. El resumen de desarrollo lee tus repositorios cada mañana entre semana y genera una por una revisión que alguien lleva días esperando, o por una pull request tuya que nadie ha tomado; una cola tranquila no envía nada.
• Antes de revisar, pregúntale a Relay qué hace una pull request. Lector de la cola te dice qué afirma hacer, qué toca y qué tamaño tiene, a partir de la propia pull request; la revisión, y cualquier comentario sobre ella, siguen siendo tuyos.
• Menciona de pasada los incidentes, los despliegues y las decisiones —“producción estuvo caída veinte minutos, una migración mala”, “api 2.14 salió a producción”, “decidimos quitar el endpoint heredado”— y Captura de incidentes los deja registrados. Una decisión que tomaste mientras atendías un incidente va al Registro de decisiones de Reuniones y acciones si tienes ese Kit, para que quede junto a tus demás decisiones; si no, va al registro de desarrollo. Cuando un incidente termine, pídele a Notas e informes un informe sin culpables.
• Pídele a Notas e informes tu nota para la reunión diaria por la mañana, o las notas de la versión de lo que se fusionó desde el último despliegue. Las dos salen del registro y de lo que le cuentas, nunca de una suposición.
• Nombra la deuda técnica en cuanto tropieces con ella y Seguimiento de la deuda técnica la guarda con tus palabras. De vez en cuando, pulsa «Repasar la lista de deuda técnica» en el panel y vuelve a valorar cada deuda.
• Cuando una deuda se planifica, se salda o no vale la pena arreglarla, dilo y la fila cambia. La deuda saldada se queda en la Lista de deuda técnica como registro de lo que se arregló. Pregunta qué hay en ella y Relay te la lee, primero lo de mayor impacto, con lo que te cuesta cada una; qué saldar es decisión tuya.
• Recurre a Retrospectiva de desarrollo cuando empiece la discusión: “¿qué salió en junio?”, “¿por qué elegimos esa base de datos?”. Dile a Relay qué repositorios importan y qué cuenta como estancado, y recuerda que aquí no hay visibilidad de la CI: el panel muestra el estado de las pull requests y nada más.

Hazlo tuyo

Aquí nada es fijo. Las piezas son agentes, rutinas, conjuntos de datos y paneles corrientes, así que todo lo que sepas sobre moldearlos vale aquí. Retira lo que no aporte nada.

Lo que la gente suele cambiar primero

Di cualquiera de estas cosas en el chat, o edítalas en la página del Kit dentro de la aplicación.

• Cuántos días cuentan como estancado, por separado para las revisiones que debes y para tu propio trabajo en espera.
• Qué repositorios vigila.
• Cuándo llega el resumen, o desactivar las tarjetas y quedarte solo con el panel.
• Qué vale la pena poner en el registro de desarrollo: hay quien solo registra incidentes y quien registra cada decisión.
• Cómo se organiza tu nota para la reunión diaria y qué repositorios cubren las notas de la versión.
• Qué cuenta como deuda que vale la pena guardar y cómo la valoras.

Tu primera ejecución

Al instalarlo se abre una breve conversación de configuración, no un formulario. Responde a grandes rasgos y corrige después.

1. Al añadir el Kit se te ofrece el primer resumen de inmediato: con GitHub conectado en la pantalla de Conectores, inícialo con un toque y Relay lee tus repositorios: cada pull request abierta que escribiste o que te pidieron revisar, a quién le toca y cuánto lleva esperando. ¿Prefieres empezar sin él? Cuéntale a Relay algo que salió o que se rompió, y va al registro de desarrollo.
2. En cualquier caso, Relay parte de lo que 1Presence ya sabe: tu memoria y las notas de incidentes, las notas de versión o las listas de tareas que haya en tu bóveda. Te ofrece lo que encuentra para que lo confirmes antes de que nada entre en un registro, y solo pregunta por los huecos.
3. Cuando el resumen termina, Relay deja una nota breve y te propone unos minutos juntos para completar lo que GitHub no puede mostrar: qué repositorios importan, qué cuenta para ti como estancado, lo que haya salido, se haya desplegado o se haya roto hace poco, una decisión que valga la pena guardar y la deuda técnica con la que sigues tropezando.
4. Lo que siga en blanco espera en la página del Kit con un camino de vuelta a Relay, y Relay lo ofrece una vez la próxima vez que hablen. Dile que una parte no se aplica a ti, o que ya terminaste de configurar, y deja de preguntar.
5. Solo te avisa de lo que de verdad se ha estancado. Una cola en buen estado no genera ninguna tarjeta.
6. Menciona de pasada un incidente, un despliegue o una decisión y entra en el registro de desarrollo, con las palabras que usaste en ese momento.
7. No puede ver el estado de los builds —el conector no tiene ninguna herramienta de CI—, así que nunca informa si un build pasó o si main está en verde.

Observa la primera pasada y luego dile qué habrías hecho de otra manera: esa corrección le enseña más que cualquier configuración.

Lo esencial

El aprendizaje, las preferencias y el costo de las ejecuciones funcionan igual en todos los Kits, así que se explican una sola vez, en la guía de Kits.

Convivir con un Kit — la guía de Kits →

← Todos los Kits