Cargando...

Discovery agil

Descubrir lo que los usuarios, inversores y publico meta, desean alcanzar con el proyecto es a menudo la parte más difícil. La comunicación entre los equipos de TI y los no técnicos puede estar llena de malentendidos y malas interpretaciones. La premisa por la que me guío en el proceso de desarrollo es que a menudo, los usuarios no saben lo que quieren hasta que lo ven, y con frecuencia no pueden articular sus expectativas en un lenguaje que los expertos en TI utilizan para diseñar sistemas.

Los técnicos suelen encuadrar sus preguntas de requisitos en un lenguaje técnico, como "¿Debe funcionar en un navegador?" o "¿Cómo se validarán los datos?" y los clientes pueden no tener los antecedentes técnicos para responder a estas preguntas. Los usuarios a menudo explican sus expectativas en un lenguaje vago, como "rápido" o "sencillo", que carecen de la especificidad que los diseñadores necesitan para desarrollar soluciones.

En esta busqueda para encontrar un lenguaje que resulte común tanto para los equipos de TI y los no expertos, durante mucho tiempo se tuilizó el Unified Modeling Language (UML) y Casos de Uso, que mediante la aplicación de un lenguaje natural y gráficos simples, permite documentar las actividades e interacciones del sistema descritas por el usuario.

Sin embargo, los diagramas de caso de uso pueden covertirse en algo bastante complejo cuando se describen sistemas grandes, lo que resulta en algo desconcertante e indescifrable para usuarios y gerentes no técnicos.

Es por ello, que desde mi perspectiva, el uso de Historias de Usuario, ayuda a respaldar los requisitos del usuario con una estructura menos formal, mediante breves y concienzudas descripciones de una capacidad del sistema o función.

El uso de la palabra "historia" es la pieza clave, en lugar de pedirle a un usuario que describa (por ejemplo) los "requisitos de velocidad y latencia" de un sistema, les preguntamos qué tareas planean hacer cuando se sientan al teclado. De acuerdo con el concepto "apenas suficiente" de documentación ágil, las historias de los usuarios son breves, escritas como una narración simple.

Por ejemplo, podemos construir las siguientes historias sobre cómo los diferentes usuarios podrían interactuar con su sistema propuesto:

"Como persona en busca de empleo, puedo buscar trabajo".
"Como empresa, puedo publicar ofertas de trabajo".

A partir de aquí, como en muchos otros esfuerzos de desarrollo de sistemas, es una cuestión de refinamiento paso a paso y de excavación incrementalmente más profunda. El equipo ágil puede luego pedir más especificidad sobre las acciones del solicitante de empleo, obteniendo información como la siguiente:

"Como persona que busca empleo, buscaré trabajos por atributos como ubicación, salario, título, empresa y fecha de publicación".
"Como persona que busca empleo, profundizaré para obtener más información sobre los trabajos seleccionados".
"Como persona que busca empleo, aprenderé más sobre la empresa que publica el trabajo".

Una forma de agregar detalles a las historias de los usuarios es pedir que se describan los criterios para evaluar el funcionamiento del sistema, lo cual genera una buena comprensión de los amplios límites de rendimiento y calidad que el cliente espera.

Esta aproximación, asegura un proceso más simple y fluido en el levantamiento de requerimientos, pues, al hablar sobre funcionalidades, se recauda información de cada una de las áreas involucradas para cubrir la acción; evitando reuinones separadas con temas repetidos entre ellas, es decir, para que se cubra la acción de "compra de mercancia", fue necesario conocer el proceso de su registro contable, financiero (para métodos de pago) y control de almacén, en vez de preguntar a cada una de las áreas por el proceso de compra, esto asegura que se lleguen a acuerdos operativos necesarios para definir un flujo programatico que será más fácil de traducir al desarrollo.