Saltar al contenido

Historias de usuario vs casos de uso

Ten en cuenta que en la informática un problema puede tener diversas soluciones, pero nosotros te mostraremos lo mejor y más eficiente.

Solución:

En realidad, los casos de uso originales (ver OOSE de Jacobson) eran bastante ligeros, como lo son ahora las historias de usuarios. Con el tiempo, evolucionaron hasta que un formato común para “casos de uso” ahora es un documento complicado con entradas, salidas, herencia, relaciones de uso, pseudocódigo, etc. Los programadores, en general, intentan convertir todo en programación.

En cualquier caso, el intento de definir qué distingue un “caso de uso” de una “historia de usuario” de un “escenario” es bastante inútil, ya que es difícil encontrar dos autoridades que estén de acuerdo.

Personalmente, encuentro el patrón “[Actor] [verbs] [noun] Llegar [business value]”útil. Si supera un párrafo de texto, puede que sea demasiado grande.

Cuando se trata de eso, “ágil” es solo una etiqueta, y las personas no están de acuerdo sobre lo que significa exactamente. De manera similar, la gente llama a cosas muy diferentes “casos de uso”.

En mi experiencia, la principal diferencia entre los dos es que una historia de usuario se centra en el usuario y, por lo general, es más corta y menos formal; idealmente, debería caber fácilmente en una postal. Probablemente no da detalles de manejo de errores etc

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 dentro del mismo caso de uso.

Sin embargo, esa es solo mi experiencia: es probable que todos hayan usado estas herramientas de diferentes maneras. No me obsesionaría demasiado con las etiquetas, solo use lo que funcione para su proyecto.

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 tratan de cubrir absolutamente todo lo que tiene que ver 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 sencilla plantilla)

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:

  1. para esas historias que se implementan en un sprint mucho más tarde, puede describir el comportamiento de una manera de alto nivel, por ejemplo, como miembro del equipo de operaciones, quiero monitorear el sistema de forma remota para poder determinar el estado del sistema mientras estoy en el camino.
  2. para aquellas historias que se implementarán 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 inicio de sesión exclusivo de operaciones para poder verificar el estado del sistema.
  3. para aquellas historias que se implementan en el sprint actual, puede describir el comportamiento de 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 de ingesta.

¡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

salud,

Robar

valoraciones y comentarios

Si crees que te ha sido de ayuda este artículo, sería de mucha ayuda si lo compartes con otros juniors de esta manera contrubuyes a extender nuestra información.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *