Directora Técnica? Arquitecto de software?

En varias ocasiones nos hemos encontrado con el tener que abordar la tarea de definir un prototipo a la hora de definir un proyecto, y si el equipo que integra el proyecto, va a adoptar la metodología de Scrum para su gestión, la controversia está servida: ¿abordamos este primer análisis de la solución completa o lo dejamos para ir abordando en cada Sprint los análisis de las historias de usuario que habrá en él y por ende sus pantallas?

Partimos de la premisa de que para definir un prototipo tenemos que identificar y plasmar la idea global de la navegación del proyecto completo, así como la distribución de la funcionalidad en todas las pantallas de la aplicación, sin meternos aún en aspectos de diseño, pero afinando en la precisión del movimiento e interacción entre el usuario y los distintos elementos disponibles.

Al mismo tiempo, dado que queremos aplicar Scrum, partimos de la premisa de no abordar un análisis inicial que nos ocupe durante meses, quedándonos solamente en el momento del arranque del proyecto, en la idea general de cada una de las funcionalidades que ha de cumplir el proyecto.
El equipo ayudado por el Product Owner, seleccionará las historias de usuario que se abordarán en ese primer sprint, del cual tenemos una idea sin profundizar.

En ese momento, el Scrum Máster se hará una pregunta: tenemos que analizar la navegacion de toda la funcionalidad del Product Backlog a priori?

La respuesta, depende de quien responda.
Si responde él mismo, la respuesta seria no. No voy a dedicar tiempo ahora a definir tareas que puede que el cliente no quiera abordar, que puede que cambie el proceso de negocio que las nutre, que puede que cambie los requisitos del cliente. Si tengo que evaluar, dedicar este tiempo a un prototipo, es ir en contra de las ventajas de Scrum, y realizar un prototipo, lo considero un Riesgo que afectara a la planificación.

Si responde el arquitecto de información de ese proyecto, la respuesta será si. No podemos dejar cabos sin atar dado que la distribución de la información, la navegación entre pantallas, y la taxonomía de las mismas, puede provocar un cambio total en el interfaz, y por tanto en el desarrollo.

Si responde el equipo, dirán no. No quiero invertir todo ese tiempo ahora porque ese tiempo lo necesito para aportar calidad a mi código, realizar un buen cuaderno de pruebas exhaustivas y refactorizar en caso de que sea oportuno.

La conclusión final de todo este planteamiento es que sin prototipo no abordamos una tarea con orden, dado que el interfaz de usuario será la cara del proyecto, y para una optimización del tiempo, debemos abordar el análisis de cada historia de usuario cuando corresponda. Incluiremos la definición de cada parte del prototipo en cada sprint, como si fuera una tarea más del resto del sprint, y lo iremos revisando con el resto del producto, al igual que las demás tareas de integración.

Como comentan en el artículo, Dr. Charles Kreitzberg y Ambrose Little, es más simple que intentar abordarlo desde un principio como algo externo al proceso de desarrollo.

Os contaré el resultado del siguiente proyecto.