Mapa mental en castellano del libro “How to Change the World” de Jurgen Apello

Añado un nuevo mapa mental a los que ya he compartido en este blog. En esta oportunidad se trata del mapa mental en castellano que resume el libro “How to Change de World” de Jurgen Apello.

Este mapa surgió a raíz del primer libro que leímos en el Club de Lectura de Madriagil y lo elaboré para dejar un resumen en castellano del libro, en un formato novedoso y también para que sirviera como  guía para su discusión y estudio,  tanto para los que asistimos a la tertulia correspondiente como para los no tuvieron la oportunidad pero que igualmente tenían interés en él. Así mismo se compartió en modo colaborativo para que pudiera ser actualizado y completado por cualquier miembro de la comunidad de Madriagil.

Imagen de la tertulia 2

Una imagen de la tertulia del Club de Lectura de Madriagil del libro “How to Ghange the World” (mayo 2016)

En este libro Jurgen expone de una manera interesante, divertida y con base en sus fallos y aciertos a lo largo de 15 años de trabajo y experimentos, las diferentes facetas a tomar en cuenta para llevar adelante cambios sociales, como por ejemplo, el cambio mental y social que conlleva la incorporación de Agile en el ADN de las personas y organizaciones, y qué modelos podemos aplicar para abordar cada faceta. Esto a través del supermodelo de gestión del cambio 3.0, que propone  un modelo de gestión del cambio específico para cada faceta: Sistema, Individuos, Interacciones y Ámbiente. Me parece una herramienta genial que proporciona una base sólida y estrategias muy útiles para aumentar la probabilidad de éxito de la adopción de cambios en sistemas sociales complejos, como pueden ser las organizaciones o las comunidades.

Imagen del mapa mental de how to change de world

Mapa mental resumen del libro “How to Change the World” de Jurgen Apello

Puedes acceder e interactuar con el mapa pulsando en el título de la imagen previa o haciendo clic aquí (irás al entorno colaborativo para hacer mapas mentales Mindmeister). En él podrás navegar por el mapa y descubrir en detalle cada uno de los modelos que componen el Supermodelo de Gestión del Cambio 3.0 y las recomendaciones para su implementación a nivel personal, grupal, de organizaciones o de la comunidad. Para expandir los nodos tienes que hacer clic en los círculos con el símbolo “+” y para contraerlos en los nodos con el símbolo “-“.

Para finalizar, comparto la recomendación que Jurgen Apello nos mandó vía correo electrónico a los participantes del Club de Lectura de Madriagil, para que te sirva de inspiración en tu rol  de agente de cambio a cualquier nivel: en tu organización, en tu comunidad o en ti mismo:

Don’t forget: change starts with talking and ends with doing.
Cheers,
Jurgen

Espero tus comentarios y que este post te sea de utilidad

Saludos Cordiales y Muchas Gracias, en especial a todos los participantes del Club de Lectura de Madriagil y a Jurgen Apello por su su libro y su amable email.

Gertrudis López

 

 

 

 

 

 

 

 

Anuncios

Mapa mental en castellano del post de Christiaan Verwijs “10 useful strategies for breaking down large User Stories (and a cheatsheet)”

Siguiendo con el tema de las historias de usuario, una de las cuestiones que surgen cuando estamos definiendo o refinando la pila de producto o a veces en la reunión de planificación del sprint es cómo o con qué criterios descomponer historias de usuario muy grandes.

Tomando como base que estamos en un entorno de desarrollo Ágil y que para entregar incrementalmente software que funcione, la premisa básica a la hora de dividir épicas, temas o historias de usuario grandes es hacerlo verticalmente, es decir, dividirlas de tal manera que las historias de usuario resultantes contengan todas las capas de la arquitectura definida, por ejemplo, siguiendo el modelo Vista Controlador (MVC), cada historia debe incluir la capa de interfaz, la capa de negocio y la capa de datos para que el incremento pueda ser software que funcione. La metáfora más apropiada para esto es que el descomponer épicas, temas o historias de usuarios grandes es como partir una tarta en trozos, teniendo en cada trozo todos los sabores y capas que componen la tarta, entonces ¿Qué criterios seguir para hacer esta descomposición?

Christiaan Verwijs escribió un post en el su blog Agilistic donde describe de una manera maravillosa 10 estrategias útiles para descomponer historias de usuario grandes, con sus correspondientes ejemplos. Este es uno de los artículos que estudiamos en el curso online sobre Historias de Usuario que impartimos en el área de Open Knowledge (OKs) de Scrum Manager

Las 10 estrategias para descomponer historias de usuario grandes que desarrolla Christiaan Verwijs pueden verse en la imagen principal de este post y son las siguientes:

1 – Descomponer por pasos de un flujo de trabajo

2 – Descomponer por reglas de negocio

3 – Descomponer por flujos de éxito y de fallo

4 – Descomponer por opciones de entrada o por tipos de plataforma donde se debe ejecutar la aplicación

5 – Descomponer por tipos de datos o por tipos de parámetros

6 – Descomponer por operaciones

7 – Descomponer por escenarios o casos de prueba

8 – Descomponer por roles

9 – Descomponer por “optimizar ahora” .vs. “optimizar más tarde”

10 – Descomponer por compatibilidad con los navegadores

En el post, describe en que consiste cada estrategia y da ejemplos concretos para cada una, por lo que me pareció útil elaborar un mapa mental en castellano de este post para poder estudiarlo más fácilmente y para poder usarlo como guía a la hora de descomponer épicas, temas o historias de usuario grandes. El mapa mental está hecho con la herramienta colaborativa para hacer mapas mentales Mindmeister 

Imagen mapa mental

Mapa mental del del post de Christiaan Verwijs “10 useful strategies for breaking down large User Stories (and a cheatsheet)

Para acceder e interactuar con el mapa pulsa en el título de la imagen previa o pulsa aquí. Cuando estés viendo el mapa, para expandir los nodos debes hacer clic sobre los círculos con el símbolo + y para contraerlos hacer clic en los círculos con el símbolo –

Espero tus comentarios y que te sea de utilidad

Saludos Cordiales y Muchas Gracias

Gertrudis López

 

 

Mecanismos para evaluar historias de usuario

Uno de los temas que ha salido en las retrospectivas de algunos de los proyectos Scrum que se desarrollan en nuestra organización es la carencia de mecanismos que permitan evaluar las historias de usuario incluyendo los problemas a los que se ha enfrentado el equipo de desarrollo al implementar las historias, ya sean imprevistos o planificados y las soluciones y decisiones que se han tomado sobre las historias.

Pienso que el equipo de desarrollo junto al Product Owner son los que mejor pueden responder a estas preguntas. Los intercambios de información y los problemas a los que se ha enfrentado el equipo de desarrollo al implementar historias previas se pueden tratar en las reuniones de planificación del sprint y de refinamiento del backlog, donde se puede medir el éxito de las historias de usuario en cuanto a lo “fácil” o “difícil” que ha sido comunicarlas al equipo de desarrollo, y lo “fácil” o “difícil” que ha sido implementarlas, lo que culmina y se evidencia en la definición de los criterios de aceptación de las mismas.

Una vez que ha habido conversaciones al respecto a partir de las cuales se han identificado posibles problemas a resolver, elementos iniciales de mejora y se ha llegado a un mejor entendimiento de los problemas que se han presentado, se pueden organizar retrospectivas específicas sobre estos aspectos, con el propósito de profundizar en los primeros resultados obtenidos y, con base en lo que se quiera revisar, determinar quien debe asistir a cada reunión. Si se quiere tratar el tema del valor que aportan las historias y cómo lo hacen, entonces sería necesaria la participación del Product Owner, de los stakeholders y/o de los usuarios finales de las mismas, adicionalmente al equipo de desarrollo y al scrum master. Si se quiere evaluar aspectos y decisiones técnicas y de diseño entonces sería necesaria la participación de líderes técnicos, expertos en las tecnologías utilizadas y por supuesto el equipo de desarrollo y el Scrum Master.

Inspirándome en el blog de Alexander Menzinsky, una de las técnicas a utilizar para recoger las opiniones e ideas que vayan surgiendo en estas retrospectivas es la técnica de la estrella de mar de Patrick Kua. Esta técnica consiste en reflejar en un tablero visual, basado en una estructura de estrella de mar, lo que se quiere seguir haciendo, lo que hay que hacer más de alguna cosa, lo que hay que empezar a hacer, lo que hay que parar de hacer y lo que hay que hacer menos, pero en vez de hacerlo para el proyecto en general, hacer una estrella para cada elemento que se quiera estudiar en la reunión, tomando como base historias particulares que se quieran trabajar o aspectos técnicos y de diseño particulares que se quieran estudiar. Gráficamente sería algo como lo que se ve en la siguiente figura, donde los participantes irían colocando sus opiniones en cada una de las áreas, se abrirían discusiones al respecto, y al final se haría una priorización en cada área de los elementos que el grupo considere más importantes para comenzar a trabajar en los próximos sprints, siempre basados en el valor que estos aportan a los usuarios de las historias.

Tablero de la tecnica de la estrella de mar                                             Tablero de la técnica de la Estrella de Mar

Otra técnica que puede utilizarse en el caso de que se haya detectado algún problema y se quiera llegar a su causa raíz para tomar acciones al respecto  es el diagrama de espina de pescado o diagrama de Ishikawa. El detalle de cómo aplicar esta técnica lo podéis ver en el blog de Alexander Menzinsky, en su post ¿Cómo identificar de forma ágil posibles causas raíz de un problema?

Luego, al ir avanzando los sprints e ir aplicando las acciones correspondientes a los elementos seleccionados, se pueden hacer reuniones posteriores para ver que ha pasado, tomando como base las estrellas iniciales o las espinas de pescado iniciales y a partir de ellas ir evaluando si las acciones tomadas han sido exitosas o no, de manera tal de poder ir ajustando el rumbo, incorporar nuevos elementos, quitar los que ya no se consideren necesarios y seguir el ciclo virtuoso de mejora continua al priorizar, seleccionar e implementar elementos de cambio, mejora o de continuidad que el grupo acuerde.

Pero teniendo en cuenta en el viejo refrán que dice que es mejor prevenir que lamentar, antes de implementar cualquier historia de usuario es necesario asegurar que sean las mejores historias de usuario posibles, es decir, que sean unas historias bien escritas, con todas las de la ley, para tratar de disminuir los posibles problemas que se puedan presentar durante su implementación. Con respecto a esto es muy importante disponer de formas concretas, precisas y prácticas para evaluar si tenemos buenas historias antes de empezar a implementarlas.

En un curso de Scrum Manager que hice sobre historias de usuario, uno de los ejercicios consistía en evaluar la calidad de unas historias de usuario con base en:

  • Los criterios de Mike Cohn para escribir buenas historias de usuario (Como [rol del usuario], quiero [objetivo], para poder [beneficio])
  • El modelo INVEST, para evaluar la calidad de una historia de usuario viendo si cumple cada una de las características:
    • Inpedendent (Independiente)
    • Negotiable (Negociable)
    • Valuable (Valiosa para el usuario)
    • Estimable (Estimable)
    • Small (Pequeña)
    • Testeable (Comprobable)

Para hacerlo definí una forma práctica, sencilla y muy visual de evaluar las historias usando una hoja Excel donde se coloca la descripción de las historias y se refleja los resultados de la evaluación según los modelos mencionados previamente, obteniéndose una escala numérica que refleja el nivel de cumplimiento o no de cada una de las características de cada modelo y reflejando a nivel visual (por colores diferentes) si la historia en realidad es una historia de usuario o no y en caso de serlo, su nivel de calidad, tal y como lo podemos ver en la siguiente ilustración:

Imagen matriz evaluacion historias de usuarioEvaluación de historias de usuarios usando los criterios de Cohn y el modelo INVEST en una hoja Excel.

Pienso que esta puede ser una forma práctica de evaluar historias de usuario antes de llegar a implementarlas y con base en los resultados obtenidos, el Product Owner apoyado por el equipo de desarrollo y el Scrum Master, buscaría mejorar la calidad de las que obtengan las puntuaciones más bajas.

Adicionalmente a esta idea, otra forma de facilitar el proceso de escritura de historias de usuario de calidad es usando patrones y/o herramientas basadas en los modelos mencionados y en otros modelos. Una de las herramientas que me parece muy adecuada para apoyar la escritura de historias de usuario, su refinamiento y posterior gestión del backlog es la herramienta easyBacklog. Está disponible de manera online, es muy fácil de usar y gratis. Para saber más de esta herramienta y ver ejemplos de su uso pueden ver el post de Alexander Menzinsky ¿Qué tal easyBacklog como software para gestionar la pila de producto y los sprints?

Muchas gracias a Alexander Menzinsky por su colaboración y consejo durante la escritura de este post y a Scrum Manager por la imagen principal del mismo.