Algunas Notas Sobre Gestión del Producto en Scrum

"Si puedes soñarlo, puedes hacerlo". Walt Disney.

Image courtesy of Stuart Miles / FreeDigitalPhotos.net

Quienes venimos de enfoques tradicionales de desarrollo de software caracterizados por proponer y hasta exigir una diversidad de artefactos, encontramos la Lista de Producto (Product Backlog) de Scrum como algo tan hermosamente simple que raya en lo poético. Quizás a esa simplicidad se deba su inmensa popularidad entre los practicantes ágiles.

La Lista de Producto es un inventario priorizado del trabajo pendiente necesario para traer el producto a la vida. El Dueño de Producto es el responsable de la Lista de Producto y de su contenido. Nadie tiene una visión del producto que va más allá del producto en sí, como el Dueño de Producto.

Sus elementos pueden incluir:

• Una exploración de las necesidades del usuario
• Opciones técnicas variadas
• Una descripción tanto de requisitos funcionales como no funcionales
• El trabajo necesario para lanzar el producto

También puede contener otros elementos como:

• Configuración del entorno
• Defectos del producto. 

La Lista de Producto reemplaza los artefactos tradicionales de requisitos, tales como las especificaciones de requisitos del software. Mientras que el Dueño de Producto se compromete a manejar la Lista de Producto, el Scrum Master, el equipo y los interesados contribuyen a esta tarea. Juntos, descubren la funcionalidad del producto. Además, la Lista de Producto es también una herramienta para proporcionar transparencia durante el proyecto.

Sobre la Priorización

La priorización de la Lista puede hacerse de muchas formas, pero es algo que siempre se hace con el Dueño de Producto a bordo, liderando la priorización. Por ejemplo, es posible crear temas que contienen una lista de historias. Cada uno de estos temas tiene un “costo de retardo” asociado. Esto permite conocer el impacto de no implementar un tema si antes implementamos otro.

En este apartado debemos tener en cuenta que si se nos dificulta la priorización de la Lista de Elementos del Producto, puede estar sucediendo que:

1. Los elementos, por ejemplo las historias de usuario, son muy grandes para priorizar
2. No hay ningún valor de negocio asociado al Elemento de la Lista de Producto.

En el primer caso podemos dividir las historias en historias más pequeñas y relacionadas. En el segundo caso, podemos desechar estas historias “sin valor” y encontrar otras que sí reflejen valor del negocio o Retorno de la Inversión. Recuerda, si el Dueño de Producto no es capaz de escribir estas historias, el Scrum Master está a su servicio para ayudarle. No pretendas en el primer intento que un usuario tenga las habilidades y experiencia necesarias para escribir historias de usuario que cumplan con los atributos INVEST. Además, por lo general, no es posible cambiar de Dueño de Producto, es alguien sin quien el proyecto no puede vivir.

Sobre los defectos del producto

Si te estás preguntando como encargarte de esas anomalías que surgen o pueden surgir luego de la salida a producción del software y no sabes si decidirte por usar historias y priorizarlas en la Lista de Producto junto con las nuevas características, y si no estás buscando dogmas, puedes simplemente pensar en trabajar con el Dueño de Producto para clasificar y priorizar esos defectos en producción, luego los puedes tratar como historias de usuario a incluirlos en una entrega específica.

Al igual que en enfoques clásicos de mantenimiento de productos, si el defecto causa un alto impacto en los usuarios, este debe escalarse y resolverse como un ajuste en producción sin pasar por la cadencia normal de Scrum. Lo que sí puedes hacer es manejar la reparación del software usando un proceso Kanban, el cual permite un enfoque más liviano de gestión. Eso sí, no olvides que un error en producción representa valor negativo para el negocio así que dedica un esfuerzo mayor a evitarlos o a reducirlos al mínimo más que a corregirlos.

Cuando hagas esto piensa que:

• Si una parte del producto tiene desperfectos, todavía no está Terminada.
• Cualquier trabajo que necesite hacerse, necesita priorizarse.
• Cualquier actividad que realice el equipo, toma tiempo.
• El tiempo consumido en una cosa, no puede consumirse en otras cosas.

Los Atributos DEEP de la Lista de Producto

Dice Mike Cohn que una Lista de Producto efectiva tiene estas cuatro propiedades: detallada apropiadamente, estimada, emergente y priorizada. De allí el acrónimo DEEP.

Detallada Apropiadamente

