¿Los casos de uso son solo historias de usuarios múltiples?Historias de usuarios vs casos de uso
¿Cuáles son los beneficios de usar historias de usuario sobre casos de uso ... y viceversa ... cuándo usar una sobre otra ... ¿Todas las metodologías ágiles usan historias de usuario?
En realidad, los casos de uso originales (véase Jacobson's OOSE) eran bastante ligeros, al igual que las historias de los usuarios son ahora. Con el tiempo, evolucionaron hasta que un formato común para "casos de uso" ahora es un documento complicado con entradas, salidas, herencia, usa relaciones, pseudocódigo, etc. Los programadores, en general, intentan convertir todo en programación.
En cualquier caso, el intento de lo definido distingue a un "caso de uso" de una "historia de usuario" lado a otro un "escenario" es bastante inútil, ya que es difícil encontrar dos autoridades que están de acuerdo. \
Personalmente , Me parece útil el patrón "[Actor] [verbos] [sustantivo] para obtener [valor comercial]".Si supera un párrafo de texto, puede ser demasiado grande.
Cuando se trata de hacerlo, "ágil" es solo una etiqueta y la gente no está de acuerdo con lo que significa exactamente. Del mismo modo, las personas llaman a cosas muy diferentes "casos de uso".
En mi experiencia, la principal diferencia entre los dos es que la historia del usuario se centra en el usuario, y suele ser más corta y menos formal; idealmente, debería caber fácilmente en una postal. Probablemente no brinde detalles sobre el manejo de errores, etc.
casos de uso pueden ser mucho más formales (aunque algunas personas también los escriben informalmente) - se enfocan en cada interacción con el sistema, y pueden entrar en más detalles sobre varios sistemas/actores/etc. diferentes en el mismo caso de uso.
Sin embargo, esa es solo mi experiencia: es probable que todos hayan utilizado estas herramientas de diferentes maneras. No me preocuparían demasiado por las etiquetas, solo use lo que funciona para su proyecto.
La gente no está de acuerdo porque no sabe lo suficiente sobre la filosofía ágil. –
Puede pensar en un caso de uso como una historia de usuario, pero no al revés. Un caso de uso cubrirá múltiples "finales" de la historia, requisitos especiales (por ejemplo, los campos de formulario deben ingresarse en formato xyz y mostrar el mensaje de error 123 si el usuario ingresa un campo en el formato incorrecto). Además, un uso puede incluir referencias adicionales a documentos externos, como las pautas de seguridad.
Estoy de acuerdo, mira si te gusta mi envoltorio basado en el tuyo – pabloelustondo
En una palabra, no.
Los casos de uso suelen ser especificaciones detalladas que describen cómo funcionará una determinada función en particular, o cómo un usuario específico va a utilizar el sistema. Por lo general, está en la voz de un usuario específico (o Actor) y es bastante autónomo.
Una historia de usuario, por otro lado, es "una invitación a la discusión". Por lo general, es una o dos oraciones. Here es un buen recurso para eso. Y el User Stories Applied de Mike Cohn bien vale la pena.
La sintaxis típica es "Como usuario <> Necesito < funcionalidad> para lograr < valor de negocio>", o "Para lograr < valor de negocio> como usuario <> Necesito < funcionalidad>", que lleva a casa el valor de la historia
Las historias de usuario son no pensadas para ser independientes, pero con la intención de invitar a la discusión de la historia entre el desarrollador y el cliente (o el proxy del cliente).
Los casos de uso no son compilaciones de historias de usuarios.
Las historias de usuarios son generalmente mucho más simples que los casos de uso. Creo que los casos de uso intentan cubrir absolutamente todo lo relacionado con el comportamiento de algún aspecto del sistema. Es decir, todos los comportamientos, todas las rutas de error y todo el manejo de excepciones.
La plantilla recomendada para un usuario es:
Como (papel) Quiero (algo) de manera que (beneficio)
(Gracias Mike Cohn por proporcionar esta plantilla simple)
Las descripciones de comportamiento como este son más ágiles.
Este tipo de plantilla le permite describir el comportamiento utilizando diferentes niveles de detalle. Por ejemplo:
EN MI CASO ¡Las fundas de uso están mucho más talladas en piedra! Y, por lo tanto, puede ser un problema actualizar después de la versión inicial.
HTH
aplausos,
Rob
Estoy de acuerdo con la mayoría de las respuestas en esta página, especialmente la de Elie, pero aún así creo que vale la pena para envolver en marcha la idea .
Por lo tanto, un Caso de uso es un UserStory compuesto, probablemente, por un conjunto de historias de usuario interconectadas, que ofrece valor comercial para el usuario.
Permítanme explicarme: la diferencia clave es el "beneficio comercial relevante". el resultado.
Por ejemplo, un caso de uso para am ATM puede ser "el usuario usa ATM para obtener algo de dinero en efectivo". Hay un usuario, un sistema y un caso de uso claro con el resultado. Ahora, si estamos desarrollando un cajero automático en un equipo ágil, probablemente tendremos una historia de "usuarios que inicien sesión en el cajero automático". Por lo tanto, una historia de usuario puede ser un conjunto "interesante" de acciones comprobables y relevantes que un usuario hace cuando interactúa con un sistema pero sin un resultado claro. Nadie "inicia sesión" en un sistema solo por diversión. No hay beneficio en hacer eso. En un diagrama de caso de uso de UML tal vez todavía tengamos un caso de uso para eso ... tal vez usando una relación de "inclusión" ... pero creo que será un estrépito para el diagrama de casos de uso. Entonces, como dice Elie, un caso de uso es una historia de usuario con resultado, con un propósito.Y, por lo tanto, esta es la forma en que desea que sea "Drive Case Case" y no "conducido por User Story". Porque, tal vez la mejor manera de implementar una historia de usuario sin resultado es eliminarlo de su sistema :). Si el cajero automático puede mirarme a la cara y dejarme entrar sin que escriba la contraseña que puede ser excelente.
Quiero enfatizar que el "valor comercial" es una parte muy importante, ya que puede ayudar con la estimación y también con la prueba de aceptación de producción. –