dojo n pl, jos a room or hall for the practice

Transcripción

1 dojo n pl, jos a room or hall for the practice Siguiendo con el espíritu de los Dojo, espacios para aprender y mejorar mediante la práctica de una determinada disciplina, desde agile Barcelona hemos querido experimentar un formato de actividad que nos permita practicar la creación y priorización de product backlogs. Durante el diseño de este formato, nos hemos basado en los objetivos: Learning by doing: el aprendizaje se realiza mediante la practica de técnicas. Colaborativo: todos los asistentes participan en la actividad en el mismo grado y forma Iterativo: el proceso de practica se realiza en periodos cortos de tiempo definido que se repiten, incrementando progresivamente la definición del product backlog. Equipos heterogéneos: las prácticas se realizan por equipos formados por asistentes con diferente nivel de experiencia, de forma que puedan aprender unos de otros. 1

2 No, no nos hemos equivocado en el orden de la presentación ni se ha acabado esta. Queremos agradecer a todos los asistentes su interés en las metodologías agiles y sus ganas de aprender y compartir lo aprendido con el resto de asistentes con los mismos intereses. Sabemos el esfuerzo que representa sacrificar tiempo de descanso personal para dedicarlo a practicar y mejorar. Cada día hay mas gente dispuesta a realizar dicho esfuerzo y a compartirlo con el resto de miembros de la comunidad. Por eso, a todos los asistentes al Product Backlog Dojo, a todos los que queríais asistir pero desgraciadamente no fue posible debido al aforo limitado y a todos los que en general compartís vuestra experiencia y conocimiento con otras personas con el único interés de enseñar y aprender: Gracias! 2

3 El objetivo de hoy es practicar mediante la construcción de product backlogs. Para aquellos asistentes con menor experiencia, recordamos que el Product Backlog se compone de una lista de historias de usuario que: Proporciona una visión global del producto a construir: todas las funcionalidades del producto se encuentran reflejadas dentro del product backlog Incompleta: el product backlog marca el camino para materializar la visión que tenemos actualmente del producto a construir. Pero el product backlog no es una planificación fijada al inicio que debe seguirse a través de las distintas iteraciones. Esta vivo a lo largo del proyecto, pudiendo ser modificado, añadidas nuevas historias de usuario, eliminadas otras, etc Diferente nivel de detalle: aquellas historias de usuario situadas en la parte superior del product backlog tienen un mayor nivel de detalle, ya que serán las que se ejecutaran en las próximas iteraciones. Sin embargo, a medida que vamos bajando a lo largo del PB, las historias de usuario tienen menor nivel de detalle. Esto viene dado el carácter cambiante del PB: puede que las historias de usuario situadas en la parte inferior no lleguen a ser implementadas nunca, por lo que no dedicamos esfuerzo a definirlas en detalle. Priorizado: el product backlog se encuentra priorizado, es decir, en la parte superior se encuentran las historias de usuario de mayor valor y en la parte inferior las de menor valor. Cambia a lo largo del proyecto: tal como hemos comentado anteriormente, el PB esta vivo a lo largo del proyecto, pudiendo ser modificado, añadidas nuevas historias de usuario, eliminadas otras, etc 3

4 A continuación, explicamos que vamos a hacer y cual va a ser el formato del Product Backlog Dojo. Realizaremos la actividad trabajando por equipos, por lo que nos dividiremos en 5 grupos, cada uno de los cuales estará trabajando en un Product Backlog. Para realizar la división en grupos, y con el objetivo de que estos fuesen lo mas heterogéneos posibles buscando que en cada uno de ellos hubiese gente con experiencia en la creación y priorización de product backlogs que pudiese ayudar a otros asistentes con menor experiencia, lo que hicimos fue: Pedir a los asistentes que se situasen a lo largo de una línea (imaginaria) en base a su experiencia, de forma que: * Si estas al principio de la línea, estas perdiendo el tiempo aquí ya que no solo conoces perfectamente el trabajo con Product Backlogs si no que seguramente fuiste quien acuño el termino * (Un paso adelante en la línea) Si estas aquí, no solo eres una persona con amplia experiencia si no que además ayudas a otros a aprender sobre el uso de PBs. * (Un paso adelante en la línea) Eres un Product Owner experimentado * Sabias lo que es un Product Backlog antes de venir aquí * Acabas de descubrir que el un PB en la diapositiva anterior 4

5 Una vez a lo largo de la línea, los separamos en equipos, de forma que: * Los cinco primeros (los de mayor experiencia) se situaron cada uno en una parte de la sala * Los cinco siguientes, cada uno a uno de los equipos formados por los cinco anteriores * Los cinco siguientes, igual que el paso anterior y así consecutivamente hasta que tuvimos los equipos formados Una vez los equipos están formados, se distribuyen a lo largo de la sala para empezar a trabajar con los backlogs. 4

6 Durante la actividad, realizamos cinco iteraciones de 12 minutos cada una de la siguiente forma: En cada iteración, el equipo trabaja sobre un backlog. Al final de la iteración, realizamos 5 minutos de retrospectiva, en la que los equipos comentan que tal ha ido, si han encontrado alguna dificultad, como han realizado el objetivo para la iteración, etc Al finalizar, los equipos rotan avanzando al siguiente backlog, de forma que la siguiente iteración la realizarán sobre un backlog diferente. El objetivo de emplear varios backlogs durante la dinámica y que los equipos fuesen rotando pretende: Que un equipo no trabaje únicamente una tipología de proyecto, si no que tenga que trabajar el backlog independientemente del producto que se fuese a construir. Incentivar el objetivo de acabar correctamente cada una de las iteraciones. Dado que el backlog que dejamos será usado por el siguiente equipo, debemos dejárselo finalizado correctamente como un listado de historias de usuario priorizadas y no como un conjunto de historias inconexas, de forma que puedan comprender cual es la visión sobre el producto a fin de poder realizar la siguiente iteración. Para la elección de los productos sobre los que se van a desarrollar los distintos backlogs, se pueden traer productos predefinidos a la actividad o dejar que sean los asistentes quienes los decidan. Nosotros preferimos dar libertad y previo a la primera 5

7 iteración los equipos dispusieron de 2 minutos para consensuar entre ellos que producto se construiría en su backlog. Una vez decidido, cada equipo explicó muy brevemente su producto para que el resto de equipos tuviese una idea del producto a construir cuando llegase al backlog en cuestión y puso un post it en la parte superior del backlog indicando el producto escogido. En equipos con menor experiencia en trabajo con backlogs, un enfoque más prescriptivo en que el facilitador es quien indica los productos a construir puede ser adecuado. 5

8 La primera iteración consiste simplemente en crear el product backlog a partir de la visión del producto comentada anteriormente. Los equipos deben realizar una primera versión con la que el resto de equipos seguirá trabajando el resto de la sesión. Es importante reforzar en esta iteración que lo que deben encontrarse los siguiente equipos es un product backlog bien construido, no una nube de historias de usuario inconexas y pendientes de priorizar. Tras la iteración realizamos una pequeña retrospectiva de 5 minutos en que los equipos comparten su experiencia a la hora de crear el backlog. 6

9 Durante la segunda iteración, los equipos utilizan el acrónimo INVEST para mejorar las historias de usuario. En esta iteración, se focalizan en las tres primeras siglas, de forma que las historias de usuario deben ser: Independent (Independientes): la historia de usuario debe ser auto contenida, de forma que no existan dependencias inherentes de otras historias de usuario. Negotiable (Negociables): Las historias de usuario, hasta que no son parte de un Sprint Backlog, deben estar siempre abiertas al cambio y a ser rescritas. Valuable (Valiosas): Una historia de usuario debe aportar valor para el usuario final. Tras la iteración, los equipos comentan los cambios que han realizado sobre los backlogs que se habían encontrado. 7

10 Hasta este momento, nos hemos centrado en la funcionalidad del producto reflejada en forma de historias de usuario. En esta tercera iteración, el equipo trabaja para que las historias de usuario puedan ser desglosadas en tareas y ejecutadas por un equipo durante un Sprint, centrándose en los tres siguientes acrónimos de INVEST: Estimable (Estimable): Debe ser posible estimar el tamaño de la historia de usuario Sized appropriately or Small (Debidamente dimensionada o pequeña): Las historias de usuario no deben ser tan grandes como para que no sea posible planificar/dividir en tareas/priorizarlas con cierto nivel de certidumbre. Testeable (Que puedan ser probadas): La historia de usuario y su descripción asociada deben proveer de la información necesaria para hacer que sea posible probar su correcta implementación. Durante la retrospectiva, los equipos comentan como han realizado la iteración, por ejemplo rompiendo las historias en otras mas pequeñas, incluyendo Definition of Done, Definition of Ready, Criterios de aceptación, etc 8

11 Una vez tenemos un Product Backlog priorizado, en el que las historias de usuario se encuentran bien detalladas, en la cuarta iteración practicamos emplear una técnica de priorización que establezca el valor de las diferentes historias de usuario en base a un contexto. Las técnicas enumeradas en la diapositiva se muestran únicamente a modo de sugerencia, los equipos pueden emplear cualquiera de ellas o, si alguno de sus miembros conoce otra que quisiese practicar, puede compartirla con sus compañeros y aplicarla. Entre las técnicas a modo de ejemplo se encuentran: MoSCoW: las historias de usuario se agrupan entre aquellas que son un * Must: imprescindibles para el producto * Should: deberían estar incluidas dado que aportan alto valor pese a no ser imprescindibles * Could: pueden estar incluidas dentro del producto * Won t: en este momento no las queremos incluir Habitualmente, la técnica MoSCoW se emplea para definir el objetivo de cada Release, de forma que ayuda al equipo a clarificar que es lo de mas valor, como por ejemplo en metodologías como DSDM Attern en las que el producto se realiza por iteraciones previamente planificadas. De esta forma, una funcionalidad que para la Release 1 era un Could, podría ser un Must en Release 3. Business Value Based: las historias de usuario se priorizan por su valor de retorno 9

