User Agile development. Is it posible?

Existen diferentes propuestas existentes de la integración de ambas iniciativas, aunque lamento deciros que en realidad es un ejercicio que deberéis hacer para vuestra organización personalmente, o incluso en función del cliente y los recursos disponibles.

A partir de lo expuesto hasta la fecha, hay evidentes e interesantes goals compartidos, que podemos resumir con desarrollar software de calidad. En cualquier caso, quizá analizando sus diferencias obtengamos los puntos que debemos atar con cariño.

•  El proceso iterativo es uno de los puntos de divergencia que dificultan la integración de ambas metodologías, las metodologías ágiles buscan maximizar trabajo finalizado, por lo que entendemos la iteración como una entrega de software validado, y en la siguiente iteración se buscar incrementar la cantidad de software finalizado disponible. En el ámbito UCD el concepto iteración se basa en mostrar una versión ligera al usuario a ser madurada en las siguientes iteraciones, en función del feed-back recibido.
  
  Aplicando diseños iterativos, e iniciar desarrollos en base a esos diseños no definitivos, nos conduce al camino del cambio continuo, algo que como todos sabemos penaliza enormemente.
  
  
• Otro punto de divergencia es el usuario en las metodologías ágiles, el product owner es habitualmente un promotor o stakeholder seleccionado, pero no tiene por que ser un usuario final de la aplicación (Situación clara de riesgo) mientras que para UCD el usuario está entendido como el usuario final.
  
  Es importante implicar a usuarios finales en la fase de diseño y de validación de la plataforma, por lo que parece recomendable reflejar las recomendaciones propuestas por UCD.
  
  
• Definición de alcance. Una potencial situación de riesgo detectada en las metodologías ágiles, es que partimos de la premisa de encontrarnos en situaciones de baja definición, en los que esta agilidad nos ayuda a avanzar optimizando recursos. Pero no existe una clara definición de cómo elaborar detallados diseños.
  
  Una de las reflexiones más interesantes que propone UCD, es la de a través de la fase de Consultoría o Análisis inicial poder discernir, diferenciar entre lo que el usuario quiere y lo que realmente necesita.
  
  En las metodologías ágiles, en las que el cliente on-site es responsable de especificar las historias, corremos el riesgo de desarrollar un producto en base a "lo que el cliente quiere"
  
  Una potencial solución es contratar un UCD expert y establecerlo como enlace entre los usuarios y el equipo de desarrollo. Parece otro buen punto de sinergia entre ambas iniciativas.
  
  
• Diseño de front-end. Este gran punto de divergencia es crítico, está relacionado con alguno de los puntos anteriormente descritos. Y es la relevancia que le damos al diseño. Realizar diseños detallados estudiando las necesidades del cliente puede ralentizar la velocidad de producción, pero no hacerlo nos puede llevar a desarrollos que necesiten ser modificados con posterioridad (minimizando las mejoras aportadas por la metodología ágil)
  
  Un posible punto de encuentro, pero a estudiar con mucho cariño, sería el de partir de un diseño de alto nivel, definir patrones de diseño o pantallas tipos, wireframes, guía de estilos y story boards, y renunciar al diseño detallado (a excepción de casos que realmente lo requieran)
  
  Así mismo, debería considerarse oportuno iniciar los desarrollos por el back-end para dar tiempo maduración de los diseños, y las iteraciones de diseño se deberían finalizar siempre durante el mismo sprint, para ser coherentes con la metodología ágil.
  
  
• Testing. Podríamos considerar un punto de divergencia también las fases de validación, pero considero que realmente la convergencia en este punto es clara. Las metodologías ágiles hablan de dos tipos o fases de test, los automatizados durante el desarrollo (unitarios e integración) y los de validación de usuario. Estos segundos serían perfectamente compatibles con los test de usabilidad que propone UCD.
  
  Igualmente podríamos llegar a considerar los test de usabilidad sobre prototipos o wire-frames, dentro de cada sprint, los resultados del test deben intentar solucionarse dentro del sprint en su mayor parte (por ejemplo estableciendo un buffer KANBAN) o ampliando el backlog de release para próximos hitos.

Seguiremos analizando en detalle las vías de integración.

Saludos,