Los Elementos de la Lista de Producto en la parte superior se describen en mayor detalle que los que están en la parte inferior de la Lista. A medida que bajamos en la lista, los elementos están menos detallados. Esto tiene sentido: son elementos que se convertirán en software apenas varias iteraciones más adelante o quizás nunca, si el usuario nota que no los necesita o si se acaba el presupuesto del proyecto. De hecho, es posible que el Dueño de Producto cambie la prioridad de alguno de estos, en cuyo caso solo debe llenar los vacíos de ese elemento para que quede “preparado” para construirse.

Figura: La priorización de la Lista de Elementos del Producto determina el nivel de detalle

Esta técnica asegura que la Lista de Producto se mantenga concisa y que los elementos a implementarse en el siguiente sprint son trabajables. Una consecuencia de este enfoque es que los requisitos se descubren, se descomponen y se refinan a lo largo de todo el proyecto. Es otra de las razones por las cuales el Dueño de Producto debe trabajar con el Equipo de Desarrollo cotidianamente durante todo el proyecto, o más o menos así reza uno de los Principios Ágiles.

Estimada

La estimación de los Elementos de la Lista de Producto usualmente se expresa en puntos de historia o en “días ideales”. Conocer el tamaño de los elementos ayuda a priorizar y a planificar las entregas a producción. Recordemos que otras estimaciones más detalladas a nivel de tareas se realizan durante la Reunión de Planificación del Sprint; y también, estas tareas y sus estimados se capturan en la Lista de Pendientes del Sprint.

Un día ideal es una abstracción del número de horas diarias en las que normalmente esperas que un miembro del equipo sea productivo, restando tiempo para asistir a reuniones, ir al baño, tomar un café o simplemente hacer una pausa laboral.

Emergente

La Lista de Producto tiene una cualidad orgánica. Evoluciona y su contenido cambia frecuentemente. Nuevos elementos se descubren y adicionan a la Lista basados en retroalimentación del usuario, principalmente. Los elementos existentes se modifican, re-priorizan, refinan o se remueven permanentemente.

Priorizada

Todos los elementos en la Lista de Producto se ordenan según su valor e trascendencia para la Organización. Los elementos más importantes y de más alta prioridad se implementan primero. Estos pueden encontrarse al principio de la lista, como indico en la Figura 1. Luego de que un elemento esté “Terminado”, se elimina de la Lista de Producto.

Finalmente

La Lista de Producto existe por un propósito más grande: construir un producto que impacte a los usuarios, que haga resonancia en ellos/ellas y que cambie en algo sus estilos de vida.

El producto debe construirse de manera orgánica, es decir, tan pronto como sea posible, debemos tener una versión que los usuarios puedan usar, el producto mínimo viable. A partir de este producto parcial, coherente y de valor, se construye el producto completo.

Al construirlo, piensa que estás componiendo una pieza musical grandiosa, la sinfonía definitiva, una que será recordada por siempre. Una obra así despliega patrones, trayectorias e incita a las personas a estar a su alrededor.

¿Quieres saber más?

Te recomiendo ampliamente este artículo de Jeff Sutherland:

Enabling Specifications: The Key to Building Agile Systems

http://scrum.jeffsutherland.com/2009/11/enabling-specifications-key-to-building.html

La Guía de Scrum: http://www.scrum.org/scrum-guides

El libro de Roman Pichler, Agile Management with Scrum, Creating Products That Customers Love. Addinson-Wesley, 2010.

Sobre Historias de Usuario, mi serie de artículos:

Historias de Usuario: un nuevo orden en los requisitos del software

http://www.gazafatonarioit.com/2013/07/historias-de-usuario-un-nuevo-orden-en.html

Historias de Usuario Altamente Efectivas, Parte 1

http://www.gazafatonarioit.com/2013/07/escribiendo-historias-de-usuario.html

Historias de Usuario Altamente Efectivas, 2

http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario.html

Historias de Usuario Altamente Efectivas, 3

http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario_12.html

Historias de Usuario Altamente Efectivas, 4

http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario_19.html

Compendio Sobre el Scrum Diario

Pregunta: ¿Cómo es posible que un gran proyecto de software se atrase un año entero?

Respuesta: ¡Un día a la vez!

[Frederick P. Brooks, Jr. The Mythical Man-Month. Pp. 153.]

Se ha llamado Reunión Diaria, Scrum Diario, Reunión de Pie, Reunión Diaria de Pie y de algunas otras formas equivalentes, en todos los idiomas. Esta no es solo una reunión de pie. Este ritual, que bien puede implementarse en proyectos de todo tipo, ágiles y no ágiles, tiene una importancia que muchas veces pasa desapercibida para el común de los mortales.

