La Magia de las Historias de Usuario / Desarrollo Conducido por Historias de Usuario

Nivel del post: Intermedio.


Cuando uno lee sobre RUP (Rational Unified Process), en una de sus definiciones dice que es un desarrollo conducido por Casos de Uso, y hoy quiero después de convivir por más de 6 meses con las Historias de Usuario, contar cómo realmente conducen el desarrollo del software mucho mejor que los casos de uso.

Introduciéndonos: El Formato

Las HU (Historias de Usuario) de usuario tienen un formato libre, y podrían expresarse como una necesidad funcional, por ejemplo:

• consultar las películas de cine disponibles en un teatro cerca a mi casa

 O como ya es popular se pueden escribir con el siguiente formato (template):

• yo como <rol> quiero/deseo/necesito  <funcionalidad> para <beneficio de negocio>

De esta forma nuestro ejemplo quedaría:

• yo como cliente deseo saber cuales son las películas disponibles en un teatro cerca a mí casa para poder elegir que película ir a ver el día de hoy

Este formato tiene las consabidas ventajas de:

• saber quien va a usar la funcionalidad y
• comprender el beneficio del negocio de forma que el equipo pueda llegar a ese beneficio por distintos caminos

Y dónde esta la magia...

Aunque el objetivo de las historias es habilitar la comunicación entre el Cliente y Equipo (para el caso de Scrum:  Product Owner PO / Dueño del Producto y el Equipo de Desarrollo), dando cumplimiento al principios del manifiesto ágil:

• Personas e interacciones sobre procesos y herramientas (ver más sobre el manifiesto ágil)

Una definición tan simple obliga al equipo a estar en comunicación con el Product Owner (PO), de la siguiente manera:

• En el Planning (ver más sobre scrum), el equipo pregunta al PO el detalle de lo que quiere y lo que espera.
• En el Planning, el equipo con base en lo conversado estima lo que va a construir en presencia del PO.
• Durante el Sprint, el equipo clarifica con el PO detalles menores olvidados.

Pero de todo esto lo que me tiene maravillado el día radica en los criterios de aceptación.

Los criterios de aceptación nos permiten reconocer cuando la historia esta HECHA / TERMINADA / REALIZADA (o criterio de DONE de Scrum), de esta forma el equipo de desarrollo no tiene pierde, pues todo su desarrollo esta orientado al resultado esperado, o mejor, orientado a los casos de prueba que a la especificación.

Esto es una ganancia enorme!!! (para quienes hemos padecido el desarrollo en cascada o RUP basado en casos de uso) la marcha de la muerte - o Desarrollo Orientado a la Frustración DOF - es la siguiente:

• Analista: El casos de uso es especificado con sus  escenarios de uso (flujo básico, alternos y de excepción) -que a ratos solo los entiende el analista/desarrollador que los escribió -
•  Desarrollador: Para cumplir con el caso de uso el desarrollador construye lo especificado en los escenarios de uso,  y valida contra unos escenarios de prueba que "el cree" necesarios para cumplir la funcionalidad.
• Tester:  luego el tester mucho mas hábil en encontrar los errores (o enfocado en esa única tarea) construye n-mil casos de prueba a un solo escenario de uso (ejemplo flujo alterno 3 )  hasta que por fin le encontraba la caída al escenario del caso de uso y lo devolvía a desarrollo con un incidente o hallazgo (forma diplomática y "very polite" de decir bug), 
• Desarrollador:  el desarrollador dice  "#$%#"% ese escenario YO NO lo considere, no estaba escrito en ninguna parte,  me demoraré un poco más en completar este caso de uso y entregarlo para pruebas"
• Tester :  a lo que el tester responde "yo te entiendo, pero caso de prueba fallido es una forma de confirmar esa funcionalidad" 
• Desarrollador : remata contestando el desarrollador  "tienes razón, nos vemos en X días cuando termine el desarrollo y marque como cerrada tu anotación en el Bugtracker"..

 y todos seguiremos tratando de dar lo mejor en un contexto que no lo permite, y que por lo general termina en una serie de enemistades:

• Desarrolladores - Testers: - pues los desarrolladores comienzan a ver con malos ojos a los testers, por más claro que tengan el proceso de pruebas como una actividad de desarrollo.
• Gerente de proyectos - Equipo: pues piensa "como es que se continúan atrasando en el cronograma, como es que no identificaron ese escenario, pensé que tenía un equipo profesional"
• Cliente - Proveedor de desarrollo: pues el cliente piensa "como es que no son capaces de cumplir con lo especificado, casi que no completan esos casos de uso y miren todos los errores que tienen"

En cambio, en las historias de usuario ya sabemos como nos van a probar la historia y como se considerara TERMINADA.

Entonces para la historia de usuario que escribimos, los criterios de aceptación serán:

• que me liste de a 10,20, ó 50 películas con su respectiva imagen y una corta descripción
• que aparezca la calificación del público a la película
• que aparezca la crítica a la película
• que aparezca la distancia del cine a mi ubicación actual (tal vez esta pueda ser otra HU)

Aunque estos criterios de aceptación  son mejor expresados en el formato / template  BDD, de la siguiente manera:

En inglés, 

• GIVEN 
• WHEN
• THEN 

o en español

• DADO
• CUANDO
• ENTONCES

(ver más  de BDD en:

• http://adrianmoya.com/2012/08/que-hay-en-una-historia/ ( o su original en inglés http://dannorth.net/whats-in-a-story/ .
• http://dannorth.net/introducing-bdd/  )

Este template permite la automatización de pruebas funcionales y obvio la mejor escritura de criterios de aceptación, veamos:

• Escenario 1: listar de a 10 películas
• DADO que me encuentro en cualquier sección de la aplicación
• CUANDO selecciono ver listado de películas
• -- Y antes no se ha seleccionado una cantidad de lista diferente 
• ENTONCES el sistema me listará las 10 películas 
• -- Y estás aparecerán en orden de estreno con su respectiva imagen y una descripción corta 

Y de esta misma forma se seguirían escribiendo los otros criterios / escenarios de aceptación...

Aun así ustedes me dirán, pero JORGEEEEE y 

¿la interfaz gráfica y la arquitectura?

R/ Pues tanto para la interfaz como para la arquitectura se definen unos lineamientos básicos para la aplicación antes de comenzar y estos irán evolucionando conforme pasa el tiempo. Si hay que definir algo de la interfaz gráfica se hará un boceto y se validará con el Product Owner durante el Sprint.

¿ y si queda faltando algo?
R/ Fácil, estamos bajo el principio de transparencia,

•  el equipo en el Planning preguntó y
• el Product Owner contestó, y 
• con base en esto se estimaron unos PUNTOS DE HISTORIA (USER STORY POINTS ), 
• se realizó el tasking de lo que se iba a construir (identificación de las tareas para construir las historias de usuario), y
• se estableció el compromiso de las historias a construir en el Sprint.

Por lo tanto, si quedó faltando algún escenario por contemplar,  SIMPLE:

 "ENTRA COMO UNA HISTORIA DE USUARIO NUEVA PARA EL PRODUCT BACKLOG"

(no les parece esto una maravilla, a mí sí)

Esta historia debe ser priorizada, además sino se identificó y es muy importante, podemos contestar: "tranquilo Product Owner en el próximo Sprint lo incluimos que máximo lo comenzamos en 2 semanas".

Y dónde quedan los bugs / incidencias / hallazgos o como le queramos decir...

Wow, este tema con la pregunta anterior era uno de los objetivos a los que tenia con este post, la respuesta es otro abracadaba, "DESAPARECEN o TIENDEN A CERO" (nada por aquí, nada por acá como diría Harry Houdini).

La razón es muy simple, si desarrollamos orientados a casos de prueba una historia de usuario no estará finalizada hasta que cumpla todos sus escenarios y cumpla todos los criterios de DONE,estos son;

• cumplir los aspectos funcionales, 
• cumplir con los criterios de aceptación y de pruebas (ya sean estas manuales o automatizadas).
• encontrarse desplegado y funcionando en un ambiente determinado, llámese ambiente de pruebas, pre-producción, laboratorio, producción -en algunos casos , etc.

Por lo tanto, si una historia de usuario esta DONE significa que:

• fue probada y certificada por el equipo
• fue aceptada por el Producto Owner

Si llegase a existir un "BUG", con plena seguridad afirmo que fue un escenario no identificado, y por lo tanto una historia nueva debe implementarse.

De esta forma las historias de usuario REALMENTE SI CONDUCEN Y DELIMITAN EL DESARROLLO, y see convierten en un punto de encuentro y de sincronización de imagen mental (entre Product Owner y Equipo) de  lo que se desea construir (ni una linea de código adicional más - pues no es necesaria - , ni una menos - pues no cumpliríamos el criterio de DONE - )  y de lo que no se desea construir, pues respecto a esto último, no hay lío, pues nadie lo identificó, o no era necesario en el momento.

Adicionalmente, los costos por garantía  también desaparecen o tienden a cero pues no habrán sorpresas de escenarios no cubiertos en producción.

En Resumen

Las grandes ventajas que he visto son:

• Estamos orientados al resultado y no a la especificación
• No quedan escenarios sin probar, pues estos son explicitados en los criterios de aceptación, situación que si sucede con los casos de uso..
• Lo que esta por fuera de los criterios de aceptación simplemente se convierte en una nueva historia de usuario y se le asignara prioridad
• Cuando una historia de usuario esta DONE!! (CRITERIO DE HECHO, o REALIZADO) y con sus pruebas funcionales automatizadas, se puede dar por olvidada la historia de usuario, en el sentido que no nos tenemos que volver a preocupar de ella pues el desarrollo orientado a casos de prueba garantizará que no quedaron escenarios por cubrir. 

Puedo afirmar con tranquilidad

MIS DÍAS DE DEFENDER LOS CASOS DE USO HAN TERMINADO.

LARGA VIDA A LAS HISTORIAS DE USUARIO

--
Hasta acá mi reflexión,
quedo atento a sus observaciones y comentarios

JORGE HERNÁN ABAD LONDOÑO

MSc. Ingeniería Informática

ScrumAlliance Certified Scrum Master member 000260715