12 económico, es decir, cuanto dinero nos genera incluir una determinada funcionalidad en el producto. Un ejemplo donde puede ser usada podría ser una startup de reciente constitución con capital limitado que necesita empezar a monetizar rápidamente su producto para continuar evolucionándolo. Technology Risk Based: se priorizan aquellas historias de usuario que tienen una incertidumbre técnologica mayor. Si nuestro producto es realizar la primera Tablet con pantalla flexible para que pueda ser doblada y guardada en el bolsillo, realizaremos primero las historias de usuario que nos permitan determinar que es tecnológicamente viable para no encontrarnos en un punto mas adelantado del desarrollo con la imposibilidad de continuar. Walking Skeleton: se pretende en la siguiente iteración construir un producto que no contenga todas aquellas historias de usuario de mayor valor que puedan ser realizadas, si no que aporte una visión minima del producto albergando todas las distintas áreas funcionales del mismo. Para ello, se dividen las historias de usuario en columnas por funcionalidad, y se realiza un corte horizontal, de forma que se incluye al menos una historia de usuario por cada área funcional. Modelo de Kano: el modelo de kano nos ayuda a establecer las historias de usuario entre aquellas que son básicas para nuestro producto, aquellas que son habituales en los productos de la misma categoría y aquellas que provocan excitación en el usuario, aportando valor extra y diferenciándonos de otros productos. Validated Learning: proviene del ciclo de Lean Startup, en el que buscamos aprender y obtener feedback sobre nuestro producto para tomar las decisiones posteriores, por lo que priorizaremos aquellas historias de usuario que nos permitan un mayor aprendizaje pese a que aporten menor valor al producto final. Durante la retrospectiva, los equipos comentan las técnicas empleadas y como han afectado a la priorización del backlog. 9

13 En la quinta iteración, los equipos priorizan un backlog con una técnica diferente a la empleada por el equipo anterior, de forma que puede visualizarse la diferencia resultante entre dos backlogs iguales priorizados de distinta forma en función del contexto del cliente y donde se pone el foco. 10

14 Finalmente, una vez todos los equipos han pasado por todos los Backlogs, realizamos la retrospectiva de la actividad entre todos los equipos. A continuación, encontrareis algunas sugerencias que se comentaron durante la retrospectiva de la actividad. Pueden serviros de ayuda si deseáis realizar un product backlog dojo, algunos de los cuales sin duda incorporaremos al formato en un futuro: Los equipos tenían que dedicar tiempo a entender el producto cada iteración. A veces, esta era una actividad compleja pese a ser parte del ejercicio. Dos de las sugerencias que surgieron para paliar esto fueron: * Que para cada Backlog hubiese un product owner fijo que permaneciese y no rotase. Puede ser una buena solución, podría ser una de aquellas primeras cinco personas con mas experiencia a la hora de crear equipos. * Que el producto sea el mismo para todos los equipos: de esta forma, los equipos comparten una visión de producto, y además permite al final de la sesión ver como un mismo producto puede ser expresado de formas diferentes en distintos backlogs. Cambiar el orden de las iteraciones: 1º priorizar épicas utilizando las técnicas de las iteraciones 4ª y 5ª, para posteriormente aplicar INVEST sobre ellas. Realizar un único Backlog, de forma que un único equipo trabaja con el cada iteración mientras el resto son observadores. Se puede realizar mediante la misma división en equipos o utilizando técnicas como Fishbowl, de forma que los asistentes irían 11

15 incorporándose y saliendo del equipo que esta trabajando el backlog. Este punto seria especialmente indicado si se tiene un grupo reducido de asistentes que no permite formar equipos. Añadir tras la finalización de las iteraciones un slot de tiempo en que se pueda realizar una presentación final del/de los backlogs creados al resto de asistentes. 11

16 Agradecer una vez mas (nunca será bastante) a todos los que vinieron a la sesión, a los que quisieron venir pero finalmente no pudo ser, a todos los que han contribuido dando feedback sobre la dinámica y aportando geniales sugerencias de mejora, y a ti, que estas leyendo este documento. 12

17 Agradecer también a La Salle su compromiso con las metodologías agiles, siendo la primera universidad que ha incorporado a su programa académico un Postgrado íntegramente dedicado a agile, y su soporte a las actividades de la comunidad cediéndonos espacio en sus instalaciones para poder realizarlas. 13

18 Y ya por último, animaros a todos a seguir contribuyendo y compartiendo en la comunidad agile barcelona, a través de cualquiera de sus canales: barcelona.org : el blog de la comunidad : la cuenta de twitter https://groups.google.com/group/agile spain barcelona: el corazón de agile barcelona, la lista en la que se realizan las discusiones, se proponen ideas, actividades, se organizan y en general, se comparte entre todos los miembros el deseo de seguir impulsando el uso de metodologías agiles. 14