Story / Impact Mapping – Contexto, principios y visión general

El desarrollo de software en pequeños lotes es bueno
Hay muchas ventajas cuando se sigue el enfoque de pequeños lotes (small-batch) en el desarrollo de software (muchos pasos individuales pequeños):

• Feedback más rápido
• Los problemas se localizan
• Riesgo reducido
• Más presión y rutina para reducir el esfuerzo

El desarrollo de software en pequeños lotes de forma ingenua no es tan bueno

Sin embargo, cuando se aborda el desarrollo de software en pequeños lotes de manera ingenua, también hay una desventaja significativa: la falta de conexión con el objetivo general.

Jeff Patton ha descrito este fenómeno usando el ejemplo de un árbol y un saco lleno de hojas:

“Me imagino un árbol cuyo tronco está formado por los objetivos y beneficios deseados que impulsan el sistema. Las ramas gruesas son los usuarios, las ramas más delgadas y las ramitas son las capacidades que necesitan. Las hojas representan las User Stories que son lo suficientemente pequeñas como para desarrollarlas en las iteraciones.
Después de todo este trabajo, después de haber construido tanta comprensión compartida, tengo la sensación de que arrancamos todas las hojas del árbol y las metemos en un gran saco, y luego talamos el árbol.”

El “saco lleno de hojas” se refiere a una lista priorizada y sin contexto de tareas en un Backlog y refleja la comprensión ingenua de los “Backlogs” que, en mi opinión, es particularmente típica de los principiantes en Agile. Aunque teóricamente suena como si fuera un enfoque de pequeños lotes, con el “saco lleno de hojas” se rompe la conexión con los principios y objetivos subyacentes y, por lo tanto, se socava la autonomía.

Los 5 atributos de un enfoque efectivo de pequeños lotes en el desarrollo de software

Sin embargo, un enfoque más efectivo va más allá de la simple división en unidades más pequeñas. Un enfoque más efectivo:

• enfatiza la intención real con la ayuda de objetivos.
• enfatiza la conexión lógica entre los objetivos y las tareas necesarias.
• muestra visiblemente los objetivos, las tareas y las conexiones para descubrir posibles discrepancias y malentendidos.
• está orientado al trabajo colaborativo.
• es iterativo, es decir, no se requiere completitud al principio.
• Story/Impact Mapping vs. desarrollo de software en pequeños lotes
  Tanto el "User Story Mapping" de Jeff Patton como el “Impact Mapping” de Gojko Adzic son respuestas (ampliamente equivalentes) a los enfoques ingenuos para determinar los pasos individuales más pequeños en el desarrollo de software en pequeños lotes (es decir, para la creación de Backlogs). Yo lo describiría de la siguiente manera:

Nota: Este proceso de Impact Mapping debería ser iterativo. Aquí se presenta de forma secuencial solo para una mejor comprensión. No es necesario ni recomendable realizar cada paso en este orden. En su lugar, puedes comenzar en el punto en el que te encuentres y alternar los pasos según sea necesario.

1) Identificar objetivos
¿Qué quieres lograr?

Debería ser algo que se pueda observar y, por lo tanto, también medir. Por esta razón me gusta el término “impacto”, porque significa que algo es medible. Sin embargo, “objetivo” es más común y además no me gusta introducir nueva terminología cuando no es estrictamente necesario.

Puede haber múltiples objetivos.

2) Identificar roles y actividades
¿Quién debe participar en una actividad para alcanzar los objetivos? O bien, ¿qué actividades deben ser realizadas por alguien para alcanzar los objetivos?

En general, prefiero empezar por las actividades. En la práctica, sin embargo, es más bien un proceso bastante iterativo.

Por favor ten en cuenta que “rol” no significa “persona”. “Persona” puede referirse a otros roles que no tienen nada que ver con tus objetivos sino más bien con sus propios objetivos. Eso normalmente significa que hay que añadir objetivos adicionales que deben ser apoyados.

3) Identificar capacidades
¿Cuál es el requisito previo para que el rol pueda realizar una actividad?
Las capacidades no necesariamente tienen que ser algo que se incorpore al software.

4) Identificar Features y Stories
¿Qué hay que hacer para crear o hacer posibles las capacidades?
Las Stories deberían consistir en trabajos más pequeños. Con los Features se trata más bien de permitir discusiones a un nivel más detallado.

Este texto proviene del blog de Jason Yip y fue traducido por nosotros al alemán.