AOS2012 - Agile Inception (2 de 2)

Pues nada, he aquí la segunda parte de la descripción de este método.
Antes de seguir, recordar la principal bibliografía, que es el magnífico libro "The Agile Samurai" de Jonathan Rasmusson, de donde además son algunas imágenes.

Nos habíamos quedado en el anterior post repasando las 5 primeras actividades o juegos. Pasemos a los 5 siguientes. Recordad que podéis encontrar un resumen del AOS 2012 y un indice de las ponencias a que asistí en este enlace.

6.Mostrar la solución 

• Presentar una solución técnica
• Revisar riesgos
• Establecer dimensiones
• Establecer resultados del producto
• Establecer claramente lo que va a costar
• Utilizar lenguaje visual
• Establecer expectativas de las áreas con más riesgo
• Obtener compromiso con la solución técnica planteada

7.Despierto por la noche

• Determinar los riesgos del proyecto
• ¿Qué nos quita el sueño?
• Hablar de los riesgos es bueno
• Debe participar el equipo: compartir los riesgos es aún mejor
• Clasificar los riesgos en dos categorías: Los que merece la pena preocuparse por ellos (probables o graves), y el resto
• Llegado el caso, antes de perder la calma, echar mano de la oración de la serenidad:

8.Medir el tamaño 

• Se trata de dar una estimación de orden de magnitud: un mes, dos, seis meses o un año
• Utilizar técnicas de estimación ágiles
• Presentar al cliente la estimación y una planificación a muy alto nivel. No se establecen compromisos en cuanto a plazos.
• Pensar en pequeño
• Dar expectativas de tamaño

9.¿Cuál va a ser el resultado?

 En este punto, hay que establecer prioridades entre las principales restricciones del proyecto:

• Alcance
• Presupuesto
• Tiempo
• Calidad
• Otros

 Recordar dos reglas fundamentales:

• No pueden ser todas prioritarias (no todas son #1)
• No puede haber dos al mismo nivel de prioridad

10.¿Cuál va a ser el coste?

•  Llegados a este punto, mediante los juegos anteriores tenemos la visión y el plan
• Debemos finalmente mostrar el coste y esfuerzo necesarios, recursos, etc.
• Detallar nuestro equipo (roles, responsabilidades, nombres, etc.)
• Aclarar quién va a ser la voz del cliente, el responsable de filtrar y focalizar las peticiones de los stakeholders.
• El resultado será algo como:

El resultado final

El resultado de esta actividad participativa será un documento o material en el que habrán quedado identificados:

• Qué se va a construir y porqué
• Qué amenaza al proyecto: riesgos y retos principales a afrontar
• Cuáles son los obstáculos a resolver
• Quiénes van a ser nuestros “vecinos”
• Qué aspecto tiene nuestra solución
• Tamaño que va a tener
• Dónde estamos dispuestos a ser flexibles y adaptables
• Duración y coste aproximados

Conclusión

Esta actividad, que explicada así puede parecer un poco "de juguete", en realidad consigue de una forma dinámica y participativa, que se encuentren y se pongan en común posturas normalmente opuestas como son las del equipo técnico/funcional, y el cliente. El hecho de ser participativa, y enfocarse en pequeñas actividades, aligera el proceso y permite que algo tan complejo y tedioso como identificar las necesidades del cliente y establecer una visión global del producto a construir, es ameno y en cierto modo, hasta divertido.

Por lo demás, recomendar el libro "Agile Samurai", que aunque en algunos momentos puede parecer "más de lo mismo" en el mundo ágl, tiene algunas perlas que lo salvan de cualquier quema.