User-Story-Primer 1 Es [PDF]

Zitiervorschau

Leffingwell, LLC.

Introducción a una historia de usuario

Por Dean Leffingwell con Pete Behrens Resumen: En este documento técnico, proporcionamos una descripción general sobre la derivación y aplicación de historias de usuario, que son el mecanismo ágil principal que lleva los requisitos del cliente a través del flujo de valor del desarrollo de software ágil. A su vez, las historias de usuario son un elemento crítico del modelo de información de requisitos ajustables y escalables para empresas ágiles y el panorama general de la agilidad empresarial, los cuales se pueden encontrar en el blog.http://scalingsoftwareagility.wordpress.com/. Este documento se extrajo del próximo libro Agile Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise, programado para su publicación en 2010. Un agradecimiento especial a Jennifer Fawcett y Don Widrig por sus contribuciones también.

© 2009, Leffingwell, LLC. Reservados todos los derechos.

Contenido Introducción3 .......................................................................................................................................... Usuario Descripción general de la historia3 ........................................................................................ Las historias de usuario ayudan a tender puentes entre el desarrollador y la comunicación con el cliente Gap4 ........................................................................................................................................ Las historias de usuario son No Requisitos4 ....................................................................................... Usuario Formulario de historia 5 ............................................................................................................ Tarjeta, Conversación y Confirmación5 .............................................................................................. Usuario Story Voice5 ........................................................................................................................... Usuario Detalle de la historia6 ............................................................................................................ Historia del usuario Criterios de aceptación6 ..................................................................................... INVERTIR en el bien Historias de usuarios7 ............................................................................................ Independiente7 ................................................................................................................................... Negociable... y Negociado8 ................................................................................................................. Valioso8 ............................................................................................................................................... Estimado9 ........................................................................................................................................... Pequeño9 ............................................................................................................................................ Comprobable11................................................................................................................................... Terrible Historias de usuarios11 ............................................................................................................. Picos14 .................................................................................................................................................... Guias para Picos14 .............................................................................................................................. Modelado de historias con Fichas15 ....................................................................................................... Resumen16 .............................................................................................................................................

© 2009, Leffingwell, LLC. Reservados todos los derechos.

Introducción a una historia de usuario Han estado en una gran fiesta de idiomas y se han echado a perder. - Moth to Costard, Love's Labor's Lost, Acto 5, escena 1, William Shakespeare

Introducción En el desarrollo ágil, la historia del usuario es un sustituto ligero y más ágil de lo que ha sido nuestro medio tradicional para especificar los requisitos de software: especificaciones de requisitos de software, especificaciones de casos de uso y similares. De hecho, se puede argumentar que la historia del usuario es el artefacto más importante en el desarrollo ágil, porque es el contenedor que principalmente lleva el flujo de valor al usuario, y el desarrollo ágil tiene que ver con la entrega rápida de valor. La historia del usuario también sirve como metáfora de todo nuestro enfoque de entrega de valor incremental, es decir: Defina una historia de valor para el usuario valiosa: impleméntela y pruébela en una breve iteración demostrar y/o envíelo al usuario: recopile comentarios, aprenda y repita para siempre.

He hablado brevemente de las historias de los usuarios en el contexto de mis documentos técnicos más amplios, Un modelo de información de requisitos ajustables y escalable para empresas ágiles y El panorama general de la agilidad empresarial1, donde, junto con los temas, las epopeyas y las características, son los principales artefactos de requisitos que se utilizan por los equipos ágiles. En este documento técnico, describiremos la historia del usuario con más detalle, porque es aquí donde encontraremos una de las prácticas ágiles clave que nos ayudan a alinear nuestra solución directamente con las necesidades específicas del usuario y, al mismo tiempo, ayudan a asegurar la calidad. . Descripción general de la historia de usuario En los documentos técnicos a los que se hace referencia y la serie de blogs relacionados, he destacado muchas de las contribuciones del modelo Scrum a las prácticas empresariales ágiles, destacando, por ejemplo, la definición del rol del propietario del producto, que es parte integral de nuestras prácticas de requisitos. Pero es a XP a quien le debemos la invención de la historia del usuario, y son los defensores de XP los que han desarrollado la amplitud y profundidad de este artefacto. Sin embargo, esto es menos una "bifurcación metodológica en el camino" de lo que podría parecer, ya que las historias de usuario ahora se enseñan de forma rutinaria dentro de las construcciones de la capacitación de Scrum como una herramienta para construir la acumulación de productos y definir el contenido de Sprint. Quizás tengamos que agradecer a Mike Cohn por gran parte de esta integración, ya que ha desarrollado historias de usuarios extensamente en su libro User Stories Applied [Cohn 2004], Para nuestros propósitos, definiremos una historia de usuario simplemente como: Una historia de usuario es una breve declaración de intenciones que describe algo que el sistema debe hacer por el usuario.

En XP, las historias de usuario a menudo las escribe el cliente, integrando así al cliente directamente en el proceso de desarrollo. En Scrum, el propietario del producto a menudo escribe las historias de los usuarios, con aportes de los clientes, las partes interesadas y el equipo. Sin embargo, en la práctica, cualquier miembro del equipo con suficiente conocimiento del dominio puede escribir historias de usuario, pero depende del propietario del producto aceptar y priorizar estas historias potenciales en la © 2009, Leffingwell, LLC. Reservados todos los derechos.

cartera de pedidos del producto. 1

www.scalingsoftwareagility.wordpress.com

© 2009, Leffingwell, LLC. Reservados todos los derechos.

Las historias de usuario son una herramienta para definir el comportamiento de un sistema de una manera que sea comprensible tanto para los desarrolladores como para los usuarios. Las historias de usuario centran el trabajo en el valor definido por el usuario en lugar de en una estructura funcional de desglose, que es la forma en que tradicionalmente se ha asignado el trabajo. Proporcionan un enfoque ligero y eficaz para gestionar los requisitos de un sistema. Una historia de usuario captura una breve declaración de función en una tarjeta de índice, o quizás con una herramienta en línea. Ejemplos: Inicie sesión en mi portal web de monitoreo de energía. Vea mi uso diario de energía. Verifique mi tarifa actual facturación de electricidad Los detalles del comportamiento delde sistema no aparecen en la declaración breve, y se dejan para que se desarrollen más adelante a través de conversaciones y criterios de aceptación entre el equipo y el propietario del producto.

Las historias de usuarios ayudan a cerrar la brecha de comunicación entre desarrolladores y clientes En el desarrollo ágil, el trabajo del desarrollador es hablar el idioma del usuario, no el trabajo del usuario hablar el idioma de la tecnología. La comunicación eficaz es la clave y necesitamos un lenguaje común. La historia del usuario proporciona el lenguaje común para generar entendimiento entre el usuario y el equipo técnico. Bill Wake, uno de los creadores de XP, lo describe de esta manera2: Un lenguaje pidgin es un lenguaje simplificado, generalmente utilizado para el comercio, que permite a las personas que no pueden comunicarse en su idioma nativo trabajar juntas. Las historias de usuario actúan así. No esperamos que los clientes o usuarios vean el sistema de la misma manera que lo hacen los programadores; las historias actúan como un lenguaje pidgin en el que ambas partes pueden ponerse de acuerdo lo suficiente como para trabajar juntas de manera efectiva.

Con las historias de usuario, no tenemos que entender el idioma de los demás con el grado de competencia necesario para elaborar un soneto; ¡Solo necesitamos entendernos lo suficiente como para saber cuándo hemos llegado a un acuerdo adecuado! Las historias de usuario no son requisitos Si bien las historias de usuario hacen la mayor parte del trabajo realizado anteriormente por las especificaciones de requisitos de software, casos de uso y similares, son materialmente diferentes en una serie de formas sutiles pero críticas. • • • • •

•

•

