Ajedrez - antoniomartel.com

Archivos por Etiqueta: SCRUM

Reunión de planificación del Sprint

Durante esta reunión, mantenida al inicio del Sprint o poco antes de empezarlo, se planifica el trabajo a realizar durante el Sprint. Participarán en ella el Scrum Master, el equipo de desarrollo y el Product Owner.

Para sprints de un mes esta reunión durará un máximo de ocho horas durando menos si el Sprint es más corto de un mes. El Scrum Master se encargará de que la reunión se lleve a cabo, de que todos entiendan para qué es la reunión y que ésta se mantenga dentro de las ocho horas de margen de tiempo.

En esta reunión de planificación calcularemos qué puede entregarse al finalizar el Sprint que va a comenzar y cómo haremos el trabajo para conseguir este objetivo:

Qué puede entregarse al finalizar el Sprint

Con la vista puesta en los objetivos definido por el Dueño del Producto discutiremos con el equipo de Desarrollo qué funcionalidades deberemos desarrollar y si caben dentro del Sprint. Escogeremos de la Lista de Producto esas funcionalidades y las pasaremos a la Lista del Sprint. Si logramos acabar esta selección de elementos de la Lista de Producto dentro del Sprint habremos conseguido el Objetivo del Sprint.

Sólo el equipo de desarrollo puede decir cuantos elementos de la lista de producto entran a formar parte de la lista del sprint. Con la vista puesta en esa lista de producto y en el rendimiento obtenido en sprints pasados, el equipo de desarrollo hará una proyección de hasta donde puede llegar en este sprint.

Cuando el equipo de desarrollo ha finalizado este cálculo de cuantos elementos de la lista de producto puede terminar en el sprint, el equipo Scrum al completo (Scrum Master, Dueño del producto y equipo de desarrollo) deciden cuál será el Objetivo del Sprint (Sprint Goal). Este objetivo estará presente durante todas las semanas de implementación del Sprint y servirá como guía al equipo de desarrollo para saber por qué y para qué se está trabajando en ese sprint

Cómo haremos el trabajo para conseguir el Objetivo del Sprint

 Los elementos de la Lista de Producto (Product Backlog) seleccionados para este Sprint componen la Lista del Sprint (Sprint Backlog) y son los elementos que el equipo de desarrollo implementará para entregarlos al final del Sprint.

El equipo de desarrollo diseñará las funcionalidades y el trabajo necesario a realizar para completar el Sprint y concluirá la reunión con éste trabajo descompuesto en unidades o tareas de un día o menos. A partir de ahí el equipo de desarrollo se auto-organizará para tomar estas tareas y llevarlas a cabo a lo largo del Sprint.

Durante la reunión de planificación el Dueño del Producto explicará lo que hay que desarrollar para poder hacer las nuevas funcionalidades de la Pila del Sprint. El equipo de desarrollo tomará más elementos de la Pila del Sprint si no tiene suficiente trabajo para el Sprint o renegociará con el Dueño del Producto los elementos de esta lista si tiene demasiados.

Al finalizar esta reunión del planificación del sprint tendremos:

  • La Lista o Pila del elementos del Sprint (Sprint Backlog)
  • El Objetivo del Sprint
  • La descomposición de la Lista del Sprint en tareas de 1 día o menos.

Ceremonias de Scrum

En Scrum existen diversas reuniones o eventos, también llamadas ceremonias, que tratan de crear regularidad y reducir al mínimo la necesidad de reuniones fuera de las definidas en Scrum. Todas estas reuniones tienen una duración máxima (timeboxing) con el objetivo de que estos eventos no se conviertan en eternos llevándonos por disquicisiones que no van a ningún lado o a la pérdida de tiempo.

El propio Sprint es el evento central dentro de Scrum y contiene al resto de eventos y ceremonias. Todos estos eventos están diseñados para permitir la inspección y la adaptación de lo que está pasando en el proyecto. Cada uno de ellos es una oportunidad de mejorar el proyecto y darle transparencia a todos los participantes. Si falta alguno de ellos podría estar faltando transparencia al proyecto y perderse esa oportunidad de adaptarse a los cambios para mejorar.

El Sprint

El Sprint es el corazón de Scrum, es un bloque de tiempo de un menos o menos, suele ser de dos semanas, durante el que se crea un incremento del producto Terminado, Utilizable y Potencialmente desplegable. Estas tres características son importantes:

  • Terminado: Se dice así cuando por consenso de los participantes del proyectos, las funcionalidades, nuevas características o errores corregidos durante el Sprint están completamente hechos o terminados. Es decir que no faltan fases de test o que las funcionalidades están incompletas a falta de uno o más sprints para finalizarlos.
  • Utilizable: Las nuevas características que estamos añadiendo en este Sprint son utilizables por el usuario final que las puede comenzar a usar tan pronto como hayan sido desplegados. No se trata de características a las que les falte alguna otra funcionalidad a ser desarrollada más adelante para poder ser utilizada.
  • Potencialmente desplegable: Puede que decidamos no subir a producción tan pronto como terminemos el Sprint y que esperemos a tener un conjunto mayor de funcionalidades a hacer esta subida pero lo que entreguemos al final el Sprint estará listo y podría ser desplegado en producción si así lo hubiéramos decidido.

