sábado, 30 de julio de 2016

¿Cómo obtener de forma ágil una primera aproximación a la solución técnica?

Esquema con una solución de arquitectura técnica BI
Recordándo el undécimo principio del Manifiesto Ágil:

Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados

el equipo o equipos de desarrollo deben de participar en en el diseño de la solución desde el primer momento. Como primer paso expongo la primera de las actividades de la Incepción Ágil que se centra en el cómo, denominada mostrar la solución

Trata de alinear a la gente en la forma de pensar sobre la construcción del producto, se hace en en el momento en que se forma el equipo y trata la arquitectura técnica para asegurarnos de que todos están de acuerdo con la solución antes de empezar.

Sus objetivos principales son:
  • Crear una primera aproximación al producto a construir
  • Hacer tangible el proyecto
  • Team building & team commitment
Mostrar la solución del Agile
Inception Deck de Jonathan Rasmusson
La solución incluirá un cierto conjunto de herramientas, unas posibles librerías u APIs y una determinada arquitectura, y la mejor forma para alinear a todos es tratarlas de forma colaborativa por adelantado y enumerarlas en esta actividad. 

Si hay riesgos o temas no resueltos, la actividad brinda la oportunidad para que se traten, quizá se aclaren, o si no hubiera todas las respuestas, se conozcan y se gestionen a lo largo del proyecto.

En la actividad el Propietario del Producto expone la visión del producto para que los demás participantes traten y debatan sobre el reto de encontrar una solución técnica. La dinámica está facilitada por el Scrum Master y como entregable se obtiene un esquema de la solución.

jueves, 21 de julio de 2016

¿Cómo impactan las historias de usuario en la toma de requisitos?

El "Druazo"
Recientemente descubrí un nuevo término que me ha arrancado más de una sonrisa y evidencia la problemática propia de las metodologías que no absorben el cambio de forma natural. Se trata del "Druazo", término que deriva del DRU "Documento de Requisitos de Usuario", documento también conocido en otros ámbitos como DDR "Documento de Definición de Requisitos".

El Druazo se produce cuando el usuario o interesado de negocio ve el producto construido y da feedback en forma de ajustes y cambios necesarios, y entonces el analista o jefe de proyecto esgrime el DRU argumentando que "en la página 67 en el segundo párrafo el usuario escribió hace 6 meses que lo que quería era..." y de forma figurada recibe un carpetazo en toda la frente.

Recordemos que un proyecto es para construir algo nuevo, algo que ampliará la herramienta con la que la compañía gestiona su core-business, mejorando algún aspecto o para incorporar una nueva linea de negocio. Por tanto un proyecto siempre es algo sobre lo que negocio no tiene experiencia y cuyas necesidades se dibujan y maduran a medida que aprende a lo largo de la construcción del producto. Nuestros usuarios no pueden saber a priori lo que necesitan, aún no tienen experiencia ni de la gestión ni de como el producto funcionará en el mercado, sólo tienen una imagen de lo que saben y la visión de lo que quieren.

Una de las dinámicas que hago en mis cursos sirve para traer a la luz los problemas corrientes en los proyectos de TI. Pido a todos los asistentes que escriban cada uno tantos post-its como problemas usuales hayan vivido, para luego consolidarlos en un tablero. El problema por excelencia, como podemos observar en la imagen de arriba a la derecha, se refiere a la presunta falta de definición en los requisitos iniciales, se pueden ver post-its como:
  • Indefiniciones de usuarios, DRU con cambios constantes
  • DRU escaso y poco definido
  • Cambio de requisitos durante el desarrollo
  • Especificaciones imprecisas de usuarios
  • Falta de definición
  • Poco esfuerzo para definir el alcance inicial
  • Especificaciones de usuario incompletas o no claras
Viñetas del columpio, un clásico en TI
Intentar definir al detalle todos los requisitos de usuario a principio de proyecto lleva invariablemente a la situación que nos muestran las famosas viñetas TI sobre la construcción de un columpio.

Lo que hay en el trasfondo de este problema es la falta de comunicación, que como sabemos Scrum resuelve con la comunicación cara a cara, la comunicación a lo largo de todo el proyecto y mediante tableros o pizarras, que no son otra cosa que una herramienta de pura comunicación y conexión de las personas que participan en el proyecto.

