Refinando historias de usuarios
Refinar las historias de usuario es el proceso de mejorar, dividir y aclarar cada historia de usuario. Se deben revisar los detalles y la claridad de cada historia de usuario. La preparación de trabajos pendientes es un término que generalmente se refiere al proceso de nivel superior de priorizar historias de usuarios. Tanto el refinamiento (clarificación) como el cuidado (priorización) son pasos importantes para lograr requisitos de buena calidad. El primero garantiza que el usuario obtenga lo que desea y el segundo se ocupa de la secuenciación para satisfacer tanto las necesidades comerciales como la eficiencia del equipo de desarrollo. En este artículo nos centraremos en el refinamiento de las historias de usuarios, dejando la priorización para un artículo separado.
Propósito de las historias de usuarios
El propósito de las historias de usuario es comunicar, para garantizar que las necesidades del usuario se expresen correctamente en un lenguaje que un desarrollador y evaluador pueda comprender completa y consistentemente. Las historias de usuario deben ser orientado al usuario, simple, claro, inequívoco y coherente, sin nada desaparecido. Al perfeccionar sus historias, eliminará muchos defectos de requisitos que a menudo no se encuentran hasta mucho después de que haya comenzado el trabajo de diseño y desarrollo. Refinar las historias de los usuarios con ScopeMaster suele ser entre 10 y 20 veces más rápido que hacerlo manualmente.
Historias de usuarios o requisitos
¿Las historias de usuario y los requisitos son lo mismo? Algunos puristas ágiles explicarán que las historias de usuarios son recordatorios de conversaciones y, por lo tanto, no requisitos. Sin embargo, hemos observado que para la mayoría de los equipos, el Las historias de usuario se tratan como requisitos., y entonces hacemos lo mismo. Los requisitos o historias de usuario son esencialmente una expresión de las capacidades que los usuarios necesitan del software, para garantizar una comunicación clara y coherente con el equipo. Tenga en cuenta que las historias de usuario (o requisitos) no incluyen tareas técnicas ni restricciones del proyecto. En adelante usaremos los términos requisito y historia del usuario indistintamente.
Los defectos en las historias de usuarios son inevitables
Escribir requisitos o historias de usuarios es lo mismo que cualquier otro trabajo de conocimiento: cometemos errores sobre la marcha. Incluso si tenemos cuidado, ocurrirán errores, son inevitables. Además, generalmente las escribimos en inglés, que es un idioma increíblemente sutil en el que los lectores pueden entender cada palabra de diferentes maneras. Así que incluso si pensamos que los hemos escrito bien, es muy probable que los lectores lleguen a una comprensión ligeramente diferente. Si dos lectores de una historia de usuario pueden llegar a un entendimiento diferente, entonces tienes un defecto. Un defecto en una historia de usuario o en un requisito dará lugar a que se cree el software incorrecto.
Costo de los defectos en las historias o requisitos de los usuarios
Comprender el costo de la calidad es un tema muy importante, ya que puede ayudarnos a apreciar por qué los requisitos de calidad realmente importan. Un defecto de requisitos que no se resuelve antes del desarrollo dará lugar a un error. Ése es un hecho inevitable. Muchos problemas de requisitos se detectan durante el desarrollo. Pero no todos ellos. Consideremos cuál es el impacto si no encontramos y solucionamos ese error hasta más adelante en el ciclo de vida de desarrollo de software (SDLC). Si el error se encuentra durante el desarrollo, es posible que tengamos que detener el desarrollo, verificar cuál es el requisito correcto, luego rediseñarlo y reescribir el código. Esto lleva tiempo y perturbará y retrasará el progreso. Dependiendo de la naturaleza y gravedad del defecto requerido, esto puede llevar a reelaboraciones importantes (diseño diferente, arquitectura diferente). Puede retrasar proyectos y provocar aumentos significativos de costos.
Ahora consideremos una situación aún más grave en la que un defecto en un requisito no se detecta hasta que el código llega a producción. Esto puede tener consecuencias aún más graves. Es posible que el software esté haciendo algo incorrecto y esté causando daño a los usuarios o a la empresa. Esto puede tener un impacto catastrófico.
Costo de recuperación de defectos en los requisitos
Si se encuentra en la producción un defecto causado por requisitos deficientes, y es grave, hay dos categorías de costos: interno y externo.
Costos Internos
- El trabajo extra para cambiar el software para que funcione correctamente.
- El trabajo extra para alterar datos que han sido manejados incorrectamente debido a la falla.
- El costo de oportunidad de desviar personal para solucionar este defecto en lugar de realizar otro trabajo útil.
Costos externos
- Costo consecuente para los usuarios o beneficiarios del software, causado por el error.
- Compensación a los usuarios que sufrieron ese error.
- Trabajo adicional por parte del personal ajeno al software para manejar el incidente/impacto en los usuarios hasta que se pueda solucionar el error.
- Daño reputacional a una organización
En la mayoría de los casos, los equipos de proyectos de software subestiman el costo de los requisitos deficientes. Si quieres aprender más sobre este tema te recomiendo este excelente libro. "La economía de la calidad del software"
Control de calidad de requisitos automatizado
ScopeMaster lleva el trabajo de control de calidad de los requisitos a un nuevo nivel. ScopeMaster ayuda a acelerar el trabajo de mejora de la calidad de los requisitos y refinamiento de la historia del usuario.
ScopeMaster automatizará la búsqueda y acelerará la corrección de muchos defectos de requisitos para ayudar a garantizar que sus requisitos o historias de usuario sean:
- Claro
- Conciso
- Coherente
- Completo
- Comprobable
- Considerable
- Único
- Orientado al usuario
- Diseño gratis
El único atributo importante que ScopeMaster no puede automatizar es detectar si realmente necesita el requisito. ¿Es valioso? Esto tendrá que resolverlo usted mismo, pero ScopeMaster le liberará tanto tiempo que tendrá la capacidad de considerar el valor real de cada requisito.
Aprender más acerca de refinamiento automatizado del trabajo pendiente
¿Cuáles son los buenos requisitos?
Hemos establecido que los requisitos deficientes son perjudiciales, costosos, derrochadores y, en algunos casos, incluso peligrosos. Entonces, ¿cómo hacemos para redactar buenos requisitos? ¿Cómo sabemos si tenemos buenos requisitos? ¿Cómo podemos detectar problemas en los requisitos? Hay algunos ingredientes universales para unos buenos requisitos que describiremos y que te ayudarán:
Orientado al usuario
Todos los requisitos deben expresarse en términos de lo que necesita un usuario. Posteriormente se pueden dividir en tareas de desarrollador, pero primero se debe expresar una versión del requisito en relación con la necesidad del usuario para que podamos estar seguros de que lo que se desarrolle satisfará las necesidades del usuario.
Claro e inequívoco
Los lectores no deben malinterpretar fácilmente un requisito. Esta es quizás la dimensión más difícil de garantizar. Significa que un requisito debe describir claramente la funcionalidad que un usuario debe realizar. Dos lectores del mismo requisito deben llegar a la misma comprensión general de qué datos deben manejarse como parte del requisito.
Conciso
Los requisitos deben ser concisos. Un requisito no necesita ser detallado ni utilizar un lenguaje florido y elegante.
Coherente
Un conjunto de requisitos debe utilizar términos coherentes para los tipos de usuario, por ejemplo administrador. Un conjunto de requisitos también debe utilizar términos coherentes de tipos de datos (tipos de objetos)
Completo
Un requisito debe ser completo en sí mismo (describir todos los pasos funcionales necesarios para esa capacidad del usuario). Además, debe estar completo un conjunto de requisitos que describan toda la funcionalidad necesaria para mantener todos los datos dentro del sistema. Para ello, el análisis CRUD es de gran ayuda.
Considerable
Si un requisito del usuario no es funcionalmente considerable (es decir, medible en puntos de función COSMIC), entonces es casi seguro que carece de calidad en alguno de los otros aspectos de esta lista. Es por eso que consideramos que la capacidad de dimensionar en CFP es una excelente prueba de claridad y calidad de los requisitos. Nótese bien. Las tareas técnicas y los requisitos no funcionales no son de esta manera dimensionables. Las tareas técnicas generalmente se dimensionan en horas de personal. El dimensionamiento no funcional es un problema no resuelto, aunque existen algunas recomendaciones (en un artículo aparte).
Comprobable
Los evaluadores deben poder determinar cómo comprobar que se ha cumplido un requisito. Por lo tanto, el requisito debe redactarse de manera que pueda comprobarse. Una de las mejores formas de garantizar que ese requisito sea comprobable es garantizar que describa claramente la intención funcional. (Para ello recomendamos el tallaje COSMIC)
Único
No queremos que un conjunto de requisitos contenga contenido duplicado o funcionalidad duplicada. (Este es quizás uno de los problemas de calidad de los requisitos menos importantes).
Sin diseño
Las historias de usuarios no deben contener ningún detalle sobre cómo se debe implementar una capacidad. Una historia de usuario no es un marcador de posición para los detalles de diseño. Puede dividir el trabajo para implementar historias de usuario en tareas técnicas, pero estas no son historias de usuarios.
Valioso
Cada historia de usuario debe proporcionar valor al usuario o a la parte interesada; de lo contrario, no debería construirse. El valor debe expresarse en términos que el usuario (no el desarrollador) reconozca.
Esa es nuestra lista recomendada de 10 atributos de buenas historias de usuarios o requisitos de software. Se aplica en todas las situaciones. Algunos expertos en requisitos argumentarán con razón que esto no es suficiente. Es cierto, hay ciertas situaciones en las que los requisitos deben cumplir estándares incluso más altos que los que hemos descrito aquí. Lo que hemos descrito es un conjunto de atributos que deberían aplicarse en todas partes, independientemente del tipo de software que esté desarrollando/ensamblando/implementando.
¡Cuidado con INVERTIR!
INVEST es un término neumónico acuñado por los primeros agilistas para proporcionar algún tipo de lista de verificación para las historias de los usuarios. Lo que representa:
- I” independiente (de todos los demás)
- “N” negociable (no es un contrato específico para funciones)
- "Valioso
- “E” estimable (en buena aproximación)
- Centro comercial “S” (para que quepa dentro de una iteración)
- “T” estable (en principio, aunque aún no existe una prueba para ello)
Nos gustan las listas de verificación, pero encontramos que la lista INVEST tiene demasiadas deficiencias para ser universalmente confiable para evaluar los requisitos de calidad y desaconsejar su uso.
No garantiza que las historias estén orientadas al usuario
Si el software no hace algo útil para un usuario, no es útil. Si nuestras historias no están orientadas al usuario, entonces son simples tareas laborales. Y en esto terminan convirtiéndose tantas historias de usuarios: tareas, no expresiones de funcionalidad o capacidad reconocible por el usuario. En resumen tu expresión de hecho probablemente será pobre.
No logra garantizar la coherencia
Si solo sigue estas pautas, es probable que termine con requisitos que confundan los nombres de usuario/persona y tengan muchos términos diferentes para los tipos de objetos.
No logra garantizar un tamaño considerable
Al hacer referencia a Estimable y no considerable, este enfoque no garantiza que cada historia de usuario tenga un tamaño (funcional). El tamaño funcional no sólo es valioso para la gestión de proyectos sino que también es una buena prueba de la calidad de los requisitos. Un requisito importante es uno de buena calidad.
No logra garantizar la ausencia de diseño
Depender únicamente de INVEST hará que sus historias de usuario se confundan con tareas (e “historias de usuario técnicas”), lo que distancia el trabajo del usuario y su valor para él.
Usando ScopeMaster
Una hora después de utilizar ScopeMaster por primera vez, encontrará y solucionará defectos de requisitos más rápido que nunca. Dependiendo de la calidad de los requisitos originales, podría encontrar y reparar hasta 200 defectos por día. ¿Se te ocurre alguna otra actividad que fuera tan productiva para encontrar y reparar defectos?
Sigue estos pasos:
- Importe las historias de sus usuarios (a través de un archivo CSV).
- Haz clic en “Analizar todo” (quizás tengas tiempo para tomar un café).
- Explore los resultados del análisis de ScopeMaster
- Comience con los ambiguos y reformúlelos para que sean historias de usuario funcionales claras y orientadas al usuario.
- Utilice el diccionario de datos generado automáticamente y el modelo de casos de uso para garantizar una denominación de usuario coherente
- Utilice el análisis CRUD para garantizar una denominación de objetos coherente
- Examine los comentarios de calidad que proporciona ScopeMaster para mejorarlos aún más.
- Utilice el análisis CRUD para garantizar que el conjunto de requisitos esté completo
