¿Por qué?

  • Inefectividad, ineficacia y/o ineficiencia, del Proyecto Software

    • porque tiene malas variables en su economía:

      • ámbito incumplido y/o

      • tiempo incumplido y/o

      • coste incumplido;

    • porque tiene mala calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene mala mantenibilidad

      • viscoso, porque no se puede entender con facilidad y/o

      • rígido, porque no se puede cambiar con facilidad y/o

      • frágil, porque no se puede probar con facilidad y/o

      • inmovil, porque no se puede reutilizar con facilidad y/o

    • porque tiene complejidad arbitraria

davidProyectoImplantacionDiseñoMal

arbolNoMantenible

¿Qué?

Una historia de usuario describe la funcionalidad que será valiosa para un usuario o comprador de un sistema o software.Las Historias de Usuario deben ser escritos para que el cliente pueda valorarlos
— Cohn
M.

EstructuraHistoriaDeUsuarioTarjeta

¿Para qué?

  • Efectividad, eficacia y eficiencia, del Proyecto Software

    • porque tiene buenas variables en su economía:

      • ámbito cumplido y

      • tiempo cumplido y

      • coste cumplido;

    • porque tiene buena calidad del software, fiabilidad, usabilidad, interoperatividad, seguirdad, …​ (-ilities)

    • porque tiene buena mantenibilidad

      • fluido, porque se puede entender con facilidad y/o

      • flexible, porque se puede cambiar con facilidad y/o

      • fuerte, porque se puede probar con facilidad y/o

      • reusable, porque se puede reutilizar con facilidad y/o

    • porque tiene complejidad necesaria

davidProyectoImplantacionDiseño

arbolMantenible

¿Cómo?

Autor

El equipo cliente, en lugar de los desarrolladores, escribe las historias de usuario, por dos razones principales:

  • En primer lugar, cada historia debe ser escrito en el lenguaje de los negocios, no en la jerga técnica, por lo que el equipo cliente puede dar prioridad a las historias para su inclusión en iteraciones y comunicados.

  • En segundo lugar, como visionarios del producto básico, el equipo de atención al cliente está en la mejor posición para describir el comportamiento del producto

Roles de Usuario

  • Un rol de usuario es una colección de atributos que definen las características de una población de usuarios y sus interacciones con el sistema

  • Cada rol de usuario llega a su software con una experiencia diferente y con diferentes objetivos, es posible agregar usuarios individuales y pensar en ellos en términos de roles de usuario.
Pasos Descripción

  • Lluvia de ideas sobre un conjunto inicial de roles de usuario

  • Para identificar los roles de usuario, el cliente y tantos desarrolladores como sea posible, se reúnen en una habitación, ya sea con una gran mesa o una pared a la que pueden pegar o pinchar tarjetas.

  • La habitación se llenará de discusiones sobre las tarjetas, de vez en cuando, será apuntado por alguien una nueva tarjeta y se lee el nombre de rol.

  • Continúe hasta que el progreso se estabiliza y los participantes están necesitando tiempo para idear nuevos roles.

  • En ese momento puedes no haber identificado todos los roles pero estás lo suficientemente cerca.

  • Es raro que esta necesidad de durar más de quince minutos.

  • Organizar el conjunto inicial

  • las tarjetas se mueven alrededor de la mesa o pared de modo que sus posiciones indican las relaciones entre los roles.

  • Superposición de funciones se colocan de manera que sus tarjetas se superponen.

  • Si los papeles se superponen un poco, se superponen las tarjetas un poco.

  • Si los roles se superponen completamente, se superponen las tarjetas enteramente

  • Consolidar roles

  • Comience con las tarjetas que son totalmente solapadas. Los autores de las tarjetas de superposición describen lo que querían decir con esos nombres de rol. Después de una breve discusión, el grupo decide si los roles son equivalentes.

    • Si son equivalentes los roles, se pueden consolidar en un solo rol tal vez tomando su nombre de los dos roles iniciales o una de las primeras tarjetas de rol pueden ser elegidas.

  • Además, el grupo también debe abandonar cualquier tarjeta para los roles que no son importantes para el éxito del sistema.

  • Redefinir los roles

  • Es posible modelar estas funciones mediante la definición de atributos de cada rol.

  • Un atributo de rol es un hecho o información útil acerca de los usuarios que cumplan el papel.

  • Éstos son algunos de los atributos que se sugieren considerar en la preparación de cualquier modelo a seguir:

    • La frecuencia con la que el usuario podrá utilizar el software.

    • El nivel de experiencia del usuario con el dominio.

    • Nivel general de habilidad del usuario con los ordenadores y software.

    • El nivel de dominio de usuario con el software que se está desarrollando.

    • Objetivo general del usuario para utilizar el software.

    • Además de identificar los atributos interesantes para un rol, escribir notas en la tarjeta.