No son especificaciones de requisitos detalladas (algo que un sistema debe hacer) sino más bien expresiones de intención negociables (necesita hacer algo como esto) Son breves y fáciles de leer, comprensibles para los desarrolladores, las partes interesadas y los usuarios. Representan pequeños incrementos de funcionalidad valiosa, que se pueden desarrollar en un período de días a semanas. Son relativamente fáciles de estimar, por lo que el esfuerzo para implementar la funcionalidad se puede determinar rápidamente. No se incluyen en documentos grandes y difíciles de manejar, sino que se organizan en listas que se pueden organizar y reorganizar más fácilmente a medida que se descubre nueva información. No se detallan al principio del proyecto, pero se elaboran justo a tiempo. - evitando así la especificidad demasiado temprana, las demoras en el desarrollo, el inventario de requisitos y una declaración de la solución demasiado restringida Necesitan poco o ningún mantenimiento y se pueden desechar de forma segura después de la © 2009, Leffingwell, LLC. Reservados todos los derechos.

implementación3

2 3

http://xp123.com/xplor/xp0308/index.shtml Sujeto al desarrollo y persistencia de pruebas de aceptación, que definen el comportamiento del sistema con detalle comprobable por regresión.

© 2009, Leffingwell, LLC. Reservados todos los derechos.

•

Las historias de usuario y el código que se crea rápidamente a partir de entonces sirven como entradas para la documentación, que luego también se desarrolla de forma incremental.

Formulario de historia de usuario Tarjeta, conversación y confirmación Ron Jeffries, otro de los creadores de XP, describió lo que se ha convertido en nuestra forma favorita de pensar sobre las historias de los usuarios. Usó la aliteración, la tarjeta, la conversación y la confirmación4 para describir los tres elementos de una historia de usuario. Dónde: Tarjeta representa 2-3 oraciones que se utilizan para describir la intención de la historia. La tarjeta sirve como un token memorable, que resume la intención y representa un requisito más detallado, cuyos detalles quedan por determinar. Nota: En XP y ágil, las historias a menudo se escriben manualmente en fichas físicas. Más típicamente en la empresa, el elemento "tarjeta" se captura como texto y archivos adjuntos en una hoja de cálculo o herramientas de gestión de proyectos ágiles, pero los equipos a menudo todavía usan tarjetas para la planificación temprana y la lluvia de ideas, como adelante. Conversacion representa una veremos discusiónmás entre el equipo, el cliente, el propietario del producto y otras partes interesadas, que es necesaria para determinar el comportamiento más detallado necesario para implementar la intención. En otras palabras, la tarjeta también representa una "promesa de conversación" sobre la intención. Confirmación representa la prueba de aceptación, que es la forma en que el cliente o propietario del producto confirmará que la historia se ha implementado a su satisfacción. En otras palabras, la Confirmación representa las condiciones de satisfacción que se aplicarán para determinar si la historia cumple o no con la intención, así como con los requisitos más detallados. Con esta simple aliteración, tenemos una lección objetiva sobre cómo se logra la calidad en ágil durante, en lugar de después, el desarrollo de código real. Lo hacemos simplemente asegurándonos de que cada nueva historia de usuario sea a) se discute y perfecciona con el detalle necesario, y b) se prueba a satisfacción de las partes interesadas clave. Voz de la historia de usuario En los últimos años, se ha aplicado una nueva forma estandarizada que fortalece significativamente la construcción de la historia del usuario. El formulario es el siguiente: Como puedo para que donde: •

• •

Rol - representa quién está realizando la acción o quizás alguien que está recibiendo el valor de la actividad. Incluso puede ser otro sistema, si eso es lo que está iniciando la actividad. Actividad - representa la acción que debe realizar el sistema. Valor de negocio - representa el valor para el negocio.

© 2009, Leffingwell, LLC. Reservados todos los derechos.

4

http://xprogramming.com/xpmag/expcardconversationconfirmation/

© 2009, Leffingwell, LLC. Reservados todos los derechos.

A esto lo llamamos la forma de expresión de la historia de usuario de “voz del usuario” y lo consideramos una construcción extremadamente útil5 porque abarca el espacio del problema ( entregado) y el espacio de la solución ( que el usuario realiza con el sistema). También proporciona una perspectiva de usuario primero () al equipo, lo que los mantiene enfocados en el valor comercial y en la resolución de problemas reales para personas reales. Esta forma de historia de usuario mejora en gran medida la comprensión de por qué y cómo los desarrolladores necesitan implementar un sistema que realmente satisfaga las necesidades de los usuarios. Por ejemplo, un usuario de un sistema de gestión de energía en el hogar podría querer: 6 Como consumidor, () Quiero poder ver mi uso diario de energía. () para que pueda comenzar a comprender cómo reducir mis costos con el tiempo ().

Cada elemento proporciona un contexto expansivo importante. El rol permite una segmentación de la funcionalidad del producto y, por lo general, extrae otras necesidades basadas en el rol y el contexto de la actividad. Por lo general, la actividad representa el "requisito" que necesita el rol. Y el valor comunica por qué se necesita la actividad, lo que a menudo puede llevar al equipo a encontrar posibles actividades alternativas que podrían proporcionar el mismo valor por menos esfuerzo. Detalle de la historia de usuario

Los detalles de las historias de usuario se transmiten principalmente a través de una conversación entre el propietario del producto y el equipo, lo que mantiene al equipo involucrado desde el principio. Sin embargo, si se necesitan más detalles sobre la historia, se pueden proporcionar en forma de un archivo adjunto (maqueta, hoja de cálculo, algoritmo o lo que sea), que se adjunta a la historia del usuario. En ese caso, la historia del usuario sirve como la "ficha" que también lleva el comportamiento más específico al equipo. Los detalles adicionales de la historia del usuario deben recopilarse a lo largo del tiempo (justo a tiempo) a través de discusiones y colaboración con el equipo y otras partes interesadas antes y durante el desarrollo. Criterios de aceptación de la historia de usuario Además de la declaración de la historia del usuario, se pueden guardar notas adicionales, suposiciones y criterios de aceptación con una historia de usuario. Es probable que muchas discusiones sobre una historia entre el equipo y los clientes tengan lugar antes y durante el tiempo en que la historia está comprometida con el código. Los flujos alternativos en la actividad, los límites de aceptación y otras aclaraciones deben capturarse junto con la historia. Muchos de estos se pueden convertir en casos de prueba de aceptación u otros casos de prueba funcionales para la historia. Por ejemplo, Como consumidor, quiero poder ver mi uso diario de energía para poder comenzar a comprender cómo reducir mis costos con el tiempo. Criterios de aceptación: • Leer los datos del medidor DecaWatt cada 10 segundos y mostrarlos en el portal en incrementos de 15 minutos y mostrarlos en la pantalla del hogar cada lectura • Lea los medidores de kilovatios para ver los nuevos datos disponibles y visualícelos en el portal cada hora y en la pantalla del hogar después de cada lectura. • No hay tendencias de varios días por ahora (otra historia). Etc ...

Los Criterios de aceptación no son pruebas funcionales o unitarias, sino que son las condiciones de satisfacción que se colocan en el sistema. Las pruebas funcionales y unitarias son mucho más profundas en la prueba de todos los flujos funcionales, flujos de excepción, condiciones de límite y funcionalidad relacionada asociada con la historia.

© 2009, Leffingwell, LLC. Reservados todos los derechos.

5

Mientras buscaba el origen de esta forma, Leffingwell recibió la siguiente nota de Mike Cohn: “Comenzó con un equipo en Connextra en Londres y fue mencionado en XP2003. Comencé a usarlo entonces y escribí sobre él en mi libro de 2004, User Stories Applied." 6 Gracias a Jennifer Fawcett de Tendril Networks por proporcionar estos ejemplos

© 2009, Leffingwell, LLC. Reservados todos los derechos.

