Tengo que reconocer que nunca me gusto la documentación masiva de requerimientos ni la especificación de sistemas. Creo que las especificaciones de software suelen ser terriblemente aburridas y lo que es peor no ayudan a construir mejor software. Pero, tengo que aceptar que, siempre me sentía mal por mí reticencia a esta documentación. Tengo claro que la captura y análisis de requerimientos son procesos (NO etapas) críticos en la construcción del software. Viví mucho tiempo con esta dicotomía que no pude resolver y para acentuar más el problema, aun cuando la documentación se hacía bien, solía ocurrir que a medio construir el Data Warehouse o solución de BI los requerimientos cambiaban tanto, que al final la solución se parecía muy poco a la documentación inicial.
Por eso cuando hace unos años cuando empecé a hacer Inteligencia de Negocios ágil, una de las grandes ventajas que vi, fue el liberarme de dichos monstruos y encontrarme que había un mejor método para capturar y analizar requerimientos: Las historias de usuario. La teoría de las historias de usuario que leí, y los ejemplos que examiné me parecían muy sencillos y fáciles. Me gustaba que tenían la ventaja de transmitir fácilmente funcionalidad que un sistema debía proporcionar y que era más fácil involucrar a los usuarios. Rápido aprendí como escribir historias de usuario, pero acepto que mis primeras versiones de historias de usuario no eran muy buenas y me tomo bastante tiempo entender realmente cómo usarlas en el contexto de Inteligencia de Negocios y todavía más cómo hacer que una historia de usuario sea realmente buena y provea valor.
En mi experiencia hay tres principios fundamentales que pueden ayudar a escribir buenas historias de usuario:
La primera la podemos encontrar en una frase del Dr. Martin Luther King Jr.: “Fe es dar el primer paso, incluso cuando no ves toda la escalera”. Claro que el Dr. King era un hombre religioso lo que le da al concepto de Fe una interpretación específica; además de que hablaba del tema de derechos civiles y no de desarrollo de software. Pero a pesar de eso creo que su frase es aplicable para entender un cambio de paradigma que se requiere cuando se desarrollan soluciones agiles. Para mí esta cita, en el contexto de desarrollo ágil, expresa el concepto de no tenemos que conocer el todo antes de empezar a construir algo. Y este cambio de paradigma es fundamental, porque en el desarrollo ágil con frecuencia se enfatiza el concepto de desarrollo incremental, pero se olvida un concepto que es mucho más importante: el desarrollo iterativo. Durante muchos años los métodos tradicionales de software han creado en desarrolladores modelos mentales que les inhibe de ver el desarrollo de software tiene más parecido con la biología que con la ingeniera, entonces se autoimponen la necesidad de diseñar la solución final completa antes de tocar la primera línea de código.
La segunda es uno de los valores del desarrollo ágil: “Colaboración con el cliente sobre negociación contractual”. En este caso debemos enfatizar que las malas experiencias que el desarrollo tradicional nos ha dejado, son las que han hecho que esa documentación de requerimientos tradicional se haga tan pesada y que con los años esto documentos ganan y ganan más páginas. Esta actitud DE desarrolladores contra usuarios debe abandonarse cuando se desarrolla de forma ágil. Las historias de usuario por su naturaleza no capturan todo lo que se requiere para construir el software. La historia de usuario es básicamente un punto inicio que fomenta la conversación entre los desarrolladores y los usuarios. La historia de usuario nos indica una valiosa porción de funcionalidad deseable del software y en la medida posible nos ayuda a contestar tres peguntas: quien desea, qué desea y porque lo desea. Los principiantes en metodologías agiles se concentran en el QUÉ, cuando normalmente el QUIÉN y POR QUÉ son más importantes.
Basado en los dos puntos anteriores, debe buscarse el tercer y más importante principio que las historias de usuario pueden tener: guiar un proceso de mejora continua en lugar de buscar la perfección. En las palabras de Kim Collins, “Esforcemos por la mejora continua, en lugar de la perfección”. Este proceso de mejora continua no es algo nuevo, Frederick P. Brooks proponía desde 1987 “Hacer crecer el software orgánicamente, agregando más y más funciones a los sistemas a medida que se ejecutan, utilizan y prueban.” (No Silver Bullet-Essence and Accident in Software Engineering).
En conclusión, para que las historias de usuario funcionen adecuadamente requieren de un fuerte liderazgo del Product Owner que:
- Tenga fe en el equipo de desarrollo y en el proceso ágil y sea capaz de valorar adecuadamente las entregas incrementales e iterativas.
- Que use las historias de usuario como una forma de comunicación y de formalización de ideas y no como un contrato.
- Que guie el proceso de mejora continua y que discierna que el software aun cuando no es perfecto aun así es valioso.
Responder a Adriana Castro Cancelar la respuesta