Buscar en Gazafatonario IT

jueves, septiembre 19, 2013

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.
Planificación del Sprint: el primer paso para producir el máximo efecto
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

7 comentarios:

  1. Entonces, el objetivo del Sprint se podría tomar a partir de lo que se conoce como una "Historia épica"? Que según lo que tengo entendido, es algo asi como una historias de usuario grande?

    ResponderBorrar
    Respuestas
    1. Aunque una épica sí es un ‘historia grande’, el objetivo del Sprint no se toma a partir de allí. De hecho, cuando llegamos a la reunión de planificación una buena práctica es que ya conozcamos, sino todo el detalle, mucho de las historias de usuario (pequeñas y con los demás atributos INVEST, en lo posible) que se van a construir en ese sprint.

      Normalmente las épicas se descomponen, se refinan, en otro momento, por ejemplo en sesiones de refinamiento con miras a los siguientes sprints, pero casi nunca en una reunión de planificación, a no ser que finalmente el equipo encuentre que no puede construir toda una historia prevista para ese sprint y proponga refinarla en dos o más historias.

      Salud@s,

      Borrar
  2. Entendido.
    Pero entonces sigo con la duda de como se construye el objetivo del Sprint. Podrías explicarme esa parte por favor? Mil gracias!!

    ResponderBorrar
    Respuestas
    1. En la práctica, el objetivo del Sprint se obtiene, en principio, a partir de las funcionalidades o porciones del producto que se vayan a construir y probar en el sprint. En otras palabras, a las historias de usuario (si se usa esta técnica) que se van a entregar al final del sprint como incremento del producto, probado y funcionando, potencialmente distribuible. Es lo que explico en la primera parte del artículo.

      Digo “en principio” porque el objetivo puede incluir más que eso: por ejemplo, el equipo Scrum en pleno (incluyendo el Product Owner), vayan a poner parte del software que ya han construido en producción o se quiere lograr algo más siempre en relación con el negocio, algo que le siga entregando valor a los usuarios. Esto puede incluir implementación de acciones de mejora en el equipo y en el proyecto que se hayan establecido como prioritarias para ese sprint, entre otras.

      Saludos,

      Borrar
    2. Entendido... Mil gracias por tu respuesta y tu tiempo!!

      Borrar
  3. Hay algo que nos cuesta realizar y es que el Development Team se empodere de su actividad y genere el como realizará la entrega del incremento.

    Que podría sugerirnos, ya que estamos iniciando con la implementación de esta metodología ágil

    ResponderBorrar
    Respuestas
    1. Jhon Jairo, son muchas las cosas que podrían hacerse. Principalmente, el Scrum Master debe acompañar al equipo de Desarrollo en su proceso de aprendizaje, en su proceso de incorporación y puesta en práctica de los valores y principios ágiles, así como en el entendimiento colectivo y asentarse en los Valores Scrum de Coraje, Foco, Respeto, Apertura y Compromiso. Este último, junto con el pilar de la Colaboración de la agilidad, les ayudará a comprender que se deben empoderar.
      Pero precisamente, el Scrum Master también debe acompañarlos en ese proceso de empoderamiento, enseñarles a ser autoorganizados y autogestionados, proactivos. Son cambios de comportamientos que toman tiempo, a veces mucho más del que estamos o están las empresas acostumbradas a esperar, pero que es necesario. Y si el Scrum Master no tiene la suficiente experiencia, entonces que se haga acompañar de alguien con mucha más experiencia, otro Scrum Master, un coach, alguien que lo ayude en esa tarea titánica. Pero siempre debe procurar estar allí para el equipo, pendiente de lo que necesitan.
      En particular, algo que me ha funcionado en diversos escenarios, es promover que entre todos se defina y se consensue la Meta del Sprint. Si esto se logra, damos un gran paso, ya que los miembros del equipo se van a sentir dueños de ese Objetivo y van a intentar hacer lo que sea necesario para alcanzarlo hacia el final del Sprint. Lo otro es lograr que el equipo de Desarrollo, al final de la Planificación, explique “al Dueño de Producto y al Scrum Master cómo pretende trabajar como un equipo autoorganizado para lograr el Objetivo del Sprint y crear el Incremento esperado”, precisamente como lo indica la guía de Scrum.
      Y que, por supuesto, sea el equipo de Desarrollo el que decida finalmente lo que puede hacer y lo que no puede hacer durante el Sprint. Entre muchas otras cosas.
      Muchas gracias por tu participación en el foro. Saludos,

      Borrar