Buscar en Gazafatonario IT

lunes, agosto 12, 2013

Historias de Usuario Altamente Efectivas, 3

VademeScrum, Sección 2: Las Historias de Usuario 3

Cualidad :: Negociable

Historias de Usuario Negociables
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


1 comentario: