Formación 'user stories' biko - mayo 2011

Historias de Usuario

¿Por qué las “historias de usuario”?
Comunicación
Entendimiento compartido del problema-solución
<< Software requirements is a comunication problem >>(User Stories Applied, Cap. 1)
Registrar funcionalidad a medias
Enfatizar la comunicación verbal
Lenguaje comprensible (libre de jerga técnica)

Requisitos
Los RQs no están nunca definidos todos de antemano. Aunque lo estuviesen, NO podrían recogerse de manera PER-FEC-TA.
Enfoque en los aspectos relevantes del momento, aplazando los detalles al momento oportuno.
Promoción del desarrollo oportunista (RQs emergentes).

Planificación
Los proyectos de SW no son perfectamente predecibles
Separación de la estimación del tamaño (puntos) de la del tiempo (horas).
Buen tamaño para planificar
Funcionan bien para el trabajo iterativo

¿Qué son las historias de usuario? (y qué no son)
La historias de usuario…
son la descripción de la funcionalidad de un software,
expresada de forma valiosa para las partes involucradas y útil para la gestión de proyectos de elevada incertidumbre.

Ejemplos de historias de usuario
Un usuario puede buscar un libro insertando cualquier combinación de título e autor.
Un usuario puede poner los libros en el carrito y sucesivamente comprarlos.
Un usuario puede escoger acompañar el envío de un libro con un billete y su propio mensaje
Un supervisor puede ver un informe de las ventas realizadas en el día.
Un usuario puede enviar información acerca de un trabajo a una amiga vía mail.

Recuerdos de unaconversación

Como presidente de España
Necesito atacar Irak
Para encontrar las armas de destrucción masiva

NO ODIES AL USUARIO
debemos determinar por quélo necesitan
COLABORACIÓN

Ejemplo: “Como…” y “Para” son determinantes
Como…
Quiero…
Para…
salir en el Guinnes
un buen pescado
Compartirlo en una cenita romántica
sacar una gran nota en mi examen

Agile Inception: cómo nacen las historias
Las historias deben ser resultado de la colaboración máxima entre cliente y equipo
Evolucionan a lo largo de la vida del proyecto.

Principales características
Las historias de usuario incluyen:
Card. Una breve descripción escrita, como recordatorio
Conversation. Una valiosa conversación, para asegurar el entendimiento y acordar el objetivo
Confirmation. Unos tests funcionales, para fijar algún detalle relevante y limitar el alcance

Título, descripciónCard, Conversation, Confirmation
El título (o descripción) de las historias de usuario es una breve frase que resume su principal objetivo y es útil como recordatorio de la correspondiente conversación.
Es habitual emplear el siguiente formato:
Como [rol],
quiero [característica],
para [valor de negocio].
Formato útil, pero no garantiza que se estén elaborando historias de calidad.
Buscar un buen título estimula la conversación y ayuda a cuestionarse.
Modelado de los roles de usuario, “personajes”, etc.

Ejemplos
COMO gestor del Portal de Navarra, QUIERO poder trabajar en el back-end del CMS con IE8
COMO periodista de la DGCOM de GN, QUIERO clasificar las noticias del TAV mediante un nuevo tema de la taxonomía, PARA mostrarlas automáticamente en la portada del portal del TAV
COMO gestor del PNa, QUIERO medir la mejora SEO producida al resolver el problema de "páginas duplicadas“ del CMS, PARA convencerme de la necesidad de acometer otras mejoras similares

Elementos de conversaciónCard, Conversation, Confirmation
Datos, elementos hablados con el cliente
Diálogos
Notas, apuntes
Prototipos, documentación aportada
Explicitar qué no se incluye
Correcto entendimiento. Visión compartida. Sincronizar las “imágenes mentales”

Glosario
¿sería buena idea tener una lista de términos de negocio, explicados y accesibles?

Pruebas de aceptaciónCard, Conversation, Confirmation
Tienen una doble función según se consideren como:
requerimientos, contribuyen a definir el alcance al expresar algún detalle relevante surgido de la conversación;
test, demuestran la correcta implementación.
Forman parte mínima del Definition of Done
No son una descripción exhaustiva de todo RQ o test. No sustituyen la habilidad personal y el buen entendimiento del dominio/circunstancias.
Se pueden añadir/mejorar sobre la marcha, aunque mejor antes de codificar.
given … when … then … ¿!se podrá automatizar?! ;)

Ejemplo
COMO comercial, QUIERO poderbuscar un cliente, PARA ver los detalles de sucuenta.
Cuandobusque un identificador de cuentaválido, la cuenta se muestra.
Cuandobusquepornumero de SS y nombreválido, la cuenta se muestra.
Si no se encuentranresultados, mostrar el mensajeadecuado

Ejemplo
Historia de usuario
Una empresa anunciadora, puede pagar la publicación de un anuncio de trabajo en la web BigMoneyJobs mediante carta de crédito.
Pruebas de aceptación
Verificar con Visa, MasterCard (pass).
Verificar con American Express (fail).
Verificar con números de carta buenos, malos y parciales.
Verificar con una carta caducada.
Verificar un importe mayor de lo máximo permitido por la carta.
…

Qué no son las historias de usuario
Descripciones técnicas, para eso ya está el equipo
No representan un contrato de alcance cerrado y formal
Una definición exhaustiva de los RQs.
Una descripción completa del sistema.

Creando las historias de usuarioI.N.V.E.S.T.
Las historias de usuario bien planteadas tienen las siguientes características:
Independent (independiente)
Negotiable (negociable)
Valuable (valiosa)
Estimatable (estimable)
Small (pequeña)
Testable (comprobable)

Independent (independiente)
Cada historia es (lo más posible) independiente de otras.
Cada historia es coherente y tiene una alta cohesión.
Problemas?
Las dependencias dificultan planificar, priorizar y estimar.
Combinar historias
Partir historias de manera diferente (más “vertical”)

Negotiable (negociable)
La "tarjeta" de la historia es tan sólo una descripción corta, un recordatorio, sin detalles ni pretensión de exhaustividad.
Se negocia el objetivo y alcance mediante la “conversación“.
Problemas?
Historias largas y detalladas crean una falsa sensación de seguridad.
Sabes que el cliente lo va a cambiar cuando lo vea

Valuable (valiosa)
Cada historia tiene un valor comprensible y tangible para el cliente (posible estimación del ROI – Return Of Investment).
Cada historia añade valor a la aplicación.
Problemas?
Escribir las historias con el cliente. Éste se sentirá cómodo cuando vea que no es un contrato cerrado.
Enfocar los user’sgoal. Evitar los detalles de interfaz.
Usar el lenguaje del dominio. Prescindir de los tecnicismos.

Estimatable (estimable)
El equipo puede manejarse con el alcance de la historia de usuario y proveer una estimación
La estimación permite priorizar la pila de producto y planificar
Problemas?
Mejorar el conocimiento del dominio (ej.: más conversación)
Mejorar los conocimientos técnicos (ej.: “Spike”)
Reducir la complejidad (dividir una historia muy grande)

Small (pequeña)
La justa medida
para poder comprender, estimar y planificar;
Según la dimensión y habilidad del equipo, las tecnologías, etc.
una buena historia debe ser pequeña en esfuerzo, generalmente representando no más de 2-3 personas/semana de trabajo.
Problemas?
Dividir la historia. Una historia que es más grande va a tener más errores asociados a la estimación y alcance.

Testeable
Necesitamos saber cuando terminamos una historia.
No desarrollemos aquello que no podemos probar.
Problemas?
Dividir en historias más pequeñas.
Pensar en las pruebas de aceptación.

“Malos ejemplos de historias” Ejercicio 1
Ejercicio
Objetivo. Aprender a analizar de forma crítica una historia de usuario, sobre la base de los atributos INVEST.

“Malos ejemplos” de historias Ejercicio 1
COMO usuario, QUIERO que la interfaz del sistema sea intuitiva, PARA dominar su funcionamientorápidamente.
Un usuario puedo añadir/editar/borrar múltiples CV.
El proceso de desarrollo producirá documentación CMMI nivel 2.
QUIERO desarrollar la capa de negocio de la aplicación de venta de entradas, PARA luego conectarla con la BBDD.
Como usuario de BigMoneyJobs, QUIERO encontrar un trabajo.

Solución
Objetivo. Aprender a analizar de forma crítica una historia de usuario, sobre la base de los atributos INVEST.

