jueves, 30 de junio de 2016

¿Hay alguna dinámica para cohesionar a los interesados en un proyecto e identificar su nivel de implicación?

Tablero con tres niveles de implicación
Como se desprende claramente de los valores y principios el Manifiesto Ágil, las prácticas de Scrum deben de propician la comunicación directa cara a cara entre las personas. Eso implica que hay que establecer las relaciones entre todos de forma temprana para generar confianza, ya que solicitar ayuda sin haber tenido contacto previo puede ser muy arduo.

La dinámica que muestro en este post se denomina conoce a tu vecinos, forma parte del pack de actividades de Incepción Ágil y tiene los siguientes objetivos:
En la dinámica todos los interesados deben de estar presentes y al exponer su rol e implicación se conocen y establecen relaciones de forma colaborativa, y también de forma colaborativa emergen aquellos actores que puedan faltar. En la mayoría de casos en nuestros proyectos, y en especial en proyectos de grandes compañías, hay más personas implicadas de las que podamos pensar en un primer momento, los proyectos suelen requerir interesados más allá de los que estarán en el día a día, y detectar a tiempo a estas personas puede evitar sorpresas e impedimentos posteriores.

Conoce a tus vecinos del Agile Inception
Deck de Jonathan Rasmusson
La dinámica:
  • Se diseña un tablero con tantos círculos concéntricos como niveles de implicación deseemos tratar:
    • en mi experiencia lo ideal son tres: equipo core, a consultar y a informar
    • The Agile Samurai propone dos: your core team y everyone else
  • Cada participante se presenta indicando su nombre, misión en el proyecto y su nivel de implicación

sábado, 25 de junio de 2016

¿Cómo funciona la toma de requisitos ágil?

La pregunta se podría reformular preguntado por como funciona el flujo de refinamiento de historias para que al equipo de desarrollo le lleguen las especificaciones con la información más reciente e incorporando todos los cambios acaecidos.

Nos basamos en una pila de producto con historias de usuario que son las utilizadas en los métodos ágiles para la especificación de requisitos, ta como describe Mike Cohn en 2004, son una descripción breve de una funcionalidad de software tal y como la percibe el usuario. Describen lo que el cliente o el usuario quiere que se implemente y se escriben con una o dos frases utilizando el lenguaje común del usuario. La primera pila de producto la podemos obtener mediante un User Story Mapping.

Las historias de usuario forman parte de la fórmula de captura de funcionalidades definida en 2001 por Ron Jeffries de las tres C's (Card - Conversation - Confirmation):
Cuadro con la técnica de las 3 C's

Cada historia de usuario debe ser limitada, esta debería poderse memorizar fácilmente y escribir sobre una tarjeta o post-it (card), ya que son una promesa de una conversación posterior. Poco antes de ser implementadas, en la reunión de refinamiento o en la de planificación de sprint, estas van acompañadas junto con los criterios de aceptación asociados de conversaciones entre el equipo de desarrollo y el Propietario del Producto. Como los cambios son bienvenidos en agilidad, no vale la pena profundizar antes, ya que en el momento de la implementación estas pueden haber cambiado desde que fueron escritas. Los criterios de aceptación transformados en escenarios de pruebas por el equipo de desarrollo, permiten al Propietario del Producto o usuario de negocio confirmar que el equipo ha entendido y recogido correctamente los requisitos.

Esta forma ágil de administrar los requisitos de los usuario evita la necesidad de elaborar gran cantidad de documentos formales, requiere que negocio lidere el rumbo del proyecto en todo su recorrido y a la vez no requiera mucho tiempo de dedicación por sprint.

domingo, 12 de junio de 2016

¿Cómo identificar de forma ágil posibles causas raíz de un problema?

En el curso de consultor de SAFe aplicamos el diagrama de espina de pescado o diagrama de Ishikawa que utilizó por primera vez el Dr.Kaoru Ishikawa de la Universidad de Tokio en 1943. Este diagrama se utiliza para identificar todos los factores fundamentales que posiblemente contribuyan a las causas raíces de un problema.

Ejemplo de un diagrama Ishikawa
Es una herramienta muy útil para buscar las causas raíz a un problema detectado en una retrospectiva por ejemplo, y así poder determinar una mejora para el siguiente sprint

La técnica se puede realizar sobre un tablero o un rotafolios sobre el que cuál se escribe y dibuja con rotuladores o marcadores. Opcionalmente se pueden utilizar post-its para los textos.

