User Agile development. Lifecycle

Podríamos dividir los procesos UCD en cuatro momentos dentro del framework ágil.

1. Trabajo previo, investigaciones, analítica web, previa al inicio de la implementación
2. Trabajo específico del Sprint, diseños específicos y evaluaciones de usabilidad específicas
3. Trabajo paralelo a los objetivos estrictos del sprint, workshops con clientes, investigaciones adicionales, etc
4. Trabajo post-sprint, validación de usabilidad, re-diseño

Si analizamos el siguiente ejemplo de Nodder & Nielsen, vemos gráficamente esta integración.

La pregunta sería, si no puede ser muy arriesgado intentar diseñar el objetivo del sprint, durante el mismo Sprint. Evidentemente depende totalmente del proyecto, pero a priori lo podemos tomar como una buena práctica, para que el camino crítico del propio Sprint no sea excesivo.



También basándonos en gráficos de Nodder & Nielsen, el trabajo sería modelo funcionaría del siguiente modo.

Podemos entender los ciclos como sprints perfectamente, o como release, según convenga y hacer un breakdown acorde.

Lo importante es que la investigación se realiza 2 ciclos antes, el diseño 1 ciclo antes, se implementa, y un ciclo después se valida.

Para los primeros ciclos, como ya hemos comentado en alguna otra ocasión, el equipo de desarrollo se puede focalizar en solucionar retos tecnológicos de backend, funcionalidades de baja carga gráfica, pruebas de concepto de plug-ins o componentes, etc. O incluso para participar de manera conjunta el experto en usabilidad, usuarios, stakeholders y el equipo de desarrollo en un diseño común inicial, en los guidelines que van a marcar el producto.

¿Cómo sabemos si necesitamos iterar nuestro modelo?

Qué complejo verdad, cuando el bosque no te deja ver los árboles, algo va mal, pero no siempre es fácil identificar posibles soluciones. 

Podemos enumerar cierta relación de síntomas a tener en consideración, como si de un análisis de riesgo se tratara, como mitigarlo depende de tu organización, del proyecto, y de toda la semántica que te rodea en general.

• No tenemos tiempo suficiente de diseño. Diseñar es un ejercicio creativo, y en multitud de ocasiones no es fácil planificar y darle una estimación, sobretodo si es temporal. Si el diseño está en el camino crítico ... tenemos un problema, situaciones de bloqueos, cuellos de botella ... baja calidad (separar los ejercicios en sprints separados es muy razonable, así como revisar el tamaño de lo sprints)
• El feedback de los usuarios, promotores no es el suficiente, no llega a tiempo, tan habitual como grave, creo que exige escalarlo a nivel de comité de dirección. La implicación de los usuarios es crítica en las metodologías ágiles
• El experto en usabilidad no trabaja full-time, si además participa en las reuniones ... su capacidad de producción se reduce, y potencialmente la calidad de los diseños
• Se ignora el feedback de los usuarios en revisiones, PELIGRO! Puede ser bien por falta de tiempo, falta de budget ... pero en cualquier caso las consecuencias pueden ser nefastas
• Falta de visión de la imagen global. Esto es un punto muy habitual, y de los que más me preocupa en las metodologías ágiles, partir de una hoja de ruta con los sprints y lo que esperamos hacer a alto nivel, puede ser fundamental
• Fallos de comunicación, o de interpretación de los diseños ... debemos implicar o comunicar adecuadamente los diseños al equipo de desarrollo.
• Gestión de dependencias, gestión del camino crítico ... el SCRUM MASTER debe facilitar la gestión de dependencias en cada sprint, garantizando la ejecución secuencial de tareas en función de prioridades.

El ejercicio anterior, me parece curioso, pero poco realista, creo que está bien conocer los problemas que puedes tener, pero creo también que aplicar bien las retrospectivas, y escuchar y ver a tu equipo es la clave para identificar, y consensuar soluciones para estos problemas. Me parece muy adecuado aplicar ejercicios similares a las gestión de riesgos de las metodologías estándar.

Saludos,