INVIERTA en buenas historias de usuarios Los equipos ágiles dedican una cantidad significativa de tiempo (quizás la mitad o más) a descubrir, elaborar y comprender las historias de los usuarios y redactar pruebas de aceptación para ellos. Así debe ser, porque representa el hecho de que: Escribir el código para un objetivo entendido no es necesariamente la parte más difícil del desarrollo de software, sino comprender cuál es el objetivo real del código.

Por tanto, invertir en buenas historias de usuario, aunque sea en el último momento responsable, es un esfuerzo digno para el equipo. Bill Wake, acuñó el acrónimo INVEST7, para describir los atributos de una buena historia de usuario.

Independien te

norteegoí sta

Valios o Estima do Pequeñ o Comprobable El modelo INVEST es bastante ubicuo y muchos equipos ágiles evalúan sus historias con respecto a estos atributos. Aquí está nuestra opinión sobre el valor de la INVERSIÓN del equipo. Independiente Independencia significa que una historia puede desarrollarse, probarse y potencialmente incluso entregarse por sí sola. Por lo tanto, también se puede valorar de forma independiente. Muchas historias tendrán algunas dependencias secuenciales naturales a medida que se desarrolle la funcionalidad del producto y, sin embargo, cada pieza puede ofrecer valor de forma independiente. Por ejemplo, un producto puede mostrar un solo registro, luego una lista, luego ordenar la lista, filtrar la lista, preparar una lista de varias páginas, exportar la lista, editar elementos en la lista, etc. Muchos de estos elementos tienen dependencias secuenciales, pero cada elemento proporciona un valor independiente y el producto puede enviarse potencialmente a través de cualquier punto de parada del desarrollo. Sin embargo, muchas dependencias no valoradas, ya sean técnicas o funcionales, también tienden a encontrar su camino en los atrasos y es necesario encontrarlas y eliminarlas. Por ejemplo, una dependencia funcional no valorada podría ser: Como administrador, puedo establecer las reglas de seguridad de contraseñas del consumidor para que los usuarios deban crear y retener contraseñas seguras, manteniendo seguro el sistema. Como consumidor, debo seguir las reglas de seguridad de contraseñas establecidas por el administrador para poder mantener una alta seguridad en mi cuenta.

En este ejemplo, la historia del consumidor depende de la historia del administrador. La historia del administrador solo se puede probar para establecer, borrar y preservar la política; pero no se puede comprobar si se aplica al consumidor. Además, completar la historia del administrador no deja el producto en un estado potencialmente apto para el envío. © 2009, Leffingwell, LLC. Reservados todos los derechos.

- por lo tanto, no valioso de forma independiente. Al reconsiderar las historias (y el diseño del sistema) podemos eliminar la dependencia dividiendo las historias de una manera diferente, en este caso a través de los tipos de políticas de seguridad aplicadas y combinando la configuración con la aplicación en cada historia: Como administrador, puedo establecer el período de caducidad de la contraseña para que los usuarios se vean obligados a cambiar sus contraseñas periódicamente.

7

Bill Wake. http://xp123.com/xplor/xp0308/index.shtml

© 2009, Leffingwell, LLC. Reservados todos los derechos.

Como administrador, puedo establecer las características de seguridad de la contraseña para que los usuarios deban crear contraseñas difíciles de piratear.