Brooks, en su ya antiquísimo libro The Mythical Man-Month, y del que me he permitido extraer la frase inicial, dice que pequeñas demoras incrementales en distintos frentes del proyecto eventualmente se acumulan para producir un enorme retraso. Se requiere entonces atención permanente para alcanzar metas individuales pequeñas o parciales en todos los niveles del proyecto. [1]

Hace ya 40 años Brooks ponía de manifiesto la necesidad de una sesión como esta. Es una reunión de planificación, no de seguimiento como erróneamente creen algunos. También es una ceremonia de sincronización del equipo, para que sus miembros se enteren de los avances del Sprint de todo el equipo y de las dificultades existentes, cuya exposición se hace para que cada participante se postule en pro de su solución.

Así que si eres un Scrum Master o haces parte de un Equipo Scrum, sigue estos consejos que he tomado de aquí y de allá, incluida mi propia experiencia facilitándolas y ayudando a terceros a facilitarlas.

Algunos Patrones de Comportamiento Durante el Scrum Diario

Sé riguroso con la agenda. No permitas discusiones y mantente firme en las 3 preguntas. De esta forma, terminarás antes de 15 minutos. Como Scrum Master es tu trabajo hacer que esto pase. Si comienza una discusión, detenla y pide a los involucrados que la aplacen hasta después de la reunión, pero asegúrate de que se lleve a cabo. Sin embargo, permite que los miembros del equipo brinden ideas rápidas sobre la solución a problemas comunes.

Las decisiones importantes del proyecto no se deberían tomar durante la Reunión Diaria. Esta es una reunión de estatus, un punto de comunicación, no es para resolver problemas. Esta es una característica importante de la Reunión de Pie.

Si promueves discusiones detalladas, a medida que la reunión avanza y llega el turno de los últimos participantes, quizás el tiempo se habrá acabado y algunos asistentes quedarán sin sincronizar con el resto del grupo, así que no permitas los conflictos o diálogos extensos para buscar soluciones o discutir procedimientos; en cambio, fomenta una o más reuniones en grupos pequeños con las personas necesarias para tomar decisiones específicas. De esta forma, los demás podrán regresar a sus tareas regulares del sprint.

La facilitación de un Scrum Master experimentado es clave hasta que todo el equipo sea un Equipo Scrum maduro y hábil. Asegúrate de que los miembros del equipo asistan a la reunión con una buena idea de lo que harán a continuación, pero también permita una discusión rápida entre los miembros del equipo para tomar decisiones sobre colaborar en una tarea o una serie de tareas.

Proporciona algunos recordatorios estratégicos rápidos que son necesarios como: “estamos cerca del final del sprint, enfoquémonos en asegurar que tengamos un producto potencialmente distribuible que entregar”. Esto es algo que se puede incorporar con el pasar de los sprints, a medida que el equipo se envuelve en la cultura ágil.

Algunas otras ideas:

Usa una especie de testigo, al mejor estilo de las carreras atléticas de relevos, para evitar que los participantes hablen unos sobre otros y asegúrate de que el orden de intervención sea estricto, por ejemplo, en el sentido de las manecillas del reloj.

No realices estas reuniones al final del día, la gente ya está cansada y quiere irse a casa. En ese momento, el interés de las personas ya es otro. Una buena alternativa a hacerla en la mañana, es llevarla a cabo justo después del almuerzo, las personas tienen energía, están felices y vienen de un corto descanso.

Además, como Scrum Master:

Sirve como fuente de inspiración del trabajo en equipo, después de todo, eso eres: un líder al servicio del equipo y de la organización.

Facilita la reunión y haz que se mantenga breve y al punto.

Establece que las tarjetas (o notas adhesivas) de tareas se muevan antes o después de la reunión, pero no durante la misma, llega a un acuerdo de trabajo con el equipo. Haz lo mismo con las horas faltantes del Sprint, con el burn-down chart o cualquier otro mecanismo que estés usando con el equipo para monitorear el avance del proyecto.

Impulsa el que los Cerdos respondan las 3 Preguntas al Equipo Completo, no a ti como Scrum Master o a alguna otra persona en particular.

No permitas que las Gallinas (ninguna Gallina) los interrumpa a menos que sea esencial, en la práctica casi nunca lo es.

Finalmente, observa atentamente y resuelve estos asuntos:

Algunas personas no escuchan cuando otros hablan

Algunas personas dan información vaga o insuficiente, o no dicen nada, lo cual es su prerrogativa. Sin embargo, estos casos deben tratarse con cautela, de manera personalizada.

