ScopeMaster-diez-pruebas-para-excelentes-historias-de-usuarios

Iniciar pruebas de historias de usuario

En la mayor parte de la actividad de software, las historias de los usuarios son un conciso recordatorio de las conversaciones entre el propietario del producto, el desarrollador y el evaluador. Aunque las historias de usuario son muy breves, el formulario suele utilizarse incorrectamente y esto genera ambigüedad, discusiones innecesarias y reelaboraciones. En este artículo, explicamos cómo probar historias de usuario para que pueda asegurarse de que sean de alta calidad y reduzcan el trabajo repetido y los plazos.

He disfrutado de un considerable debate en línea sobre la validez de incluso pensar en la calidad de las historias de usuario. Si acepta que las historias de usuario claras son útiles para un proyecto, entonces el concepto de prueba de historias de usuario debería tener sentido para usted.

Conozca estas diez pruebas para escribir excelentes historias de usuarios.

1. Borrar

Tus historias de usuario deben ser claro y sin ambigüedades. El propietario del producto, el desarrollador y el evaluador deben tener un entendimiento común de lo que se debe transmitir a partir del texto de la historia. Al escribir sus historias, asuma que si pueden malinterpretarse, así será. Además, asegúrese de que sus historias incluyan todas las funciones necesarias (excluida la navegación).

Consejo: Céntrese en la intención funcional de la historia del usuario, por ejemplo, "Como usuario_registrado puedo actualizar mi perfil".

Fondo

Probablemente sea mal entendido

Analizamos más de 100.000 historias de usuarios y descubrimos que la longitud promedio de las historias es de 12 palabras. Matemáticamente hay más de 80 mil millones de permutaciones de 12 palabras. Esto significa que hay formas casi infinitas en las que los lectores pueden malinterpretar las historias de los usuarios.

Las malas historias de usuarios provocan un exceso de retrabajo (±125 veces)

También hemos estimado que, en promedio, cada palabra de una historia de usuario conduce a 125 términos de codificación. Esto significa que un error (que puede dar lugar a un malentendido) dará lugar a una considerable repetición del trabajo una vez que se haya iniciado la codificación.

El aumento del trabajo remoto significa que somos más dependientes de la palabra escrita. Es importante utilizar las palabras correctas.

Pruebas de claridad automatizadas

La mayoría de las historias de usuarios están abiertas a malas interpretaciones. ScopeMaster® realiza un análisis lingüístico detallado de cada palabra dentro de la historia del usuario para detectar los significados funcionales. El motor de análisis está diseñado específicamente con el propósito de eliminar ambigüedades en las historias de usuarios de software (detecta patrones de sujeto, verbo, objeto dentro del texto). Esta es la base de cómo el motor de análisis realiza "lo último en pruebas de desplazamiento a la izquierda".

El motor de análisis también realiza cientos de comprobaciones lingüísticas en busca de fraseología y términos ambiguos que puedan dar lugar a una mala interpretación de la historia del usuario. Estas pruebas se basan en las enseñanzas de algunos de los principales expertos en requisitos del mundo. (Es como si los expertos revisaran todas las historias de sus usuarios).

2. Conciso

Manténgalos breves. Las historias no necesitan ser largas para transmitir el significado funcional esencial. Una o más frases cortas pueden ser suficientes. Recuerde que los criterios de aceptación son complementarios a la historia.

Consejo: Evite descripciones sobre navegación, detalles de implementación, criterios de aceptación y atributos de objetos.

Consejo: Evite detalles de implementación.

Consejo: Separe los criterios de aceptación de la historia principal del usuario.

Pruebas de concisión automatizadas

ScopeMaster® realiza un análisis detallado de las palabras de cada historia de usuario, destacando el uso excesivo de palabras innecesarias.

Pruebas de requisitos estáticos

ScopeMaster® ejecuta cientos de pruebas en cada historia de usuario. Es como SonarQube pero para historias de usuarios.

Prueba de historia de usuario: captura de pantalla

3. Orientado al usuario

Una historia debe escribirse desde la perspectiva del usuario. La recomendación ágil típica es el formato:

Como un Tipo de usuario Yo quiero realizar algo de modo que razón

En algunos casos, el tipo de usuario puede ser otra pieza de software, o quizás incluso un dispositivo que interactúa con el software, como un sensor.

Consejo: Nunca escribas tus historias desde la perspectiva del desarrollador.

Consejo: Evite el término general usuario, en su lugar, utilice etiquetas ricas y consistentes para el tipo o rol de usuario, como usuario registrado o visitante_no autenticado

Pruebas automatizadas de detección de usuarios

El analizador ScopeMaster® detecta usuarios candidatos dentro de cada historia. ScopeMaster resaltará casos de historias que carecen de un usuario. Opcionalmente, puede indicarle al analizador cuál es la palabra de "usuario" dentro de su historia.

4. Comprobable

Una historia puede ser comprobable si contiene declaraciones claras de funcionalidad. Utilice frases que infieran el movimiento, almacenamiento y recuperación de datos. Ejemplos de historias comprobables incluyen frases como "actualización del perfil", “mostrar informe de ventas“, "enviar correo electrónico". Escribir sus historias de esta manera garantizará que la intención funcional central sea clara. Esto proporciona la base a partir de la cual se pueden generar escenarios de prueba. El conjunto de pruebas completo normalmente dependerá de criterios de aceptación detallados y complementarios.

Consejo: Los criterios de aceptación detallados son complementarios de la historia de usuario principal; no incorporan criterios de aceptación dentro del texto de la historia de usuario.

Generación de pruebas automatizada

Como consecuencia de “conocer” la intención funcional de su historia de usuario, el motor ScopeMaster® propone escenarios de prueba y casos de prueba esenciales que pueden usarse como base para las pruebas funcionales. Las pruebas generadas por ScopeMaster están alineadas 100% con la funcionalidad de la historia del usuario. Cubren pruebas tanto positivas como negativas. Se pueden considerar como las pruebas mínimas imprescindibles que se deben realizar. Esto supone un importante ahorro de tiempo para los profesionales de pruebas.

5. Medible

Me refiero aquí a la mensurabilidad del tamaño, específicamente usando el Punto de función CÓSMICA (CFP) como base para el dimensionamiento. Es un estándar ISO maduro, de segunda generación, adecuado para todo tipo de trabajo de software. Las historias de usuarios solo se pueden medir si contienen expresiones claras de todos los movimientos de datos que serán necesarios y medidos. La mensurabilidad ayuda significativamente tanto con la planificación como con el aseguramiento de la calidad. El tamaño funcional no es el único atributo medible de una historia de usuario, sin embargo, es uno de los más importantes (porque se relaciona muy estrechamente con el esfuerzo para construirla).

Consejo: No medir el tamaño añade incertidumbre al trabajo del software.

Consejo: Conozca la metodología de dimensionamiento COSMIC en esta guía.

Fondo

La unidad de tamaño básica es la Punto de Función CÓSMICA que es un estándar ISO para el tamaño. Comience su viaje de aprendizaje con este actualizado, guía para software de medición.

Una estimación temprana de la PPC es muy útil, ya que a medida que se conozcan los detalles del requisito, esa estimación se acercará a una medición más precisa.

Aplicable universalmente

Para aquellos que se resisten a estimar o medir los requisitos (funcionales) del tamaño, considere lo siguiente. El tamaño mínimo de una historia de usuario es 2-3 CFP. El costo típico para desarrollar una CFP es $200 – $2000. El tiempo que lleva estimar el tamaño es de aproximadamente 10 minutos por CFP manualmente o 2 minutos con la ayuda de la automatización. Conocer el tamaño es increíblemente valioso para determinar cuánto costará el proyecto, cuánto tiempo llevará y más. Tanto “conocer el tamaño” como “realizar el tamaño” reducen la incertidumbre y mejoran la calidad.

Estimación de tamaño automatizada

ScopeMaster se diseñó originalmente con el objetivo principal de determinar el tamaño funcional (puntos de función COSMIC e IFPUG) a partir de los requisitos del software. Se ha validado que las estimaciones de tamaño de ScopeMaster se encuentran típicamente dentro de 15% de un tamaño determinado manualmente. Esto no sólo reduce el trabajo de realizar el dimensionamiento sino que también ayuda a introducir el dimensionamiento de ingeniería formal a aquellos que actualmente desconocen la existencia de técnicas tan valiosas.

6. consistente

Utilice palabras consistentes para ambos tipos_de_usuario y tipos_objeto a través de un conjunto de historias de usuarios. La denominación coherente reducirá la confusión, los defectos, el retrabajo y el desperdicio. Los sistemas complejos y los entornos con mucha jerga tienden a ser propensos a que los miembros del equipo le den términos diferentes al mismo usuario u objeto.

Comprobaciones de coherencia automatizadas

Después de analizar el texto individual de cada historia, el motor ScopeMaster hace referencias cruzadas de todas las historias de usuario dentro de un conjunto (o trabajo pendiente). Identifica cada aparición de tipos de objetos y los presenta en forma de tabla para que las inconsistencias puedan detectarse fácil y rápidamente.

7. Completar

Los requisitos faltantes son una de las principales causas de fracasos en los proyectos de software. La mayoría de los proyectos crecen en tamaño a medida que se hacen evidentes necesidades adicionales. Este aumento en el alcance conduce a más trabajo, más retrabajo, plazos extendidos, sobrecostos presupuestarios y, en algunos casos, fracaso total del proyecto. Aunque el enfoque ágil desalienta el trabajo inicial excesivo, Es esencial realizar un trabajo inicial de evaluación del alcance.. Busque atentamente los requisitos que faltan cuando escriba sus historias de usuario.

