¿Cuántas veces hemos visto las tradicionales especificaciones detalladas que los equipos de desarrollo reciben después de una larga fase de análisis? Documentos de hasta 150 páginas describiendo un requisito, diagramas, máquinas de estado, tablas descriptivas, matrices de trazabilidad que se tornan ilegibles después de cierto número páginas, todo con estricto apego a UML. Desafortunadamente muchas más de las que quisiéramos.
Las especificaciones de diseño detalladas surgieron como una de las soluciones de definición de requisitos para el desarrollo de software bajo herramientas CASE de tal manera que los parámetros establecidos en ellas generaran código que finalmente terminaría reduciendo los costos en el desarrollo de software. (Ajá, ya todos sabemos en qué terminó aquel cuento)
Pero, ¿Por qué no hacer software en equipo? Hoy contamos con una técnica que ha sido ampliamente aceptada por los equipos de desarrollo ágiles, se trata de las Historias de usuario, son en esencia requisitos del producto de software los cuales están escritos en lenguaje de usuario y enfocados a la necesidad del él mismo, teniendo entre sus características los criterios de aceptación para dar por concluida la historia una vez desarrollada.
Lo bueno
- La principal ventaja de usar historias de usuario es su tamaño ya que permiten hacer estimaciones más precisas sobre el esfuerzo requerido para completarlas.
- Son escritas en lenguaje coloquial de modo que pueden ser interpretadas por cualquier miembro del equipo para su desarrollo.
- Al ser resultado de una charla entre los Team Members y el Product Owner, fomentan la comunicación y el entendimiento entre ambas partes.
- Apoyan el principio de desarrollo iterativo al no ser necesario contar con todas las historias de usuario escritas desde el inicio de un proyecto.
Lo malo
- En proyectos muy grandes se torna complicado establecer la relación entre todas las historias de usuario. Para esa situación, Mike Cohn nos sugiere organizarlas de acuerdo a funcionalidades por rol.
- Puede omitirse cierto tipo de información y en especial, para equipos geográficamente distribuidos se convierte en un problema ya que, si las historias no se documentan adecuadamente la información puede perderse.
Lo feo
- Las buenas historias dependen de la experiencia en el uso de la técnica de las personas involucradas.
- Históricamente se ha entendido la captura de requerimientos como una etapa única y al inicio de los proyectos, hacer uso de las Historias de Usuario para recolectar requerimientos durante todo el desarrollo del proyecto puede resultar en insatisfacción del negocio al entender esta práctica como desconocimiento de áreas técnicas sobre cómo desarrollar software.