Algunas personas censuran cuando alguien no tiene un buen avance o comete algún error

Algunas personas postergan discusiones o la comunicación entre ellas durante el día hasta la Reunión Diaria

¿Quieres saber más?

La descripción completa sobre el Scrum Diario la encuentras en “La Guía de Scrum", a cuya última versión en español puedes llegar a través de:

http://www.gazafatonarioit.com/2017/11/revision-la-guia-de-scrum-2017_7.html

Sobre la reunión diaria, este artículo de Jason Yip es todo un tratado alrededor del tema y expone una serie de patrones que bien podemos implementar: “It's Not Just Standing Up: Patterns for Daily Standup Meetings”:

http://martinfowler.com/articles/itsNotJustStandingUp.html

Sobre Scrum y cultura ágil puedes leer estos artículos en mi Gazafatonario:

Scrum: Lo Fundamental

http://www.gazafatonarioit.com/2013/05/scrum-lo-fundamental.html

¿Por qué fallan las implementaciones Scrum?

http://www.gazafatonarioit.com/2013/10/por-que-fallan-las-implementaciones-de.html

Sí, usted está listo para implementarun proyecto ágil

http://www.gazafatonarioit.com/2014/01/si-usted-esta-listo-para-implementar-un.html

Cultura ágil: ese oscuro objeto del deseo

http://goo.gl/IuJIlY

Mitos, Monstruos, Leyendas Urbanas yotros Desvaríos de Ágil y Scrum

http://www.gazafatonarioit.com/2013/06/mitos-monstruos-leyendas-urbanas-y.html

Scrum Orgánico para Iniciantes

http://www.gazafatonarioit.com/2013/05/scrum-organico-para-iniciantes.html

Lista de Chequeo Scrum

http://www.gazafatonarioit.com/2013/05/lista-de-chequeo-scrum.html

En particular, sobre el rol y responsabilidades del Scrum Master, facilitador del Scrum Diario:

Vademescrum, SecciónI: El Scrum Master 1

http://www.gazafatonarioit.com/2013/06/vademescrum-seccion-i-el-scrum-master-1.html

De Jedi Master a ScrumMaster

http://www.gazafatonarioit.com/2013/10/de-jedi-master-scrum-master.html

Referencias

[1] The Mythical Man-Month by Frederick P. Brooks, Jr., Addison Wesley Pub. Co., 1975, 25th Anniversary edition, 2000.

Sí, usted está listo para implementar un proyecto ágil

En caso de duda, pregunte a un experto.

Además de conocer, entender y adoptar los valores y principios del manifiesto por el desarrollo ágil de software, piense que no se trata de un solo proyecto, se trata de toda una transformación organizacional que implica cultura, filosofía, enfoques, técnicas, métodos y, lo más importante, personas.

La evolución hacia ágil es importante, igual que establecer cuáles serán los factores clave de éxito y, entre aquella y estos, la selección de equipos y proyectos pilotos se convierte en algo vital en todo esfuerzo de mejoramiento ágil.

Sobre la evolución a ágil

Si viene de una metodología en cascada, de un enfoque tradicional de comando y control tipo PMI, de un modelo de calidad riguroso tipo CMMI, o de una combinación de todos, entonces esto le interesa:

1. Debe definir un proceso de mejoramiento continuo que lo lleve del enfoque actual a una estrategia ágil. No intente hacerlo tipo “Big Bang”, es decir, de la noche a la mañana. Seguramente durante mucho tiempo tendrá que convivir con los dos universos de proyectos.
2. La implementación del proceso ágil empieza con la interiorización de los valores y principios ágiles (El Manifiesto Ágil) y es única y adaptada a todas las especificaciones que se ajusten a las metas organizacionales.
3. Debe ser una transformación progresiva a través del enfoque ágil, el cual integra paso a paso las prácticas ágiles requeridas. Por ejemplo, empiece con Scrum y algunas prácticas adicionales (Kanban, Story Mapping, Impact Mapping, Planning Poker, User Stories) y luego siga con algunas de estas: TDD, BDD, Pair Programming, Refactoring, entre otras.
4. Si tiene que tomar elementos del proceso actual, use prácticas de Lean para hacerlos más livianos y eliminar lo que podría constituirse en desperdicio.
5. Implemente los conceptos de Valor, Software de Valor para el negocio, Definición de Terminado, Definición de Listo y Criterios de Aceptación. Haga que todas las personas en la organización los adopten y los conviertan en tema cotidiano de conversación.
6. Despójese y remueva de la organización los vicios y las comodidades actuales. Si quiere nuevos y mejores resultados, cuéntele a todos, debe empezar a hacer las cosas de una manera diferente.
7. Tenga el coraje para decir que implementar Ágil no es fácil. Hacer software es una tarea compleja y, aunque las prácticas ágiles son livianas y fáciles de entender, son extremadamente difíciles de llegar a dominar… ¡o algo así reza en la guía de Scrum!

Sobre los factores clave de éxito

1. Los miembros del equipo deberían estar dedicados 100%y trabajar fuera de su rol funcional actual.
2. La administración debe estar dispuesta a seguir adelante con el enfoque, sin importar los errores que se cometan.
3. El Dueño de Producto es parte del equipo.
4. Un Scrum Master debe estar presente y ser capaz de trabajar con el nuevo proceso.
5. Defina una estrategia de trabajo con todas personas y recursos de apoyo.
6. No sea impaciente, el éxito quizás no se logra en el primer intento.
7. Empiece con unas pocas métricas para medir la realidad de los proyectos y de la organización, no a las personas.

Sobre los proyectos piloto

Uno o más proyectos pilotos son importantes. Algunas de las características que debe tener un piloto son las siguientes:

Duración: ni muy corta ni muy larga. De 3 a 9 meses, con una media de 6 meses es un buen tiempo para un proyecto piloto. Recordemos que aunque los resultados parciales de los Sprints nos van a permitir afinar el proceso y las técnicas, también necesitamos el resultado final de cada proyecto piloto para tomar decisiones importantes y mirar aspectos a reforzar. Más de 9 meses es mucho tiempo para ello. Importante aquí es explicar bien a la organización que los métodos ágiles no solo son para proyectos pequeños como estos pilotos, sino para cualquier tipo de proyecto.

Complejidad: ni muy fáciles ni muy complejos. Deben ser mediamente importantes pero definitivamente no críticos para la organización. Hay que recordar que estamos en un proceso de aprendizaje y que podemos cometer errores. Si estos errores son en proyectos críticos, podemos echar al canasto de la basura todo el esfuerzo de implementación ágil debido a la mala imagen ante la organización, al retiro de nuestros patrocinadores, etc. La organización puede ver esto como que Ágil no funciona. Importante es que el proyecto, aunque no corporativo, tenga visibilidad organizacional, que sea conocido por la alta gerencia.

Tamaño: un solo equipo de desarrollo, como dice la guía de Scrum, de entre 3 y 9 personas. 5 o 6 personas es un tamaño adecuado. Adicionemos el Dueño de Producto y el Scrum Master y estamos listos. Por supuesto, esto debemos conjugarlo con la complejidad y duración del proyecto. El equipo debe estar físicamente en una sola ubicación. Un coach de más experiencia puede apoyar ciertas tareas y ser un soporte para el Scrum Master.

Personas: Los miembros del equipo deben:

• Tener empatía y ser abiertas
• Tener coraje para aceptar y conducir el cambio
• Tener auto-disciplina que se traduzca en disciplina de equipo
• Confiar en ellas mismas y en el resto del grupo

Como siempre, debe ser un equipo multi-funcional empoderado, con los recursos y autoridad necesaria para alcanzar las metas del negocio. Aspectos como la visión de las personas, colaboración, responsabilidad y productividad se conjugarán bien en un proyecto piloto y mantendrán elevada la energía del grupo.

Muy importante es conseguir Orientación vía entrenamiento o acompañamiento para los Scrum Master y adicionar a esto dedicación, para lograr que el proyecto funcione sin importar lo que pase. No se comprometa más allá de lo posible, explique a la organización que al principio el equipo ágil recién formado perderá el balón varias veces, pero se embarcará en una estrategia de mejoramiento continuo.

Cuando el equipo alcanza un buen paso/velocidad, invite a los ejecutivos a las ceremonias, especialmente a la Revisión. Observe Transparencia todo el tiempo, teniendo todos los artefactos (tablero Scrum, burndown chart, burndown de entrega, lista de impedimentos, Meta del Sprint, Definición de Terminado, etc.) a la vista de todos en el área de trabajo del equipo Scrum. Programe la agenda para que los interesados “vayan a ver” la actividad y guíelos a través del proceso, los artefactos y las actividades del Sprint. Haga que se “involucren” y busque su retroalimentación.

Otros aspectos a tener en cuenta

Más allá de todo lo anterior, considere lo siguiente:

• Asegúrese de que los líderes hayan entendido y recibido bien los valores y principios del manifiesto ágil. Sí, ya sé que lo dije antes, lo repito dada la relevancia y lo que significa para una iniciativa de mejoramiento ágil que se conozca el Manifiesto.
• Para un mejoramiento más rápido, considere involucrar un buen coach.
• Enfóquese primero en la calidad.
• Limite la cantidad de trabajo-en-proceso.
• Mantenga la inspección y adaptación. Los procesos ágiles como Scrum se basan en el empirismo, donde se aprende por observación. La inspección y adaptación son los medios mediante los cuales podemos mantener el proceso de mejoramiento encausado y los proyectos piloto en el camino correcto.
• Conozca cómo medir el avance (Tarea, Historia, Sprint, Release). En cualquier caso recuerde: el software funcionando es la medida principal de progreso.
• Asegúrese de que el Dueño de Producto esté empoderado para tomar decisiones por el equipo.
• Madure el enfoque de manejo de código fuente y de las pruebas.
• Estudie o trate de reconocer cuando está convirtiendo los sprints en “cascadas disfrazadas”. Este es uno de los errores más frecuentes cuando la transición se hace desde los métodos clásicos de ejecución de proyectos.
• Mantenga comunicación constante con los equipos piloto y con la organización y conserve su compromiso con la transparencia.
• Finalmente, la organización necesita comprar el proceso. No tener retroalimentación del negocio (o del Cliente) es una falla. Asegúrese de tener los interesados y Dueños de Producto correctos que puedan gestionar el backlog de producto y compartir su visión.

¿Quiere saber más?

Puede visitar estos enlaces:

El Manifiesto por el desarrollo ágil de software:

http://www.agilemanifesto.org/iso/es/

Scrum Orgánico para Iniciantes

http://www.gazafatonarioit.com/2013/05/scrum-organico-para-iniciantes.html

Lista de Chequeo Scrum

http://www.gazafatonarioit.com/2013/05/lista-de-chequeo-scrum.html

Scrum – Lo Fundamental

http://www.gazafatonarioit.com/2013/05/scrum-lo-fundamental.html

Vademescrum, Sección I: El Scrum Master 1

http://www.gazafatonarioit.com/2013/06/vademescrum-seccion-i-el-scrum-master-1.html

Nueva Versión de la Guía Oficial de Scrum

http://www.gazafatonarioit.com/2013/08/nueva-version-de-la-guia-oficial-de.html

Mitos, Monstruos, Leyendas Urbanas y otros Desvaríos de Ágil y Scrum

http://www.gazafatonarioit.com/2013/06/mitos-monstruos-leyendas-urbanas-y.html

Planificación del Sprint: el primer paso para producir el máximo efecto

http://www.gazafatonarioit.com/2013/09/planificacion-del-sprint-el-primer-paso.html

Gerentes de Proyectos de software, ¿una especie en vías de extinción?

http://www.gazafatonarioit.com/2013/09/gerentes-de-proyectos-de-software-una.html

Planificación del Sprint: el primer paso para producir el máximo efecto

“Es un mal plan aquel que no admite modificación”

Publio Sirio, siglo I a.C.

Presentación

Ya sabemos que “el trabajo a realizar durante el Sprint se planifica en la Reunión de Planificación de Sprint.” [1] Es durante esta reunión a la que asiste el Equipo Scrum en pleno que se responden estas dos cuestiones:

• ¿Qué puede entregarse en el Incremento resultante del Sprint que comienza?
• ¿Cómo se conseguirá hacer el trabajo necesario para entregar el Incremento? [2]

Durante la reunión se propone un Objetivo a alcanzar en el sprint que inicia y se discuten los elementos de la Lista de Producto que, una vez terminados, dan como resultado el logro del objetivo propuesto.

Durante la primera parte de la reunión el Dueño de Producto propone los elementos de la Lista de Producto que quiere ver terminados hacia el final del sprint. En la práctica, el Equipo de Desarrollo realiza todas las preguntas necesarias al Dueño de Producto con el fin de clarificar aspectos de los elementos de la Lista de Producto, por ejemplo, de las historias de usuario seleccionadas para el sprint. Esta parte de la reunión es un evento típico de recolección de información, se establecen los criterios de aceptación de las historias de usuario, los pormenores funcionales y no funcionales de las mismas y todo lo que haga falta para que el equipo pase luego a decidir cómo se conseguirá terminar el trabajo del sprint.

