Continuous Discovery en Scrum / Agile
Ya he escrito sobre cómo los equipos de producto agiles o de Scrum ejecutan Product Discovery y Product Delivery en paralelo. También he escrito sobre cómo los equipos a veces prefieren trabajar con Timeboxing en el Product Discovery.
En este artículo quiero escribir sobre la tendencia creciente hacia Continuous Delivery y Continuous Discovery.
La idea de Continuous Delivery (entrega continua) se está extendiendo cada vez más. Muchos equipos han hablado de ello en los últimos años, pero ahora también hay equipos que realmente trabajan con ello.
Casi todos los equipos de producto trabajan hoy en día con builds continuos. El principio detrás es que es mejor encontrar los problemas que surgen más pronto que tarde. Por eso, los builds normalmente se inician tan pronto como se realizan cambios.
Algunos equipos de producto han llevado este principio a un nivel completamente nuevo. Han aprendido que los problemas de integración consumen mucho tiempo y que mediante la integración temprana y frecuente (en lugar de una única fase antes de las pruebas) pueden mejorar significativamente su rendimiento general, minimizando el tiempo en que trabajan de forma aislada.
Del mismo modo, es mejor ejecutar suites de pruebas de regresión automatizadas de forma continua para detectar problemas nuevos lo más pronto posible (lo que reduce significativamente el número de fuentes de error y el tiempo de corrección), en lugar de probar todo en una fase al final de un ciclo de Release (incluso de un ciclo de dos semanas) y descubrir todos los problemas de golpe.
La consecuencia lógica es que algunos equipos ahora lanzan regularmente (conocido como Continuous Deployment). Esto significa que cada cambio lógico (o grupo de cambios) se entrega directamente en pequeños "micro-releases". Esto tiene algunas grandes ventajas. La primera es que esta es la estrategia definitiva para releases incrementales y, por tanto, el mecanismo principal para Gentle Deployment: bueno para nuestros clientes y bueno para nosotros. La segunda ventaja es que la búsqueda y solución de problemas en producción es mucho más fácil cuando solo se cambia una o pocas cosas a la vez.
Sin embargo, todo lo que he descrito hasta ahora tiene que ver con Product Delivery. Pero, ¿qué pasa con el Product Discovery?
Llevo bastante tiempo abogando por el mismo principio cuando se trata de encontrar Product Backlog Items. En lugar de una "fase de Product Discovery" de varias semanas, en la que se crean, validan y luego se pasan a desarrollo los Product Backlog Items, quiero animar a los equipos a un Product Discovery continuo, en el que identificamos, validamos y describimos permanentemente nuevos Product Backlog Items. Algunos trabajos de Discovery duran solo unas pocas horas, otros más tiempo, pero es un proceso permanente de generación de ideas, validación y descripción.
En Dual-Track Scrum, en el Discovery Track se generan continuamente Product Backlog Items y en el Delivery Track estos elementos se construyen, prueban y despliegan continuamente.
Teniendo en cuenta la tendencia de Continuous Discovery y Continuous Delivery, muchos equipos encuentran el proceso Scrum un poco restrictivo y consideran que el modelo Kanban es más adecuado en este caso.
Aunque no todos los equipos cambiaron necesariamente a Kanban, he visto a muchos que adaptaron Scrum hacia Kanban exactamente por esta razón. La adaptación más común es, en lugar de lanzar después de cada Sprint de por ejemplo dos semanas, lanzar las funcionalidades y otros cambios directamente cuando están listos, a menudo varios micro-releases por semana. En este caso, los equipos utilizan el Timeboxing de Scrum como una forma de estructurar su trabajo y fomentar Retrospectivas regulares.
Básicamente, la transición a Continuous Discovery y Continuous Delivery es algo realmente positivo y muchos de los mejores equipos que he conocido trabajan con ello; aunque aquí, como en todas partes, puede ser necesario hacer compromisos.
Este texto proviene del blog de Marty Cagan y fue traducido al alemán por nosotros.
