Los modelos tradicionales no nos sirven. Por ejemplo, el modelo tradicional en cascada o en espiral basados en la toma de requerimientos, análisis, diseño, construcción, pruebas e implantación ya no nos vale.
Una de las principales desventajas de estas metodologías es que si realizamos una toma de requerimientos pobre o poco concreta, a menudo porque el propio cliente no tiene claro lo que desea o nosotros mismos no analizamos bien el requerimiento, puede ser que nos demos cuenta de las desviaciones en fases muy tardías del proyecto.
Pero en la realidad, suele suceder que las necesidades de los clientes cambian desde que se dieron las indicaciones iniciales por lo que se hace necesaria captar estos cambios de forma más rápida.
Por tanto, como estas necesidades tan cambiantes crean un nivel de incertidumbre parece lógico construir mecanismos y técnicas para tratar de atar las cosas lo mejor posible desde un principio y hacer partícipe al cliente que pide el proyecto/desarrollo de su definición. También deberíamos hacerle partícipe de los problemas que puedan surgir o involucrarle en la definición y validación de los mismos.
Por todo esto, actualmente la aparición de la metodologías ágiles toman como parte fundamental la idea de acoger el cambio como algo natural en los proyectos siempre teniendo en cuenta tres premisas fundamentales:
- Construir sólo lo necesario PMV (Producto Mínimo Viable).
- Eliminar todo aquello que no añade valor.
- Parar si algo no va bien (lo que está relacionado con el principio de cero defectos).
Función del product owner
Debe ser la persona (o dueño o representante del cliente) que interactuará con todas las áreas de negocio que tiene la capacidad de priorizar y decidir las tareas. Será quien valide los resultados que se se vayan produciendo en cada entrega del producto.
Con esta figura nos aseguramos que las peticiones del cliente son las solicitadas.
La función del product owner es vital, debe ser quien decida que historias de usuario entran en el product backlog, cuáles no y además la prioridad de las historias del product backlog. Por tanto no solo es necesario estimar las historias de usuarios si no indicar la prioridad de cada una de ellas.
Historias de usuario
En las metodologías ágiles la descripción de las necesidades se realizan a partir de las historias de usuario que son, principalmente, lo que el cliente o el usuario quiere que se implemente; es decir, son una descripción breve, de una funcionalidad software tal y como la percibe el usuario.
En el product backlog o pila de producto es donde se situarán todas y cada una de las historias de usuario solicitadas por el cliente.
Aunque dependiendo del proyecto se podría incluir cualquier otro campo que proporcionase información útil, a continuación describo aquellos campos que se consideran más necesarios para describir de manera adecuada una historia de usuario. Estos campos se pueden observar en la siguiente figura:
- ID: identificador de la historia de usuario.
- Título: título descriptivo de la historia de usuario.
- Descripción: descripción sintetizada de la historia de usuario.Si bien el estilo puede ser libre, la historia de usuario debe responder a tres preguntas: ¿Quién se beneficia? ¿Qué se quiere? y ¿Cuál es el beneficio? Cohn (M. Cohn, 2004) [1] recomienda seguir el siguiente patrón:Como [rol del usuario], quiero [objetivo], para poder [beneficio]. Con este patrón se garantiza que la funcionalidad se captura a un alto nivel y que se está describiendo de una manera no demasiado extensa.
- Estimación: estimación del tiempo de implementación de la historia de usuario en unidades de desarrollo, conocidas como puntos de historia (estas unidades representarán el tiempo teórico de desarrollo/persona que se estipule al comienzo del proyecto).
- Valor: valor (normalmente numérico) que aporta la historia de usuario al cliente o usuario. El objetivo del equipo es maximizar el valor y la satisfacción percibida por el cliente o usuario en cada iteración. Este campo determinará junto con el tiempo, el orden con el que las historias de usuario van a ser implementadas.
- Dependencias: una historia de usuario no debería ser dependiente de otra historia, pero en ocasiones es necesario mantener la relación. En este campo se indicarían los identificadores de otras historias de las que depende.
- Pruebas de aceptación: pruebas consensuadas entre el cliente o usuario y el equipo que el código debe superar para dar como finalizada la implementación de la historia de usuario. Este campo también se suele denominar “criterios o condiciones de aceptación”.
Si bien las historias de usuario son lo suficientemente flexibles como para describir la funcionalidad de la mayoría de los sistemas, no son apropiadas para todo. Si por cualquier razón, se necesita expresar alguna necesidad de una manera diferente a una historia de usuario, se recomienda que se haga. Por ejemplo, las interfaces de usuario se suelen describir en documentos con muchos pantallas (aplicaciones Moockups, ). Al igual puede ocurrir con documentos especificaciones de seguridad, normativas o similares.
No obstante, lo que sí es importante con esta documentación adicional es mantener la trazabilidad con las historias de usuario. Por ejemplo, a través de hojas de cálculo donde se lleve el control de a qué historia pertenece cada documento adicional, o especificando el identificador de la historia en algún apartado del documento.
Conoce nuestro Master en Dirección del Capital Humano (ceupe.cl)
Comentarios