Experimentos en el Backlog

No innovamos. Los agilistas no innovamos… tanto. A fin de cuentas, también somos seres humanos y nos cuesta salir de nuestra zona de confort.
Cuando un equipo decide adoptar Scrum, es habitual que coloque Historias de Usuario en su Product Backlog. En todo el mundo se hace así.

Algo ahí hace ruido: las Historias de Usuario sirven para construir cosas que ya están definidas. Cuando llegan a los equipos de desarrollo, alguien (el Dueño del Producto con los usuarios, por ejemplo) ya descubrió, entendió y detalló lo que se requiere construir. También se lo involucró al equipo de desarrollo, seguramente. Han utilizado buenas prácticas: una tarjeta, varias conversaciones y criterios de aceptación. Todo muy “INVEST”… para luego ir a construir algo. Algo que aportará valor.

Detengámonos ahí. En la certidumbre. Pretendida certidumbre. Pretendida.

Los productos y servicios que se construyen usando Scrum, no suelen tener alcance predefinido. No se sabe qué características agregarán más valor al usuario y al cliente. Por eso, cada vez más equipos utilizan Design Thinking para descubrir de forma temprana y Lean Startup para descubrir de forma evolutiva, aquello que les conviene construir.

En ese contexto de incertidumbre, proponemos colocar Experimentos en los Backlogs.

Así como las Historias de Usuario sirven para aclarar qué se debe construir, un equipo podría (¿debería?) tener en su Backlog, unos cuantos Experimentos. Tantos como dudas e inquietudes tengan. Los mismos le permitirán aprender más y de forma continua, temas relacionados con sus usuarios, las necesidades, el potencial de sus ideas y características. Y ese aprendizaje crecerá a lo largo de todo el proyecto.

Cada experimento tiene su hipótesis. Cada hipótesis supone un camino y un resultado. Pero no sabemos si eso ocurrirá o no. Entonces diseñamos y ejecutamos el experimento más simple posible.

Validamos o refutamos. Y aprendemos.

Las Hipótesis dejan de ser tal cosa. Ese abordaje minimalista y prudente nos provee aprendizaje. Ese aprendizaje nos permite avanzar… o cambiar el rumbo.

Si refutamos una hipótesis, habremos ahorrado tiempo y esfuerzo que hubiéramos dedicado a construir algo que no lo valía.

Por otro lado, una vez validada la Hipótesis de cierto experimento, se hará más visible la conveniencia de avanzar con el desarrollo más profundo de las características en cuestión.

Presentamos, además de la idea, un Canvas de Experimentos, para que los equipos lo utilicen para diseñar sus propios experimentos de forma simple.

Para que cada día haya más Experimentos en los Backlogs de los equipos.


Este artículo fue escrito a partir de la aplicación y refinamiento de estos conceptos en diversos proyectos e iniciativas, por parte de Rodrigo Monelos y Pablo Tortorella, Agile Coaches de Kleer.


Anuncios

Documentación en proyectos ágiles – Mitos, respuestas y alternativas superadoras

Un tema complejo el de la documentación.

Muchos piensan que el manifiesto ágil incita a los equipos a no documentar, debido al segundo de los 4 valores: Software funcionando sobre documentación extensiva. Esto es falso, es un mito. Se puede documentar todo lo que realmente sea necesario.

Lo difícil radica en que siempre (estemos o no en un proyecto “ágil”) debemos preguntarnos para qué y para quién la haremos y analizar en cada caso, si es que realmente necesitamos documentos para cumplir esos objetivos.

Suelo recomendar el uso de gráficos y esquemas en las paredes del espacio de trabajo del equipo, con los temas importantes (ej: la arquitectura del proyecto, la infraestructura, las decisiones de diseño más importantes).

También puede ayudar el hecho de grabar videos con las explicaciones más complejas.

Estas dos primeras recomendaciones (gráficos y videos) serían útiles para asegurar la coherencia entre el diseño y la implementación de aplicaciones.

Otro tema importante en la documentación ágil son las pruebas automatizadas: Unitarias, de integración, funcionales, de aceptación, de performance…
Si ya las hacen, sabrán de qué hablo. De lo contrario, lo explicito: Las pruebas automatizadas tienen gran poder en cuanto a mostrar “qué hace la app” y “cómo lo hace“). Y además hacen más baratas las pruebas de regresión.

En cuanto a la capacitación de nuevos integrantes del equipo, nada peor que mandarlos a leer documentos. Suelen ser aburridos, fueron hechos casi siempre con un sesgo del autor, tienen partes ambiguas… (y una larga lista de etcéteras.)
Para resolver ese tema, recomiendo que usen programación de a pares (y pairing en general, para todas las actividades del equipo). Haciendo se aprende más rápido y mucho mejor, que leyendo documentación.

En cuanto a entender y comunicar requerimientos del sistema, creo que una buena User Story (Historia de Usuario) puede ayudar mejor que los Casos de Uso o Requerimientos tradicionales. En el libro de mi socio y amigo Martín Alaimo se explica este tema a la perfección.

Por último, quiero aclarar que conozco bastante bien el lenguaje de modelado unificado (UML) y creo que en muchas ocasiones es útil usar los diagramas de secuencia, de implementación (AKA deploy) y aquellos que el equipo requiera para entender mejor alguna situación compleja y/o repetitiva.

A modo de cierre: no creo que “ser ágil” implique “no documentar”. Sino que “ser ágil” implica siempre estar atento y crítico con todo el proceso de desarrollo. Todo es perfectible y la clave está en encontrar el balance y el equilibrio adecuado. Un buen primer paso puede ser analizar las opciones de mejora que estén a nuestro alcance, en el camino entre lo que hacemos ahora y la/s mejor/es alternativa/s posibles.

“Capacitación” (Not!)