COMO usuario, QUIERO que la interfaz del sistema sea intuitiva, PARA dominar su funcionamientorápidamente.
¿Cómo comprobarlo? Hay conceptos muy ambiguos.
No es independienteporquela interfaz abarca el sistema entero.
Un usuario puede añadir/editar/borrar múltiples CV.
Fácilmente divisible en funcionalidades independientes más pequeñas.
El proceso de desarrollo producirá documentación CMMI nivel 3.
Es un requerimiento no funcional
QUIERO desarrollar la capa de negocio de la aplicación de venta de entradas, PARA luego conectarla con la BBDD.
No aporta valor al usuario.
No permite una entrega incremental de funcionalidad disponible para el usuario. En general: historia ≠ capa de software.
Como usuario de BigMoneyJobs, QUIERO encontrar un trabajo.
Es una funcionalidad valiosa, pero de tamaño excesivo. Incluye múltiples tareas/pasos/objetivos intermedios.

“Independent” user-stories Ejercicio 2
Ejercicio
Objetivo. Enfrentar un típico caso de dependencia entre historias de usuario. Aprender alguna estrategia para resolver este tipo de problemas. Debatir las implicaciones de abordar este problema de una forma u otra.

“Independent” user-storiesEjercicio 2
Card
Conversation
...
(Épica)COMO empresa anunciadora, QUIERO pagar un anuncio de trabajo vía web, PARA que quede inmediatamente publicado
Confirmation
Puedo pagar con tarjetas tradicionales (VISA, Mastercard, American Express), o PayPal.
Ahhh… también con electrónicas (VISA electron)
Emplear el TPV de mi banco.
…

Ejemplo de dependencia Ejercicio 2
Posible planteamiento en historias de usuario
La empresa puede pagar un anuncio con Mastercard.
La empresa puede pagar un anuncio con VISA.
La empresa puede pagar un anuncio con American Express.
La empresa puede pagar un anuncio con una carta VISA Electron.
La empresa puede pagar un anuncio con PayPal.
etc.
Problema de dependencia entre las historias de usuario planteadas
La estimación de las historias depende del orden de ejecución
algunas historias dependen del uso del mismo TPV
<< La primera me costará más, no he usado nunca un TPV… >>
Muy similar
Mismo TPV

“Independent” user-stories Ejercicio 2
Solución
Objetivo. Enfrentar un típico caso de dependencia entre historias de usuario. Aprender alguna estrategia para resolver este tipo de problemas. Debatir las implicaciones de abordar este problema de una forma u otra.

Soluciones a la dependencia Ejercicio 2
Algunas posibles estrategias para resolver los problemas de dependencia:
Combinar las historias dependientes en una única historia independiente
La empresa puede pagar un anuncio con las cartas de crédito tradicionales (VISA, Mastercard, American Express).
Separar las historias de otra manera
Separar las historias introduciendo un “spike”
Investigar el uso del nuevo TPV.
Separar las historias bajo otro punto de vista
La empresa puede pagar un anuncio con una carta de crédito (ej.: VISA).
La empresa puede pagar un anuncio con otras cartas adicionales (ej.: Mastercard, American Express).
Hacer una doble estimación de las historias de usuario dependientes.

“Valuable” user-stories Ejercicio 3
Ejercicio
Objetivo. Aprender a expresar los conceptos y las necesidades técnicas de una forma más comprensible y valiosa para el cliente.

“Valuable” user-storiesEjercicio 3
Ejemplos con problemas
Las conexiones a la BBDD serán mediadas por un connection pool.
La gestión de los errores y del logging se llevarán a cabo mediante un conjunto de clases comunes a todo el portal.
Como usuario, quiero disponer de un API para hacer búsquedas
Como usuario, quiero tener un gadget de escritorio para buscar por nombre
¿Cómo podríamos darle la vuelta?

“Valuable” user-stories Ejercicio 3
Solución
Objetivo. Aprender a expresar los conceptos y las necesidades técnicas de una forma más comprensible y valiosa para el cliente.

Ejemplos de posibles solución
Las conexiones a la BBDD serán mediadas por un connection pool.
La aplicación podrá ser usada de forma concurrente por 15 usuarios con una licencia de BBDD de 5 usuarios.

