requirements - usos - historias de usuario y tareas
Historias de usuarios vs casos de uso (6)
¿Los casos de uso son solo historias de usuarios múltiples?
¿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 usuarios?
Cuando se trata de eso, "ágil" es solo una etiqueta, y las personas no están de acuerdo sobre exactamente lo que significa. 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 de un usuario se centra en el usuario, y generalmente es más corta y menos formal; idealmente, debería caber fácilmente en una tarjeta postal. Probablemente no proporcione detalles sobre el manejo de errores, etc.
Los casos de uso pueden ser mucho más formales (aunque algunas personas también los escriben de manera informal): se centran 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 usado estas herramientas de diferentes maneras. No me preocuparían demasiado por las etiquetas, solo use lo que funciona para su proyecto.
En realidad, los casos de uso originales (ver OOSE de Jacobson ) eran bastante livianos, al igual que las historias de los usuarios 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 definir lo que distingue un "caso de uso" de una "historia de usuario" para un "escenario" es bastante inútil, ya que es difícil encontrar dos autoridades que estén de acuerdo.
Personalmente, encuentro útil el patrón "[Actor] [verbos] [sustantivo] para obtener [valor comercial]". Si supera un párrafo de texto, puede ser demasiado grande.
Los casos de uso no son compilaciones de historias de usuarios.
Las historias de usuario 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) para que (beneficio)
(Gracias Mike Cohn por proporcionar esta plantilla simple)
Las descripciones de comportamiento expresadas así son más ágiles.
Este tipo de plantilla le permite describir el comportamiento utilizando diferentes niveles de detalle. Por ejemplo:
- para esas historias que se implementan en un sprint mucho más tarde, se puede describir el comportamiento en un alto nivel, por ejemplo, como miembro del equipo de operaciones, quiero monitorear el sistema de forma remota para poder determinar la salud del sistema mientras viajo.
- para esas historias que se implementan en el próximo sprint, puede describir el comportamiento de una manera un poco más detallada, por ejemplo, como miembro del equipo de operaciones. Quiero tener un solo acceso de operaciones exclusivas para poder verificar el estado del sistema.
- para las historias que se implementan en el sprint actual, puede describir el comportamiento de una manera muy detallada, por ejemplo, como miembro del equipo de operaciones, quiero tener una interfaz web para poder verificar el estado actual del servidor ftp ingest.
¡En mi humilde opinión, los casos de uso están mucho más tallados en piedra! Y, por lo tanto, puede ser un problema actualizar después de la versión inicial.
HTH
aclamaciones,
Robar
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.
En una palabra, no.
Los casos de uso suelen ser especificaciones detalladas que explican cómo funcionará una determinada función, 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. Aquí hay un buen recurso para eso. Y las Historias de usuarios aplicadas de Mike Cohn bien valen 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>", lo que lleva a casa el valor de la historia .
Las historias de los usuarios no están pensadas para ser independientes, sino para invitar a la discusión de la historia entre el desarrollador y el cliente (o el proxy del cliente).
Estoy de acuerdo con la mayoría de las respuestas en esta página, especialmente la de Elie, pero todavía creo que vale la pena resumir la idea.
Por lo tanto, un Caso de uso es un UserStory compuesto, probablemente, por un conjunto de historias de usuario interconectadas, que entrega valor comercial al usuario.
Permítanme explicarme a mí mismo: la diferencia clave es el "beneficio empresarial 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 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 genial.