userstorycontext-fig1_1En este post voy a seguir compartiendo mi experiencia con un proyecto en la que el proveedor del software utiliza metodología ágil para su desarrollo (ver Trabajar ‘ágil’ cambiará tu vida). Hoy me centro en la definición del Alcance (scope).

En la primera parte del proyecto, partíamos de un ‘paquete’ ya existente que mi cliente quería adoptar con mínimas modificaciones. En esta fase, no tuvimos especiales dificultades para definir el alcance. Las modificaciones requeridas sobre el paquete base eran fáciles de describir y convertir en ‘user stories’. Utilizamos una herramienta para registrar todas las peticiones (Jira) y periódicamente revisábamos prioridades para definir los objetivos del equipo de desarrollo en cada sprint (del tema de cumplimiento de fechas y tiempos ya hablaré en otro post).

En la segunda fase del proyecto, la cosa se ha complicado bastante. Hay que añadir un nuevo  set de funcionalidades a la aplicación. Desde el lado de mi cliente, hemos definido en detalle los requerimientos de negocio, funcionales y hasta se ha diseñado un modelo de información y un flujo de procesos. Todo ello se lo hemos pasado al proveedor del software con la intención de que nos evaluara esfuerzo y presupuesto. Y ahí nos hemos atascado. Porque a la hora de evaluar esfuerzo, si no hay user stories, parece que no son capaces. Pero… ¿quién es responsable de hacer las user stories? ¿Ellos? ¿Nosotros? ¿Con qué detalle? ¿Cuánto tiempo lleva? En fin, en esto estamos.

Mi conclusión es que, de nuevo, esto es diferente a un proyecto tradicional. Desde el lado del cliente, no hay que asumir que con la documentación habitual vas a tener una propuesta habitual, sobre todo si estás trabajando con una compañía joven que sólo está familiarizada con metodología ágil para su desarrollo interno. Desde el  lado del proveedor, hubiera esperado que hubiera alguien capaz de entender la complejidad del scope sin bajar a tanto nivel de detalle y con la experiencia suficiente para hacer estimaciones a ese nivel.

Mi recomendación es que si vais a trabajar con desarrolladores ‘ágiles’, aclaréis todos estos aspectos muy pronto en la relación, antes de que os atasquéis.  Y recuerda, trabajar ‘ágil’ cambiará tu vida.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *