viernes, 25 de julio de 2008

User Stories

Las User Stories describen funcionalidades de un sistema de software que aportan valor al usuario y/o al cliente. Una User Story está compuesta por:
  • Una descripción escrita de la funcionalidad, usada para planificar y como recordatorio (normalmente se escriben en post-it y se pegan en pizarras para que el equipo las tenga presentes mientras está desarrollando)
  • Conversaciones sobre la story, que sirven para despejar las dudas y los detalles de la funcionalidad
  • Pruebas de aceptación (UAT), que sirven como documentación y pueden ser usadas para determinar cuándo una story está completa y libre de bugs.
Las User Stories son la unidad más pequeña de incremento del sistema y la unidad de estimación y control en un entorno ágil. Incluye los objetivos y motivaciones del usuario. Un caso de uso normalmente es más grande que una user story. Por ejemplo, cada camino dentro de un caso de uso podría ser una user story.

Descripción Escrita

Es importante entender que los post-it o tarjetas con la descripción escrita son sólo una parte muy pequeña de una user story. La parte más importante es la conversación, donde el usuario le explica al desarrollador qué es exactamente lo que quiere y los detalles de la funcionalidad. El desarrollador podría escribir anotaciones en la parte trasera del post-it, pero si lo hace tiene que ser algo cortito, una pequeña anotación de pocas palabras, nada más.

Un ejemplo de descripción escrita para user story podría ser:

Como buscador de trabajo quiero poder subir mi curriculum a la página para que las consultoras me llamen si están interesadas.

Es necesario que conste el para qué en la descripción escrita, ya que esto permite tomar decisiones con respecto al diseño, a cómo resolver el problema. Si el usuario no explica para qué quiere esa funcionalidad, es probable que el desarrollador no entienda toda la perspectiva del requerimiento y no codifique lo que el usuario necesita.

Como <rol de usuario>, quiero <función del sistema> para poder <valor de negocio>

También es importante que el rol del usuario esté bien especificado. Poner un usuario genérico o un usuario muy específico son errores muy comunes a la hora de escribir los post-it. Un post muy interesante del blog de Assembla titulado "Do's and Dont's for User Stories, Use Cases, Scenarios" trata sobre estos temas. Básicamente lo que dice es que si tenemos problemas a la hora de la construcción, tenemos que tener bien claro a quién podemos llamar para resolver alguna duda que se haya presentado sobre la funcionalidad o el negocio, pero tampoco es bueno que el usuario sea demasiado específico, por ejemplo Pepe, porque la agenda de Pepe puede ser estrecha y puede que no sea fácil encontrarlo. Además Pepe no existe como rol dentro del producto. Pepe es un individuo, la instancia de un rol. Cuando escribimos las user stories hablamos de roles de usuario.

Pruebas de Aceptación

Las user stories son notas, recordatorios de una conversación. ¿Cómo termina la conversación? Puede ser en un documento, en una pantalla, en un prototipo, pero nada de esto es obligatorio. Lo importante es que quede definido cómo se va a aceptar y para esto las Pruebas de Aceptación automatizadas son ideales.

¿Por qué automatizadas? Porque para "abrazar al cambio" (lema fundamental del manifiesto ágil) debemos reaccionar de forma rápida ante él. En un negocio donde los cambios se dan constantemente y el código es refactoreado todos los días, las pruebas de regresión se multiplican exponencialmente. Tediosa y muy susceptible a errores sería la tarea de un tester si todos los días tuviera que probar lo mismo de forma manual.

Cuando un miembro del equipo está conversando con el usuario sobre una user story, un tipo de anotaciones que puede hacer en la cara opuesta del post-it es el de recordatorio sobre cómo testear la story. Por ejemplo, uno podría escribir:
  • Probar subir un curriculum dañado
  • Probar subir un curriculum vacío
  • Probar dejar vacío el campo de Nombre
  • Probar dejar vacío el campo de Remuneración Pretendida

Dividir una User Story épica

Cuando una user story es demasiado grande se dice que es épica. Programar una user story épica podría llevar un mes, un año, lo que sea; la cuestión es que seguro va a tomar más tiempo que la duración de una iteración (pequeñas para cualquier metodología ágil) y va a resultar imposible estimarla. Por eso las user story épicas hay que dividirlas.

