Chess - antoniomartel.com

Archivos por Etiqueta: teoría

Demo del sprint o sprint review

Al finalizar el sprint se realiza una revisión de lo entregado en el sprint para poder ver lo que se ha estado haciendo durante el mismo y tener la oportunidad de adaptarse si hubiese que hacer algún cambio. No se trata de una reunión de seguimiento en la que se va a juzgar al equipo de desarrollo sino de tener la posibilidad de presentar el trabajo y comprobar cómo de cerca o de lejos estamos del objetivo y si necesitamos hacer cambios para que el producto esté más orientado a las necesidades del cliente.

El tiempo máximo establecido para esta reunión de demo o presentación del trabajo del sprint es de 4 horas para sprints es de un mes o la mitad si el sprint es de sólo dos semanas. Es trabajo del Scrum Master el que la reunión se lleve a cabo y se mantenga dentro de los tiempos establecidos.

A esta reunión de demo asistirán el Scrum Master, el Dueño del Producto, el equipo de trabajo y los interesados que el Dueño del Producto invite a la reunión y en ella se explicarán qué elementos de la pila del producto se han terminado y cuales no para poder acabarlos. Tras esto el equipo de desarrollo demostrará ante todos los asistentes cómo funcionan los elementos terminados de la lista del sprint.

Esta reunión servirá para que el cliente pueda ver cómo se han desarrollado los requisitos que ha dado, si se están entendiendo estos requisitos, sus objetivos generales para el producto y comprobar si se cumplen sus objetivos. El equipo, desde su punto de vista, puede comprobar si realmente está entendiendo estos requisitos y mejorar la comunicación con el cliente. Estas reuniones en las que se presenta el producto poco a poco servirán para ir entregando el trabajo e ir obteniendo feedback del mismo sin esperar meses y meses antes de presentarlo al cliente que podría no estar contento con las decisiones tomadas en todo ese tiempo.

Algunos de los problemas más habituales de las reuniones de demo del sprint son:

Demos indemostrables

Habrá ocasiones en las que los miembros del equipo de desarrollo pueden pensar que no tienen nada que mostrar en esta reunión de demo o que lo que han hecho en este sprint no tiene una interfaz gráfica que pueda ser mostrada. En casos como estos deberemos buscar una demo mínima que pueda presentarse.

Por ejemplo, si tenemos una funcionalidad que se trata de montar el entorno de desarrollo para poder comenzar a trabajar, en la reunión de demo mostraremos el Eclipse funcionando con el jetty configurado para las pruebas, el cliente de Subversion instalado y la herramienta de conexión a la base de datos correctamente configurada para establecer la conexión.

Si tenemos otra tarjeta que nos indica que debemos montar una estructura de tablas de bases de datos y sus relaciones podremos crear una página Hello World mínima que se conecte a esta base de datos y muestre un listado de las tablas que acabamos de crear.

Demos vacías

Hacemos demos pero en estas se muestran sólo powerpoints y no trabajo real que demuestre que no estaremos avanzando a través de los sprints y cuando alcanzamos el final del proyecto nada funciona, los módulos no están bien integrados entre sí y nada pinta tan bien como lo hacían en los powerpoint.

Deberemos mostrar trabajo real en las demos que presenten lo que se ha estado haciendo. Los powerpoint están prohibidos en estas presentaciones. Será necesario buscar la manera de presentar nuestro trabajo y que sea éste el verdadero valor de lo que estamos haciendo.

Temor a las demos

A veces el equipo de trabajo acude con miedo estas demos. Va a estar el cliente, el dueño del producto, quizás más representantes del cliente y no hemos terminado todos las funcionalidades previstas para el sprint, o lo que es peor, algo puede fallar en la presentación y verse mal. Bueno, no pasa nada, la reunión de demo no es una reunión de seguimiento, se trata de mantener una reunión intencionalmente informal.

Se mantiene esta reunión cada poco tiempo para que no haya grandes dramas o grandes sorpresas en ellas. Se trata de tomarle el pulso al proyecto y ver cómo va, no de apretarle las tuercas al equipo de desarrollo. Si algo salió mal en la reunión de demo será nuestra prioridad en el siguiente sprint y como seguramente sólo será la corrección de un bug podremos sumar puntos fácilmente en la reunión de demo del siguiente sprint.

Si las cosas salen mal repetidamente en las reuniones de demo o muchas funcionalidades previstas para el sprint quedan marcadas como no terminadas porque no pasan los tests, deberemos reducir la carga de trabajo prevista para nuestros sprints. Nuestra velocidad está siendo más baja de lo que pensábamos y necesitamos algo más de tiempo para que más cosas sí queden bien terminadas en la reunión de demo.

Scrum diario o Daily Scrum

La reunión diaria de Scrum es una reunión de 15 minutos en la que el equipo Scrum se reúne siempre en el mismo sitio y a la misma hora para comentar sus actividades diarias. Cada uno de los miembros del equipo contesta a las siguientes preguntas:

  • ¿Qué hice ayer?
  • ¿Qué haré hoy?
  • ¿Qué me impide avanzar?
Con estas preguntas se sincroniza todo el equipo de trabajo que cada día sabrá qué es lo que han estado haciendo sus compañeros de trabajo y en qué van a trabajar hoy. También sabrán si sus compañeros tienen alguna dificultad o la prevén para un futuro cercano y si pueden ayudar. Esto favorece que surjan cuestiones, dudas y ofrecimientos de ayuda que nos hagan avanzar más rápidamente. Algunas de las frases más útiles que pueden surgir durante estas reuniones son:
  • «No sé cómo añadir la autoridad certificadora a nuestra KeyStore de Java» a lo que otro compañero responde «Yo he hecho esto antes, luego nos vemos y te explico«.
  • «Se me están acabando las tareas antes de ejecutar los nuevos scripts, pronto necesitaré un backup de seguridad de producción» a lo que el Scrum Master podría responder «Le pediré al cliente que realice un export de producción con fecha de mañana a las 03:00 AM«.
  • «Hoy voy a acabar con las historias de usuario para las transferencias periódicas. Pronto se necesitará analizar nuevas historias de usuario con el Dueño del Producto» a lo que el analista responde «Me veré con el Dueño del Producto lo antes posible para que las tengas preparadas antes de comenzar el trabajo«.

A menudo, después de esta reunión, el equipo de desarrollo o algunos de sus miembros se reúnen inmediatamente después para resolver las cuestiones que han surgido. En los ejemplos anteriores se reunirían los dos desarrolladores para explicar cómo añadir la autoridad certificadora al KeyStore, el analista y el Dueño del Producto para describir nuevas historias de usuario y el Scrum Master iría a llamar por teléfono al cliente para programar una exportación de la base de datos de producción.

El trabajo del Scrum Master en esta reunión consistirá en asegurarse de que tenga la reunión todos los días, de cumplir la regla de que sólo los miembros del equipo de desarrollo participan en el Scrum Diario y de que esta reunión se mantenga en los límites de tiempo de 15 minutos por reunión.

Es habitual que en muchas organizaciones esta reunión de Scrum diaria se haga de pie (Daily stand-up meeting) para evitar que los asistentes hablen más de la cuenta y la reunión dure más de 15 minutos. Yo en cambio las prefiero organizar sentados alrededor de una mesa de reunión y escribir en una hoja de papel o en un documento de Google Docs las respuestas a las tres preguntas de la reunión. Luego, una vez terminada la reunión, revisaba cada una de las respuestas y a modo de checklist comprobaba que no quedasen cuestiones sin resolver o que se dijeron en la reunión y no queden en el olvido.

Un problema habitual en muchos equipos Scrum es que las reuniones diarias duren mucho más de los 15 minutos programados, reuniones de pie que duran más de una hora consumiendo el tiempo productivo de los desarrolladores y que llegan a ser temidas por los miembros del equipo de trabajo. Es frecuente también que algunos opinen que 15 minutos no son suficientes para mantener la reunión diaria. Hay diversas razones por las que pasa esto. Algunas de las más habituales son:

Reuniones dentro de la reunión diaria

Dentro de la reunión diaria se quieren mantener las reuniones detalladas para resolver problemas específicos que deberían mantenerse después de la reunión diaria. El equipo de trabajo no debe entrar en cómo añadir la autoridad certificadora a la KeyStore en Java sino que ésto debe quedar para otra reunión inmediata posterior, en la que estén sólo los implicados, para ahondar en esta explicación.

Las cosas no están claras

Falta un objetivo del sprint claro o falta refinamiento en el backlog. Cuando no hay un claro objetivo del sprint es habitual que surjan muchas dudas durante la reunión diaria. Del mismo modo cuando los requisitos de las historias de usuario no están suficientemente bien refinadas y recogidas vuelven a surgir muchas cuestiones en la reunión diaria. Si trabajas en resolver estos puntos, el trabajo diario de los desarrolladores será mucho más claro y conciso por lo que estarán deseando acabar la reunión para continuar con su desarrollo.

Se explica hasta el último detalle

Se entra en especificar hasta el último detalle de la tarea que se está haciendo. Si la reunión dura 15 minutos y en el equipo trabajan 4 desarrolladores tendrá menos de 5 minutos cada uno para responder a las 3 preguntas. Aproximadamente 1 minuto 15 segundos por pregunta. Es realmente muy poco tiempo por lo que hay que ser muy conciso. Hay personas que con esto tienen tiempo suficiente pero otras que realizan un repaso tan completo a cada uno de los detalles en los que están trabajando que requieren al menos el triple de tiempo. Hay que explicarles que se trata de ser breves, explicar a grandes rasgos en qué están trabajando y del límite de tiempo que se tiene para que la reunión sea productiva y para que los demás no se aburran o desconecten de la reunión.

El objetivo del sprint

El objetivo del sprint es la meta que definiremos durante la reunión de planificación del sprint y que nos permite tener una idea clara, en palabras, de qué es lo que conseguiremos si acabamos de implementar todas las funcionalidades definidas para este Sprint. Se trata de dar una función coherente a los elementos de la lista del producto seleccionados para este sprint.

Si por ejemplo desarrollamos una web para la banca online podríamos tener un sprint en el que habría que desarrollar los siguientes elementos:

  • Desarrollar formulario que permita definir transferencias periódicas de dinero (mensuales, trimestrales, anuales).
  • Desarrollar vista que permita ver, anular y modificar transferencias periódicas.
  • Desarrollar módulo backend que permita que las transferencias periódicas programadas se ejecuten a su debido momento.
Para que, a medida que se trabaja, el equipo mantenga el objetivo del sprint en mente podríamos definir la meta del sprint la siguiente:

Permitir crear al usuario transferencias periódicas de dinero.

Sin embargo, con frecuencia tendremos para el sprint una serie de funcionalidades o bugs a resolver que juntos no permiten dar un objetivo o meta clara en común. Pensemos por ejemplo que estamos desarrollando una web de eCommerce en la que, durante la reunión de planificación del sprint, decidimos que las historias de usuario a desarrollar sean:

  • Implementar la forma de pago con PayPal.
  • Añadir varios productos a la vez a la cesta de la compra.
  • Proporcionar sugerencias útiles a los usuarios registrados que ya compraron algo.
  • Corregir bug en producción por el que no se muestra el último elemento de la cesta de la compra cuando éste contiene más de 200 caracteres en su descripción.
  • Corregir bug en producción por el que no se muestran correctamente los caracteres especiales como tildes y acentos del idioma francés.

Para un caso como este en el que no tenemos una narrativa común que defina un objetivo claro para el sprint podríamos definir lo siguiente como meta del sprint:

Objetivo del Sprint: Implementar 3 historias de usuario y corregir todos los errores de producción.

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.

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos. Contiene enlaces a sitios web de terceros con políticas de privacidad ajenas que podrás aceptar o no cuando accedas a ellos. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Más información
Privacidad