En este artículo exploramos los resultados del uso de la herramienta de análisis de historias de usuario, ScopeMaster en un conjunto de ejemplos de historias de usuarios (acceda a los originales aquí). Las historias que hemos utilizado fueron publicadas por Mike Cohn en el sitio web de Mountain Goat y describen las funciones de un sitio web interactivo que se va a construir.

Ejemplos de historias de usuarios: analizadas por ScopeMaster

Acerca de las historias de usuarios de ejemplo

Hemos elegido estas historias de usuarios de ejemplo porque están disponibles gratuitamente y están publicadas por un conocido autor de libros sobre el tema de la redacción de historias de usuarios de software. Son ejemplos que cualquiera puede descargar. (El PDF en realidad contiene ejemplos de tres proyectos diferentes). Para este ejercicio acabamos de ver las historias de los Sitio web de ScrumAlliance .  Descargue el CSV con las historias de usuario de ejemplo

El objetivo del ejercicio es explorar lo que ScopeMaster puede revelar sobre un conjunto típico de historias de usuarios.

Preparación

Paso 1. Convierte el PDF a CSV

El documento PDF contiene una lista con viñetas de historias de usuarios. Para preparar la lista para la importación, primero copiamos cada historia de usuario en una fila de una hoja de cálculo. Luego, la hoja de cálculo se guardó como CSV lista para importar a ScopeMaster. ¡Esta fue la parte que llevó más tiempo de todo el ejercicio! Afortunadamente, la mayoría de las historias de usuarios de hoy en día están contenidas en una estructura que se puede formatear fácilmente como un archivo CSV, por lo que normalmente se evitaría este paso.

En total son 98 historias de usuarios. Aprovechamos la oportunidad para generar una identificación de referencia única para cada uno antes de importarlos. Puedes reutilizar el csv que creamos si lo deseas, aquí: Historias de usuario de ejemplo originales de Mountain Goat – ScrumAlliance CSV

Paso 2. Importar a ScopeMaster

Luego creamos un nuevo proyecto en ScopeMaster y seleccionamos la opción "importar CSV".

Diagrama de modelo de caso de uso a partir de un conjunto de historias de usuario de ejemplo

Recomendamos separar la parte funcional de la historia del usuario del texto de beneficios, por lo que le pedimos a la importación de ScopeMaster que lo hiciera por nosotros.

Paso 3. Analizar todo

Luego iniciamos el análisis automatizado. Con solo presionar el botón verde.

Diagrama de modelo de caso de uso a partir de un conjunto de historias de usuario de ejemplo

Aquí es donde ocurre la magia. El motor de análisis de ScopeMaster trabaja en cada historia de usuario por turno, la interpreta, analiza, prueba, dimensiona y compara.

en tan solo menos de 3 minutos, ScopeMaster analizó cada palabra de las 98 historias de usuarios y realizó casi 112.000 pruebas.

Diagrama de modelo de caso de uso a partir de un conjunto de historias de usuario de ejemplo
ScopeMaster analizó todo el trabajo pendiente de 98 historias de usuarios en menos de 3 minutos

Resultados

Ahora echemos un vistazo a lo que ScopeMaster nos dice sobre estas historias de usuarios.

Cada historia de usuario: interpretada, probada y dimensionada (si es posible)

  • ScopeMaster examinó cada palabra de cada historia de usuario para determinar si puede establecer una intención funcional clara. ¿Está limpio?
  • Si es así, ScopeMaster determinó quién es el usuario y qué quieren/necesitan lograr. es decir. ¿Está orientado al usuario y es funcional?
  • A partir de la intención funcional determinada anteriormente, ScopeMaster estimó el tamaño funcional en los puntos de función COSMIC de los estándares ISO. ¿Cual es el tamaño?

Información sobre las historias de usuarios de ejemplo

El diagrama del modelo de casos de uso se generó a partir de la interpretación de el conjunto de historias de usuario. Este diagrama revela instantáneamente información sobre muchos aspectos de calidad del conjunto de historias de usuarios que simplemente no son visibles en repositorios de requisitos como Trello, Jira y Azure DevOP. Este diagrama revela la relación lógica entre historias de usuarios. ¿Este diagrama le ayuda a determinar si tiene los requisitos correctos?

Diagrama de modelo de caso de uso a partir de un conjunto de historias de usuario de ejemplo
La interpretación funcional del conjunto de historias de usuarios es muy reveladora y se mantiene dinámicamente.

De las historias de usuarios al modelo de datos

A partir de las intenciones funcionales determinadas por ScopeMaster, se determina un diagrama de clases sugerido de todas las clases probables y sus métodos a partir del texto de las historias de usuario.Esto puede ayudar a los desarrolladores a comprender qué datos deben considerar y cómo se pueden almacenar y manejar. Este no es un diagrama de clases definitivo, pero sí un punto de partida muy útil.  ¿Este diagrama ayuda a determinar cómo organizar y estructurar los datos para cumplir con los requisitos?

Diagrama de clases - automatizado
Clases y métodos autosugeridos a partir del conjunto de historias de usuarios.

Pruebas generadas directamente a partir de historias de usuarios

Pseudocódigo de ejemplo para escenarios de prueba, generado a partir del texto de la historia del usuario

Determinar el tamaño del trabajo pendiente

Para todos los equipos, todos los proyectos, las historias de usuarios varían en tamaño y el esfuerzo para entregarlas. Esta variabilidad puede ser muy alta. ScopeMaster fue diseñado desde el principio para automatizar el dimensionamiento funcional de los requisitos de software escrito. Esto significa que fue diseñado para eliminar o reducir el trabajo administrativo de los requisitos de lectura para determinar una estimación formal del tamaño funcional del software que describen. El tamaño funcional es un indicador de magnitud independiente de la tecnología y orientado al usuario. ScopeMaster estima el tamaño funcional en los dos estándares ISO principales para el software de dimensionamiento, a saber Puntos de Función CÓSMICA y IFPUG Puntos de función. Recomendamos el primero porque se adapta mejor a las arquitecturas de software modernas y maneja mejor los requisitos incompletos. ScopeMaster estima la funcionalidad tamaño de todas las historias de todo su trabajo pendiente en cuestión de minutos, evitando que el equipo pierda tiempo en discusiones sin valor sobre puntos de la historia o tallas de camisetas.

Dimensionamiento automatizado de un conjunto de historias de usuarios.
ScopeMaster dimensiona automáticamente las historias de usuario en puntos de función COSMIC estandarizados

Análisis de calidad

En poco menos de 3 minutos, ScopeMaster identificó cientos de problemas con las historias de los usuarios.

Historias de usuario de ejemplo de Mike Cohn analizadas y probadas por ScopeMaster: captura de pantalla
Informe de calidad de ScopeMaster sobre historias de usuario de ejemplo de Mike Cohn del sitio web ScrumAlliance

Ambigüedades

51 de las 98 historias de usuarios tenían un significado funcional ambiguo que, si no se resuelve, provocaría errores. 51 defectos identificados.

Faltan historias de usuarios de seguridad básica

No se mencionó el inicio de sesión, la autenticación, la autorización, el permiso o el cierre de sesión en las historias de los usuarios. Evidentemente se trata de una omisión importante. Normalmente esperamos que esto requiera al menos varias historias de usuarios. (aunque la historia de la “contraseña olvidada” está ahí). 5 defectos identificados:

• Acceso
• Validar correo electrónico
• Cambiar la contraseña
• Cerrar sesión
• Y luego, con cada historia de usuario sensible a roles, sería necesario realizar una verificación de roles y/o permisos.

El conjunto original de historias de usuarios no describía completamente la funcionalidad requerida.

Términos inconsistentes para Usuarios/Personas

ScopeMaster identificó 26 tipos de usuarios potenciales. Es probable que en realidad sólo haya 10 personas distintas. 16 defectos identificados.

Términos inconsistentes para Usuarios/Personas

De manera similar, ScopeMaster identificó 41 tipos de objetos potenciales, mientras que probablemente solo haya entre 25 y 30. 16 defectos identificados.

Integridad del mantenimiento de datos (análisis CRUD)

Para cada tipo de objeto válido debe haber al menos 1 función para cada evento CRUD. Después de eliminar los tipos de objetos redundantes, esto lleva a que falten alrededor de 80 historias de usuarios funcionales. 80 defectos identificados.

Valores atípicos de capacidad

El diagrama del modelo de casos de uso reveló más requisitos faltantes basados en roles/personas. Estimamos al menos 1 o 2 por tipo de usuario. 10 defectos identificados

Declaraciones de valor

ScopeMaster identificó que sólo 58 de los 98 han utilizado la frase “para que”, sin embargo, todos menos 3 incluyen el término “así”. 3- 40 defectos identificados

NFRS

Además, la detección de requisitos no funcionales de ScopeMaster identificó que existen varias categorías relevantes de NFR que no se mencionaron en este conjunto de historias de usuarios: accesibilidad, auditabilidad y observabilidad. 3 Defectos identificados

Resumen de resultados de calidad

En sólo 3 minutos, ScopeMaster identificó 211 problemas probables (97 + 114) con estas historias de usuarios. También se ha inferido a través del análisis CRUD que sólo la mitad de las historias de usuario probables necesarias están realmente enumeradas. (Es posible que este conjunto de historias de usuario de ejemplo se haya recortado deliberadamente antes de publicarse).

Además, ScopeMaster generó más de 140 escenarios de prueba esenciales, lo que ayudará a acelerar la iniciativa de prueba funcional, una vez que se haya creado la funcionalidad.

El propósito de este ejercicio no fue criticar las historias de usuario de ejemplo, sino resaltar el valor de utilizar ScopeMaster en cualquier conjunto de historias de usuario.

Agradecemos cualquier comentario de la gente de Mountain Goat.

Conclusión

En este ejercicio, podemos ver que ScopeMaster realiza un trabajo valioso en este conjunto de historias de usuario de ejemplo. Tiene:

  • Se revelaron más de 200 problemas que pueden resolverse fácilmente antes de convertirse inadvertidamente en la causa de una repetición del trabajo.
  • Alcance faltante revelado
  • Revelado un posible diseño de datos.
  • Produje escenarios de prueba básicos utilizables para cada historia de usuario, incluidas pruebas positivas y negativas.
  • Estimó el tamaño funcional de cada piso, (incluidos los faltantes) en estándares ISO de tamaño funcional.

Todo esto se suma a una cantidad sustancial de trabajo útil y esclarecedor que ayuda a aportar certeza al alcance y reducir el riesgo de cualquier proyecto de software.

Sería fantástico escuchar a Mike Cohn o a cualquiera que haya trabajado en el sitio web de ScrumAlliance sobre su experiencia con el uso de estas historias de usuarios y sus opiniones sobre el análisis de ScopeMaster. Hasta el momento nadie de su equipo ha estado disponible para comentar.