Segunda parte del post para aquellos que en 10 min quieran quedarse con la idea principal de Scrum. Aquí tienes el enlace a la primera parte.
—
Las Reuniones
El segundo pilar más importante de Scrum son las reuniones (el primero era el ciclo de vida iterativo e incremental, los Sprints). Su importancia reside en que las reuniones son la base para lograr transparencia y comunicación, y posibilitan algo característico en un equipo ágil: que sea auto-gestionado y multifuncional. Las reuniones se realizan a lo largo de todo el proyecto, según las siguientes tipologías:
– Reunión de Planificación del Sprint (Sprint Planning Meeting). Al principio de cada Sprint, para decidir que se va a realizar en ese Sprint.
– Reunión diaria (Daily Scrum). Máximo 15 minutos, en la que se trata que hizo ayer, que va a hacer hoy y que problemas se han encontrado.
– Reunión de Revisión del Sprint (Sprint Review Meeting). Al final de cada Sprint, y se trata qué ha completado y qué no. También se muestra el trabajo al Product Owner.
– Retrospectiva del Sprint (Sprint Retrospective). También al final del Sprint, y sirve para que los implicados den sus impresiones sobre el Sprint, y se utiliza para la mejora del proceso.
Consideraciones importantes y cosas que deberías tener muy claras antes de terminar esta serie de post
Aunque este post es breve, no quiero por dejar pasar por alto algunas consideraciones importantes:
– Cada proyecto, empresa, producto, línea de negocio, etc., requiere una adaptación de Scrum a su caso. Scrum es un marco de trabajo, o meta-metodología, como lo llaman algunos, por lo que tiene que adaptarse.
– Scrum, aunque nace en el mundo del desarrollo software, es una metodología lo suficientemente genérica como para poder aplicarse a la gestión de otro tipo de proyectos. De ahí que se esté extendiendo su uso a otros ámbitos.
– Normalmente Scrum no se utiliza sola, ya que no cubre todo lo que se necesita para abordar un proyecto software. En software es muy típico acompañar Scrum con la metodología XP, que aporta cuestiones más cercanas a la programación, y con Kanban (te recomiendo este post sobre qué es Kanban), que ayuda mucho en la gestión de las tareas en las que se descomponen las historias de usuario.
– Scrum no es la única metodología ágil que existe. No es la solución a todos los males. Hay empresas en las que, por su negocio, no encaja bien Scrum. Y en lograr, si aplica, su implantación está la clave del éxito y lo que supone un verdadero esfuerzo (aprender las bases de Scrum es lo fácil, como has visto se pueden sintetizar en 2 post)
Enlaces de interés
– Una animación: Introducción y conceptos de Scrum.
– Si quieres seguir adelante con Scrum, y quieres que alguien te eche una mano, te dejo un enlace.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Pingback: Bitacoras.com
Hola Javier, tengo una duda:
¿Qué beneficio se obtiene de que se hagan estas reuniones por separado:
– Reunión de Revisión del Sprint.
– Retrospectiva del Sprint.
Me parecen similares, y veo que se harían en momentos direrentes… Así, como de las dos primeras que hablas me quedan claros sus beneficios, aquí no tanto.
¡Gracias por anticipado!
Hola Santiago
Que cada una persige y trata un objetivo diferente, la 1a estudiar el valor aportado al cliente. La 2a la mejora del proceso de desarrollo (mejora continua)
Saludos
Buenas Santiago,
En la revisión del Sprint el foco se encuentra en el resultado de valor entregado al cliente. Por el contrario, en la reunión de retrospectiva el foco se encuentra en la mejora del proceso de desarrollo (es decir de la misma metodología seguida).
No son iguales y, de hecho, en base a la experiencia te digo que deberían buscarse mecanismos para hacer notar esa diferencia (reuniones en lugares diferentes, otro moderador, etc.). Saludos!
Muchas gracias por la pronta respuesta.
Me ha quedado claro, y por los comentarios de que la experiencia aún nos lleva a reforzar más esa diferencia ya se nota el peso que tiene.
¿En la de Retrospectiva del Sprint, debe estar el Product Owner?
La participación del Product Owner es opcional.
Si se está empezando a implantar Scrum mi opinión es que no esté. De esta manera el equipo de desarrollo tiene mayor libertad para hablar sobre los problemas internos, etc.
saludos
Ok
¡Gracias!
Pues lo dicho. Y supongo que todo dependerá del «buen rollo» que se tenga conel PO 😉
Hola Javier, has resumido de manera clara como se trabaja Scrum. Una consulta estoy realizando mi Tesis haciendo uso de la metodología Scrum, para el modelado que diagramas tengo que incorporar como mínimo, si solo tengo mis casos de usos en que me baso para incorporar los demás diagramas (como en RUP). Gracias
Scrum no entra en diagramas, eso es un tema a incorporar voluntariamente si lo necesitas. Saludos!
No me queda claro si en la reunión de planificación del Srpint participan todos los miembros del equipo? o esta planificación es solo responsabilidad del Product Owner
Muy claro, conciso, directo y práctico, te felicito y gracias por el aporte!
Gracias
Eres de gran ayuda 🙂
Qué peligroso trabajar siguiendo metodologías ágiles cuando el PM no sabe exactamente lo que es y centra en la idea de que saldrán los proyectos antes y serán mejores (burbuja de pensamiento, ganaré más, trabajaré menos, mi cara se verá más, proyectos: todos a mí). Premisas de este género de PM sobre lo que es Scrum:
– Comercial vende producto o servicio –> de aquí sale LA historia de usuario (comercial = conocimiento orgánico? conocimiento técnico? null?, porque si historia de usuario = requisitos funcionales y requisitos funcionales =! requisitos orgánicos … Mal empieza la historia).
– Un vez el comercial acapara en su mente LA historia de usuario (al completo, of course) a modo de palabra divina irrefutable, pasa a desarrollar un documento vital: la propuesta comercial.
– Ahora viene el primer Sprint (el SPM): el PM echa un vistazo alrededor y selecciona a su equipo (me ahorro los criterios de selección). En 10 min les cuenta lo que no sabe, da igual cómo de patente quede su NI (nivel de ineptitud) justo los 10 últimos min de la jornada, porque el SPM termina con un: mañana os váis al cliente (por no dar no dan ni dirección, ahí empieza el poder visionario de EL equipo).
– DS: al final de un día improductivo a más no poder, después de aguantar voces, gritos, insultos, sarcasmos y todo lo que a uno se le ocurra por parte del cliente y demás fauna con morada en cliente, el líder de EL equipo hace reunión para preguntar al resto de miembros qué han hecho y marcar en LA historia de cliente (no olvidemos, propuesta comercial) a modo de checklist, lo que se ha hecho. WTF? Sí. Aquí acaba la jornada. Mañana más, ahora, mejor con poco será mejor mañana.
– SRM: no se ha completado ningún sprint porque, señores, esto es en serio o nos dimos un golpe con la almohada de piedra? El PM … Uff, ocupadísimo para ir a una reunión, si total, no habla ni con su equipo, bastante tiene con malmeter entre los miembros para que se entretengan en devorarse unos a otros y no den la murga.
– SR: pobre del que abra la boca. PM tranquilo, total, más que él no sabe nadie de su equipo, uff, y un developer? Un developer no tiene ni idea de metodologías ni de gestión de proyectos. En su equipo nadie vale nada, porque PM es EL boss. Y si alguien dice algo lo utilizará en su contra y desprestigio público y privado.
Lo dicho, un problema eso de metodología ágil a discreccion. Yo creo que lo indispensable es partir del conocimiento de lo que es un prototipo evolutivo reutilizable, eso para comprender la esencia de Scrum. Distinguir entre requisitos orgánicos y funcionales también es vital. Tener un mínimo de nociones de lo que es la deuda técnica tampoco va mal. Y si puedes hablar algún idioma a parte del que nos enseñan en casa o el que se aprende en cualquier bar de la calle, también está bien.
Pero vamos, que yo soy un triste Spanish developer. Así que acepto descalificativos, mayúsculas para gritar.
Hola. Buen post, sin embargo discrepo un poco sobre la review. Esta es una reunión de trabajo, donde no se le muestra recién al PO. Muy por el contrario, el debería dar cuenta posiblemente a los stakeholders sobre el incremento, ayuda a refinar el producto backlog y si es posible muestra el el incremento con ayuda del equipo de desarrollo.