Coroid modela un ciclo de vida de software completo, no solo la fase de compilación. La mayor parte se ejecuta automáticamente; una parte es un punto de control opcional que se activa cuando el trabajo es lo suficientemente relevante como para justificarlo.
El flujo de trabajo SDLC opcional
En la Nuevo trabajo forma, bajo configuraciones avanzadas, hay una casilla de verificación:
Usar el flujo de trabajo SDLC (opcional) — revise la intención y las Especificaciones antes de planificar. Deje esta opción desactivada para iniciar la planificación directamente a partir de su resumen.
Está desactivado de forma predeterminada. Si está desactivado, su resumen pasa directamente a la planificación. Si está activado, primero se generan y aprueban dos artefactos:
- Intención — el propósito real del trabajo, con las decisiones y supuestos que lo sustentan registrados.
- Especificaciones — alcance, exclusiones y criterios de aceptación.
Solo después de que estos sean aprobados comienza la planificación.
Cuándo activarlo
Actívelo cuando el coste de desarrollar algo incorrecto sea elevado, cuando la solicitud provenga de alguien que no revisará el plan personalmente, o cuando el resumen contenga un supuesto que prefiera ver por escrito y acordado.
Déjelo desactivado cuando el resumen ya sea inequívoco. Una puerta de aprobación adicional en el trabajo rutinario supone fricción sin beneficio alguno — y el paso de aprobación del plan sigue aplicándose independientemente.
Las cinco etapas
El ciclo de vida completo se desarrolla en cinco fases, cada una generando evidencia que utiliza la siguiente.
| Etapa | Qué ocurre | Estado |
|---|---|---|
| Definir | Una solicitud ambigua se convierte en intención aprobada, decisiones, supuestos y medidas de éxito. | Versión beta |
| Visualizar | Conceptos de interfaz opcionales, refinados y aprobados como guía de diseño. | Versión beta |
| Entregar | El plan se descompone y los agentes lo ejecutan. | Disponible |
| Comprobar | Los requisitos se mapean a tareas, comprobaciones, resultados de revisiones y cambios en las solicitudes de incorporación de código. | Disponible |
| Mejorar | Los monitores, remediaciones y evaluaciones convierten las regresiones en trabajo para el siguiente ciclo. | Disponible |
Definir y Visualizar son las dos fases en desarrollo activo. Entregar, Comprobar y Mejorar son las que se ejecutan en cada tarea hoy en día, independientemente de si se activa o no el punto de control.
Por qué los artefactos tienen versión
Las aprobaciones se vinculan a una versión exacta de un artefacto. Editar un artefacto aprobado crea un borrador nuevo en lugar de modificar silenciosamente lo que se había acordado.
Esto es lo que hace que una aprobación tenga sentido. Una aprobación que flote — vinculada a "las Especificaciones" en lugar de a una versión específica de las mismas — aprueba lo que el documento diga más tarde, lo cual no constituye una aprobación en absoluto.
Roles de aprobación
Las responsabilidades de producto, diseño, técnica, seguridad y despliegue se pueden asignar de forma independiente, de modo que la persona que aprueba las implicaciones de seguridad no sea necesariamente la misma que aprueba el alcance.
Línea de procedencia de la evidencia
El objetivo de generar evidencia en cada etapa es que un pull request finalizado pueda rastrearse hacia atrás: este cambio implementa esta tarea, que proviene de este requisito, que a su vez proviene de esta intención aprobada.
Esa cadena es lo que hace que la entrega autónoma sea auditables. Sin ella, tendría código funcional pero ningún registro de por qué es el código que solicitó.
Cómo se relaciona esto con los planes
El flujo de trabajo SDLC y los planes son puntos de control diferentes:
- El flujo de trabajo SDLC aprueba qué se debe construir, antes de que exista un enfoque.
- El plan aprueba cómo se construirá, antes de que exista el código.
Puede utilizar uno, ambos o ninguno. Ambos son más económicos que revisar un pull request ya finalizado con el que no esté de acuerdo.