Metodologías ágiles y gestión del cambio: Introducción y definición (1 de 3)

Aprovechando que ya hace algún tiempo invertí un tiempo en recopilar los conceptos teóricos sobre metodología ágil y propuestas para para la gestión del cambio que os lo publico para que os sirva de referencia.

 

 

Introducción

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. Cada fase de este proceso está separada y no comienza formalmente la siguiente fase hasta que se ha acabado la anterior y se han validado los entregables. Estas metodologías parten de una definición formal de un proyecto que suele estar ligada a una situación contractual entre proveedor y cliente y una ejecución de cada una de las etapas anteriores.

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:

Imagen 1. Historia de usuario

• 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.

Popularmente se asocia el concepto de historia de usuario con el de la especificación de un requisito funcional. De hecho, muchas veces se habla de que a la hora de especificar una necesidad del cliente o del usuario, las metodologías ágiles usan la historia de usuario y las tradicionales, el requisito funcional. Sin embargo, detrás del concepto de historia de usuario hay muchos aspectos que lo diferencian de lo que es una especificación de un requisito, diferencias que muchas veces son poco conocidas y que llevan a muchos equipos a dudas y confusiones.

Una historia de usuario describe funcionalidad que será útil para el usuario y/o cliente de un sistema software. Y aunque normalmente las historias de usuario asociadas a las metodologías ágiles, suelen escribirse en pos-it o tarjetas, son mucho más que eso. Como se ha comentado anteriormente, una historia no es sólo una descripción de una funcionalidad, sino también es de vital importancia la conversación que conllevan.

Las historias de usuario, frente a mostrar el “cómo”, sólo dicen el “qué”.  Es decir, muestran funcionalidad que será desarrollada, pero no cómo se desarrollará. De ahí que aspectos como que “el software se escribirá en X lenguaje” no deben estar contenidos en una historia de usuario.

De esta manera, equiparar las historias de usuario con las especificaciones de requisitos no es demasiado correcto ya que por definición, las historias de usuario no deben tener el nivel de detalle que suele tener la especificación de un requisito.

Una historia de usuario debería ser pequeña, memorizable, y que pudiera ser desarrollada por un par de programadores en una semana (o adaptaremos el tiempo al proyecto). Debido a su brevedad, es imposible que una historia de usuario contenga toda la información necesaria para desarrollarla, en tan reducido espacio no se pueden describir aspectos del diseño, de las pruebas, normativas o convenciones de codificación a seguir.

Para resolver el anterior problema hay que entender que el objetivo de las historias de usuario es, entre otros, lograr la interacción entre el equipo y el cliente o el usuario por encima de documentar (ver manifiesto ágil) por lo que no se deben sobrecargar de información.

Otro concepto que suele crear confusión sobre las historias de usuario son los casos de uso. Aunque hay quien ha logrado incluir casos de uso en su proceso ágil, no quiere decir que las historias de usuario sean equivalentes a los casos de uso. Realmente, las historias de usuario están más cerca de la captura de requisitos (aquella fase que sirve para extraer las necesidades del usuario).

Básicamente, si decíamos que una historia de usuario es el “qué” quiere el usuario, el caso de uso es un “cómo” lo quiere.

Generalmente, cuando un proyecto comience a seguir una metodología ágil, se deberían olvidar completamente los casos de uso y el equipo debería centrarse en la realización de historias de usuario. Esto puede producir los siguientes problemas:

• Las historias de usuario no proporcionan a los diseñadores un contexto desde el que trabajar. Pueden no tener claro cuál es el objetivo en cada momento. ¿Cuándo le surgiría al cliente o usuario esta necesidad?
• Las historias de usuario no proporcionan al equipo de trabajo ningún sentido de completitud. Se puede dar el caso que el número de historias de usuario no deje de aumentar, lo que puede provocar desmotivación en el equipo. Realmente, ¿cómo de grande es el proyecto?
• Las historias de usuario no son un buen mecanismo para evaluar la dificultad del trabajo que está aún por llegar.

Por tanto, si en un proyecto ocurre alguno de estos problemas se puede barajar la posibilidad (relajando la agilidad) de complementar las necesidades descritas en las historias de usuario con casos de uso donde quede reflejado el comportamiento necesario para cumplir dichas necesidades.

Las características descritas en la a continuación, serían las adecuadas para medir la calidad de una historia de usuario (según el método INVEST):

• Independient (independiente): es importante que cada historia de usuario pueda ser planificada e implementada en cualquier orden. Para ello deberían ser totalmente independientes (lo cual facilita el trabajo posterior del equipo). Las dependencias entre historias de usuario pueden reducirse combinándolas en una o dividiéndolas de manera diferente.
• Negotiable (negociable): una historia de usuario es una descripción corta de una necesidad que no incluye detalles. Las historias deben ser negociables ya que sus detalles serán acordados por el cliente/usuario y el equipo durante la fase de “conversación”. Por tanto, se debe evitar una historia de usuario con demasiados detalles porque limitaría la conversación acerca de la misma.
• Valuable (valiosa): una historia de usuario tiene que ser valiosa para el cliente o el usuario. Una manera de hacer una historia valiosa para el cliente o el usuario es que la escriba el mismo.
• Estimable (estimable): una buena historia de usuario debe ser estimada con la precisión suficiente para ayudar al cliente o usuario a priorizar y planificar su implementación. La estimación generalmente será realizada por el equipo de trabajo y está directamente relacionada con el tamaño de la historia de usuario (una historia de usuario de gran tamaño es más difícil de estimar) y con el conocimiento del equipo de la necesidad expresada (en el caso de falta de conocimiento, serán necesarias mas fases de conversación acerca de la misma).
• Small (pequeña): las historias de usuario deberían englobar como mucho unas pocas semanas/persona de trabajo. Incluso hay equipos que las restringen a días/persona. Una descripción corta ayuda a disminuir el tamaño de una historia de usuario, facilitando su estimación.
• Testable (comprobable): la historia de usuario debería ser capaz de ser probada (fase “confirmación” de la historia de usuario). Si el cliente o usuario no sabe como probar la historia de usuario significa que no es del todo clara o que no es valiosa. Si el equipo no puede probar una historia de usuario nunca sabrá si la ha terminado o no.

Bibliografía

Roberto Canales Mora. Informática profesional. Ed. Starbook. Roberto Canales Mora

Agilidad y Lean. Gestionando los proyectos y negocios del s. XXI. Javier Garzás, Miriadax