10x - 100x más rápido
1.000 veces más completo
En promedio, realizamos alrededor de 1000 pruebas por historia de usuario. Esta es una combinación de pruebas estáticas y dinámicas. Este es un nivel de escrutinio que no se logra normalmente con las revisiones manuales de historias.
¿Quiere saber más? Lea los detalles sobre el tipo de pruebas realizadas por ScopeMaster.
ScopeMaster proporciona análisis de requisitos de software que ayudan a los equipos de entrega de software a entregar proyectos de software más rápido y con mayor certeza.
Si se puede malinterpretar, será
Si los lectores clave (autor, usuario, evaluador, desarrollador) pueden interpretar una historia de usuario de manera diferente, entonces es probable que uno de ellos esté trabajando con una comprensión incorrecta, generando desperdicio y reelaboración. Es muy importante eliminar estas ambigüedades de raíz.
125 razones para probar historias de usuarios
La proporción de palabras en una historia de usuario con respecto a la cantidad de tokens de codificación que normalmente vemos es 1:125. Una historia de usuario de 12 palabras probablemente terminaría convirtiéndose en alrededor de 1500 tokens de codificación, aproximadamente 300 líneas de código. Entonces, por cada minuto dedicado a corregir una palabra ambigua en una historia de usuario, probablemente se ahorrarán 125 minutos en codificación. ¡Eso sí que es tiempo bien empleado!
Pruebas de extrema izquierda
Las pruebas de historias de usuario pueden parecer una idea extraña, pero no lo es. De hecho, es una de las cosas más productivas que puedes hacer en un proyecto de software. Es el epítome de las pruebas de extrema izquierda. Si desea convertirse en un propietario de producto más exitoso, comience a probar esas historias lo antes posible. Las historias de usuarios son una expresión de los requisitos de los esfuerzos de software ágil. Al igual que otros entregables de desarrollo de software, también son propensos a errores. El desafío particular de las historias de usuarios es que pueden malinterpretarse muy fácilmente, lo que puede generar una gran pérdida de tiempo y esfuerzo. De hecho, es más probable que se malinterpreten.
Cómo probar historias de usuarios
Entonces, ¿Cómo lo hacemos? Empecemos por lo básico. ¿Qué es un requisito de software empresarial?:
Un requisito (o capacidad) empresarial real es “lo que se debe entregar para aportar valor al negocio” (Robin Goldsmith). Las historias de usuarios son los requisitos funcionales discretos que conforman esa capacidad.
¿Qué pasa si no pruebas tus historias de usuario?
Las historias de usuarios deficientes (o los requisitos deficientes) son la causa fundamental de los defectos de producción del 35% (Accenture, 2021). Un problema de requisitos que no se resuelve hasta fases posteriores del desarrollo/implementación puede costar entre 75 y 1000 veces más que si se solucionara antes de que comenzara la codificación.
Necesidad de disciplina para reducir la ambigüedad
Cuando escribimos código, seguimos disciplinas para mejorar la legibilidad, reducir la complejidad, aumentar la reutilización y mucho más. (Para más información sobre esto, lea el excelente Código completo, por Steve McConnell). Escribir historias de usuarios también justifica dicha disciplina, especialmente para minimizar la ambigüedad, la inconsistencia y la complejidad. De hecho, una buena historia de usuario puede resultar bastante aburrida porque no es ambigua. Esté preparado para ajustar la forma en que escribe historias de usuarios, adopte coherencia y disciplina para eliminar ambigüedades. Afortunadamente, ScopeMaster le ayudará a aprender sobre la marcha.
Herramientas relacionadas
jsonlint es una herramienta en línea para probar la sintaxis de un archivo json
Validador HTML es una herramienta en línea para probar la sintaxis HTML.