Comprobación de integridad automatizada

El motor de análisis ScopeMaster identifica todas las apariciones de un tipo de objeto en un conjunto de historias de usuarios. Luego realiza un análisis CRUD. para identificar historias potencialmente faltantes. ScopeMaster incluso sugiere cuál podría ser la historia que falta.

Obtener una comprensión completa del alcance total de un proyecto en las primeras etapas de su ciclo de vida es extremadamente valioso para los gerentes de proyectos.

8. Único

Todos los requisitos deben ser únicos. Los requisitos duplicados son un problema que tiende a ser más frecuente en proyectos más grandes.

Comprobación de unicidad automatizada

El motor de análisis ScopeMaster identifica todas las apariciones de un tipo de objeto (y la intención funcional asociada) en un conjunto de historias de usuarios. Cuando hay dos pisos que realizan la misma operación CRUD en un objeto, estos se resaltan.

9. Valioso

Todas las historias de usuarios deben ser valiosas para el "negocio". Es apropiado cuestionar el valor y la importancia de cada historia de usuario, de modo que solo se entregue la funcionalidad más importante. Si no se puede rastrear la historia de un usuario hasta ofrecer un resultado comercial mensurable, es posible que no sea valiosa y tal vez deba eliminarse su alcance. El valor financiero real de la historia puede ser difícil de medir, utilizando el tamaño funcional (CFP) como base para el valor (especialmente para la medición del valor ganado EVM).

10. Sin diseño

Las historias de usuarios no deben hacer referencia a la tecnología utilizada para entregarlas. Este nivel de detalle se puede incluir como complemento a la historia del usuario para ayudar a proporcionar contexto sobre “cómo” debe entregarse. Esto es particularmente adecuado para aspectos no funcionales de cómo se logrará la funcionalidad.

Comprobación automatizada del lenguaje técnico

El motor de análisis ScopeMaster busca cientos de frases técnicas y otra terminología que no es apropiada para las historias de los usuarios.

Recomendación

Deje que ScopeMaster pruebe sus historias de usuario por usted, simplemente importe y presione el botón verde, su análisis de lenguaje inteligente evaluará la calidad y hará recomendaciones para mejorar sus historias de usuario.

Conclusión

A medida que avanzamos hacia un trabajo más remoto, aumenta nuestra dependencia de la palabra escrita en el desarrollo de software. Dedique tiempo a pronunciar las palabras correctas. Las historias de usuarios de buena calidad son la base de un software de calidad. Debes probar historias de usuarios antes de comenzar a codificar, para evitar perder tiempo.

Cada una de estas 10 pruebas representa un atributo de calidad de una buena historia de usuario. Puede utilizar esto como una lista de verificación para comparar cada historia de usuario que escriba. Probar historias de usuarios generará importantes dividendos al reducir el retrabajo, la reducción del alcance y la volatilidad del alcance. Y si quiere hacerlo más rápido, pruebe ScopeMaster, hace el trabajo pesado de probar historias de usuario.

Historias de usuarios ágiles

Muchos agilistas utilizan el Lista de verificación para INVERTIR Criterios para historias de usuarios originalmente de Bill Wake:

Iindependiente
nortenegociable
Vvalioso
miestimable
Scentro comercial
testable

Cuidado con INVEST

El autor original señala que INVEST es un subconjunto incompleto de atributos.
No reconoce que las historias de los usuarios pueden ser interdependientes.
Requiere que las historias estén orientadas al usuario.
No insiste en que las historias sean inequívocas.
No reconoce los peligros de trabajar con una comprensión incompleta del alcance.
No fomenta el análisis disciplinado (nombramiento coherente, orientación al usuario, concisión)
No requiere que las historias sean medibles (aunque se refiere a Estimable, este es un criterio muy vago).

La creación original de INVEST también menciona que las tareas deben tratarse de manera diferente y aplicarse el acrónimo SMART:

Específico
Mensurable
Realizable
Realista
Limitados en el tiempo

Siempre he encontrado que los controles SMART son efectivos y apropiados para las tareas, pero no para historias de usuarios.

¿Por qué deberíamos escribir mejores historias de usuarios?

Como todo tipo de trabajo de conocimiento, la redacción de historias de usuarios (o requisitos de software) es propensa a errores. Estos errores deben abordarse antes de desarrollar el software; de lo contrario, consumirán mucho tiempo y serán costosos de resolver una vez. Es más probable que una historia de usuario escrita por una persona tenga el potencial de ser malinterpretada por sus lectores.