Desarrollo trunk-based: la práctica de ingeniería que hace funcionar Scrum
Los equipos Scrum se comprometen a entregar software funcional al final de cada sprint. Ese compromiso solo es creíble si las prácticas de ingeniería que sustentan la capacidad de integrar y desplegar bajo demanda están realmente en su lugar. En muchos equipos Scrum, no lo están. Los equipos trabajan en ramas de funcionalidad de larga duración y luego se enfrentan a un doloroso evento de integración al final del sprint cuando todo el trabajo se fusiona simultáneamente. El coste de integración es alto, la retroalimentación se retrasa y la promesa de entrega continua sigue siendo teórica en lugar de operativa.
Lo que el desarrollo trunk-based significa en la práctica
Integrar en main al menos una vez al día: el máximo tiempo de divergencia es un día. Los conflictos de fusión son pequeños y frecuentes en lugar de grandes y ocasionales.
Usar ramas de corta duración (máximo dos días): una rama que no puede completarse y fusionarse en dos días generalmente indica que el trabajo necesita descomponerse más.
Usar banderas de funcionalidad en lugar de ramas para ocultar el trabajo incompleto: el código se integra y prueba en la base de código principal pero no se expone a los usuarios finales hasta que el equipo está preparado.
Pruebas automatizadas rápidas: el prerequisito más importante. Un conjunto de pruebas que tarda cuarenta y cinco minutos en ejecutarse desincentiva la integración frecuente.
Si sus equipos Scrum tienen dificultades con la integración o la brecha entre ceremonia y entrega, la práctica de entrega de programas y proyectos de XNM puede ayudarle a evaluar sus prácticas de ingeniería y a construir los cimientos técnicos que hacen creíble la entrega ágil.