Al buscar en Google en la web, Agile Sages considera que los casos de uso y las historias de usuarios 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 lo que una gacela es para una glorieta
- Extreme Programming.org: Las historias de usuario tienen el mismo propósito que los casos de uso, pero no son lo mismo.
El enfoque basado en casos de uso fue una de las técnicas más populares para la captura de requisitos y algunas personas ahora consideran que es un tipo de técnica obsoleta y de estilo antiguo que se asocia con muchos problemas que causan que su equipo NO sea “ágil” debido a los problemas de caso de uso :
- Requisito inicial: tratar de definir los detalles de todos los aspectos del inicio resultará en una gran cantidad de tiempo y esfuerzo desperdiciados, ya que será necesario volver a hacer gran parte del trabajo.
- Descomposición funcional: la naturaleza funcional de los casos de uso conduce naturalmente a la descomposición funcional de un sistema en términos de casos de uso concretos y abstractos que están relacionados por extensión e incluyen asociaciones de casos de uso.
Si busca en la web con las palabras clave “caso de uso vs historia de usuario”, encontrará una larga lista de artículos que sugieren los inconvenientes, problemas o trampas del enfoque de caso de uso, mientras que hay una lista aún más larga de los beneficios relacionados con la historia de usuario. . Interesante, las cosas cambian tan rápido en la industria de TI, e incluso más rápido para las personas que cambian de las cosas que solían ser “de moda” en el pasado a las cosas “más modernas” de ahora.
Curiosamente, a algunas personas les gusta percibir las cosas en un patrón binario y buscan cosas de moda asociándose con ellas simbólicamente en lugar de practicarlas genuinamente. Algunas personas incluso no quieren que otras personas sepan que todavía están usando casos de uso, o podrían considerarse obsoletos y anticuados.
Ahora, algunas personas ponen un signo igual relacionado con la historia del usuario y el caso del usuario:
- Agile = historia de usuario o Agile = historia de usuario + Scrum
- Historia de usuario = justo lo suficiente y justo a tiempo
- Historia de usuario = cumplir con las expectativas del usuario y satisfactoria
- Caso de uso = Captura detallada de requisitos por adelantado
- Caso de uso = <<incluye>> + <<extiende>> = descomposición funcional
- El caso de uso es “entrada de usuario” -> “respuesta del sistema” solo estilo
- Caso de uso = estilo antiguo y obsoleto
Como proveedor de herramientas, somos bastante neutrales en cuanto a métodos, herramientas y técnicas. Personalmente, quiero dejar claro que soy un gran fanático del desarrollo ágil, la historia de usuario y el proceso scrum. En particular, los principios subyacentes y las mejores prácticas relacionadas con conceptos tales como:
- Descubrimiento de requisitos en lugar de entrega de requisitos
- Bajo el principio anterior, eso produce dos propiedades importantes en el proceso de desarrollo ágil
- Justo a tiempo
- Sólo 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 en 1992-1995: transformaciones de metamodelos y esquemas)
Ahora, volvamos a los temas “caso de uso vs historia de usuario”. Bueno, los sabios ágiles de peso pesado ya votaron por eso, ¿soy tan terco tratando de anular sus “votos argumentando que son similares o incluso iguales?
Permítanme mostrarles un ejemplo para ilustrar si la historia del usuario es “tan diferente” del caso del usuario:
Ejemplo
Las buenas historias de usuarios 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 [papel], quiero [hacer algo], para que [beneficios]
que es el contenido mínimo de una historia de usuario que se debe incluir en la tarjeta.
Las conversaciones son el contenido de la segunda “C” de una historia de usuario que representa la discusión entre los usuarios finales, el propietario del proyecto y el equipo de desarrollo. En estas conversiones, registra la discusión verbal o mucha otra información útil, como correos electrónicos, esquemas o cualquier otro contenido relacionado para el proyecto.
La “C” final de una historia de usuario es la confirmación, que es el criterio de aceptación utilizado para confirmar que la historia de usuario se implementó, corrigió y entregó con éxito.
Permítanme elaborar un poco más sobre cómo desarrollar la parte de confirmación de una historia de usuario. Aquí usamos la plantilla más conocida llamada Gherkin, que adopta la fórmula Dado-Cuándo-Entonces para guiar la redacción de pruebas de aceptación para una Historia de usuario:
- (Dado.. y) algo de contexto
- (Cuando.. y) se lleva a cabo alguna acción
- (Entonces… y) Realizar algunas acciones
Las herramientas como los marcos de prueba Cucumber y Jbehave fomentan el uso de la plantilla Dado/Cuándo/Entonces para realizar pruebas automatizadas, aunque también se puede usar puramente como una heurística, independientemente de si se usa una herramienta.
Reunamos toda la información para la historia de usuario de “registrarse en el curso” y pongámosla en el formato 3Cs:
Adopté el formato de las 3 C comúnmente utilizado para representar la historia de usuario de “registrarse en el curso”. Asimismo, también adopté el formato más utilizado para describir para el mismo caso de uso “registrarse en el curso” elaborado por una descripción de caso de uso. Numé los pasos de la sección de confirmación (la última C) de la historia de usuario que está asociada con el número de paso que puse en la descripción del caso de uso. Son los mismos “nueve pasos” del escenario a colocar en cada una de las aproximaciones con distinto orden. Creo que la representación de ambos modelos es aceptable para sus correspondientes sabios y seguidores. Entonces, la pregunta nuevamente, ¿la historia del usuario es muy similar al caso del usuario y, sin embargo, son diferentes o el orden de los pasos causa todo tipo de críticas por el enfoque del caso de uso?
¿Semánticamente equivalente con diferente significado?
Investiguemos si hay un caso similar en el dominio del modelado, de modo que comparemos con la situación aquí, o podría ayudarnos a emitir nuestro propio voto sobre “historia de usuario versus casos de uso”, pero no seguir ciegamente a la multitud o repetir lo que el los sabios dijeron como una charla de loros.
Ejemplo: semánticamente equivalente
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; incluso a través de ambos diagramas son semánticamente equivalentes. En otras palabras, tanto el diagrama de secuencia como el diagrama de colaboración tienen la misma cantidad de objetos que participan en un escenario con la misma cantidad de mensajes que pasan por el mismo conjunto de objetos para realizar una tarea de un escenario. Sin embargo, el primero es el enfoque temporal y el segundo es el enfoque espacial. El diagrama de secuencia es más intuitivo cuando se usa con el modelado de escenarios, mientras que el diagrama de colaboración es apropiado para modelar relaciones estructurales entre objetos. es decir, desea representar el escenario del objeto participado estructuralmente en el marco MVC (modelo/vista y capas de control).
Personalmente, no creo que el uso de la historia de usuario haga que mi equipo se vuelva ágil, y el caso de uso hará que mi equipo sea “sincero”. Lo más importante es cómo aplicamos y usamos esas 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.
Todavía recuerdo en los días de diseño y análisis estructurado, tal vez podamos usar Abstract Data Type en ADA para aplicar los principios de diseño y análisis orientado a objetos sin tener el soporte de OOP en 198x, ¿verdad? Desafortunadamente, es posible que ni siquiera te encuentres con los conceptos del tipo de datos abstracto. ¡Oh! Dios mío, accidentalmente revelo: ¿soy viejo? O, debería pensar en positivo, ¿experimentado?
¿Qué piensas? ¿Cuál es tu voto sobre esto? Avísame o corrígeme si me equivoco.
