¿La historia de usuario es compatible con el caso de uso?

Buscando en internet, los sabios del Agile consideran que los casos de uso y las historias de usuario son dos cosas diferentes:

• Mike Cohn:Las historias de usuario no son casos de uso
• Alistair Cockburn:Una historia de usuario es para un caso de uso como una gacela para un mirador
• Extreme Programming.org:Las historias de usuario cumplen el mismo propósito que los casos de uso, pero no son iguales.

El enfoque centrado en casos de uso fue una de las técnicas más populares para capturar requisitos, y algunas personas ahora lo consideran una técnica anticuada, de estilo antiguo, asociada con muchos problemas que hacen que tu equipo NO sea “ágil” debido a los problemas propios de los casos de uso:

• Requisitos previos: tratar de definir en detalle todos los aspectos de lo previo resultará en mucho esfuerzo y tiempo desperdiciados, ya que gran parte del trabajo tendrá que repetirse.
• Descomposición funcional: la naturaleza funcional de los casos de uso conduce naturalmente a la descomposición funcional de un sistema en casos de uso concretos y abstractos relacionados mediante asociaciones de extensión e inclusión de casos de uso.

Si buscas en internet con las palabras clave “caso de uso frente a historia de usuario”, encontrarás una larga lista de artículos que sugieren los inconvenientes, problemas o trampas del enfoque de casos de uso, mientras que hay incluso una lista más larga de beneficios relacionados con las historias de usuario. Interesante, las cosas cambian tan rápidamente en la industria de la tecnología, y aún más rápido para las personas que pasan de lo que antes era “moda” a lo que ahora es la “nueva moda”.

Curiosamente, algunas personas les gusta percibir las cosas en un patrón binario y perseguir cosas de moda asociándose simbólicamente con ellas en lugar de practicarlas genuinamente. Algunas personas ni siquiera quieren que otros sepan que aún usan casos de uso, o podrían considerarse anticuados y de estilo antiguo.

Ahora algunas personas colocan un signo de igualdad relacionado con la historia de usuario y el caso de uso:

• Ágil = historia de usuario o Ágil = historia de usuario + Scrum
• Historia de usuario = justo lo suficiente y justo a tiempo
• Historia de usuario = cumplir con las expectativas del usuario y satisfacer
• Caso de uso = captura detallada de requisitos previos
• Caso de uso = <<incluye>> + <<extiende>> = descomposición funcional
• El caso de uso es solo estilo “entrada del usuario” -> “respuesta del sistema”
• Caso de uso = estilo antiguo y obsoleto

Como proveedor de herramientas, somos bastante neutrales en métodos, herramientas y técnicas. Personalmente, quiero enfatizar claramente que soy un gran aficionado al desarrollo ágil, las historias de usuario y el proceso Scrum. En particular, los principios fundamentales y las mejores prácticas relacionadas con conceptos como:

• Descubrimiento de requisitos en lugar de entrega de requisitos
• Bajo el principio anterior que da lugar a dos propiedades importantes en el proceso de desarrollo ágil
  • Justo a tiempo
  • Justo lo suficiente

(Escribiré más publicaciones relacionadas con los principios anteriores con mis propias opiniones, que están estrechamente relacionadas con mi área de investigación de doctorado entre 1992 y 1995 – metamodelos y transformaciones de esquemas)

Ahora, volvamos al tema “caso de uso frente a historia de usuario”. Bueno, los sabios del Agile de peso ya han emitido su voto al respecto, ¿seré tan terco tratando de anular sus “votos” argumentando que son similares o incluso iguales?

Déjame mostrarte un ejemplo para ilustrar si la historia de usuario es “tan diferente” del caso de uso:

Ejemplo

Las historias de usuario buenas son mucho más que simples declaraciones. Una historia de usuario estándar consta de tres partes, comúnmente conocidas como las tres C.

La primera “C” de cada historia de usuario debe seguir el formato estandarizado de:

Como [rol], quiero [hacer algo], para que [beneficios]

que es el contenido mínimo de una historia de usuario para ser colocada en la tarjeta.