Identificado el problema, este se escribe en la parte central derecha del tablero, se dibuja una caja alrededor de él y una linea horizontal hacia la izquierda.

El siguiente paso trata de identificar las causas que pueden ser derivadas de sesiones de brainstorming. Estas causas son etiquetadas como categorías de causas de problema en cada una de las espinas de pescado que salen de la línea principal. 

En caso de que sea difícil encontrar categorías la técnica propone las siguientes categorías genéricas :
  • Métodos
  • Máquinas (equipos)
  • Personas (mano de obra, talento)
  • Materiales
  • Métricas
  • Entornos
Ejemplo de la búsqueda de las causas raíz de porqué
no funciona la comunicación en una compañía
A partir de este punto las causas se remontan a las causas de raíz con la técnica de los 5 Why's. En base a brainstormings de "¿por qué sucede esto?" sobre todas las posibles causas del problema, el Scrum Master o facilitador escribe las respuestas como una rama de la categoría correspondiente. Las causas pueden ser escritas en varias ramas si se refieren a varias categorías.

Se continúa iterando y preguntando "¿por qué?" para generar niveles más profundos de las causas, las capas de ramas indican relaciones causales. Una vez llegados a las causas raíz se buscan soluciones y planes de acciones para cada una, se vota y se implementan las soluciones una por una. Implementar todas las soluciones a la vez posiblemente desviaría el foco del trabajo hacia las mejoras. Esta técnica permite aflorar suposiciones y evitar trampas lógicas.

miércoles, 8 de junio de 2016

¿Cómo poner un perímetro que delimite nuestra visión del producto?

Tablero lo que NO es
Una forma de limitar la visión de un producto, para focalizarnos sólo en lo que realmente debe de ser, es la dinámica crear una lista de lo que NO es o NOT list, una de las actividades de la Incepción Ágil. Con esta dinámica se acota el alcance del producto/proyecto de una manera colaborativa haciendo team building y team commitment.

Decir que "si" es algo fácil, decir que "no" suele ser difícil, pero muy potente, pone los pies en la tierra y establece el nivel de expectativas adecuadas explicitando lo que no forma parte del producto/ proyecto. Es una forma efectiva de eliminar gran cantidad de residuos por adelantado.

Ocurre que hay cosas que podrían estar en el alcance de la visión de un producto pero por alguna razón, usualmente por tiempo y/o dinero, no lo están. Mejor resaltar estas cosas para resolverlas cuanto antes.
Lista de lo que NO es del Agile
Inception Deck de Jonathan Rasmusson

El tablero tiene las siguientes áreas:
  • Lo que es (in scope): Lo que se considera que debe de formar parte del alcance del producto/proyecto
  • Lo que no es (out of scope): Lo que considera que debe de quedar fuera del alcance del producto/proyecto
  • Por resolver (unresolved): Dudas de alcance no resueltas

sábado, 4 de junio de 2016

¿Cómo se gestionan los riesgos en Scrum?

Riesgos - cortesía de WorldArtsMe
La gestión del riesgo pretende detectar y mitigar el impacto de sucesos adversos. Con mentalidad tradicional tendemos a pensar que el alcance corresponde a una visión de negocio correcta, y que si entregamos un producto de acuerdo a esos requerimientos satisfacemos las necesidades de nuestro cliente o usuario. Por otro lado damos por hecho que el equipo resolverá los temas técnicos porque es el responsable de escribir un código que funcione. Con esta mentalidad obviamos los riesgos más importantes y más comunes, los riesgos relacionados con el cambio en los requerimientos, la falta de comunicación y el bajo rendimiento de los miembros del equipoJustamente a estos riesgos es a los que Scrum da solución de forma implicita.

La mejor acción para mitigar y eliminar
 riesgos es entregar el producto

Scrum, debido a su carácter iterativo, con entrega temprana y frecuente, inspección y revisión, hace que nos adaptemos cuando las cosas no van como deseamos. Reduce el coste de la asunción de riesgos truncando caminos infructuosos rápidamente con cada sprint. Scrum es una gestión de riesgos en si mismo y que ocurre en todo momento: en la daily, en las reuniones de planificación de sprint, en las reuniones de planificación de release, en las reuniones de revisión y también en la retrospectivas.

Existen otros tipos de riesgos que Scrum no gestiona implícitamente, como por ejemplo la falta de comprensión de Scrum por parte del cliente, productos de terceros que no funcionan como se esperaba, dependencias externas que no se resuelven a tiempo, Propietarios del Producto que no están comprometidos con su rol o cuyas agendas entran en conflicto con las necesidades del equipo... pero todos estos riesgos los visibiliza Scrum de forma temprana, como dice Rafael, un profesor mio, Scrum es como una suegra, pone sobre la mesa todos los puntos débiles e imperfecciones al primer contacto. :-)

Pensemos que el objetivo de cada sprint es que el equipo entregue el incremento con el que se han comprometido cumpliendo con DoD, de forma que sea potencialmente instalable en producción. Así, ya en el primer sprint aparecen gran parte de riesgos e impedimentos que se deben de resolver para el siguiente sprint. Usualmente resueltos los impedimentos al principio del proyecto habremos eliminado gran parte de los riesgos, que en un proyecto tradicional suelen aparecer a final cuando estamos a punto de entrega.

Nosotros aprovechamos las reuniones de refinamiento para hablar y detectar riesgos e impedimentos de sprints futuros. Como buena solución los añadimos como una historia especial a la pila de producto para que se tengan en cuenta y se hagan las acciones oportunas para mitigarlos o resolverlos a tiempo.

viernes, 3 de junio de 2016

¿Cómo medir la calidad de las historias de usuario?

En 2003 Bill Wake desarrolló un método llamado INVEST para asegurar la calidad en la escritura de historias de usuario. El método sirve para comprobar la calidad de una historia de usuario revisando que cumpla una serie de características:
  • I - Independent (independiente)
  • N - Negotiable (negociable)
  • V - Valuable (valiosa)
  • E - Estimable (estimable)
  • S - Small (pequeña)
  • T - Testable (comprobable)
Independent (independiente)

Es ventajoso que cada historia de usuario pueda ser planificada e implementada en cualquier orden. Para ello las historias deberían de ser totalmente independientes (lo cual facilita el trabajo posterior del equipo). Resaltar que las dependencias entre historias de usuario pueden reducirse combinándolas en una o dividiéndolas de manera diferente.

Negotiable (negociable)

Una historia de usuario es una descripción corta de una necesidad que no incluye detalles. Las historias deben ser negociables ya que sus detalles serán acordados con el cliente o usuario durante la fase de conversación poco antes de su inclusión en un sprint. Por tanto, se debe evitar una historias de usuario con demasiados detalles porque limitarían la conversación acerca de las mismas.

Valuable (valiosa)

Una historia de usuario tiene que ser valiosa para el cliente o el usuario. Una manera de hacer una historia valiosa es que la escriba el mismo.

Estimable (estimable)

Una buena historia de usuario debe de poder ser estimada con la precisión suficiente para ayudar al cliente, usuario o Propietario del Producto a priorizar y planificar su implementación. La estimación generalmente la realizará el equipo de desarrollo y está directamente relacionada con el tamaño de la historia de usuario (una historia de usuario de gran tamaño es más difícil de estimar) y con el conocimiento del equipo de la necesidad expresada (en el caso de falta de conocimiento, serán necesarias mas fases de conversación acerca de la misma).

Small (pequeña)

Las historias de usuario deberían englobar como mucho unas pocas semanas/persona de trabajo. Incluso hay equipos que las restringen a días/persona. Una descripción corta ayuda a disminuir el tamaño de una historia de usuario facilitando así su estimación.

Testable (comprobable)

La historia de usuario debería ser capaz de ser probada (fase confirmación de la historia de usuario). Si el cliente o usuario no sabe como probar la historia de usuario significa que no es del todo clara o que no es valiosa. Si el equipo no puede probar una historia de usuario nunca sabrá si la ha terminado o no.

Consejos para unas buenas prácticas:
  • Siempre escribir las historias con el "qué", evitar el "cómo".
  • No escribir una descripción exhaustiva, solo lo justo.
  • Escribir criterios de aceptación y ser suficientemente explícito.
  • Estimar todas las historias, no hacerlo puede crear falsas expectativas.
  • No fiar toda la información en las tarjetas, a veces es buena idea una documentación externa como una wiki por ejemplo.
  • Nunca dar una historia por finalizada cuando está "prácticamente hecha".
Tarjetas para historias de usuario de Braintrust preparadas para INVEST