A primer vista, la mayoría de las metodologías ágiles define de manera simple que las historias se desarrollen ordenadas por el valor de negocio que otorgan. Sin embargo, en muchos casos es más prudente mezclar el valor de negocio con pasos deliberados para "adquisición de conocimientos".
Veamos cómo podemos lograr un equilibrio entre entregar la funcionalidad requerida en el momento adecuado.
El problema del conocimiento "en cascada"
En la tarea de diseño de cualquier equipo, se suele trabajar en un probelma que todavía no se comprende, creando una solución que no entendemos completamente, y expresando nuestras ideas en tecnologías y lenguajes que generalmente no conocemos del todo - y todas estas cosas siguen cambiando a medida que pasa el tiempo, sin que podamos evitarlo.
A medida que trabajamos, aprendemos más acerca del probelma, acerca de las tecnologías, y de la misma solución propuesta.
El caso extremo de la integración por "big-bang", clásica de los modelos en cascada, previene cualquier adquisición de conocimientos antes de que finalice el proyecto, y que inevitablemente llevan a una "gran sorpresa" cuando ya no queda tiempo para reaccionar. En términos de producción ágil, estamos acumulando decisiones inválidas de diseño, que constituyen un "inventario" cada vez más grande. En términos de reducción de riesgos, este escenario deja un gran riesgo hacia el final, genera conocimiento de la historia de manera tardía, y de hecho no es divertido ni de vivir ni de observar.
El enfoque ágil del conocimiento
Desde la perspectiva ágil, los equipos se enfocan desde la primer iteración en "aumentar su conocimiento". Y lo hacen aprendiendo. Los equipos integran frecuentemente desde el inicio, por lo que pueden atajar a tiempo la "gran sorpresa" y dividir su solución en muchas sesiones. Al hacer esto pueden descubrir antes sus propios errores, es decir, "aprenden" de las equivocaciones, y las solucionan para que las integraciones tengan menos probabilidades de fallar. Este factor de aprendizaje se va achicando con el tiempo, a medida que el equipo avanza por las iteraciones, ya que los "problemas principales" ya fueron atacados tempranamente. Y esto es definitivamente bueno.
¿Qué nos asusta?
Una técnica para mejorar este enfoque es preguntarnos "¿Qué nos preocupa? ¿Qué nos asusta?". Y luego, enfrentar estos miedos desde la primer iteración del desarrollo, en vez de seguir la regla de "primero el mayor valor de negocio". Este tipo de trabajo puede parecer que no tiene una secuencia determinada, excepto la secuencia de que constantemente el equipo incrementa su conocimiento. Pero mientras más tiempo invierta el equipo en adquirir conocimientos, más logrará reducir los riesgos del proyecto.
En conclusión, podemos trabajar siguiendo el orden de valor de negocio una vez que los riesgos fueron mitigados. Una vez que la curva de adquisición de conocimeintos comienza a estabilizarse y quedar horizontal, es un buen momento para desarrollar las características siguiendo el valor de negocio. Y esto es lo que dice la regla general de las metodologías ágiles. De hecho, siempre se fue creando valor de negocio durante el período de adquisición de conocimientos, pero durante esta etapa ganar valor de negocio no es el motivador principal.
Es importante no confundir la "adquisición de conocimientos" con un "Gran diseño completo".
Una vez que se estabilizan las curvas de adquisición de conocimientos y de entrega de valor de negocios, el dueño del producto está en posición de entregar productos a tiempo (o antes, si necesita igualar a la competencia) con un grupo reducido de características, o entregar más tarde con el conjunto completo de funcionalidades. La elección es, como siempre, del dueño del producto.
¿Cómo ven este enfoque desde su experiencia? ¿Lo vivieron, podría haberles ayudado en algunos proyectos?
Basado en Iterating to adquire knowledge, not just business value
