En las metodologías ágiles la descripción de las necesidades se realiza a partir de las historias de usuario (user story) 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 (M. Cohn, 2004)
El concepto de historia de usuario tiene sus raíces en la metodología “eXtremeProgramming” o programación extrema. Esta metodología fue creada por Kent Beck y descrita por primera vez en 1999 en su libro “eXtreme Programming Explained”. No obstante, las historias de usuario se adaptan de manera apropiada a la mayoría de las metodologías ágiles, teniendo por ejemplo, un papel muy importante en la metodología Scrum.
Las historias de usuario son una forma rápida de administrar los requisitos de los usuarios sin tener que elaborar gran cantidad de documentos formales y sin requerir de mucho tiempo para administrarlos. Las historias de usuario permiten responder rápidamente a los requisitos cambiantes.
Qué información contiene una historia de usuario
Aunque dependiendo del proyecto se podría incluir cualquier otro campo que proporciona se información útil, en este apartado se describen 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:
De esta manera, una historia de usuario está compuesta por los siguientes elementos:
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) 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".
Cohn en (M. Cohn, 2004) comenta que 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, recomienda que se haga. Por ejemplo, las interfaces de usuario se suelen describir en documentos con muchos pantallazos. Al igual puede ocurrir con documentos especificaciones de seguridad, normativas, etc.
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, etc.
¿Las historias de usuario equivalen a requisitos funcionales?
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 pósit 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 Java” 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 correctoya 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. 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, convenciones de codificación a seguir, etc.
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 (manifiesto ágil, ver lección 1) por lo que no se deben sobrecargar de información. Sin embargo, la realidad de los proyectos y de los negocios es otra y hace que la teoría se deba ajustar a la práctica, por lo que se pueden dar varias soluciones para reflejar toda esa información que en un primer momento parece que no cuadra en las historias de usuario:
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, como comenta Cockburn (A. Cockburn, 2002) [1], 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 quipo debería centrarse en la realización de historias de usuario. Según Cockburn(A. Cockburn, 2008) [2], esto puede producir los siguientes problemas:
En el caso de que se usen las historias de usuario y los casos de uso de manera complementaria, una historia de usuario suele dar lugar a la especificación de varios casos de uso.
¿Las historias de usuario equivalen a requisitos funcionales?
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 pósit 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 Java” 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 correctoya 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. 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, convenciones de codificación a seguir, etc.
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 (manifiesto ágil, ver lección 1) por lo que no se deben sobrecargar de información. Sin embargo, la realidad de los proyectos y de los negocios es otra y hace que la teoría se deba ajustar a la práctica, por lo que se pueden dar varias soluciones para reflejar toda esa información que en un primer momento parece que no cuadra en las historias de usuario:
- Relajar la agilidad usando los tradicionales requisitos en ciclos de vida ágil.
- Usar casos de uso en vez de historias de usuario.
- Utilizar técnicas de trazabilidad para relacionar las historias de usuario con otros documentos: de diseño, normativas, etc.
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, como comenta Cockburn (A. Cockburn, 2002) [1], 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 quipo debería centrarse en la realización de historias de usuario. Según Cockburn(A. Cockburn, 2008) [2], 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.
En el caso de que se usen las historias de usuario y los casos de uso de manera complementaria, una historia de usuario suele dar lugar a la especificación de varios casos de uso.
Para asegurar la calidad de una historia de usuario, Bill Wake describió en 2003 un método llamado INVEST (Wake, 2003). El método se usa para comprobar la calidad de una historia de usuario revisando que cumpla las características descritas a continuación:
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.
Asignar valor a una historia de usuario
Como se comentaba en la introducción del tema, los ítems del Product backlog, deben estar priorizados, es decir, deben tener asignados un valor. Dicho valor es asignado por el Product Owner, y pondera básicamente las siguientes variables:
- Beneficios de implementar una funcionalidad
- Pérdida o coste que demande posponer la implementación de una funcionalidad
- Riesgos de implementarla
- Coherencia con los intereses del negocio
- Valor diferencial con respecto a productos de la competencia
Uno de los aspectos más importantes aquí es que la definición de "valor" para cada cliente puede variar. Por lo tantoes muy recomendable incluir algún tipo de escala cualitativa.
Una manera rápida de empezar a asignar valor a las historias es dividirlas en 3 grupos, según sean imperativas, importantes o prescindibles. Dentro de cada grupo nos resultará más fácil realizar una ordenación relativa por valor numérico y después asignarlo. Todo ello servirá para que en cada iteración entreguemos el producto al cliente maximizando su valor.
Existen otro tipo de ponderaciones, por ejemplo la técnica MoSCoW. Esta técnica fue definida por primera vez en el libro Case Method Fast-Track: A RAD Approach, en el año 2004. Su fin es obtener el entendimiento común entre cliente y el equipo del proyecto sobre la importancia de cada requisito o historia de usuario. La clasificación es la siguiente:
M - MUST. Se debe tener la funcionalidad. En caso de que no exista la solución a construir fallará.
S - SHOULD Se debería tener la funcionalidad. La funcionalidad es importante pero la solución no fallará si no existe.
C - COULD Sería conveniente tener esta funcionalidad. Es en realidad un deseo.
W - WON'T No está en los planes tener esta funcionalidad en este momento. Posteriomente puede pasar a alguno de los estados anteriores.
No hay comentarios:
Publicar un comentario