Definiendo productos ágiles con Craft.io

Estas semanas estoy probando aplicaciones para definir productos en base a historias de usuario.

Creo francamente que los técnicos muchas veces cometemos el error de querer utilizar una herramienta absolutamente para todo (anti patrón “martillo de oro”) y puede ser contraproducente tratar de meter a los usuarios de negocio por nuestro embudo.

Posiblemente sea muy buena idea trabajar con una herramienta en la fase de definición y con otra en la de construcción.

Y sí, si te lo preguntas, claro que me acuerdo del manifiesto ágil y tengo muy en cuenta que son más importantes las personas y sus interacciones que los procesos y herramientas. Claro que prefiero trabajar en la definición de proyectos con paneles físicos y pizarras. Lo único es que alguien luego (o en paralelo) tiene que ir recopilando la información.

Hoy voy a jugar un poco con Craft.io que podéis encontrar en https://craft.io/. Obviamente mi entendimiento del producto será limitado así que os recomiendo probarlo por vosotros mismos y llegar a vuestras conclusiones.


Me voy a crear una cuenta gratuita y voy a dar de alta un proyecto que voy a llamar “proyecto de futuro”.


Creo el nuevo proyecto:


La aplicación tiene 4 lengüetas: descubrir, definir, planificar y construir.

Curiosamente empieza por defecto por definir. Voy a seguir por aquí pero mirad antes de jugar con la herramienta el tutorial completo porque es mejor empezar por discover si quieres hacer un User History Mapping y que te cree todos las historias desde ese punto.

La estructura lógica es que tenemos algunos elementos esenciales como objetivos, personas, etc. Luego unos temas que tienen épicas e historias.


Si pinchamos sobre el + de Essentials vemos las opciones que nos propone.


Creamos el sumario del proyecto. Recordad que los proyectos hay que saber contarlos a las personas que no tienen contexto (que normalmente son los que aprueban las inversiones). Un glosario tampoco estaría mal.


Todo proyecto debería tener objetivo y diría que hasta KPIs para medir su éxito y saber si es mejor dejarlo a tiempo.


Podemos identificar los usuario-persona (o cliente-persona) como se dice ahora.


Y bueno, los que queráis más.


En los temas, me gusta agrupar empezar por distintos tipos de usuarios. Hacemos un problema grande descomponiéndolo en 7 más pequeños. Realmente da igual quién hace qué, por lo que no os molestéis demasiado en la integridad en una primera fase.


Para cada uno de los usuarios definimos las épicas agrupadoras y las historias


Cada una de las historias puede tener atributos como: importancia, categoría, valor, esfuerzo, puntos de historia, valoración de kano (esto me encanta porque lo cuento en todos los cursos).


A las historias se les puede incorporar el diseño por lo que tenemos junto a la definición una previsualización en distintas partes del sistema.


Podemos exportar la documentación que va quedando bastante aparente.


En la sección de plan podemos definir versiones e hitos. Interesante que podemos ver el porfolio de multiples proyectos.


Creamos una nueva versión con el Producto Mínimo Viable.


La llamamos PMV.


Y añadimos las fechas de inicio y de final.


Creamos un hito o milestone.


Vemos cómo se va quedando reflejado.


Creamos una segunda versión del producto donde meter las historias menos prioritarias.


Y visualizamos el modelo.


A las historias les podemos cambiar el atributo de versión una a una.


También desde RoadMap las podemos cambiar todas a la vez.


Podemos crear Sprints con sus fechas de inicio y final y añadir las historias.


Recordad que en un product backlog no todo son historias, podemos tener otros tipos de backlog items.


Podemos visualizarlo en columna para comprobar los contenidos completos asociados a cada versión.


Cada elemento que vamos creando podemos asociarlo a un rol y/o usuario.


De este modo podemos crear paneles Scrum donde ver todo el trabajo o por usuario concreto.


Los paneles pueden ser Scrum o Kanban. En estos últimos se puede definir el WIP.


Con toda la información guardada y actualizando en grado de avance podemos seguir fácilmente todos los items desde una pantalla de control.


Como podemos ver, esta herramienta tiene un metamodelo bastante útil porque en la mayoría de los casos no vamos a necesitar mucha más información a nivel de definición y seguimiento (estoy pensando en empresas muy grandes con un gran porfolio de proyectos y alta complejidad técnica por debajo).

Si os fijáis, desde el principio advertía que si quieres hacer un User Story Mapping tendrías que empezar en discover.

Podemos dar de alta una idea.


Sobre esta idea hacer el User Story Mapping.


Y decirle que me lo pase directamente a definición.


Le decimos a qué versión queremos que nos lo pase.


Y ya tenemos trasladados todos nuestros items a define. Rápido y sencillo. De todos modos parece razonable para un primer paso pero luego por experiencia parece que tenga más sentido seguir en define para darle más integridad al modelo.


La verdad es que me ha gustado mucho la herramienta. Obviamente está en el extremo opuesto de CardBoard https://www.adictosaltrabajo.com/tutoriales/user-story-mapping-con-cardboard/ donde teníamos un meta modelo muy reducido y mucha flexibilidad para pintar.

Todavía tengo que seguir probando algunas otras pero si os fijáis bien, lo importante es tener una metodología base para definir los proyectos. La herramienta luego veremos cómo nos da cobertura a esa metodología con la que nos sintamos cómodos.

Este modelo lo podéis encontrar en https://app.craft.io/share/7BC521D62305843009655840431

Si queréis aprender modelos de definición de proyectos y más sobre construcción de software de calidad podéis informaros sobre nuestros cursos. Tal vez te lo pueda contar en persona.

https://www.autentia.com/servicios/formacion/curso-gestion-alcance-definicion-producto/