“Yo no puedo ser ágil, en nuestro negocio es impensable un paso a producción cada Sprint”, “Nosotros tendremos que usar nuestro propio Scrum, los pasos a producción son demasiado delicados para hacerlos tan frecuentemente”, “En esto de la agilidad hay que ser menos radical y se debe permitir que no siempre un Sprint termine con un paso a producción”.
Te podría poner más frases literales, del estilo, que suelo escuchar. Esto de cuándo son los pasos a producción (delivery, release, poner a disposición de los usuarios o como cada uno lo llame) se malinterpreta demasiadas veces por aquellos que quieren hacer uso de Scrum o similares.
Te voy a poner lo que dice la guía de Scrum, que guste o no, es lo que dice la guía de Scrum, aunque suene así de redundante, luego ya cada uno puede hacer, obviamente, lo que quiera y mejor le funcione, y será “su Scrum”, pero… ¿qué dice Scrum de todo esto?, pues dice esto…
“The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it.”
Te dejo la traducción de la última parte por si hay dudas con el inglés…
“…lo cual significa que está en condiciones de ser utilizado y que cumple la Definición de “Terminado” del Equipo Scrum. El incremento debe estar en condiciones de utilizarse sin importar si el Dueño de Producto decide liberarlo o no.”
Otro trocito de interés para lo que estamos hablando…
“The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.”
Traducción de la última parte…
“…durante el cual se crea un incremento de producto “Terminado” utilizable y potencialmente desplegable.
Resumiendo, que nadie dijo que obligatoriamente un final de Sprint debe coincidir con un paso a producción. Lo cual tiene todo el sentido común del mundo, y lo contrario podría ser hasta imposible.
El cuándo se harán los pasos a producción dependerá del desarrollo que haga, no es lo mismo web que software empotrado, y de lo que decida el Product Owner, negocio. Quizá negocio considera que aún el “incremento” no tiene el número suficiente de funcionalidades como para poder salir al público.
Así que podremos encontrar múltiples posibilidades, que cada fin de Sprint termine con un paso a producción, que cada fin de Sprint termine con un incremento que no pasa a producción e, incluso, varios pasos a producción dentro del Sprint.
Ahora bien, dicho esto…
Que no se nos pase esto que es importante, si bien cada Sprint no tiene que terminar en paso a producción necesariamente, si que termina en “incremento”. Y un “incremento” es una versión en condiciones de ser usada, desarrollada y probada, que ha supera el Definition of Done (si eso lee en un proyecto ágil, acordar una buena definición de lo que significa terminado (el done)), que si el Product Owner decidiera liberar, pasar a producción, podría pasarse inmediatamente.
Recuerda las ideas calve sobre Scrum que te dejé en el vídeo de abajo.
Típicamente un “incremento” al final del Sprint, o antes, o está en producción o está en pre-producción, dos opciones, continuous delivery o continuous deployment (te dejo este post, por si acaso, ¿Continuous Delivery? ¿Continuous Deployment? Aclarando términos).
Y una segunda cosa, que no necesariamente un Sprint tenga que terminar con paso a producción no debe hacernos olvidar una cosa muy importante… los pasos a producción deben ser lo más pronto posible.
Eso cada uno verá cuando es lo “más pronto posible”, pero debes luchar al máximo, como Product Owner, Equipo, Scrum Master por que así sea. Cuando antes sean los pasos a producción, más información tendrás de la realidad, más aprenderás, más sanearás tu desarrollo para que esto sea posible y lo sea en buenas condiciones, mejor será tu Testing, menos impacto tendrá un error, fallo de negocio, funcionalidades indebidas, más adaptación al cambio, más adecuación a lo que quieren los usuarios, menos desperdicio, etc.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Buen post Javier. Debería ser prescindible si todos los equipos que hacen Scrum se hubieran leído la Scrum Guide, donde se deja claro que significa «Done» y «Pottentially shippable» para hablar del Incremento. Pero desgraciadamente mucha gente no lee la guía y se basa en mitos u opiniones que ha oído por ahí.
Leed la Scrum Guide (www.scrumguides.org). Es gratis y sólo 16 páginas. 🙂
También estoy muy de acuerdo con que una cosa es desplegar y que los usuarios accedan al software. Las prácticas como los despliegues «blue-green» o los «feature toggle» son buenas maneras de hacer la validación más realista con menos riesgo.
Alex Ballarin – http://www.itnove.com