Algunos criterios de división pueden ser:
  • Por Datos: Por ejemplo, si tengo un formulario web podría empezar con pocos datos. Podría construir los campos de Nombre del Postulante, Teléfono y Remuneración Pretendida. Y más adelante agregar otra user story con los campos que faltan.
  • Por Casos Especiales: Por ejemplo, si tengo un caso especial de que se tiene que registrar un extranjero, pero necesita llenar unos datos especiales y hay que dar de alta otros registros. El caso de alta de los extranjeros puede ir para otra user story.
  • Por Operaciones: Se podría dividir la Alta, Baja y Modificación en tres user stories diferentes.
  • Por Temas cross y no funcionales: Podría empezar con una implementación que no maneje seguridad, log, manejo de errores, performance, volumen, e irlos agregando en siguientes iteraciones.
  • Por Prioridad: No es bueno tener una user story que abarca funcionalidad de distintas prioridades. Por ejemplo: "Como vendedor de Cta Cte quiero poder dar de alta y buscar facturas para poder almacenarlas y después imprimirlas como indica la ley". Probablemente el dar de alta sea imprescindible, pero el buscar se pueda dejar para otra iteración. Cuando las prioridades están mezcladas, se termina invirtiendo tiempo en funcionalidades de baja prioridad, dejando sin hacer otras de mayor prioridad.
Al dividir una user story hay que tener en cuenta cuáles son los Minimum Marketable Features del producto. Esto es: el conjunto de mínimas funcionalidades con la que el producto puede instalarse en producción.

¿Qué tan larga tiene que ser una User Story?

Recién vimos criterios de división para cortar una user story para que fuera estimable y que pudiera construirse en una iteración. Sin embargo, no es imprescindible llegar a que la user story tenga un detalle atómico.

En general, no tiene sentido dividir una user story:
  • Por debajo de un tiempo estimado de 2 o 5 días (pensando en iteraciones un poco más largas, de dos o tres semanas)
  • En tareas: Hay que dividir por funcionalidad, no por tareas!

User Stories Efectivas

Así como para UML tenemos buenas practicas para escribir Casos de Uso Efectivos, también existen para User Stories y están descriptas en detalle en el libro de Mike Cohn: "User Stories Applied For Agile Software Development".

Cohn dice que una buena User Story debe ser:
  • Independiente: No debe depender de otra user story.
  • Negociable: Las user stories no son obligaciones contractuales, son simplemente descripciones de funcionalidades, que pueden cambiar o negociarse en cualquier momento.
  • Valiosa para el Cliente o el Usuario: Consideremos una user story de este estilo: "El software debe estar escrito en C++" o "El programa se conectará a la Base de Datos a través de un pool de conecciones". Al usuario realmente no le interesan estos detalles. Éstas no son user stories.
  • Estimable: La funcionalidad que describe tiene que tener un tamaño que un desarrollador pueda estimar. Hay tres razones comunes por las que una user story puede resultar imposible de estimar: 1) Falta de conocimiento del dominio por parte de los desarrolladores, 2) Falta de conocimiento técnico por parte de los desarrolladores, 3) La user story es demasiado grande.
  • Pequeña: Por todo lo que ya estuvimos viendo.
  • Testeable: Deben poder ser testeadas para que los desarrolladores puedan asegurar que la funcionalidad está completa y funcionando correctamente (por lo general por medio de los UAT). Ejemplos de user stories no testeables: 1) "Como operario quiero que el software sea fácil de usar...", 2) "Como data entry quiero nunca tener que esperar demasiado para que una pantalla aparezca...". ¿Qué es fácil de usar? ¿Qué es esperar mucho?

Responsabilidades de los Desarrolladores

Los desarrolladores son responsables de:
  • Ayudar al cliente a escribir user stories efectivas, y conseguir toda la información necesaria mediante la conversación y quizá algunas de las técnicas de relevamiento vistas en mi post de Team Skill 2: Entendiendo las Necesidades del Usuario, como Prototipos, Demos o Storyboards.
  • Si se ven tentados a preguntar o incluir una story sobre el uso de una tecnología o una pieza de infraestructura, por ejemplo, intentar describir la necesidad en términos de valor para el usuario o el cliente.
En Scrum, por ejemplo, estas responsabilidades caen sobre el rol del Scrum Master o de algún analista del equipo.

Responsabilidades de los Clientes

Los clientes son responsables de:
  • Escribir stories efectivas, que definan funcionalidad de tamaño apropiado, independientes, generen valor para el usuario o para él mismo (es responsable de que el producto tenga algún sentido) y de que sean testeables.
En Scrum, por ejemplo, estas responsabilidades caen sobre el rol del Product Owner.