VademeScrum, Sección 2:
Las Historias de Usuario 3
Cualidad :: Negociable
 |
| Las Historias de Usuario se negocian entre los usuarios y el equipo de desarrollo |
Una buena historia de usuario permite
que entre el negocio y el equipo del proyecto haya arreglos flexibles o un balance
entre la funcionalidad a construir y las fechas de entrega. Un aspecto
importante a tener en cuenta es que una historia de usuario se puede convertir
fácilmente en dos o más, adicionando o eliminando criterios de aceptación,
modificando el objetivo o valor del negocio de la historia y aun la misma
actividad que implementa la historia. Los buenos equipos de desarrollo detectan
a tiempo y rápidamente los aspectos que se pueden negociar de una historia con
el usuario (por ejemplo con el Dueño del Producto) y establecen las razones por
las cuales debería modificarse el alcance expuesto en una historia o la fecha
de entrega de la misma.
Esta última puede ser en una iteración
posterior, en una entrega (release) futura, o en una eventual versión
que esté pendiente por definir. Una práctica útil en estos casos es clasificar
las historias en:
- Requeridas o críticas
- Importantes
- Opcionales
- No se construirán
Esta clasificación también nos ofrece
un marco de negociación. Incluso una tipificación de este tipo se puede aplicar
rápidamente a cada criterio de aceptación de la historia, lo que permitiría
ampliar el margen de negociación con los usuarios o con el negocio. Las
historias requeridas son aquellas sin las cuales la solución no puede vivir
(van en las primeras entregas); entre tanto, las importantes son aquellas sin
las cuales el sistema puede vivir durante algún tiempo, es decir, podemos salir
a producción sin estas, pero van en las entregas intermedias del proyecto.
Las historias opcionales, por su
parte, son aquellas funcionalidades conocidas coloquialmente como las “buenas,
bonitas y baratas”, es decir, aquellas que si hay tiempo y presupuesto se
construyen y van en las entregas finales del proyecto. En ocasiones también es
importante establecer funcionalidades que no se construirán debido quizás a
restricciones de presupuesto o de tiempo o simplemente porque no tienen ningún
valor para el negocio.
Historia
Negociable 1
Como: Bloguero
Quiero: hacer una
entrada al blog
Para: posicionarme
como experto en un tema específico
Criterios de Aceptación:
- Debo ser capaz de publicar contenido multimedia (imágenes y video)
- El texto de la entrada debe ser enriquecido (que permita enlaces Web, formato, etc.)
- La entrada se debe poder compartir vía redes sociales
- La entrada se debe poder imprimir
- La entrada se debe poder enviar vía correo electrónico
Durante la negociación podemos llegar
a acuerdos con los usuarios, por ejemplo, en una primera iteración podríamos
solo permitir la publicación de texto en la entrada, más adelante podríamos
permitir la adición de contenido multimedia. En otra iteración, quizás en otra
entrega, podremos permitir que la entrada se comparta vía redes sociales y por
correo electrónico. Incluso podríamos llegar a la conclusión de no implementar
la funcionalidad de impresión de la entrada y dejar simplemente que el lector
imprima usando las características que vienen con su navegador Web.
Las cosas así, esta historia de
usuario podría convertirse en:
ID:
Hacer una entrada básica al blog
Como: Bloguero
Quiero: hacer una
entrada al blog
Para: posicionarme
como experto en un tema específico
Criterios de Aceptación:
- El texto de la entrada debe ser enriquecido (que permita enlaces Web, formato, etc.)
Los demás criterios de aceptación
estarán presentes en otras historias “Hacer una entrada al blog”, como por
ejemplo:
ID:
Hacer una entrada al blog para compartir
Como: Bloguero
Quiero: hacer una
entrada al blog
Para: posicionarme
como experto en un tema específico
Criterios de Aceptación:
- La entrada se debe poder compartir vía redes sociales
- La entrada se debe poder enviar vía correo electrónico
O esta otra:
ID:
Hacer una entrada básica al blog con contenido multimedia
Como: Bloguero
Quiero: hacer una
entrada al blog
Para: posicionarme
como experto en un tema específico
Criterios de Aceptación:
- Debo ser capaz de publicar contenido multimedia (imágenes y video)
Recomendaciones
La negociación de las historias de
usuario es parte fundamental de todo proyecto ágil. Y como en todo proyecto ágil,
es necesario tener a los usuarios, representados quizás por un Dueño de
Producto, y al equipo de desarrollo, del mismo lado. Habrá una negociación
fluida si el usuario está realmente interesado en el éxito del proyecto, si está
dispuesto a comunicarse de manera efectiva y a trabajar con el equipo. Y tanto
el usuario como el equipo de desarrollo deben tener en cuenta que las historias
de usuario, incluyendo sus pruebas de aceptación, evolucionan iteración tras
iteración. Además, el enfoque que se use para abordar y negociar los requisitos
del negocio, también se puede aplicar a los requisitos técnicos o no
funcionales.
Resumiendo, una historia de usuario no
es un contrato firmado en piedra con sangre, más bien es una carta de intención
de algo que el sistema debe hacer y cuyos detalles se abordan durante la
conversación entre el usuario (Dueño del Producto) y el equipo de desarrollo. Y
esto se hace justo antes de iniciar la construcción de esa historia, en el caso
de proyectos conducidos con Scrum, esta negociación puede hacer parte de la
Reunión de Planeación, pero no está supeditada a este marco de tiempo nada más,
puede ocurrir en cualquier momento durante un sprint. Además, la negociación es
una habilidad en la que deben trabajar los equipos de desarrollo, ya no es más
un asunto que atañe solo a los comerciales de la organización de software.
Artículos Relacionados
El artículo donde presento las
Historias de Usuario, a manera de introducción: Historias de Usuario: un
nuevo orden en los requisitos del software, lo encuentran en:
La primera parte de esta serie de
artículos sobre los atributos INVEST y las buenas historias de usuario: Historias de Usuario Altamente Efectivas, Parte 1. Lo encuentran en:
La parte 2 de esta serie de artículos
sobre los atributos INVEST y las buenas historias de usuario: Historias de Usuario Altamente Efectivas, Parte 2 – Cualidad :: Independiente.
Lo encuentran en:
Referencias
- INVEST in Good Stories, and SMART Tasks
- A User Story Primer, by Dean Leffingwell with Pete Behrens
- User Stories Applied, by Mike Cohn
Gracias, saludos desde Colombia
ResponderBorrar