Dentro de cada Sprint encontraremos las siguientes reuniones y ceremonias que se explicarán con más detalle a lo largo de este capítulo:

  • Reunión de planificación del Sprint (Sprint Planning Meeting)
  • Reuniones de Scrum Diario (Daily Scrums)
  • Reunión de demo o revisión del sprint (Sprint Review)
  • Retrospectiva del Sprint (Sprint Retrospective)

El Sprint tiene las siguientes características:

  • Cada Sprint comienza justo después de la finalización del Sprint anterior.
  • El Sprint se ajusta a un Objetivo del Sprint que es la meta que quiere alcanzarse cuando se acabe el Sprint. Por ejemplo: Desarrollar el sistema de login de la aplicación.
  • No se disminuyen los objetivos de calidad para llegar al objetivo del Sprint.
  • El alcance del Sprint puede ser clarificado con el Dueño del Producto y el Equipo de Desarrollo para renegociarlo con ellos a medida que sucede el Sprint y vamos conociendo más durante el Sprint.

Podemos considerar al Sprint como un mini proyecto que tiene un horizonte de un mes o menos (por ejemplo dos semanas). Un proyecto que tiene un objetivo y unas etapas en las que se va a definir qué se va a construir, se diseña y se trabaja un plan para la construcción del producto resultante al finalizar esas dos semanas.

El objeto de dividir el proyecto en todos esos mini proyectos de un mes o menos es el del clásico divide y vencerás. Con proyectos tan pequeños podemos mantener acotada al complejidad, evitar que cambie lo que se está construyendo y evitar que aumente el riesgo de proyecto durante ese tiempo. Además al ser proyectos tan pequeños podemos adaptarnos al finalizar y comenzar un nuevo Sprint a lo que hayamos aprendido en el Sprint anterior. Por todo esto el riesgo de estos mini proyectos estarán limitados al costo de un mes de trabajo como máximo.

¿Se puede cancelar un Sprint?

Sí, un Sprint puede ser cancelado antes de que llegue a su fin. El Dueño del Producto y sólo él puede decidir que no merece ya la pena el Objetivo del Sprint por lo que puede concluirlo.

Algunas cosas pueden ocurrir en el plazo máximo de un mes que puede durar un Sprint: la dirección cambia de estrategia, a los interesados en el producto ya no le interesan las funcionalidades a desarrollar en este Sprint, o las condiciones del mercado o de la tecnología cambian y ya no tiene sentido el objetivo del Sprint.

Debido a la corta duración del Sprint las cancelaciones normalmente no tienen lugar porque no tantas cosas pueden cambiar de repente. Es algo que debemos de evitar porque cancelar un Sprint tiene un coste: Hemos estado preparando y planificando el Sprint y debemos reunirnos de nuevo para planificar el siguiente. Casi todo ese esfuerzo se tira a la basura para comenzar un nuevo Sprint. Podemos dar además la sensación de estar actuando sin una clara dirección o estar tomando los objetivos de los sprints muy alegremente, sin pensarlos demasiado.

A la hora de cancelar un Sprint revisaremos todos los elementos de la Lista o Pila de Producto y comprobamos cuales de ellos están en estado Terminado y son potencialmente entregables para presentarlos al Dueño del Producto y que éste diga si lo acepta como entrega o no. El resto de elementos de la Lista del Sprint que no estuviesen completados vuelven a la Pila del Producto para volver a ser estimados ya que el trabajo que se haya hecho en ellos pierde valor con rapidez y debe volverse a estimar.

Mi libro número tres entre todos los libros de programación

Mi libro Gestión Práctica de Proyectos con Scrum lleva vendiéndose desde mayo de 2014, más de 3 años en los que el libro ha llegado a bestseller en su categoría varias veces y en todo Amazon, brevemente, en dos ocasiones.

Pero en este tiempo ha seguido vendiéndose a una media de unos 2 a 3 libros diarios en los últimos tiempos lo que lo convierte ahora en un libro longseller. Esta misma tarde se ha colocado en el número 600 de todos los libros más vendidos en Amazon España y en el número 3 de todos los libros, no sólo digitales, en la categoría de Programación y desarrollo de software.

Además, en este tiempo ha cosechado 17 comentarios en Amazon México, 41 en Amazon.com y 56 en Amazon España con opiniones tan buenas como éstas:

«No me esperaba encontrar esto y la verdad que me ha sorprendido gratamente»
— Iván

«Lo que más rescato es la prioridad que se tuvo para exponer lo realmente importante, logrando así un libro compacto y preciso»
— Cliente de Amazon

«Claro y eficaz, utiliza un lenguaje sencillo y es una magnifica obra para introducirse en scrum de una forma realista»
— Cliente de Amazon

«Es la experiencia del autor en su aplicación, ventajas desventajas, lecciones,… Sencillo y ameno»
— KermitSBD