Cuando haya terminado, usted puede colgar las tarjetas de rol en un área común utilizado por el equipo para que puedan ser usados como recordatorios
Dos técnicas adicionales

  • Una persona es una representación imaginaria de un rol de usuario.

    • Una persona debe ser descrito suficientemente para que todos en el equipo se sientan como si conocieran la persona (p.e.: Mario, incluso con foto)

  • Uso de personajes extremos al considerar el diseño de un nuevo sistema.

    • Por ejemplo, es fácil imaginar el traficante de drogas y una mujer con varios novios.

    • Así, mediante los personajes extremos se puede conducir a nuevas historias. Es difícil saber si estas historias serán las que se deban incluir en el producto.

    • Probablemente no es mucha inversión y vale la pena el tiempo. Como mínimo, puede tener unos minutos de diversión al pensar en cómo el Papa podría utilizar su software y aunque sólo pueda conducir a una idea o dos.

Elementos

Tarjeta Conversación Confirmación

  • Descripción escrita de la historia utilizada para la planificación y como un recordatorio. Se escriben tradicionalmente a mano en tarjetas de papel.

    • <Rol> quiere <función> para <valor de negocio>

    • Ejemplos:

      • Un usuario puede buscar puestos de trabajo.

      • Una empresa puede publicar nuevos puestos de trabajo.

      • Un usuario puede limitar quién puede ver su hoja de vida

      • …​

    • Contraejemplos:

      • El software será escrito en C ++.

      • El programa se conectará a la base de datos a través de una agrupación de conexiones.

  • Sirve para profundizar en los detalles de la historia.

    • En lugar de escribir todos estos detalles como las historias, el mejor enfoque es que el equipo de desarrollo y el cliente discutan estos detalles. Es decir, tener una conversación sobre los detalles en el momento en que los detalles se vuelven importantes.

    • No hay nada de malo en hacer un par de anotaciones basadas en la discusión en una tarjeta de historia de usuario

  • Pruebas que transmiten la documentación de los detalles que se puede utilizar para determinar cuándo una historia está completa.

    • Las descripciones de prueba están destinadas a ser cortas e incompletas.

    • Así, las pruebas de aceptación son el proceso de verificación de que las historias se desarrollaron de tal manera que cada uno trabaja exactamente en la forma en que el equipo cliente espera que funcione.

    • Estas expectativas se captan mejor en la forma de las pruebas de aceptación, en lugar de escribir largas listas de "El sistema deberá …​“, … con el estilo de declaraciones de requisitos.
Pruebas de Aceptación

  • El cliente debe centrar sus esfuerzos en la escritura de pruebas que aclaran la intención de la historia a los desarrolladores.

    • No buscamos necesariamente metas de cobertura de código del 100% o las pruebas de todas las condiciones de entorno.

    • Utilizamos nuestra intuición, nuestro conocimiento y nuestra experiencia pasada para guiar nuestro esfuerzo de la prueba.

Responsabilidad

Desarrollo

Ejecución

  • La especificación de las pruebas es a menudo una responsabilidad compartida:

    • Debido a que el software que se está desarrollando para cumplir una visión propia del cliente, las pruebas de aceptación deben ser especificadas por el cliente. El propietario de producto traerá su conocimiento de los objetivos de la organización que impulsan el proyecto

    • Pero un desarrollador de pruebas dedicado y cualificado traerá su mentalidad suspicaz para los aspectos más técnicos de esta actividad. Por lo general, aumentará algunas de las historias con las pruebas que considere porque el cliente no es responsable de la identificación de todas las pruebas posibles. Además, tenga en cuenta que un buen equipo de programación tendrá pruebas de unidad para muchos de los casos de bajo nivel.

    • La prueba se ve mejor como un proceso de dos pasos:

      • Primero, señalar futuras pruebas apuntadas en la parte posterior de las tarjetas de la historia.

      • Segundo, las notas de las pruebas se convierten en pruebas de pleno derecho que se utilizan para demostrar que la historia ha sido codificada correcta y completamente.

  • Es vital que las pruebas de las historias de usuario se vean como parte del proceso de desarrollo, no es algo que sucede "después de la codificación que se añade"

  • Las pruebas pueden ser añadidas o eliminadas en cualquier momento

    • Pero escribir pruebas tempranamente es muy útil debido a que la mayoría de las suposiciones del equipo del cliente y sus expectativas son comunicados a los desarrolladores antes de la codificación de la historia. Al inicio de una iteración, se reunirán y especificarán tantas pruebas iniciales como se puedan imaginar.

    • Pero no se detiene ahí y no se detiene con reunirse una vez por semana con el cliente. Como los detalles de una historia se elaboran, se especifican pruebas adicionales.

  • Como mínimo, las pruebas de aceptación deben ser ejecutadas al final de cada iteración.

    • Debido a que el código que funciona en una iteración puede ser roto por el desarrollo en una iteración posterior, es importante ejecutar pruebas de aceptación de todas las iteraciones anteriores. Esto significa que la ejecución de pruebas de aceptación se vuelve más lento con cada iteración que pasa.

    • Si es posible, el equipo de desarrollo debe mirar por la automatización de algunas o todas las pruebas de aceptación.

Historias técnicas

  • Elementos no-funcionales, cosas que deben hacerse pero que no son un entregable ni están directamente relacionadas con ninguna historia específica, y no son de valor inmediato para el Dueño de Producto.

    • Ejemplos:

      • Instalar un servidor de compilación continua

      • Refactorizar la capa de acceso a datos

      • Escribir una descripción general del diseño

  • Intentamos evitar las historias técnicas. Busca efusivamente formas de transformar las historias técnicas en historias normales con valor de negocio mensurable. Así el Dueño de Producto tendrá mejores oportunidades para realizar decisiones correctas entre los pros y los contras.

  • Si no podemos transformar una historia técnica en una historia normal, intentamos ver si es posible hacerla como una tarea dentro de otra historia.

    • Por ejemplo, “refactorizar la capa de acceso a datos” podría ser una tarea dentro de la historia “editar usuario”, ya que esto involucra utilizar la capa de acceso a datos.

  • Si lo anterior falla, definirla como historia técnica y mantener una lista separada con dichas historias.

    • Permitimos al Dueño de Producto que vea dicha lista, pero no que la modifique.

    • Usamos los factores de dedicación y la velocidad estimada para negociar con el Dueño de Producto y sacar algo de tiempo del Sprint para implementar estas historias.

  • Por supuesto, la otra opción es simplemente mantener al Dueño de Producto fuera del ciclo o darle un factor de dedicación no negociable.

Características

  • De valor para los usuarios o clientes.La mejor manera de asegurarse es que el cliente tenga que escribir las historias.

    • Los clientes están a menudo incómodos con este principio, probablemente porque los desarrolladores los han entrenado para pensar en todo lo que escriben como algo que puede ser utilizado en su contra más tarde.

    • La mayoría de los clientes comienzan a escribir historias en sí mismas una vez que se sientan cómodos con el concepto de que las tarjetas de historia son recordatorios para hablar más tarde en lugar de compromisos formales o descripciones de la funcionalidad específica.

    • De la misma manera, vale la pena tratar de mantener asunciones de interfaz para historias de usuario.

  • Independientes. Las dependencias entre historias conducen a problemas de priorización, planificación y la estimación mucho más difícil de lo que debe ser.

    • Cuando se presentan con este tipo de dependencia, hay dos formas de sortearlo:

      • Combine las historias dependientes en una más grande, pero la historia independiente

      • Encontrar una manera diferente de dividir las historias

      • Si no desea combinar las historias y no puede encontrar una buena manera de separarlos, siempre se puede tomar el enfoque simple de poner dos estimaciones de la tarjeta: una estimación si la historia se hace antes de la otra historia, una estimación más baja si se hace después

  • Estimables. Hay tres razones por las que pueden no ser estimables:

    • Los desarrolladores carecen de conocimiento del dominio. Si no la entienden como está escrita, deben discutirlo con el cliente. Una vez más, no es necesario entender todos los detalles pero necesitan tener un conocimiento general de la historia.

    • Los desarrolladores carecen de conocimientos técnicos. La solución es enviar uno o más desarrolladores a un spike (pico), que es un breve experimento para aprender sobre un área de la aplicación.

      • Al spike en sí siempre se le da una cantidad definida de tiempo máximo.

      • Así, una historia inestimable se convierte en dos: un spike para reunir información y luego una para hacer el trabajo real

    • La historia es demasiado grande. A pesar de que son demasiado grandes para estimar de forma fiable, las epopeyas son útiles como recordatorios sobre grandes partes de un sistema que necesitan ser desarrolladas

  • Pequeñas. Es mejor tener más historias que tener historias que son demasiado grandes. Es bueno tener historias que pueden codificarse y probarse entre medio día y tal vez dos semanas por un o un par de programadores. La determinación final de si una historia tiene el tamaño adecuado se basa en el equipo, sus capacidades y la tecnologías en uso.

    • Cuando una historia es demasiado grande se refiere a veces como una epopeya. Se pueden dividir en dos categorías:

      • Historias complejas. Una historia de usuario que es de por sí grande y no puede ser fácilmente desglosada en un conjunto de historias constituyentes.

        • Si una historia es compleja debido a la incertidumbre asociada a ella, es posible que desee dividir la historia en dos historias: una de investigación (spike) y una de desarrollo de la nueva característica.

      • Historias compuestas. Normalmente hay muchas maneras de desglosar una historia compuesta. Este desglose anterior es en el sentido de operaciones de crear, editar y eliminar (CRUD).

        • Una alternativa es desglosar a lo “largo” con límites de los datos.

    • A veces las historias son demasiado pequeñas. Típicamente, una que el desarrollador dice de ella que no quiere que se escriba o estime porque haciendo eso puede llevar más tiempo que hacer el cambio.

      • Los informes de fallos y cambios en la interfaz de usuario son ejemplos comunes de historias que a menudo son demasiado pequeñas.

      • Un buen enfoque para las historias pequeñas, comunes entre los equipos XP, es combinarlas en historias más grandes que representan aproximadamente medio día a varios días de trabajo. La historia combinada se le da un nombre y se programa y trabaja como con cualquier otra historia.

  • Negociables.Son breves descripciones de la funcionalidad y los detalles son lo que debe ser negociado en una conversación entre el cliente y el equipo de desarrollo.

  • Comprobables. Las historias deberán ser escritas con el fin de ser comprobables. Con el éxito de pasar sus pruebas se demuestra que una historia se ha desarrollado con éxito. Si la historia no puede ser probada, ¿cómo pueden saber los desarrolladores cuando han terminado de codificación?

