Buscar en Gazafatonario IT

domingo, marzo 30, 2014

Lanzamiento de Agiles 2014: “Lo mítico, lo estético, lo simbólico”

La imagen es de Jorge Johnson.
La imagen es de Jorge Johnson.
El 27 de marzo ocurrió un hecho histórico para quienes hacemos parte del ecosistema ágil, se trata del lanzamiento de las 7as jornadas latinoamericanas de metodologías ágiles, Ágiles 2014.
En la Universidad EAFIT de Medellín nos reunimos representantes de la Industria, de la Academia, de las organizaciones sin ánimo de lucro del sector productivo (de software) y los entusiastas de las metodologías ágiles, miembros de la Comunidad Ágiles Colombia. En el ciberespacio, nos acompañaban desde distintos puntos, participantes de las distintas comunidades latinoamericanas con quienes llevamos adelante este proyecto.
Bajo el lema de “Sea protagonista del cambio en el mundo del trabajo”, Luis Mulato, presidente de la Conferencia, nos empezaba explicando cómo “narradores, protagonistas y testigos de historias de cambio nos han transmitido sus vivencias y ahora somos responsables de difundir su legado: Sí podemos cambiar el mundo”.
Me vino a la mente aquel fabuloso ensayo de Tobias Mayer en su libro The People’s Scrum, donde relata una imagen, la de “una oficina donde reina la risa y la pasión. Donde todos, inspirados por un espíritu de camaradería, habitados por un clima de entusiasmo, propósito común y esperanza, trabajan en un ambiente que fomenta la escucha, la comunicación abierta y la colaboración a mansalva.” Tobias se refería a un ambiente parecido al de una plaza o al del patio de la escuela, “donde la innovación y las ideas disruptivas eran una parte natural de cada interacción”.
Mulato nos contó la historia de Ágiles, desde la Pampa argentina hasta el café colombiano, hoy, y nos explicó como nuestra visión es la de “fortalecer a Colombia como un país comprometido con el uso de metodologías ágiles e integrar a la región, expandiendo los conocimientos y experiencias de las comunidades predecesoras en Centroamérica y México.”
La imagen es de Claudia Sandoval.
La imagen es de Claudia Sandoval.

Nos mostró cómo personalidades de la talla de Mary y Tom Poppendieck, Janeth Gregory y Jurgen Appelo, James Patton y Diana Larsen, entre otros, han participado en ediciones anteriores y que esperábamos contar con reconocidos expertos de la misma talla que ellos. Y hablamos de los beneficios de que la industria se sumara a la Conferencia:
  • Conocer las tendencias
  • Conocer experiencias en el medio
  • Ver la aplicabilidad del modelo
  • Compartir los resultados
  • Experimentar la felicidad de las personas
  • Percibir y dejarse contagiar de la energía renovadora que trae la cultura ágil, volver a amar los lunes en la oficina

Después, un momento especial, bueno, una suma de momentos, las charlas ignite, las conferencias relámpago, donde en solo 5 minutos, con 20 diapositivas que avanzan automáticamente, diversos conferencistas nos deleitaron con temas tan diversos como las de Jorge Johnson con sus “Girasoles, falanges y estimación relativa” en la que nos decía que todos somos geómetras y que nuestro cerebro “necesita buscar una cohesión o patrón geométrico”, nos habló de la filotaxis, naturaleza autoorganizada y la proporción dorada y cómo todo esto tiene relación con la estimación de proyectos ágiles de software. Al final, nos lanzó su hipótesis, la está estudiando a fondo me dijo, obteniendo las bases teóricas: “Nuestro cerebro tiene grandes habilidades para hacer estimación relativa con la secuencia Fibonacci.” Siendo fan de la archipopular progresión, yo no lo dudo. Esperaremos con ansias los resultados de su investigación.
Jaime García nos habló de la necesidad de un “Agilector 4000” en su “Selección Ágil de la Tecnología” y nos dejó a todos con la expectativa hasta octubre, fecha en la que ocurrirá el evento. Adrian Moya nos habló de “Desarrollo Guiado por Comportamiento” o BDD. Entre otros. La lista completa de participantes y temas y presentaciones la pueden encontrar aquí. Desde el exterior, vía Internet, nos acompañaron Diego Fontdevila con su “Arquitecturas y Organizaciones”, Martín Salias con su “Como escala la naturaleza” y Ricardo Colusso, entrevistando a Carlos Churba sobre “Principios para Estimular la Creatividad”. Al final, Verónica Vera nos deleitó con su “Futuro netamente humano”. En ese instante, el ambiente era mágico y quienes fuimos artífices y probablemente los participantes de esta fiesta de apertura nos dejamos contagiar de la felicidad, esa que tanto hemos vuelto a buscar y que estamos encontrando vía la cultura ágil.
En el cierre de la velada hablé de cómo es que seguimos viviendo en un momento histórico, pleno de ciencia y tecnología, pero también lleno de dilemas y conflictos humanos. Mientras lo decía, pensaba de nuevo en ese ensayo de Tobias, en su imagen renovada de la oficina del futuro, y en el mecanismo que teníamos para lograrlo. Tobias dice que “ese mecanismo no se llama Scrum. No hay framework, proceso o metodología que por sí solo permita alcanzar esta visión.” Más adelante expone finalmente que “hay solo una persona, un método, una cosa que puede hacer realidad esta visión. .” Por eso el gran reto, dije entonces, el nuestro, es que junto al cálculo y a la técnica, junto al método y a la teoría, hagamos convivir lo mítico, lo estético, lo simbólico.”
¡Nos vemos en octubre!

martes, marzo 04, 2014

Algunas Notas Sobre Gestión del Producto en Scrum

"Si puedes soñarlo, puedes hacerlo". Walt Disney.
Image courtesy of Stuart Miles / FreeDigitalPhotos.net
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
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
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
Escribiendo Historias de Usuario Altamente Efectivas, Parte 1
Escribiendo Historias de Usuario Altamente Efectivas, 2
Escribiendo Historias de Usuario Altamente Efectivas, 3
Escribiendo Historias de Usuario Altamente Efectivas, 4