En Agilidad, normalmente aquellos que siguen Scrum (te dejo un post de introducción sobre Scrum), pero también en otros que no siguen esta metodología (o más bien “framework”) es bastante frecuente encontrar dos tipos de Sprint especiales: el Sprint cero y el de Release.
Estos dos tipos de Sprint se ha ido introduciendo poco a poco, siendo hoy bastante frecuentes (al menos yo los he visto muchas veces). En mi opinión de han ido introduciendo en los proyectos principalmente por las caprichosas necesidades que nos depara el duro mundo real. Y no tanto por prescripción de los framework, es más, sobre ambos hay bastante polémica, sobre si su uso es necesario o esconden malas prácticas.
Veamos que trata de resolver cada uno de ellos…
El Sprint cero
En algunos equipos es frecuente el uso del llamado Sprint cero, cuyo objetivo son los preparativos previos a comenzar el desarrollo. Así, normalmente, durante el Sprint 0 se realizan las tareas como las siguientes:
- Se dejan listos los entornos de desarrollo.
- Se trabaja en el product backlog, principalmente en dejar listas las historias de usuario, priorizadas y estimadas.
- Se hace una previsión del reparto de historias de usuario por iteración.
- Se hace un estudio de la arquitectura.
Autores como Ambler, comentan que el Sprint cero es aquel en que se organiza el trabajo, se estudian requisitos iniciales, conceptualizaciones arquitectónicas iniciales, se dejan listos los puestos de trabajo, la planificación inicial, y todo lo que se necesita para iniciar el proyecto.
Aunque para Ken Schawber, coautor de Scrum, el Sprint cero no deja de ser una frase mal aplicada para describir la planificación previa al primer Sprint.
Por cierto, como he comentado otras veces, sin ser tan popular, FDD describe con más detalle lo que vendría a ser ese Sprint cero típico en proyectos que usan Scrum. Te dejo un post sobre FDD.
El Sprint de release
En las frameworks ágiles, y en Scrum especialmente, cada iteración, cada Sprint, debiera concluir con un incremento funcional sobre el producto, que además sea potencialmente entregable. Pero no todo lo “potencialmente entregable” es realmente “entregable”.
El Sprint de release (una reléase es una versión que va a pasar a producción, te dejo aquí alguna información más) es aquel que implementa aquellas tareas necesarias para poner el sistema en producción.
Aquel que muchos «proyectos» requieren al final de un ciclo de reléase, es decir después de un número de iteraciones o Sprint previos a un paso a producción.
Un último Sprint dedicado a preparar el paso a producción.
En este Sprint de release se realizan tareas como el despliegue, generación de “scripts” de recuperación del sistema en caso de problemas al pasar a producción, tareas relacionadas con las bases de datos en producción, documentación, pruebas de carga, etc.
Sobre el Sprint de reléase hay comentarios a favor y en contra, hay quien dice que es necesario, y quien dice que debería evitarse, ya que el equipo debería dejar lo suficientemente listas las cosas al final de un sprint regular como para que los pasos a producción no requieran de ese tiempo dedicado.
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
Pingback: Bitacoras.com
Hola Javier,
No soy un experto en metodologías ágiles pero, ¿el sprint de release no se carga bastante parte de las ventajas de las metodologías ágiles?
Si espero 16 sprints antes de empezar a hacer pruebas de carga, generar documentación, scripts de migración de base de datos, etc., ¿cómo se qué lo que he estado haciendo es realmente válido? ¿Y si las pruebas de carga son un fracaso? ¿Y si no puedo crear un script de migración de BD? ¿Y si resulta que hacer todo eso me lleva más de 1 sprint?
Me recuerda a un escenario que (casualmente) describía hoy Paul Stovell en su blog: Two week sprints; twelve month releases
Un saludo,
Juanma
Hola Juanma,
el ideal, imposible para muchas organizaciones, sería poder pasar a producción en cualquier momento, eso sería lo más rápido, yo creo que lo mejor, lo que más feedbback del usuario real daría etc. No sé si llegaste a ver el post de cómo lo hacen en Quora, que pasan a producción casi a diario. Esto está muy relacionado con en continuous delivery/deployment.
En otros sitios es imposible, por razones técnicas (cada software es un mundo) o por razones organizativas, es decir burocráticas, departamentos separados que deben revisar cómo se hace el paso a producción, etc.
Yo coincido con lo que comentas, lo ideal sería que directamente ese sprint no existiese, la realidad es que exite con mucha frecuencia
Saludos
Más que por la frecuencia de despliegues (creo que, como tú dices, no siempre el continuous deployment/delivery es posible o, ni siquiera, una buena idea), el tema del sprint de release me parece preocupante porque deja historias de usuario a medio implementar, y pierdes el «done, done, done», que me parece una de las características más útiles de las metodologías ágiles en general.
Supongo que parte del problema es la moda de «ser ágil», que hace que algunas empresas pretendan etiquetarse como «ágiles» a base de convertir la fase de análisis en «sprint 0» y la de pruebas en «sprint de release».
Tengo una duda, ¿Cómo empieza todo en un proyecto agil?
Supongamos que un cliente contacta con nosotros y nos dice «necesito un sitio web para la venta online de billetes de Renfe»
Aquí están mis dudas si usamos Scrum, y sé que el equipo Scrum está formado por el product owner, Scrum máster y development team:
¿Quién recoge los requisitos iniciales?
¿Quién y cuando se decide la arquitectura a emplear y el lenguaje o frameworks de desarrollo, etc.?
¿O es que el primer item del product backlog es «como X necesito un sitio web para que los ciudadanos compren el billete de tren»?
Entiendo que al inicio hay un trabajo previo de entender lo que nos están pidiendo, de saber el dimensionamiento del equipo de desarrollo y sus capacidades, de poder darle al cliente una estimación de lo que le va a costar el desarrollo y cuándo podrá disponer de él al completo. Porque aunque realicemos entregas tempranas entre 2 y 4 semanas, hasta que no tenga gran parte del producto no lo va a poder usar.
Llegará un momento que ya si se podrá poner a disposición de los ciudadanos y después de este momento se irán añadiendo nuevas funcionalidades.
Entonces mi duda es cómo inicia un proyecto ágil, desde que nos transmiten una necesidad hasta que ya estamos con unas cuántas historias de usuario en el Product backlog .
Muchas gracias!!
Hola Javier,
No me voy a pronunciar sobre la polémica acerca del llamado «Sprint 0», hay quien lo hace y quien no, y en buena medida creo que depende del grado de madurez en Scrum que tenga el equipo en cuestión.
Pero sobre lo del «Sprint de release», me parece que lo que cuentas o no está bien expresado, o directamente está mal. No es ágil algo sólo por llamarlo Sprint. Como dice Juanma, no tiene sentido (sentido ágil, quiero decir) iterar e iterar sin poner en producción. Eso no es ágil. Vale que mientras desarrollas, «producción» puede ser un entorno no-público, o de acceso restringido a ciertos usuarios «elegidos». Pero aún en ese caso, el último «paso a producción» debería ser cuestión de copiar unos archivos entre servidores, y no debería necesitar de más intervención humana que la de alguien que inicie el proceso.
Si necesitas un período final para «preparar el paso a producción», definitivamente NO estás haciendo Scrum ni agile. Estás desarrollando de forma iterativa y ,posiblemente, incremental. Pero eso no es ni Scrum, ni agile, ni nada parecido. En todo caso, estarás utilizando algunas de las herramientas de dichas metodologías, y te estás engañando a tí mismo y posiblemente a los que te rodean diciendo que eres «ágil».
Disculpa el trolleo, pero lo que no es correcto no es correcto. Y no porque alguien lo llame erróneamente se convierte en correcto. Seamos un poco rigurosos y coherentes, y tratemos de evitar este tipo de falacias que no hacen sino desvirtuar conceptos.
Un saludo,
@dagarfol
Hola,
Yo creo que si eres ágil. Eres ágil en desarrollo, pero no en producción. No serás una organización ágil, pero si un departamento/equipo de desarrollo ágil, si saco prototipos desde desarrollo a preproducción cada 2 semanas tranquilamente, pero la empresa necesita un mes cada 6 meses para pasar a producción… ¿por qué no soy ágil? Soy ágil en desarrollo. Vale que me faltará el continuous delivery/deployment. Pero lo cortés no quita lo valiente.
Además, en cualquier caso, yo creo que es algo lógico y razonable en ciertos entornos que se necesite un sprint de release (quizás se le podría llamar la iteración de release, pero creo que es rizar el rizo, total estando en 4 semanas no tiene porque no ser un Sprint).
Puede incluso que estándo muy rodada la parte técnica una funcionalidad requiera de un montón de gente coordinada para ello (imaginemos que es un nuevo servicio que se va a facturar y se pone en mercado para cientos de usuarios, necesito la superivisión del dto. de marketing, facturación, seguridad, etc., y eso me lleva un tiempo de preparación). También puede pasar que tenga que hacer el despligue en un CDP altamente controlado, y eso me va a llevar a tareas dedicadas solo al paso a producción. O que la empresa A desarrolle siendo muy ágil pero el paso a explotación del software lo hace la empresa B. Estoy totalmente deacuerdo que no serán un total ágil, o una empresa ágil, pero si el equipo desarrolla de manera ágil.
Nada de trolleo, me parece muy interesante este tema.
Saludos
Hola!
Estupendo, gracias por responder y aceptar el debate.
Ser ágil en desarrollo es como ser joven de espíritu: crees que eres algo que realmente no eres. Un departamento/equipo de desarrollo no es ágil por hacer «sprints». No te conviertes en ágil por hacer TDD, integración contínua, o daily meetings. Ni siquiera te convierte en ágil hacer todo eso y además usar historias de usuario, planning poker y demás. Todo eso te acerca a ser ágil, pero no te convierte en ágil.
Eres ágil cuando interactúas con tus usuarios y puedes responder rápidamente a los cambios/refinamientos en sus necesidades. Si sólo te expones a dichos cambios una vez cada 6 meses, ¿dónde está la agilidad?
Hacer desarrollos iterativos y llamarlos sprints no es ser ágil.
Yendo directamente a la base de scrum (puesto que hablamos de sprints), al final de cada sprint debes entregar algo terminado. La definición de terminado incluye tanto test unitarios automatizados como de aceptación. Y los test de aceptación los hace el usuario final en el entorno de producción.
Si por la complejidad de la puesta en producción los test de aceptación se planifican para unas fases o fechas concretas, independientes de los sprints del equipo, ¿donde está la agilidad? No puedes dar por «terminado» nada. Vuelves a tener 6 meses de desarrollo y luego una fase de pruebas.
Eso no es ágil. Ahí no hay respuesta rápida al cambio. Usas técnicas de metodologías ágiles, si, pero no estas haciendo desarrollo ágil. Es una diferencia sutil, pero importante. No es lo mismo hacer deporte que ser deportista. Y no es lo mismo hacer sprints que ser ágil.
En todo caso, si separásemos desarrollo e implantación podríamos tener un proyecto 100% ágil, el de desarrollo, y otro cuya agilidad es más o menos cuestionable. Pero entonces lo que tenemos son proyectos diferentes, y por tanto no tiene sentido llamarlo «sprint de release». Otra cosa es que por estar relacionados ambos proyectos se gestionen de forma conjunta. Pero llamar «sprint» a la fase final es erróneo.
Un saludo!
@dagarfol
Hola David,
Continuo ☺
Totalmente de acuerdo, todas esas prácticas que mencionas no te hacen ágil (es más, muchas son anteriores al concepto agilidad).
Pero… ¿qué tienes que tener un usuario real que vea la aplicación en producción, en real, para ser ágil? Yo no lo creo así.
¿Y qué hay del usuario interno – negocio? ¿Y del usuario real que ve la aplicación en demo, en preproducción? Entiendo el esquema que planteas en software mediano, pero en software grande lo veo difícil.
Además, en ningún sitio dice que esto tenga que ser así.
Por otro lado, más allá de si el término Sprint es el más adecuado o no, desde luego que no soy yo el único que así lo llama, es más es un término muy altamente popular y reconocido:
https://www.google.es/search?q=%22release+sprint%22&ie=utf-8&oe=utf-8&rls=org.mozilla:es-ES:official&client=firefox-a
Pero es que hasta reconocidos autores, en mi humilde opinión, de populares libros ágiles así lo llaman, y me estoy refiriendo, por ejemplo, a Cohn
http://www.mountaingoatsoftware.com/blog/correct-use-of-a-release-sprint (que además ilustra otro caso más de porque hay veces que no puedes evitar el Sprint de release)
En Scrum al final de cada sprint que necesitamos un «incremento del producto potencialmente entregable.», que no es lo mismo que “entregable” . Que eres capaz de que al final del Sprint sea entregable… pues mejor, pero no siempre puedes. Y las circunstancias son miles, las que mencioné antes, o el simple hecho de que para pasar a producción tengas que pasar por una fase de integración (cosa que suele suceder en software grande).
Por lo anterior existe la disciplina del continuous delivery (y yo puedo ser ágil sin continuous delivery)
La aceptación la puede hacer un usuario interno, o una selección de usuarios reales en preproducción.
Corto ya, que menudo comentario gigante me ha salido 🙂
Saludos!
Retomo el debate, que me parece interesante 🙂
Para mi la clave está en lo que dice David:
No es tanto una cuestión de ponerlo en producción o no, pero se supone que la filosofía del sprint es que lo que se hace, se hace. Y queda terminado. Y puedes pasar a otra cosa.
No veo como se puede considerar terminado algo que necesita una fase de pruebas, integración y generación de scripts en instalación dentro de 6 meses.
Un saludo,
Juanma.
Hola,
Si para ser ágil, al final de todos y cada uno de los Sprint tengo que concluir un paso a producción, va a ser una verdadera lástima decirles a mis compañeros que desarrollan firmware para el ABS de los coches (hablo de un caso real) y que, obviamente, no pueden pasar a producción cada 2 semanas, porque eso implcaría poner software en los ABS de los coches que circulan por la calle cada 2 semanas… que la agilidad les ha dado la espalda, que han sido rechazados, expulsados, y que ya nunca podrán ser ágiles 🙁 Son ahora de segunda… son iterativos.
Lo decía con ironía, y sin acriitud, por supuesto, además lo del desarrollo para ABS con «metodologías ágiles?» es un caso real de una empresa con la que colaboro.
Saludos!
Hola una vez mas!
Disculpa que haya tardado en responder, pero no quiero dejar esto a medias.
A ver, me parece que nos estamos perdiendo un poco.
Por un lado, decir que tienes un «departamento/equipo de desarrollo ágil» es una falacia si en ese departamento/equipo sólo hay desarrolladores. Los equipos ágiles no son sólo auto-organizados sino cross-funcionales (viva el spanglish!), lo que implica testers y gente de operaciones, entre otros.
Además, siguiendo las bases del (lo siento, mi proxy no me permite acceso al original 🙁 ), el objetivo es alcanzar un estado de continuous delivery. Para ello existen toda una serie de técnicas como continuous integration, continuous testing, TDD, devops, etc.
El uso de cada una de estas técnicas te proporciona cierto grado de agilidad, pero sólo cuando lo tienes todo puedes decir sin temor a equivocarte que «eres ágil». Mientras tanto, lo que tienes es «sólo» cierto grado de agilidad.
Así que la cuestión es ¿un proyecto «agil en desarrollo» es un proyecto ágil? Para mí no. Es más ágil que uno «normal», pero no lo llamaría ágil.
Por otro lado, en cuanto al sprint de release, parece que hay 2 vertientes: la que incluye un sprint de esos cada al final del proyecto, y la que lo hace X sprints «normales» o en determinadas circunstancias.
En cuanto a la primera, me parece aceptable que se planifique un sprint cuyo objetivo sea «Instalar la aplicación en el cliente XXX», y que en el backlog estén las tareas de adaptación a dicho entorno. No creo que esto vaya en contra de lo prescrito por la metodología, aunque me sigue pareciendo que llamarlo «de release» no es correcto.
En cuanto a la segunda, si cada X meses de desarrollo (o cada X sprints), hay que detener el desarrollo para hacer un sprint de release, dejas de añadir valor. Y además no es sino hasta después de dicho sprint que todo lo anterior lo puedes considerar terminado. Y eso, aunque lo diga el señor Mr Cohn, no es ágil ni scrum.
Los proyectos que despliegan en entornos altamente controlados, requieren controles de calidad exhaustivos, o están en situaciones similares que retrasan los ciclos de feedback, sólo están haciendo uso de técnicas ágiles, pero nunca, por definición, serán proyectos ágiles.
Reconocer esto no debe suponer un varapalo o un tipo de castigo, sencillamente es una práctica que se realiza en ciertos casos donde es necesario, o cuando la empresa en cuestión asume que puede prescindir de dicho grado de agilidad.
El problema es que hay empresas que (se) engañan diciendo que son ágiles, o que hacen proyectos ágiles, cuando en realidad quieren decir que sólo son ágiles en desarrollo. El resto sigue siendo lo de siempre: fases, iteraciones y falsa sensación de control.
En cuanto a tus amigos del firmware de ABS, bueno, no hace falta ser tan dramáticos. No es que sean «de segunda» ni mucho menos, pero si son sólo «ágiles en desarrollo» tendrán que reconocer que no son de primera. 😉
Un saludo!
@dagarfol
P.D. Disculpas por los mega-comentarios…
Hola,
Ya casi se me había olvidado este tema. Pero el verano y la limpeza de correos me lo ha devuelto a la mente.
Sólo una cosa, todo esto… ¿es una opinión o está basado en algo? ¿dónde vienen todas esas afirmaciones de qué, y quién, es y no es ágil? ¿en ese link gigante a la wikipedia?
Por cierto, y por fundamentar y apoyar en algo más que las ideas de cómo cada uno de nosotros creemos, hacemos, hemos visto, opinamos o nos gustaría que fuesen las cosas, casualmente he estado leyendo otra vez el libro de Ken Schwaber, el Enterprise and Scrum.
Incluso yo puedo estar más o menos de acuerdo con Ken Schwaber, pero como él se inventó el Scrum… pues lo puede definir como quiera, y de su libro he extraido algunos párrafos:
…We need to release a new feature to our customers within three months.
..they stayed together for the first one or two Sprints of the release
… the prototype team manager started by telling us that she wanted only two releases that year
… organizes a subset of the overall Product Backlog into a release Product Backlog.
… the 12 items had to be done and the release needed to ship within six months.
Supongo que consideramos que Scrum es una metodología ágil (creo que ahi estamos de acuerdo). Y al menos ahí… en Scrum, parece que el concepto release más allá de un Sprint no está prohibido…. ni es de equipos ágiles de segunda.
Saludos veraniegos.
Hola, estamos comenzando una tesis y optamos por scrum pero nos estampamos contra la realidad de la cátedra que te exige un dia «D» EN EL CUAL HAY QUE ENTREGAR EL RELEVAMIENTO, ANÁLISIS, DIAGNÓSTICO,y Modelado lo que no es más ni menos que una metodología estándar.
Pero el docente nos dicen hagan un mix con scrum lo que nos limita contra la filosofía del mismo.
Pregunto estas etapas se incluyen en un sprint? o se hace todo eso primero y en el sprint únicamente se codifica?
Gracias
Hola,
Lamentablemente hasta ahora veo este articulo y el foro que llevaron sobre él.
Aunque tarde, quiero comentarle a Sergio que es el mismo caso que llevo en la vida real en los proyectos que he ejecutado y que estoy ejecutando. Solo puedo aplicar SCRUM en el DESARROLLO. Las demás etapas como la de ANALISIS DE REQUERIMIENTOS y DISEÑO empleo las metodologias tradicionales. Luego a partir del documento de diseño aprobado, mi equipo de DESARROLLO trabajo como un EQUIPO SCRUM.