Ahora, cada historia puede valerse por sí misma y puede desarrollarse, probarse y presentarse de forma independiente. Negociable ... y Negociado A diferencia de los requisitos tradicionales, una historia de usuario no es un contrato para una funcionalidad específica, sino más bien un marcador de posición para que los requisitos se discutan, desarrollen, prueben y acepten. Este proceso de negociación entre la empresa y el equipo reconoce la legitimidad y primacía de los insumos empresariales, pero permite el descubrimiento a través de la colaboración y la retroalimentación. En nuestras organizaciones anteriores, en silos, generalmente se requerían requisitos escritos para facilitar el ancho de banda de comunicación limitado entre departamentos y para servir como registro de acuerdos pasados. Sin embargo, Agile se basa en el concepto de que un enfoque basado en equipos es más eficaz para resolver problemas en un entorno colaborativo dinámico. Una historia de usuario es en tiempo real y está estructurada para aprovechar este enfoque de colaboración y comunicación directa y eficaz. Finalmente, la negociabilidad de las historias de usuario ayuda a los equipos a lograr la previsibilidad. La falta de requisitos demasiado limitados y demasiado detallados mejora la capacidad de los equipos y las empresas para hacer concesiones entre la funcionalidad y las fechas de entrega. Debido a que cada historia tiene flexibilidad, el equipo tiene más flexibilidad para cumplir con los objetivos de lanzamiento, lo que aumenta la confiabilidad y fomenta la confianza. Valioso El objetivo de un equipo ágil es simple: ofrecer el máximo valor dadas las limitaciones de tiempo y recursos existentes. Por lo tanto, el valor es el atributo más importante en el modelo INVEST y cada historia de usuario debe proporcionar algún valor al usuario, cliente o parte interesada del producto. Los trabajos pendientes se priorizan por valor y las empresas tienen éxito o fracasan en función del valor que los equipos pueden ofrecer. Un desafío típico que enfrentan los equipos es aprender a escribir historias de usuarios pequeñas e incrementales que puedan generar valor de manera efectiva. Los enfoques tradicionales nos han arraigado para crear estructuras funcionales de descomposición basadas en componentes técnicos. Este enfoque de capas técnicas para la creación de software retrasa la entrega de valor hasta que todas las capas se unen después de múltiples iteraciones. Wake8 ofrece su perspectiva de capas verticales, en lugar de técnicas. Piense en una historia completa como un pastel de varias capas, por ejemplo, una capa de red, una capa de persistencia, una capa lógica y una capa de presentación. Cuando dividimos una historia [horizontalmente], solo servimos una parte de ese pastel. Queremos darle al cliente la esencia de todo el pastel, y la mejor manera es cortar verticalmente las capas. Los desarrolladores a menudo tienen la inclinación de trabajar solo en una capa a la vez (y hacerlo "bien"); pero una capa de base de datos completa (por ejemplo) tiene poco valor para el cliente si no hay una capa de presentación. La creación de historias valiosas requiere que reorientemos nuestras estructuras funcionales de ruptura de un enfoque horizontal a uno vertical. Creamos historias que atraviesan la arquitectura para que podamos presentar valor al usuario y buscar su retroalimentación lo antes y con la mayor frecuencia posible. Si bien normalmente el valor se centra en la interacción del usuario con el sistema, a veces el valor se centra más apropiadamente en un representante del cliente o una parte interesada clave. Por ejemplo, quizás un director de marketing solicita una tasa de clics más alta en los anuncios presentados en el sitio web. Si bien la historia podría escribirse desde la perspectiva del usuario final: Como consumidor, puedo ver otros programas de precios de energía que me atraen para poder inscribirme en un programa que se adapte mejor a mi estilo de vida.

© 2009, Leffingwell, LLC. Reservados todos los derechos.

... para proporcionar una perspectiva más clara sobre el valor real, sería más apropiado redactarlo desde la perspectiva del director de marketing:

8

ibídem

© 2009, Leffingwell, LLC. Reservados todos los derechos.

Como director de marketing de servicios públicos, puedo presentar a los usuarios nuevos programas de precios para que sea más probable que sigan comprándome energía.

Otro desafío al que se enfrentan los equipos es articular el valor de las historias técnicas como la refactorización de código, las actualizaciones de componentes, etc. Por ejemplo, ¿cómo determinaría el propietario del producto el valor de: Refactorizar el registro de errores sistema.

Articular el valor de una solución técnica como una historia de usuario ayudará a comunicar a la empresa su importancia relativa. Por ejemplo: Como consumidor, puedo recibir un mensaje de error claro y coherente en cualquier parte del producto para saber cómo abordar el problema. O Como miembro de soporte técnico, quiero que el usuario reciba un mensaje coherente y claro en cualquier lugar de la aplicación para que pueda solucionar el problema sin llamar al soporte.

