Las metodologías tradicionales de desarrollo incorporan tareas y procesos que sirven para medir el éxito del proyecto desde diversos puntos de vista: calidad, por ejemplo, a través de los errores detectados en cada una de las entregas; calendario, contrastando el esfuerzo final en trabajador/día con las estimaciones realizadas al principio; costes, al poner en relación el presupuesto inicial y el gasto real. La lista sigue.

El problema -o el reto- es que ejecutar y analizar esas métricas no es, precisamente, el fuerte de las organizaciones que practican un desarrollo ágil. ¿Cómo medir entonces el éxito del proyecto? La clave está en la satisfacción del usuario. Aunque pongamos en práctica el proceso de forma impecable, siguiendo todos los pasos precisos, si el cliente final no está contento con el resultado, no hay éxito posible.

Esto nos conduce hasta la siguiente pregunta: ¿Cómo se mide la satisfacción de un cliente? La satisfacción es un término abstracto, así que a veces no queda más remedio que utilizar métricas subjetivas. Algunas son inequívocas, como que el cliente muestre una sonrisa de oreja a oreja. Pero desgraciadamente, las cosas no siempre son tan sencillas.

Define “éxito”. Por eso, conviene buscar desde el principio una especie de acuerdo o consenso entre el cliente y el equipo de desarrollo sobre lo que se entiende por “éxito”. Hay, desde luego, una serie de preguntas guía que conviene plantear antes de abordar el proyecto:

• ¿Cómo sería una aplicación de éxito para tu organización? ¿Cómo la definirías?
• ¿Qué es el éxito para ti? ¿Qué entiendes por éxito?
• ¿Cómo sabrás cuándo un proyecto ha tenido éxito?

Define “proyecto completado”. Y, en relación directa con lo dicho anteriormente, es necesario buscar un consenso también sobre cuándo y cómo se considerará que el proyecto ha sido efectivamente “completado”. Dónde acaba, vamos. Porque bien está lo que bien acaba…

Los usuarios de un grupo de discusión de Agile India proponen las siguientes métricas. El cliente quedará satisfecho si:

• Obtiene los resultados de negocio que esperaba al idear el proyecto
• Ha podido modificar y corregir el curso del proyecto según las exigencias de negocio
• Ha podido intervenir desde el principio en el desarrollo
• Ha podido asignar prioridades al desarrollo de las funcionalidades, consiguiendo la funcionalidad más apropiada en el plazo apropiado.
• Ha podido interrumpir el desarrollo de ciertas funcionalidades antes de que fuesen implementadas, porque se ha dado cuenta de que no iban a servir
• Ha establecido una relación bidireccional exitosa con el equipo de desarrollo
• No se ha llevado sorpresas durante el proyecto
• Considera que ha obtenido un buen resultado por el dinero invertido

Más información en Infoq y en agileindia.

Esta entrada fue publicada el Sunday, 10 de February de 2008 a las 10:15 y está clasificada bajo: Ágil. Puede hacer un seguimiento de los comentarios de esta entrada gracias al feed RSS 2.0. Puede dejar un comentario, o enviar un trackback desde su sitio.