Las conversaciones son el contenido de la segunda “C” de una historia de usuario, que representan la discusión entre los usuarios finales, el propietario del proyecto y el equipo de desarrollo. En estas conversaciones, se registra la discusión verbal o muchos otros datos útiles, como correos electrónicos, prototipos o cualquier otro contenido relacionado con el proyecto.

La última “C” de una historia de usuario es la confirmación, que son los criterios de aceptación utilizados para confirmar que la historia de usuario se ha implementado correctamente y se ha entregado con éxito.

Déjame explicar un poco más sobre cómo desarrollar la parte de confirmación de una historia de usuario. Aquí utilizamos la plantilla más conocida llamada Gherkin, que adopta la fórmula Dado-Cuando-Entonces para guiar la redacción de pruebas de aceptación para una historia de usuario:

• (Dado.. y) algún contexto
• (Cuando.. y) se realiza alguna acción
• (Entonces.. y) Realizar algunas acciones

Herramientas como Cucumber y los marcos de pruebas Jbehave fomentan el uso de la plantilla Dado-Cuando-Entonces para realizar pruebas automatizadas, aunque también puede usarse puramente como una heurística, independientemente de si se utiliza alguna herramienta.

Reunamos toda la información para la historia de usuario “registrar curso” y coloquemos en formato 3C:

Adopté el formato 3 C comúnmente utilizado para representar la historia de usuario “registrar curso”. Asimismo, también adopté el formato más ampliamente utilizado para describir el mismo caso de uso “registrar curso”, elaborado mediante una descripción de caso de uso. Numeré los pasos de la sección de confirmación (la última C) de la historia de usuario, que están asociados con el número de paso que coloqué en la descripción del caso de uso. Son los mismos “nueve pasos” del escenario que se colocan en cada enfoque, aunque con un orden diferente. Creo que ambas representaciones de modelos son aceptables para sus respectivos sabios y seguidores. Entonces, la pregunta nuevamente es: ¿la historia de usuario es muy similar al caso de uso, y sin embargo son diferentes, o es el orden de los pasos el que genera toda clase de críticas hacia el enfoque de casos de uso?

Semanticamente equivalentes con significados diferentes?

Investiguemos si hay un caso similar en el dominio de modelado, para compararlo con esta situación, o podría ayudarnos a emitir nuestro propio voto sobre “historia de usuario frente a casos de uso”, sin seguir ciegamente a la multitud ni repetir como un loro lo que dijeron los sabios.

Ejemplo: Semanticamente equivalentes

En UML podemos describir un escenario de caso de uso con un diagrama de secuencia, pero generalmente no usamos un diagrama de colaboración para el mismo propósito; aunque ambos diagramas son semanticamente equivalentes. En otras palabras, tanto el diagrama de secuencia como el diagrama de colaboración tienen el mismo número de objetos participando en un escenario con el mismo número de mensajes que circulan alrededor del mismo conjunto de objetos para realizar una tarea de un escenario. Sin embargo, el primero se centra en el tiempo y el segundo en el espacio. El diagrama de secuencia es más intuitivo al usarlo con modelado de escenarios, mientras que el diagrama de colaboración es adecuado para modelar relaciones estructurales entre objetos. Por ejemplo, si desea representar de forma estructural el escenario de los objetos participantes en un marco MVC (capas de modelo/vista y control).

Personalmente, no creo que usar historias de usuario haga que mi equipo se vuelva ágil, ni que los casos de uso hagan que mi equipo sea “prematuramente enfocado”. Lo más importante es cómo aplicamos y usamos estas herramientas con qué tipo de mentalidad y mejores prácticas detrás. No me preocupa demasiado que la gente me considere “de estilo antiguo” o anticuado cuando en realidad actúo de forma ágil.

Aún recuerdo en los días del análisis y diseño estructurado, quizás podríamos usar el Tipo de Datos Abstracto en ADA para aplicar los principios de análisis y diseño orientados a objetos sin tener el soporte de la POO en 198x, ¿verdad? Desafortunadamente, es posible que ni siquiera te encuentres con los conceptos del Tipo de Datos Abstracto en absoluto. ¡Oh! Dios mío, accidentalmente lo he revelado – ¿soy viejo? O, debería pensar positivamente – ¿experimentado?