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.
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"..
- 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,
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.
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.
"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
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 |