«Genial: En mi trabajo, vamos a implantarlo y me ha tocado ser Product owner… Ha sido un repaso, muy ameno de lo que vemos en las formaciones. Muy recomendable»

— Isabel Soler López

«Cumple exactamente lo que promete la sinopsis: Un libro interesante y práctico. Escrito desde la experiencia y el sentido común»
— Santi

«Genial libro para entender el Scrum de forma practica y util»
— Cliente de Amazon

«El libro me encanta, es una buena intro para metodología Scrum, y se lee muy bien y rápido. Lo recomiendo»
— WildWilly

«Una ‘novela’ real de un técnico: Me ha gustado mucho. Me parece muy fácil de leer y muy didáctico. Se lee como una novela de casos ocurridos al autor»
— Cliente Amazon

«Realmente bueno: Un libro muy interesante tanto para el que se inicia como para el conocedor de Scrum (es mi caso). En su texto que es muy ameno, -aderezado con dibujos y citas muy útiles-, vas a encontrar consejos y también la esencia de Scrum (…) Es conveniente releerlo otras veces»
— Cliente de Amazon

El Scrum Master y la organización

¿En qué ayuda el Scrum Master a la organización o empresa en la que trabajamos? En textos anteriores vimos en qué ayudaba el Scrum Master al Product Owner y al Equipo de Trabajo pero ¿y a toda la empresa en su conjunto?

Lo más importante de todo es liderar los cambios en la empresa para poder adoptar Scrum, es decir, ayudar a todos a que entiendan el motivo de las reuniones diarias, las reuniones de demo, la pila del producto, etc. buscar un hueco para estas reuniones y organizarlo todo para poder implementar Scrum en la empresa.

Para hacer esto habrá que planificar la adopción de Scrum en la organización ayudando a poner fechas para una implementación de Scrum gradual y cada vez mayor en la empresa si este es el caso. Por ejemplo podría establecer un calendario para que cada vez más equipos se vayan sumando al uso de Scrum, fijando reuniones de formación previas para explicar cómo se trabaja con Scrum y hacer seguimiento de cómo van estas implementaciones de Scrum en la organización para luego realizar los cambios que sean necesarios que incrementen la productividad de los equipos Scrum.

El Scrum Master tendrá también que ayudar a sus compañeros y empleados en la empresa a entender cómo funciona Scrum y cómo llevarlo a cabo. Debe llevar ese papel de formador o ‘profesor’ de Scrum para hacer que todos entiendan este cambio de paradigma.

Por último el Scrum Master deberá trabajar con los otros Scrum Masters de la empresa para que en conjunto se incremente la efectividad y la productividad de la aplicación de Scrum que se está haciendo en la empresa. Deberán poner en común las cosas que están funcionando o no en la adopción de Scrum y hacer los cambios necesarios para mejorar la aplicación de Scrum en la organización.

El Scrum Master y el Equipo de Desarrollo

El trabajo del Scrum Master no es el de jefe de proyectos ni es sólo el de servir de ayuda al Product Owner (que tampoco es el jefe de proyectos). En el trabajo diario del Scrum Master también debe ofrecer servicios de ayuda al Equipo de Desarrollo además de al Product Owner.

El más importante quizás sea el de eliminar impedimentos para el progreso del Equipo, es decir, ayudar en lo que el equipo necesite para tener su trabajo preparado y no tener que estar esperando por nada. Si por ejemplo se necesita solicitar una exportación de la base de datos antes de realizar algún trabajo, será trabajo del Scrum Master realizar estas gestiones para que el Equipo de Desarrollo lo tenga preparado a tiempo y no tenga que quedarse esperando a que esto se resuelva.

Otro de los puntos importantes en los que debe trabajar el Scrum Master es en el de guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional. Los equipos de desarrollo normalmente esperan que alguien les asigne las tareas y a encargarse sólo de aquellas tareas que pone el título de su contrato. El Scrum Master debe intentar cambiar este paradigma haciendo que cambie esta mentalidad para que el Equipo de Desarrollo sepa elegir sus propias tareas (de acuerdo por supuesto a la priorización hecha por el Product Owner) y a encargarse de todas las tareas sin derivarlas a otros departamentos porque ellos son los especialistas (departamentos de administradores de bases de datos o de analistas para que ellos hagan el análisis o un import o export de bases de datos).

Entre los trabajos del Scrum Master también está el de organizar los eventos o reuniones de Scrum para facilitar que éstas sucedan. Deberá organizar la reunión diaria, la reunión de demo, la reunión de retrospectiva, procurar que todos asistan y que sea del máximo provecho para todos los interesados.

También deberá servir al Equipo de Desarrollo para ayudarlo a crear productos de alto valor que no quiere decir que tengan un nivel de calidad alto, que se da por supuesto, sino a que el Equipo de Desarrollo esté centrado en producir funcionalidades y características que le aporten el máximo valor o utilidad al producto que se está construyendo.

Por último, y no menos importante, el Scrum Master deberá guiar al Equipo de Desarrollo cuando éste no ha trabajado nunca con Scrum para ayudarles en su adopción y en que sea completamente entendido por todo el equipo.

Suscríbete