En estos últimos ejemplos, el valor es claro para el usuario, para el propietario del producto, las partes interesadas, y para el equipo. Estimable Una buena historia de usuario es estimable. Si bien una historia de cualquier tamaño puede estar en la lista de trabajos pendientes, para que se desarrolle y pruebe en una iteración, el equipo debe poder proporcionar una estimación aproximada de su complejidad y la cantidad de trabajo requerido para completarla. La inversión mínima en la estimación es determinar si se puede completar en una sola iteración. La precisión adicional de la estimación aumentará la previsibilidad del equipo. Si el equipo no puede estimar la historia de un usuario, generalmente indica que la historia es demasiado grande o incierta. Si es demasiado grande para estimarlo, debe dividirse en historias más pequeñas. Si la historia es demasiado incierta para estimar, entonces se puede usar una historia de picos técnicos o funcionales para reducir la incertidumbre, de modo que resulten una o más historias de usuarios estimables. (Cada uno de estos temas se analiza con más detalle en las siguientes secciones). Uno de los principales beneficios de estimar historias de usuarios no es simplemente derivar un tamaño preciso, sino más bien extraer cualquier suposición oculta, criterios de aceptación faltantes y aclarar la comprensión compartida del equipo de la historia. Por lo tanto, la conversación en torno al proceso de estimación es tan (o más) importante que la estimación real. La capacidad de estimar una historia de usuario está muy influenciada por el tamaño de la historia, como veremos a continuación. Pequeña Las historias de usuario deben ser lo suficientemente pequeñas como para poder completarse en una iteración; de lo contrario, no pueden proporcionar ningún valor o considerarse realizadas en ese momento. Sin embargo, historias de usuarios aún más pequeñas brindan más agilidad y productividad. Hay dos razones principales para esto: mayor rendimiento y menor complejidad. Mayor rendimiento A partir de la teoría de las colas, sabemos que los lotes más pequeños pasan por un sistema más rápido. Este es uno de los principios primarios del flujo magro y está reflejado en la ley de Little:

En un sistema estable (donde el rendimiento, la cantidad de trabajo que se puede hacer en una unidad de tiempo, es constante), tenemos que disminuir el trabajo en proceso (la cantidad de cosas en las que estamos trabajando) para disminuir el tiempo de ciclo (el tiempo transcurrido entre el inicio y el final del proceso). En nuestro caso, eso significa que menos historias más pequeñas en proceso saldrán más © 2009, Leffingwell, LLC. Reservados todos los derechos.

rápido.

© 2009, Leffingwell, LLC. Reservados todos los derechos.

Además, cuando un sistema se carga al máximo de su capacidad, puede volverse inestable y el problema se agrava. En sistemas muy cargados, los lotes más grandes se mueven desproporcionadamente más lento (el rendimiento disminuye) a través del sistema. (Piense en un sistema de carreteras en la hora pico. Una motocicleta tiene un rendimiento mucho mayor que los automóviles y camiones. Hay más espacio para maniobrar cosas más pequeñas a través de un sistema cargado). Porque los equipos de desarrollo generalmente están completamente asignados a la capacidad o por encima de ella (80 -120%), se encuentran en la categoría de carreteras de “hora punta”. Cuando la capacidad alcanza el 80% aproximadamente, los objetos más grandes aumentan el tiempo de ciclo (ralentizan) mucho más que los objetos más pequeños. Peor aún, la variación en el tiempo del ciclo aumenta, lo que significa que se vuelve más difícil predecir cuándo un lote realmente podría salir del sistema, como se puede ver en la Figura 1 a continuación9. A su vez, esta menor previsibilidad

causa estragos en los horarios, los compromisos y la credibilidad del equipo. Figura 1

Los lotes grandes tienen menor rendimiento y mayor variabilidad en el tiempo de ciclo.