Ejemplos de posible solución
La gestión de los errores y del logging se llevarán a cabo mediante un conjunto de clases comunes a todo el portal.
Los mensajes de error serán presentados al usuario y registrados para posteriores análisis de una forma coherente.

Casos particulares: épicas
Las épicas son historias de usuario “grandes”, por su tamaño (puntos) y/o dedicación (horas).
Proporcionan una visión de alto nivel.
Valiosas para la planificación inicial del sistema.
Generalmente incluyen trabajo para varias iteraciones.
Deben ser divididas en más pequeñas.

Ejemplos:
“Que la aplicación sea bonita”
“Que el rendimiento sea bueno”
¿ Llevarlo al DoD de las historias?
¿ Realizar tareas independientes?
Casos particulares: RQs no funcionales

Casos particulares: RQs técnicos
El equipo de desarrollo puede necesitar definir trabajos no funcionales
¿rendimiento?
¿desarrollos estructurales?
Muchas veces son tareas necesarias, ¿por qué trabajarlas como historia?
“Necesito configurar el maven
con la integración continua”

Historias de usuario y Scrum
La “userstories” son una herramienta surgida de Extreme Programming (XP). Se han vuelto un estándar de-facto para Scrum; aunque Scrum sólo exige una “pila de producto” compuesta de “tareas”.
Reunión de “planificación de producto”
Conversación con el cliente, visión del proyecto, valorar alternativas, esbozar soluciones, etc.
Se crean épicas/historias (Card, Conversation, Confirmation).
Reunión de “planificacion de sprint”
Planificas en base a historias estimadas
Definition of Done (DoD)
Deberá pasar los test de aceptación

Propiedades
Prioridad
Dependencias
Backlog plano, o mapa(http://www.agileproductdesign.com/blog/the_new_backlog.html)
Valor de negocio (¿ROI?)

Historias: alineadas con el Manifiesto Ágil
Manifiesto por el Desarrollo Ágil de Software
Estamos descubriendo mejores maneras de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de esta experiencia hemos aprendido a valorar:
Individuos e interacciones, sobre procesos y herramientas
Software que funciona, sobre documentación exhaustiva
Colaboración con el cliente, sobre negociación de contratos
Responder ante el cambio, sobre seguimiento de un plan
Esto es, aunque los elementos a la derecha tienen valor, nosotros valoramos por encima de ellos los que están a la izquierda.

“Twitter. Historias de Usuario” Ejercicio 4
Ejercicio
Objetivo. Practicar la técnica de las historias de usuario sobre un caso real. Crear ocasión de debate.

Relación entre historias, alcance y disciplinas
En general: historia ≠ capa de software
Focusonthedelivery of features
<< customersget no valuefromthecompletion of activities >>(Agile Estimating and Planning, p. 12)

División de una historia en tareas
H = ∑ T1+T2+…+Tn+DoD+∆
<< no garanteethatthesum of theseperfectspartsis a perfectwhole >> (UserStoriesApplied, p.147)
Comprobación DoD (delta a sumar a las tareas de una historia)
Grafica de coste vs. detalle
Historia ≠ ∑ tareas

Indicadores
PRIORIDAD: Prioridad en la implementación de una historia de usuario respecto al resto. A mayor número, mayor prioridad. Otra aproximación a la priorización de tareas se hace a través del método MoSCoW:
M – Must, se debe completar este requerimiento para finalizar el proyecto
S – Should, se debe completar este proyecto por todos los medios, pero el éxito del proyecto no depende de él.
C – Could, se debería completar este requerimiento si su implementación no afecta a la consecución de los objetivos principales del proyecto.
W – Would, se puede completar este requerimiento si sobra tiempo de desarrollo (o en futuras versiones del mismo)

Historias de usuario vs. casos de uso

http://www.smartsite.es	149
http://www.biko2.com	12
http://twitter.com	2
https://twitter.com	1
http://paper.li	1

Formación 'user stories' biko - mayo 2011

by Jose Ramón Díaz on May 23, 2011

Accessibility

Categories

Tags

Upload Details

Usage Rights

5 Embeds 165

Statistics

Formación ’user stories’ biko - mayo 2011 — Presentation Transcript