Documentación

  • Mantenemos la Pila de Producto en un documento Excel con “compartir” habilitado (es decir, muchos usuarios pueden editar simultáneamente la hoja).

  • Esta demostrado ser la manera más simple de permitir múltiples editores diferentes sin causar problemas de bloqueo o fusión de documentos.

  • Por la misma razón, no colocamos este documento en el repositorio de control de versiones; en vez de eso, lo almacenamos en una unidad de red compartida.

  • Oficialmente, el Dueño de Producto es el propietario del documento, pero no queremos dejar al resto de usuarios fuera. Muchas veces un desarrollador necesita abrir el documento para clarificar algo o cambiar una estimación.

  • Identificador

  • Nombre

  • Notas

  • Importancia

  • Estimación inicial

  • Como probarlo

  • Opcionales:

    • Componentes

    • Categoría

    • Bug tracking ID

    • Solicitante

height32

  • ID: un identificador único, simplemente un número auto-incremental. Esto nos permite no perder la pista a las historias cuando cambiamos su nombre.

  • Importancia: Todos los elementos importantes deberían tener ratios de importancia asignados, diferentes ratios de importancia.

    • Cualquier historia sobre la que el Dueño de Producto piense que tiene una remota posibilidad de incluirse en el Sprint debería tener un nivel de importancia único definido.

    • El ratio de importancia se emplea solo para ordenar los elementos por relevancia.

      • Es útil dejar espacio entre la secuencia de números

      • En realidad, da igual si los elementos menos importantes tienen todos el mismo valor, ya que probablemente no se discutirán durante la planificación de Sprint en cualquier caso.

      • Así que si el elemento A tiene una importancia de 20 y el elemento B una importancia de 100, simplemente significa que B es más importante que A. No significa que B sea cinco veces más importante que A. Si B tuviera una importancia de 21, ¡aun significaría lo mismo!

  • Nombre: una descripción corta de la historia (normalmente, 2 a 10 palabras).

    • Suficientemente claro como para que el Dueño de Producto comprenda aproximadamente de qué estamos hablando, y suficientemente clara como para distinguirla de las otras historias.

    • Por ejemplo, Ver tu historial de transacciones

  • Notas: cualquier otra información, clarificación, referencia a otras fuentes de información, etc.

    • Normalmente muy breve.

  • Estimación inicial: la valoración inicial del Equipo acerca de cuanto trabajo es necesario para implementar la historia, comparada con otras historias.

    • La unidad son “puntos de historia” y usualmente corresponde a “días-persona ideales”.

    • Pregunta al Equipo: “si tuvierais el número óptimo de personas para esta historia (ni muchos ni pocos, típicamente 2) y os encerraseis en una habitación con cantidad de comida, y trabajaseis sin distracciones, ¿en cuantos días saldríais con una implementación terminada, demostrable, testeada y liberable?”.

      • Si la respuesta es “con 3 tíos encerrados en una habitación nos llevaría 4 días”, entonces la estimación inicial son 12 puntos.

    • Lo importante no es que las estimaciones absolutas sean correctas (es decir, que una historia de 2 puntos deba durar 2 días), lo importante es que las estimaciones relativas sean correctas (es decir, que una historia de 2 puntos debería durar la mitad que una historia de 4 puntos).

  • Como probarlo: una descripción a alto nivel de como se demostrará esta historia en la Demo al final del Sprint.

    • Se trata, esencialmente, de una simple especificación de un test: “Haz esto, entonces haz lo otro, y entonces debería ocurrir aquello”.

    • Si practicáis desarrollo dirigido por pruebas, esta descripción puede usarse como pseudo-código para vuestro test de aceptación.

  • Componentes (opcional): usualmente implementado en la forma de “check-boxes” en el documento Excel, por ejemplo “base de datos, servidor, cliente”.

    • Aquí, el Dueño de Producto puede identificar qué componentes técnicos estarán involucrados en la implementación de la historia. Esto es útil cuando tienes varios equipos Scrum, por ejemplo un equipo de back-office y otro equipo de cliente, y quieres que sea fácil para cada equipo saber a qué historias deben dedicarse.

  • Categoría (opcional): una categorización básica de la historia

    • Por ejemplo “back-office” o “optimización”.

    • Así, el dueño de producto puede filtrar fácilmente “optimización” y cambiar todas las prioridades de este tipo a “baja”, etc.

  • Bugtracking ID (opcional): si tienes un sistema de bug tracking (seguimiento de errores) aparte, es útil mantener un historial de cualquier correspondencia directa entre una historia y uno o más errores reportados.

  • Solicitante (opcional): el Dueño de Producto puede querer mantener un historial acerca de qué cliente o persona interesada pidió originalmente la historia, para poder así ofrecerle información actualizada sobre el progreso de la misma.

Sintesis

Bibliografía

Obra, Autor y Editor Portada Obra, Autor y Editor Portada

  • Refactoring (Pearson Addison-Wesley Signature Series)

    • Fowler Martin

    • Financial Times Prentice Hall; Edición: 01 (28 de noviembre de 2018)

height32

  • Test Driven Development. By Example (The Addison-Wesley Signature Series

    • Beck Kent

    • Addison Wesley; Edición: 01 (8 de noviembre de 2002)

height32

  • Extreme Programming Explained: Embrace Change: Embracing Change

    • Kent Beck, Cynthia Andres

    • Addison-Wesley Educational Publishers Inc; Edición: 2nd edition (16 de noviembre de 2004)

height32

  • Planning Extreme Programming (The Xp Series)

    • Beck Kent, Fowler Martin

    • Addison Wesley; Edición: 01 (16 de octubre de 2000)

height32

  • Scrum and XP from the Trenches (Enterprise Software Development)

    • Henrik Kniberg

    • Lulu.com; Edición: 1 (4 de octubre de 2007)

height32

  • Scrum: El revolucionario método para trabajar el doble en la mitad de tiempo

    • Jeff Sutherland,

    • Editorial Ariel (20 de enero de 2015)

height32

  • Refactoring Databases: Evolutionary Database Design

    • Scott J Ambler, Pramod J. Sadalage

    • Addison-Wesley Professional; Edición: 1 (13 de marzo de 2006)

height32

  • User Stories Applied: For Agile Software Development

    • Cohn, M.

    • Addison Wesley, 2004

UserStoriesAppliedForAgileSoftwareDevelopment

  • Scrum y XP desde las trincheras

    • Henrik Kniberg. Prólogos de Jeff Sutherland y Mike Cohn

    • proyectalis.com

ScrumXPTrenches

  • Diseño Ágil con TDD

    • Carlos Blé Jurado

    • Lulu.com

DisenoAgilconTDD

Ponente

  • Luis Fernández Muñoz

setillo

  • Doctor en Inteligencia Artificial por la UPM

  • Ingeniero en Informática por la UMA

  • Diplomado en Informática por la UPM

  • Profesor Titular de ETSISI de la UPM