Hola a todos
Recuerdo hace más de 15 años cuando enseñaba taller de ingeniería de software, casos de uso, programar en Java en Eafit y otras cosas antiguas, que le explicaba a los estudiantes que las especificaciones de software según el estándar IEEE 830-1998 (1) deberían ser:
- Completas. Todos los requisitos deben estar reflejados en ella y todas las referencias deben estar definidas.
- Consistentes. Debe ser coherente con los propios requisitos y también con otros documentos de especificación.
- Inequívocas (no ambiguas). La redacción debe ser clara de modo que no se pueda mal interpretar.
- Correctas. El software debe cumplir con los requisitos de la especificación. Se tienen que cumplir y construir.
- Trazables. Se refiere a la posibilidad de verificar la historia, ubicación o aplicación de un ítem a través de su identificación almacenada y documentada.
- Priorizables. Los requisitos deben poder organizarse jerárquicamente según su relevancia para el negocio y clasificándolos en esenciales, condicionales y opcionales.
- Modificables. Aunque todo requisito es modificable, se refiere a que debe ser fácilmente modificable.
- Verificables. Debe existir un método finito sin costo para poder probarlo.
Lo cierto, es que el tiempo pasó, las historias de usuario se hicieron populares dentro del mundo ágil y luego dentro del desarrollo de software, y esto sucedió debido a que cada vez evidenciamos más que ser rigurosos en la especificación no aumenta la precisión del desarrollo, que es mejor un breve enunciando con criterios de aceptación, o un boceto y una conversación cara a cara para sincronizar las expectativas del cliente con los desarrolladores, que documentos grandes y estrictos que nos demorábamos meses construyendo, verificando y validando, para luego llegar tarde construir la solución incorrecta.
No volví a toparme mis amados Caso de Uso, con sus relaciones de inclusión y exclusión, ni sus flujos básicos y alternativos, ni con sus diagramas respectivos, todo eso pasó, y pasó para darle lugar a una interacción fluida que nos está permitiendo entregar valor de forma temprana y continua, y reduciendo radicalmente los errores de implementación debido a que nunca adivinábamos todo lo que el usuario tenía en mente.
Constantemente le insisto a las empresas y equipos con los que trabajo:
"Ágil es:
Definición continua
Desarrollo continuo
Despliegue continuo y
Validación continua de valor"(2)
Pero este artículo no es sobre nostalgias, su propósito es dar claridad sobre las historias de usuario y que estas no cumplen con los criterios requeridos para ser especificaciones de software como lo pide la norma, pues:
- No están completas: son dinámicas y se actualizan cada que se requiera.
- Algunas son ambiguas: puede que al momento de redactarse falten algunos aspectos (3) y en el momento de la planning (en el mundo Scrum) o durante el desarrollo, se hagan preguntas que logren resolver la ambigüedad y esto permita una mejor comprensión de lo que quiere el usuario. Lo anterior muchas veces es más valioso que creer correctamente entendido y no se hacen preguntas que permitan validar lo expresado.
- No todas son correctas: no necesariamente se van a construir dentro del software, algunas quedarán en el olvido o se decidirá libremente no hacerlas pues ya no generan valor.
- Probablemente no sean trazables: no siempre habrá trazabilidad pues probablemente se registró en un post-it y este luego se tiró a la basura y, por lo tanto, la única evidencia que quedó de esa historia de usuario es el software funcionando aprobado en producción.
Es por esto, que continuamente en los entrenamientos que imparto en los cuales debo hablar de las historias de usuario, lo primero que enfatizo es en que:
"Las historias de usuario no son requisitos de software, son solo necesidades de un usuario",
Para cerrar los dejo con esta frase de Jeff Patton, quien ideó el User Story Map:
¿Quieres saber más sobre historias de usuario?
En junio mi gran amigo Lucho Salazar y yo estaremos facilitando un curso donde te contaremos de nuestras experiencias en este y otros asuntos sobre lo esencial de las historias de usuario. Encuentras más información en:
¡Te esperamos!
Notas, Aclaraciones, Referencias y Comentarios
- https://es.wikipedia.org/wiki/Especificaci%C3%B3n_de_requisitos_de_software
- Lo escribo escalonado pues no se da de forma paralela, sino de forma escalonada y más cercana en el tiempo, desde unas cuantas horas hasta máximo dos meses.
- http://www.lecciones-aprendidas.info/2018/07/aclarando-sobre-historias-de-usuario.html
No hay comentarios.:
Publicar un comentario