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

Comentarios

Añadir nuevo Buscar

Escribir comentario

Nombre: Email:  No notificar:Notificar: Título: Código UBB:         -color-aguanegroazulfucsiagrisverdelimamarrónmarinoolivapúrpurarojoplataturquesablancoamarillo -tamaño-minúsculopequeñomedianograndeenorme

diego  - Me ha pasado   |Publisher |2008-11-06 02:54:24 Este año, hemos empezado por Enero un proyecto muy complejo tecnológicamente para nosotros, y lo hemos empezado (sin hacerlo sabiendo) de esta manera, y cuando tuvimos estabilizados la adquisición de conocimientos (luego de 2 o 3 sprints) comenzamos a entregar mayor valor de negocio. También hay que decir, que luego seguimos adquiriendo conocimiento y que no todo lo tecnológico estuvo resuelto en los 2 o 3 primeros sprints, sino que ahí fue donde dijimos que nos sentíamos mas cómodos para saber que podíamos hacer el proyecto de la forma que lo estábamos planteando. Responder | Citar

cbalvarez   |Author |2008-11-06 05:18:25 A mí me costó años llegar a decir abiertamente 'no se: no se que necesito porque no conozco toda la tecnología, no se cuan rápido va a andar porque todavía no se muy bien que querés' Como el 'no saber' tiene alguna carga de vergüenza, hay gente que lo usa para forzarnos a tomar un compromiso irrazonable, porque la alternativa es asumir que no sabemos. Cuando nos cruzamos con alguien así, lo mejor (lo mejor dentro de la ley, digo) es decir claramente: no se. Responder | Citar

Powered by !JoomlaComment 3.26

3.26 Copyright (C) 2008 Compojoom.com / Copyright (C) 2007 Alain Georgette / Copyright (C) 2006 Frantisek Hliva. All rights reserved."