Complejidad disminuida Las historias más pequeñas no solo pasan más rápido debido a su tamaño proporcional y crudo, sino que también lo hacen más rápido debido a su menor complejidad, y la complejidad tiene una relación no lineal con el tamaño. Esto se ve más fácilmente en las pruebas donde las permutaciones de las pruebas necesarias para validar la funcionalidad aumentan a un ritmo exponencial con la complejidad de la función en sí. Esto se correlaciona con los consejos que recibimos sobre el desarrollo de código limpio, como señala Robert Martin [Martin 2009] sobre sus reglas para escribir funciones de software: Regla 1: Haz una cosa Regla 2: Mantenlos pequeños Regla 3: hazlos más pequeños que eso Esta es una de las razones principales por las que la secuencia de estimación de Fibonacci (es decir, 1, 2, 3, 5, 8, 13, 21…) es tan eficaz en la estimación de historias de usuarios: la estimación del esfuerzo crece de forma no lineal al aumentar el tamaño de la historia. Sobre la relación de tamaño e independencia Surge una pregunta justa en cuanto a la relación entre tamaño e independencia, ya que parece lógico que las historias más pequeñas aumenten el número de dependencias. Sin embargo, las historias más pequeñas, incluso con una mayor dependencia, ofrecen un rendimiento de mayor valor y proporcionan comentarios de los usuarios más rápidos que las historias más grandes. Entonces, el agilista siempre se inclina por historias más pequeñas y luego las hace aún más pequeñas.

© 2009, Leffingwell, LLC. Reservados todos los derechos.

9

Fuente: [Poppendieck 2007].

© 2009, Leffingwell, LLC. Reservados todos los derechos.

Comprobable En agile correctamente hecho, todo el código es código probado, por lo que se deduce que las historias deben ser comprobables. Si una historia no parece ser comprobable, es probable que la historia esté mal formada, sea demasiado compleja o tal vez dependa de otras historias del atraso. Para asegurarse de que las historias no entren en una iteración si no pueden salir, muchos equipos ágiles de hoy adoptan un enfoque de escribir la prueba primero. Esto comenzó en la comunidad de XP utilizando Test Driven Development, una práctica de escribir pruebas unitarias automatizadas antes de escribir el código para aprobar la prueba. Desde entonces, esta filosofía de enfoque se está aplicando al desarrollo de los criterios de aceptación de la historia y las pruebas funcionales necesarias antes de codificar la historia en sí. Si un equipo realmente sabe cómo probarlo, es probable que también sepa cómo codificarlo. Para garantizar la capacidad de prueba, las historias de usuario comparten algunos errores comunes de capacidad de prueba con requisitos vagos. Palabras como rápido, administrar, agradable, limpio, etc. son fáciles de escribir, pero difíciles de probar porque significan cosas diferentes para diferentes personas y, por lo tanto, deben evitarse. Y si bien estas palabras brindan negociabilidad, proporcionar algunos límites claros y objetivos ayudará al equipo y a la empresa a compartir las expectativas del resultado y evitar grandes sorpresas.

División de historias de usuarios Una historia de usuario generalmente comienza como una característica o una epopeya: un concepto amplio y vago de algo que queremos hacer por un usuario. A menudo encontramos estas grandes historias vagas durante nuestro proceso de descubrimiento y las capturamos en el trabajo pendiente. Sin embargo, estas son historias compuestas, como se muestra a la derecha, y generalmente son demasiado grandes para ser implementadas dentro de una iteración. Para preparar el trabajo para las iteraciones, un equipo debe dividirlas en historias más pequeñas. No existe una rutina establecida para dividir las historias de los usuarios en fragmentos del tamaño de una iteración, aparte de la guía general para hacer que cada historia proporcione una porción vertical, una parte del valor del usuario, a través del sistema. Sin embargo, con base en un trabajo reciente de Richard Lawrence, recomendamos aplicar una selección adecuada de diez patrones comunes para dividir una historia de usuario, como indica la Tabla 110:

© 2009, Leffingwell, LLC. Reservados todos los derechos.

10

Adaptado de Richard Lawrence, http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/.

© 2009, Leffingwell, LLC. Reservados todos los derechos.