Para resolver una toma de requisitos progresiva, centrada en lo que da valor en cada momento y de forma que aproveche el conocimiento tácito y la empatía que todos tenemos, la agilidad utiliza las historias de usuario, una promesa de un conversación cara a cara posterior basada en la fórmula de las 3 C's.

En uno de los cursos sobre historias de usuario hicimos un ejercicio final con la composición de un collage para mostrar lo que cada uno de los asistentes se lleva consigo. Uno de los alumnos compuso el collage que sigue, que describe tan bien como la toma de requisitos a través de las historias de usuario da solución al problema principal de la comunicación negocio-informática. Para mi el mensaje más importante del Manifiesto Ágil es "personas sobre procesos", y este collage lo muestra con toda su profundidad en relación a la toma de requisitos:
Collage que muestra como a través de las historias de usuario la agilidad da solución a un problema tan común
Gracias José Félix :-D

sábado, 9 de julio de 2016

¿Cuál es la manera ágil de concebir y acometer las tareas de los sprints?

Patrones de estrategia de sprint
Una de las cosas que aprende un Scrum Master con recorrido es a leer los tableros de los equipos. Un paseo por la sala dónde trabajan estos y con un vistazo a los tableros aprendemos a leer el nivel de autoorganización y multifuncionalidad de los diferentes equipos

Los equipos recién aterrizados en Scrum suelen comprender el proceso, las reglas y artefactos de Scrum, suelen no tener interiorizada la mentalidad ágil y tienden a aplicar comportamientos clásicos de pensamiento en cascada a las prácticas de Scrum, convirtiendo estas el algo así como un Frankenstein, hecho a pedazos de ambas metodologías, práctica que recibe el nombre de ScrumFall.

Recién comprendido el marco de Scrum y su construcción incremental e iterativa a base de sprints, los iniciados suelen trasladar las fases de la gestión en cascada a los sprints. Para cada funcionalidad a construir el primer impulso es pensar en modo clásico, en división en horizontal (por capas) y asignar sprints de forma secuencial a las diferentes fases de construcción. En un primer sprint se hace el análisis, que se acaba al 100%, en el siguiente sprint se inicia el desarrollo para finalmente hacer en un último sprint o grupo de sprints el testing (tal como está ilustrado como ScrumFall inter-sprints en la imagen arriba a la izquierda). Posiblemente esta solución sea mejor que un proyecto sin iteraciones, ya que así tenemos muchos pequeños proyectos y minimizamos riesgos y tenemos puntos de feedback, pero estamos lejos aún de ser ágiles y de beneficiarnos de todo lo que aporta Scrum. Este patrón se suele corregir de forma temprana, una buena formación en que se resalte la mentalidad ágil suele evitar que los equipos noveles caigan en esta práctica.

Ejemplo de tablero ScrumFall intra-sprints
 cortesía de Joaquín
Lo que sí es muy frecuente es el ScrumFall intra-sprints. El equipo obtiene la pila de sprint en la planificación de sprint, desglosa en tareas y en ese mismo momento asigna todas las tareas a los diferentes especialistas del equipo. El resultado es una construcción por fases de la funcionalidad, entregamos la funcionalidad completa y finalizada en la revisión de sprint, pero la construcción ha sido en cascada. Construir de esta manera puede funcionar perfectamente, pero perdemos los beneficios del trabajo por parejas o en equipo, los beneficios de las diferentes perspectivas de las personas que lo forman, y de lo que no solemos ser muy conscientes, de que esas fases no siempre son lineales, suele haber retrocesos y bucles que suelen ser un gran desperdicio.

Insistí mucho a uno de los equipos que acompañé como Scrum Master que la maquetadora y el desarrollador del front trabajaran juntos, durante los primeros 5 sprints no lo comprendieron y no lo hicieron, así que las tareas iban y venían de uno a otro hasta que el resultado fuera satisfactorio. Cuando por fin experimentaron mi consejo y se sentaron juntos ante un ordenador lo vivieron de primera mano, el tiempo de construcción se redujo sensiblemente y además se habían divertido y congeniado. Me emocioné mucho cuando expusieron su experiencia en una retrospectiva :-D

