Cuando empecé a trabajar con el enfoque ágil por el año 2000 me sorprendió ver un rechazo radical en los seguidores del agilismo (de esa época) respecto de la actividad de Análisis y del rol Analista. Pienso que esta actitud en parte estaba justificada por la poco eficaz "Fase de Análisis" (un período de tiempo en la que se concentran todas las actividades de elicitación, especificación y validación requisitos) y en la cual unas personas con un rol fijo y único, los llamados "Analistas" son los encargados de dichas actividades. Sin embargo, ni dicha actitud, ni tampoco el ímpetu por reducir la documentación deben dar pié a NO realizar gestión de requisitos. Ningún método ágil propone NO especificar qué es lo que se espera como producto, sería absurdo. Llámense Historias de Usuario o Casos de Uso, salvando sus diferencias de granuralidad y de aplicación, se trata al fin y al cabo de requisitos.
El enfoque ágil abre muchas oportunidades para el cliente y para el proveedor. Para aprovechar dichas oportunidades es el cliente quien puede (y debe) impulsar y apoyar más la aplicación de un enfoque ágil en sus proyectos.
Sabemos que el éxito (o fracaso) de un proyecto depende en gran parte de la adecuada gestión de los requisitos. Pero no se trata de la cantidad de requisitos especificados, ni siquiera del detalle en su especificación, las claves para una ingeniería de requisitos "renovada" y eficaz las podemos obtener del enfoque ágil. Esta visión se plasma en los siguientes consejos para la gestión de requisitos desde una perspectiva ágil.
1. ¿Cuánto especificar los requisitos?
Este consejo lo explico detalladamente en Gestión ágil de requisitos o ¿cuál y cuánta documentación/especificación es suficiente?
2. ¿Cuándo especificar los requisitos?
- Para establecer un compromiso de entrega con el cliente. Aquí nos referimos a la especificación de requisitos realizada antes de iniciar TODA la implementación, incluso antes de firmar un posible contrato o acuerdo de desarrollo. En esta situación la preocupación es establecer el alcance, costo y plazo del proyecto, todo ello con un nivel de precisión aceptable. Muchas veces el propósito de este estudio es para hacer una valoración preliminar dentro de un portafolio de proyectos.
- Para explicar al equipo qué se espera como resultado de la implementación de un requisito, cómo puede darse por satisfecha su implementación. Este debería ser el nivel "suficiente" para CADA requisito y justo antes de su implementación. Es decir, si un requisito se implementará a mediano o largo plazo, probablemente todavía no es necesaria tal detalle en su especificación.
3. ¿Cómo especificar los requisitos?
De todas formas, respecto a dicha discriminación de los requisitos y de las técnicas para especificarlos me atrevo a sugerir una especificación mínima, la cual podría extenderse atendiendo a las particularidades de cada producto o de cada requisito. Esta especificación mínima contendría los siguientes elementos (ya sea en un formato ficha, documento o elementos gestionados en alguna herramienta de apoyo):
- Visión del producto o servicio. Incluye breve descripción, características principales, actores, modelo de negocio, productos competidores y modelo de dominio (básicamente para fijar la terminología del dominio). Esta visión está bastante alineada con el contenido de un Lean Canvas, usado para evaluar una idea de negocio. La Visión del producto o servicio podría no estar explícitamente establecida, pero la parte cliente debería asegurarse que el equipo ejecutor tenga dicho conocimiento. Si se opta por establecer la visión explícitamente en un documento, debería bastar con unas pocas páginas.
- Requisitos Funcionales. Identificación en un panel, lista o diagrama de todos los requisitos, la idea es disponer de una panorámica de los requisitos del producto o servicio. Justo antes de su implementación se necesitará además la especificación del requisito (la que sea "suficiente"). La especificación mínima para cada requisitos funcional se compone esencialmente de bocetos y escenarios (expresados ya como Pruebas de Aceptación). Lectura recomendada: "Gestión de requisitos dirigida por las Pruebas de Aceptación".
- Requisitos No funcionales. Identificación de una lista de los requisitos no funcionales generales o transversales. Los requisitos no funcionales asociados a un requisito funcional específico es mejor incluirlos en la especificación del requisito correspondiente, o al menos tener algún tipo de enlace hacia dicho requisito.
4. Orientarse hacia una solución mínima y satisfactoria
Cuando se trata de la adquisición un producto o servicio ya desarrollado nuestra ambición en cuanto a requisitos suele estar principalmente limitada solo por nuestro presupuesto :-), con lo cual podría haber una cierta relajación respecto de adquirir lo mínimo que nos sea satisfactorio. Por contraparte, si estamos en la parte del proveedor y nuestro producto o servicio entrará a competir con otros, probablemente nos veamos forzados a ir mucho más allá de una versión mínima (ver Modelo Kano). Sin embargo, cuando se trata de un desarrollo a medida que estamos solicitando a un proveedor, sin lugar a dudas debemos ser mucho más estrictos respecto del alcance, plazos y costo del proyecto, y es en esta situación en la cual es más necesaria la estrategia de la solución mínima y satisfactoria. Esto no descarta que si el resultado es exitoso probablemente se encontrará apoyo para continuar mejorándo.
Lecturas recomendadas:
- Agilismo en la economía doméstica y su extrapolación a empresas.
- Bueno, bonito y barato ¿puede conseguirse esto con un método ágil?.
5. Cubrir el rol de Product Owner
6. Comunicar y reforzar la Visión del producto/servicio
Para que todos los participantes en el desarrollo puedan discriminar de forma eficaz entre unos requisitos y otros es imprescindible que conozcan la visión del producto. Así podrán decidir/entender qué requisitos deben especificarse con mayor detalle o precisión, qué requisitos deben probarse más exhaustivamente, qué requisitos deben implementarse cuanto antes o cuáles podrían incluso no llegar a implementarse sin que esto conlleve un fracaso para el proyecto.
La visión del producto o servicio puede ir cambiando durante el desarrollo (y luego durante el mantenimiento) con lo cual también es importante informar dichos cambios, incluidos aquellos asociados a la estrategia para hacer realidad la visión. Incluso aunque no existan cambios es conveniente reforzar continuamente dicha visión.
7. Gestionar los cambios en los requisitos
“Todo producto exitoso demandará mantenimiento”. Basta con que el cliente utilice un producto o servicio (lo cual es quizás es el mejor síntoma de éxito) para que solicite mejoras y nuevos requisitos. En un proceso de desarrollo incremental es natural que se generen cambios en los requisitos, primero porque precisamente favorece que aparezcan oportunamente las desviaciones de expectativas del cliente con respecto del producto o servicio resultante, y segundo, la gestión eficaz del Backlog es esencialmente el ordenamiento estratégico del trabajo pendiente para ser implementado, así pues el contenido y orden del Backlog probablemente cambiará. El cambio tradicionalmente es visto como algo negativo, sin embargo, en el enfoque ágil el cambio es algo natural, a lo cual no debería existir más resistencia que la comprensión y justificación del cambio, en lugar de ignorar o resistirse al cambio hay que gestionarlo de forma eficaz. Lectura recomendada: ¿Por qué un enfoque ágil permite gestionar mejor los cambios en un proyecto?. Encarar los cambios no significa renunciar a la gestión de alcance del proyecto, al contrario, ésta debe hacerse de forma más intensa. Lectura recomendada: Gestión de alcance en proyecto en un proyecto ágil.
Pero ¿qué conlleva el mantenimiento de la especificación de requisitos?. Básicamente debe involucrar facilidades para plantear el cambio, estudiar alternativas, prever su impacto, localizar dónde hacer el cambio, y finalmente, facilidades para hacerlo y probarlo. Además, también es útil conocer en el ámbito del cambio tanto el histórico de cambios como otros cambios que se esperan a futuro. Si bien los cambios se hacen a nivel de implementación, si contamos con una especificación de requisitos también deberemos hacer el mantenimiento de dicha especificación, actualizándola con el cambio realizado. Para facilitar el mantenimiento de la especificación es importante que sea lo más minimalista posible. Así pues, si tomamos como ejemplo el mantenimiento de una especificación como la planteada en el punto 3, los cambios esencialmente se concretarían añadiendo, modificando y/o eliminando pruebas de aceptación. Lectura recomendada: "Gestión de requisitos dirigida por las Pruebas de Aceptación".
8. Gestión de requisitos integrada en el modelo de proceso del proyecto
Históricamente se ha asumido que los requisitos deben estar especificados en detalle muy tempranamente, antes de la ejecución del proyecto. Esta "tradición" se explica porque al mismo tiempo se ha asumido que el modelo de proceso del proyecto debería ser en Cascada o incluso Secuencial, asi las actividades de definición y de ejecución se abordan como fases, períodos de tiempo diferentes, incluso llevadas a cabo por diferentes equipos. En un modelo de proceso ágil, el cual puede ser incremental, o iterativo e incremental, las actividades asociadas a la gestión de requisitos, para acoplarse a dicho modelo de proceso, presentan algunas novedades tales como:
- No es imprescindible identificar y detallar todos los requisitos tempranamente.
- El cliente debe estar continuamente participando en la especificación de requisitos y/o en mejoras a los requisitos ya implementados. El cliente en un enfoque tradicional concentra su participación al inicio y al final de proyecto, en uno ágil esto se distribuye a lo largo del proyecto.
- Se asume que los requisitos podrían cambiar y que hay que gestionar adecuadamente esos cambios.
- La gestión de alcance es muy continua. Se esperan cambios y ante cada cambio habrá que gestionar el alcance del proyecto.
Conclusiones
Espero que quede claro que mi recomendación global es aplicar un enfoque ágil para la gestión de requisitos :-). Si bien la gestión de requisitos no es un tema muy tratado en la literatura ágil (en dichos términos), es indudable que en cualquier desarrollo de producto o servicio la gestión de requisitos es esencial. Muchas prácticas ágiles están estrechamente relacionadas con gestión de requisitos y de otras puede derivarse una forma diferente y más eficaz de llevar a cabo la gestión de requisitos. Una importante innovación, por así decirlo, en el enfoque ágil es que la gestión de requisitos no está temporalmente aislada, no es un grupo de actividades que en un determinado momento da como resultado una especificación de requisitos. En el enfoque ágil la gestión de requisitos está integrada con la planificación y desarrollo, se realiza a lo largo de todo el proyecto, y está condicionada por el modelo de proceso, sea este incremental (incremental sin Sprints), o iterativo e incremental (incremental con Sprints).
Patricio Letelier
No hay comentarios:
Publicar un comentario