En principio, el equipo debe estimar el esfuerzo necesario que le tomará terminar cada historia de usuario según lo establecido en la Definición de Terminado. Para ello, el equipo debe poner de manifiesto su experiencia en el ciclo de vida del desarrollo del software, desde el análisis, pasando por el diseño, la implementación, las pruebas, la documentación, hasta el despliegue del producto funcional. La estimación puede hacerla entonces usando técnicas ágiles como Planning Poker, que permite fijar los puntos de historia de cada una de las historias de usuario y que servirán luego para calcular la Velocidad del equipo y evaluar aspectos de productividad y calidad.

Al final de la reunión el equipo tiene definidos:

• Un Objetivo del Sprint y
• Una Lista de Pendientes del Sprint

Además del número total de puntos de historia que se construirán en el sprint que comienza. El objetivo del sprint es una corta descripción, una o dos frases, de lo que el equipo planea alcanzar durante el Sprint. Por ejemplo, si estamos construyendo un sistema de publicación en línea, este bien puede ser el objetivo de un Sprint:

• Implementar la creación básica de blogs, adición básica y publicación de entadas a los blogs y publicación de comentarios a esas entradas.
• Implementar la gestión básica de usuarios, el ingreso a la aplicación y el recordatorio de contraseñas.

Es una meta que debe estar visible a todos los miembros del equipo y de los demás interesados y cuyo significado debe entenderse a cabalidad. Por ejemplo, “adición básica de entradas a los blogs” quiere decir que se permitirán entradas con texto y una imagen en algún formato conocido; y no quiere decir que se permitirán todos los formatos de imágenes usados hoy, ni que se permitirá inserción de videos o de documentos, tampoco que habrá revisión ortográfica. Es precisamente el contexto lo que debe ser acordado y entendido por todo el Equipo Scrum.

Algunas malas prácticas en la reunión de Planificación y cómo evitarlas

A la reunión de Planificación del Sprint asiste el equipo Scrum en pleno, incluyendo el Scrum Master y el Dueño de Producto, responsable de direccionar el trabajo del Equipo de Desarrollo. Incluso es posible que asistan algunos interesados que apoyen al Dueño de Producto en la clarificación de los elementos de la Pila de Producto. El Equipo debe planear muy bien la reunión, el Scrum Master debe velar porque se haga en el bloque de tiempo establecido por las reglas de Scrum, por ejemplo, 4 horas para un Sprint de 2 semanas. El Dueño de Producto debe estar preparado para responder las cuestiones que surjan de la selección de elementos de la Lista de Producto que serán seleccionados para el sprint.

El Equipo de Desarrollo debe estar completo, ser multifuncional, preparado física y anímicamente para enfrentar un nuevo sprint, los sprints anteriores son cosas del pasado, las acciones de mejoramiento se tomaron y se llevaron a la Lista de Producto para su implementación efectiva, de acuerdo con la prioridad del Dueño de Producto y del Equipo en general. El Equipo está conformado por personas, no por súper héroes que trabajan 16 o más horas al día o con capacidades por encima del promedio (esto último apenas es una ganancia pero no debe tomarse como fundamento para sobrecargar al equipo con tareas que van más allá de su esfuerzo normal).

Aun así debemos tener cuidado: una reunión de planificación mal ejecutada terminará con un mal plan, con elementos de la Lista de Producto pobremente entendidos (por ejemplo, requisitos incompletos o ambiguos), con sobrecarga de trabajo para el equipo, con “sprints individuales”, es decir, iteraciones planeadas para cada miembro del equipo en vez de una sola para todo el equipo; sin la definición de “terminado” o sin el objetivo del sprint claro. Por ello tengamos en cuenta lo siguiente.

Esto es lo que hemos aprendido de las reuniones de planificación del sprint:

No empiece sin el Dueño de Producto. El Dueño del Producto está ausente o remoto. En Ágil/Scrum promulgamos y valoramos más la interacción entre las personas que los procesos y las herramientas. “El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara” [3], dice uno de los principios del Manifiesto Ágil. Así que es primordial que el Dueño de Producto esté disponible y presencial durante toda la reunión.

Además, el Dueño de Producto debe estar cuando se realice la estimación y la planeación de tareas. En ocasiones, el Dueño de Producto ayuda a bajar la tensión y las expectativas que se hace el Equipo cuando de construir un incremento del producto. El Dueño de Producto quizás insista en hacer las cosas de otra manera, sencilla o más liviana, pero de valor para el negocio. O al contrario, el Equipo de Desarrollo o el Scrum Master pueden motivar al Dueño de Producto a disminuir su interés en ciertos aspectos del producto pero a fijarse en otras características de mucho más valor y rendimiento para la organización. Recordemos “la simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.” [4]

No permita que el Dueño de Producto sea quien decida sobre la cantidad de trabajo que el equipo debe realizar. En otras palabras, que el Dueño de Producto proponga (imponga) la cantidad de elementos de la Lista de Producto a construir durante el sprint, sin tener en cuenta la Velocidad del equipo o el esfuerzo total que el equipo puede acometer durante la iteración. A medida que el Dueño de Producto propone elementos de la lista, el equipo estima su implementación y resta el estimado del tiempo total efectivo del sprint. Recordemos que “los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.” [5]

El Dueño del Producto no está listo para el Sprint. O la Lista de Producto no está lista. Muy bien, estamos todos los que somos para la reunión pero a las primeras de cambio el Dueño de Producto nos empieza a decir que no tiene las respuestas, que desconoce tal o cual característica, que debe consultar dentro de tres o más días con alguien más, incluso externo a la organización, que no está seguro si las cosas son así o de otra forma, en fin, esa serie de respuestas que finalmente nos llenan de requisitos incompletos y, por consiguiente, de supuestos. Nuestro cerebro tiende a llenar los vacíos con conjeturas que le pueden hacer mucho daño al proyecto.

En el caso de las consultas para más tarde o para días posteriores, le debemos aclarar al Dueño de Producto (y por “debemos” quiero decir el Scrum Master), que dado que el sprint tiene una duración muy corta (2 semanas, por ejemplo), no es posible esperar tanto tiempo por sus respuestas y pasamos así al siguiente elemento de la lista. Precisamente, para evitar estas anomalías, recurrimos a prácticas de refinamiento de la Lista de Producto que consisten en que, en medio del sprint actual, nos reunimos con el Dueño de Producto para agregar detalles, lo mismo que priorizar y estimar los elementos de la lista de los próximos dos sprints. Así cuando llegue el momento de la planificación, el Dueño de Producto esté lo suficientemente preparado como para iniciar la nueva iteración sin contratiempos.

Planear un esfuerzo total que sobrepasa los límites del Equipo, por ejemplo, planear tareas del ciclo de vida del software en tiempos de reunión de Revisión o de Retrospectiva. Si el equipo es de 5 personas y estamos haciendo sprints de 2 semanas, debemos restar 15 horas de esfuerzo total por estas 2 reuniones (10 por la reunión de revisión y 5 por la de retrospectiva), además unas 12  horas de esfuerzo por reuniones diarias y 20 horas por la reunión de Planificación del Sprint, esta de la que estamos hablando. Es decir, unas 47 horas menos, con lo que el esfuerzo real sería de 353 horas para ese equipo de 5 personas.

Incluso deberíamos planear jornadas efectivas de menos de 8 horas, por ejemplo 6 o 7, máximo. Con 7 horas, por ejemplo, el esfuerzo total del equipo de 5 personas sería de unas 300 horas. Algo realista y que, a la larga, contribuye a aumentar la productividad, la energía de las personas del equipo, la motivación y, como  consecuencia, mejora la calidad de los productos que construyen. “Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.” [6]

Otras cosas que no debemos hacer antes, durante o después de la reunión de Planificación del sprint

• La reunión tarda más de lo debido. El Scrum Master debe estar atento a ello. Puede ser un indicativo de falta de productividad o de que estamos sobre-planificando el sprint.
• Cada miembro del equipo planea su “sprint individual”. O se hace una planeación para alguien en particular, “alguien adicional”.
• No planear de manera colaborativa. Va de la mano con la anterior práctica errónea.
• No planear la reunión con anticipación. Vale para todo el Equipo Scrum. Si hicimos Refinamiento deberíamos tener el suficiente apresto para realizar una reunión dinámica y efectiva.
• No definir un Objetivo del Sprint. ¿Entonces hacia dónde vamos? El Objetivo es la brújula que nos orienta.
• Planear tareas de 8 horas o más para un miembro del equipo. Se deben planear 2, 3 o más tareas cuya suma de esfuerzos individuales sume el tiempo total de esfuerzo diario de cada miembro del equipo.
• Permitir que alguien, por ejemplo el Dueño de Producto o el Scrum Master, incluso alguien externo, asigne las tareas al resto del equipo.
• Ausencia física del Scrum Master en la reunión de planificación. Puede estar virtual pero seguramente el valor de su participación será mucho menor.

Referencias

[1], [2] La Guía de Scrum. http://www.scrumguides.org/download.html

[3], [4], [5], [6]  El Manifiesto Ágil. http://www.agilemanifesto.org/iso/es