Arriba a la derecha muestro un tablero que ilustra ScrumFall intra-sprints en toda su dimensión. Cada uno de los carriles está asignado a uno de los diferentes miembros del equipo y todas las tareas, en diferentes situaciones, están asignadas individualmente a esos miembros. La consecuencia de esa estrategia es que cada miembro está focalizado básicamente en sus propias tareas perdiendo de vista la perspectiva general del sprint. Una segunda lectura que podemos hacer es la de una columna "en construcción" muy saturada, vemos que algunos de los miembros del equipo tienen muchas tareas abiertas, lo que supone convivir con el desperdicio de la multitarea y probablemente tiempos de espera por dependencias de otras tareas de otros miembros. ¿No sería deseable que todo el equipo estuviera focalizado a la vez en lo mismo y se ayudasen unos a otros en todo momento?

La forma ágil de acometer tareas en un sprint es la siguiente:
  • Por historias de usuario, recorriéndolas de la más prioritaria a la menos prioritaria, y no trabajar en más de una o dos a la vez.
  • Con autogestión: el equipo va autoasignando las tareas en las dailys a medida y en función del avance de sprint, eso coordinará y alineará diariamente al equipo.
  • De forma cross funcional: el equipo intenta acometer como verdadero equipo una sola historia de usuario a la vez. Los beneficios son que todos los miembros están focalizados y participan de la historia de usuario en curso, con lo que las buenas ideas surgen de las diferentes perspectivas que tiene cada individuo, y permite que los miembros se ayuden y se apoyen entre sí.
¡Pare de comenzar y empiece a terminar!

Termino el post con un buen tablero scrumboard en el equipo está "quemando" las historias de usuario de arriba a abajo, como una unidad cohesionada.
Ejemplo de un scrumboard con un equipo integrado trabajando de manera cross funcional

jueves, 7 de julio de 2016

¿Cómo priorizar la pila de producto de forma cualitativa y que cada valor tenga un significado intrínseco?

Aunque todas las historias de usuario puedan ser importantes, para poder focalizarnos en el trabajo de forma eficiente, es necesario destacar aquellas que den mayor valor al sistema, por tanto, las historias de usuario deben de estar priorizadas. Estas deben de tener asignadas un valor que intervenga en el sistema de priorización, un valor asignado por el Propietario del Producto y que se debe de basa básicamente en las siguientes variables:
  • Valor de negocio; beneficios al implementar una funcionalidad y coherencia con los intereses del negocio
  • Criticidad en el tiempo; pérdida o coste que demande posponer la implementación de la misma
  • Reducción de riesgos que implica implementarla
  • Valor de oportunidad; valor diferencial con respecto a productos de la competencia
Valores de las prioridades en la técnica MoSCoW
Uno de los aspectos a tener en cuenta es que la definición de "valor" puede variar para cada uno de nuestros clientes. Más allá de un sistema de clasificación de tipo prioridad alta, media o baja es muy recomendable utilizar algún tipo de escala cualitativa, una que tenga un significado intrínseco. Este es el caso de la técnica MoSCoW, en la que el usuario responsable de asignar la prioridad es consciente del efecto real que producirá su elección. Esta técnica fue definida por primera vez en el año 2004 por Dai Clegg de Oracle UK Consulting en el libro "Case Method Fast-Track: A RAD Approach". Su finalidad es obtener un entendimiento común entre cliente y el equipo del proyecto, en concreto sobre la importancia de cada historia de usuario. La clasificación es la siguiente:
  • M - MUST HAVE (es necesario): Se debe tener la funcionalidad implementada en la solución, sino esta fallará o la solución no puede ser considerada un éxito.
  • S - SHOULD HAVE (es recomendable): Se debería tener la funcionalidad implementada en la solución ya que es una funcionalidad de alta prioridad. La solución es prescindible, no fallará si no existe pero debería de haber causas justificadas para no implementarla.
  • C - COULD HAVE (podría implementarse): Es deseable, por tanto sería conveniente tener esta funcionalidad implementada en la solución, dependerá de las posibilidades de los tiempos y el presupuesto del proyecto.
  • W - WON'T HAVE (no lo queremos... quizá en un futuro): Se trata de una funcionalidad de muy baja prioridad o descartada en ese momento, pero que en futuro pueda ser relevante. Posteriormente, cuando cobre importancia, puede pasar a alguno de los estados anteriores.
Es importante distinguir entre prioridad y valor para el cliente. Puede ser que una historia de usuario no tenga ningún valor para el cliente o usuario, pero que esta sea absolutamente necesaria, por tanto de alta prioridad. Por ejemplo la infraestructura necesaria para la implementación de un software, no aporta valor al cliente en sí, pero sin ella no se puede desarrollar ni ejecutar la solución desarrollada.

lunes, 4 de julio de 2016

¿Hay mecanismos para evaluar historias de usuario?

Hoja Excel de evaluación de historias de usuarios
Cortesía de Gertrudis López :-D
El éxito de un proyecto depende en gran medida del Propietario del Producto, de su compromiso con Scrum y como líder en el rumbo del proyecto. Un punto clave del éxito está en su capacidad para transmitir las funcionalidades a través de buenas historias de usuario.

Os quiero invitar a leer el artículo "Mecanismos para evaluar historias de usuario" de mi compañera Gertrudis. Ella, al igual que yo en este blog, va poniendo sus granitos de arena para que la agilidad y Scrum vayan calando en nuestra cultura TI y vaya llegando a nuestras empresas y compañías.

En su artículo encontraréis una excelente herramienta de evaluación de historias de usuario basada en los criterios de Mike Cohn y el modelo INVEST. Por otro lado propone la genial idea de retrospectivas focalizadas en mejorar y dar solución a problemas de historias de usuario a los que se ha enfrentado los equipos de desarrollo.

sábado, 2 de julio de 2016

¿Cómo coordinar acciones de múltiples departamentos sobre un mismo entorno?

Facilitando la visibilización de dependencias
Uno de los impedimentos transversales a proyectos que más retos puede plantear es un entorno como el de test de una gran compañía. Este es un punto en el que convergen todos los proyectos, y por el número de proyectos concurrentes en curso y los actores relacionados, su coordinación puede ser muy compleja: hay momentos de servidores caídos por alguna actualización, funcionalidades inoperativas por pruebas de otra naturaleza, baterías de pruebas cambiantes, ventanas de prueba difíciles de coordinar…

Ante esta situación buscamos y creamos una herramienta visual que ayudase a coordinar y alinear los eventos del entorno de test. La idea se basa en un tablero de dependencias, como el utilizado en el marco de Scrum escalado SAFe, cuya función es "visibilizar" todos los eventos sobre test de manera que las personas presentes, viendo el cuadro general y formando parte del todo, detecten dependencias y busquen soluciones de forma colaborativa y consensuada desde sus perspectivas y opiniones particulares. Cuando nuestro compañero coloca un post-it con un evento que nos afecta, o al que afectamos, tenemos la oportunidad de ponerlo sobre la mesa, conversar sobre ello y de coordinarnos.

El tablero tiene el acrónimo VDD (Visibilidad de Dependencias) y está concebido para los 10 actores que pueden afectar a test (titular de cada uno de los carriles), más un carril con aquellos eventos que se producen de forma periódica. En la cabecera en horizontal tenemos las siguientes dos semanas y colocamos los post-its aproximadamente a la altura del día de la semana correspondiente. Los eventos que concebimos tratar en esta primera versión son:
Como curiosidad mencionar que alternamos las semanas entre la parte izquierda y derecha, cada dos semanas ocurre que la semana siguiente está a la derecha y la de más allá a la izquierda. Pensamos en dar la vuelta al tablero para tener dos semanas en la parte delantera y otras dos en la trasera, pero finalmente la solución adoptada y que nos funciona es el tablero de una sola cara.

Realizamos una reunión semanal de 15 minutos ante el tablero que se ha vuelto nuestro punto de referencia. Es nuestra herramienta de coordinación, pensada únicamente de y para las personas que participen, comunica a los asistentes y hace que conecten entre sí.

El tablero está dentro de marco de mejora continua y periódicamente realizamos retrospectivas para explicitar los beneficios obtenidos y obtener áreas de mejora desde dentro, desde las personas que lo utilizan. Todos los participantes coinciden en que es muy visual y eso da una imagen global de test que los sitúa dentro del contexto que hace que se sientan que forman parte habiendo mejorado sustancialmente la comunicación, tanto de los eventos en curso, como entre las personas de los diferentes departamentos involucrados. Los beneficios han sido muy elocuentes, ventanas de pruebas sin sorpresas, subidas coordinadas que han permitido ganar tiempo… poco a poco se irán desvelando las aportaciones futuras de esta herramienta.
Reunión semanal en una área común como el vending