Metodologías AgilesIntroducción

Una metodología Ágil es una metodología efectiva par a modelar y documentar un proyecto de software, es una colección de valores principios y practicas para modelar software que puede ser aplicados de manera simple y ligera.

La metodología Agil tiene varios principios que la diferencian sobre las metodologías tradicionales reflejados en un Manifiesto que enuncia cuatro valores que son :

1. Los individuos y sus relaciones sobre las personas y los procesos .- con este principio se hace manifiesto el énfasis de esta metodología sobre las personas , ya que ellas son de las que depende el éxito o el fracaso de un proyecto, es a las que se les debe motivar

2. Un Software funcional, que trabaje sobre la documentación mas completa .- con este principio se trata de decir que lo mas importante es que el software trabaje , cumpla con las necesidades de negocio, no hacer de la documentación un fin en si mismo, ya que esta es solo para dar soporte , no es el objetivo primario del desarrollo, existen situaciones en donde incluso la documentación podría ser innecesaria, por ejemplo una pequeña aplicación emergente, que una vez pasada la emergencia , esta aplicación desaparece, el cargar de documentación de requerimientos, arquitectura , testeo etc. Podría considerarse de sobra, sin embargo eso no quiere decir que no es necesaria la documentación, esta debe existir pero solo la suficiente

3. Colaboración el cliente sobre el contrato de negocio .- Se trata de colaborar con el cliente el mayor tiempo no de luchar con el sobre un contracto minucioso , esto puede ser difícil ya que los clientes no están acostumbrados, ellos están acostumbrados a trabajar sobre un contrato con el que puedan defenderse si las cosas van mal

4. Ser capaz de responder a los cambios y no obsesionarse sobre el seguimiento de un plan .-Es tener la capacidad de adaptación, no decir NO A LOS CAMBIOS, aceptar las sugerencias de los usuarios, sin por eso hacer un lado la planificación

Estos valores han dado lugar a doce principios que son :

1. La satisfacción del cliente

2. Bienvenida a los cambios que puedan ocurrir

3. Entregar regularmente software que trabaje

4. Gente de negocios y desarrolladores trabajan diariamente en conjunto

5. Construcción de proyectos alrededor de individuos motivados para esto

6. Las comunicaciones cara a cara son las mejores

1

7. Software que trabaje es la mejor medida del progreso

8. Atención continua a la excelencia y al buen diseño

9. Promover el desarrollo sostenible

10. Simplicidad

11. Las mejores arquitecturas, requerimientos , y diseños emergen de equipos auto-organizados

12. Introspección , los equipos deben regularmente hacerse una revisión hacia si mismos y sus procesos para intentar mejorar

Modelado Agil

En el modelado Agil se trata de hallar el equilibrio ente exceso de modelado y carencia de este, se intenta que el modelado no se convierta en una carga, que sea suficiente para documentar el sistema, se pueden aprovechar el modelado de un proyecto RUP , esto es la documentación UML, se intenta promover procesos ligeros.

Con la modelación Agil se siguen tres objetivos que son:

Promover y definir un grupo de valores, practicas y principios que ayudan a producir los modelos adecuados

Orientación de cómo aplicar el modelado de proyectos agiles

Orientación de cómo aplicar el modelado Agil a otro tipo de procesos o metodologías (por ejemplo RUP)

Criterios para un meldado Agil

Un modelado Agil debe seguir estos criterios :

Deben dar valor positivo, deben servir realmente de ayuda para dar un software funcional

Deben solo cumplir su propósito y no mas , esto es dar a entenderse solo con los suficiente, no usar herramientas pesadas, por ejemplo las ofrecidas por Rational Rose, no ser tan estricto

Debe ser comprensible para su audiencia, no para todos, el nivel de detalle debe ser comprensible de acuerdo a la audiencia a la que se le presente

Deben ser lo suficientemente precisos

Deben ser lo suficientemente consistentes , modelos mas detallados que otros pueden causar confusión a las audiencias a las que van dirigidos.

2

Deben ser lo suficientemente detallados, muchos detalles pueden ser irrelevante de acuerdo a quien se dirige el modelo.

Tan simples como sea posible.

La documentación de las metodologías agiles debe ser tan simple como sea posible y de acuerdo a la audiencia a la que vaya dirigida, no es un modelado tan prescriptivo, no da recetas de diseño, no crea documentación innecesaria, se puede usar cualquier tipo de diseño o documentación que nos ayude, puede haber procesos que sea difícil capturarlos con los diagramas conocidos, pero si otros, una metodología Agil podría asociarlos.

Ejemplos de metodologías consideradas Agil son

Programación Extrema Scrum MSF 4.0 Microsoft RAD * Cristal RUP Agil Otras ..

En este documento hablaremos de las primeras cuatro metodologías, estas metodologías pueden combinarse , por ejemplo Programación Extrema y Scrum , RAD puede integrarse con otras etc.

Aspectos de las Metodologias Agiles

Requisitos para poder utilizar Scrum

Los siguientes puntos son de especial importancia para la implantación de una gestión ágil de proyectos como Scrum:

Cultura de empresa basada en trabajo en equipo, delegación, creatividad y mejora continua.

Compromiso del cliente .- Scrum exige del cliente una alta implicación y una dedicación regular:.

Compromiso de la Dirección de la organización para resolver problemas endémicos y realizar cambios organizativos, formando equipos autogestionados y multidisciplinares y fomentando una cultura de gestión basada en la colaboración y en la facilitación.

Compromiso conjunto y colaboración de los miembros del equipo.

Relación entre proveedor y cliente .- las dos partes asumen que habrá cambios para que el cliente obtenga lo que realmente necesita, no lo que está escrito en un documento

Facilidad para realizar cambios en el proyecto. Para poder utilizar Scrum se debe poder ir incorporando requisitos de manera incremental en el producto del proyecto

3

Tamaño de cada equipo entre 5 y 9 personas (con técnicas de colaboración entre equipos que trabajan en el mismo proyecto).

Equipo trabajando en un mismo espacio común para maximizar la comunicación.

Dedicación del equipo a tiempo completo.

Estabilidad de los miembros del equipo

Herramientas documentales - Historias de Usuario

En la programación XP, suele utilizarse algo similar a lo utilizado en la Metodologia RUP, esto es los casos de uso, pero en esta Metodologia, el concepto cambia, ya no es un formato preciso, es mas anecdótico, se trata de referir la manera en que los usuarios pueden usar el sistema, las historias de usuario son escritas para los usuarios no para el equipo de desarrollo

Las historias de Usuario no son requerimientos detallados, pueden obtenerse durante las iteraciones, como una experiencia de uso del sistema resultado de una iteracion, deben usar la terminología del usuario , un lenguaje de negocios , no la de un desarrollador, deben ser cortas un ejemplo ser algo tan simple como esto que refleja esta Story Card (que es donde se pueden apuntar aspectos de historias de usuario) y dice :

Un usuario puede mandar su resumen a través de una pagina Web

Mas importante que una Story Card, que es la parte visible de la historia, son las conversaciones entre clientes y desarrolladores

Una Historia de Usuario describe una funcionalidad, un propósito de un sistema o software, son tradicionalmente escritas a mano y se componen de tres aspectos

1. Uno que describa la historia y como planeación y recordatorio

2. Conversaciones que puedan servir para reflejar detalles de la historia

3. Test que puedan documentar cuando una historia ha sido completada

Puede tenerse un proyecto inicial de historias pero pueden surgir otras durante todo el proyecto, pueden apilarse historias cortas durante una iteración para su atención, pueden priorizarse en pilas para su desarrollo en cada iteración

4

Metodología Ágil - SCRUM

Introducción

Scrum es una metodología ágil, que puede ser usada para manejar el desarrollo de productos complejos de software , en esta metodología se usan practicas iterativas e incrementales. Scrum a sido usado desde proyectos simples hasta en proyectos de cambios estructurales completos en las empresas para sus negocios . Scrum incrementa significativamente la productividad y reduce el tiempo de espera para ver los beneficios así como facilitar la adaptación de los sistemas desarrollados

Características

Scrum por su proceso iterativo incremental produce un grupo de funcionalidades en cada fin de iteración. Sus características son:

Scrum es un proceso agile para el manejo y control del trabajo de desarrollo Scrum es un contenedor de practicas de ingeniería existentes Scrum es un enfoque basado en equipos , incrementa el desarrollo cuando los

requerimientos cambian rápidamente Scrum es un proceso que controla el caos entre los conflictos de interés y las necesidades Scrum es un camino para mejorar las comunicaciones y maximiza r la cooperación Scrum es un camino para detectar la causa y solucionar cualquier problema en el

desarrollo Scrum es escalable desde proyectos simples a proyectos completos organizacionales,

Scrum ha controlado y organizado el desarrollo de productos y proyectos con miles de desarrolladores e implementadores

Scrum es la ruta para sentirse bien en el trabajo

Naturalmente Scrum se enfoca en la construcción de proyectos exitosos en las organización, sin mayores cambios dentro de los 30 días de cada carrera (ciclo) construyendo una funcionalidad completa y demostrada del producto al final de cada carrera, Scrum puede implementarse al principio o a la mitad de un proyecto de desarrollo

Scrum es un conjunto de prácticas interrelacionadas y reglas que optimizan el entorno de desarrollo, reducen la sobrecarga organizativa, y sincronizan los requisitos del mercado con los prototipos de cada iteración . Basado en una teoría de control de procesos moderna, Scrum nos da el mejor software posible teniendo en cuenta los recursos disponibles, una calidad aceptable, con las fechas requeridas de liberación. Una funcionalidad del producto útil es dada cada treinta días como requisito, la arquitectura, y el diseño aparecen, incluso cuando la tecnologías es inestable aun

5

Scrum como lo muestra la ilustración se basa en el equipo, en reuniones diarias presididas por el Scrum máster para establecer el estado del proyecto, y en la salida cada 30 días de características del proyecto finalizadas y listas para trabajar, el corazón del Scrum es la iteración, que en cada iteración presenta una mejora del funcionamiento del producto final, en cada iteración se evalúa la tecnología y capacidades requeridas, diariamente se pueden modificar el enfoque si se encuentran nuevas dificultades y tratar de remediarlas, el corazón del Scrum es la productividad

Fig. Proceso de trabajo del Scrum

Las más de cincuenta organizaciones que han usado el Scrum en miles de proyectos han tenido siempre mejoras en la productividad , las practicas existentes son envueltas y mejoradas necesariamente y así dar al usuario o al mercado los incrementos del producto

Scrum ha sido usado producir productos financieros, productos de Internet . En cada ejemplo, la organización era incapaz producir productos utilizables en un período de tiempo largo, así que ingenieros, dirección, e inversionistas estaban profundamente preocupados. Scrum saco del atolladero y empezó una entrega de producto incremental, a menudo con un primer producto de utilizable en el primer trimestre

Scrum aplicado para el desarrollo de productos tuvo su primer referencia en “El nuevo , nuevo producto para el desarrollo de juegos” (Harvard Business Review 86116:137-146, 1986) y posteriormente aclarada "The Knowledge Creating Company" ambos por Ikujiro Nonaka y Hirotaka Takeuchi (Oxford University Press, 1995. Basados en estas ideas y en la investigación de

6

teoría de procesos y en colaboración con DuPont Advanced Research Facility, Scrum fue formulado por primera vez y presentado al OMG ( Object Management Group) en 1995.

Roles del Scrum

Scrum implementa sus procesos a través de tres roles considerados fundamentales, todas las responsabilidades de dirección son divididas en estos roles

El propietario del producto

Este rol, representa a la persona interesada en el estado del proyecto y el sistema resultante, este es el que se enfoca en que se retorne la inversión (ROI), el backlog proveído a este rol representa una herramienta poderosa al proyecto, este lo usa para dar a los requerimientos la mas alta prioridad, estos mismos son el mas alto valor del negocio , este rol conoce cuales son las funcionalidades requeridas para resolver la problemática del negocio

Los clientes pueden estables los requerimientos que optimizan el ROI al inicio del proyecto pero ellos no pueden establecer con sus estimados de manera precisa los esfuerzos implicados durante el desarrollo del proyecto , la persona en este Rol es la que ajusta el ROI mas frecuentemente y por eso debe diferenciársele a la persona cliente

El Scrum máster

Es el responsable de los procesos del Scrum, de que finalicé exitosamente , el que enseña el Scrum a todos los involucrados, el encargado de organizar e introducir la cultura del Scrum, descubrir los beneficios esperados y el que se asegura de que se sigan las reglas y practicas del Scrum. También puede ayudar al equipo a decidir cuales de los elementos (backlog) deben desarrollarse en cada iteración (sprint)

El equipo

Es el responsable del desarrollo, deben ser auto-dirigidos, auto-organizados, son los que sacan las características deseadas (el backlog) en cada iteración, y son los responsables de esto mismo . Es el equipo el que decide que parte de la funcionalidad (backlog) debe sacarse en cada incremento

Implementación de Scrum

1.- Comenzar el proceso de Scrum

Debemos seleccionar al equipo , existe una fabula que ejemplifica el significado del proceso del Scrum:

“Un cerdo y una gallina se encuentran en la calle. La gallina le dice al cerdo: ¿por qué no abrimos un restaurante?" El cerdo le dice: "Buena idea, ¿cómo se llamaría el restaurante?" La

7

gallina contesta: "¿Por qué no lo llamamos "Huevos con jamón?" "Lo siento pero no", dice el cerdo, "Yo estaría comprometido pero tú solamente estarías involucrada”

Según esta fabula el equipo consiste de cerdos (gente a la que se le asigna el trabajo) y los pollos (las personas interesadas pero que no trabajan directamente en el ) , identificando los cerdos nosotros podemos componer el equipo de trabajo

Recomendaciones

No mas de 6 – 9 miembros por equipo Si hay mas miembros , romperlos en grupos Cada grupo enfocado en una sola área de trabajo Todo el staff trabajara en esta área

2.- Nombrar al Scrum Máster

El Scrum máster es la persona que conduce las reuniones diarias, mide empíricamente los progresos, toma decisiones y resuelve los problemas de lentitud o trabajo parado, un ingeniero o un director de marketing puede estar en esta área, es la persona que hace las preguntas referidas en el diagrama de proceso del Scrum, que se hizo desde la reunión pasada, que problemas ha habido y que espera para la próxima reunión

3.-Identificar el acumulado

Acumulado (Backlog ) es todo el trabajo pendiente para un área del producto , bien definido en sus términos

Listar todo el trabajo a ser realizado Agrupar todo el trabajo que puede hacerse en los 30 días En áreas no bien definidas o cambiantes establecer un incremento de horizonte conocido Listar todo el trabajo a ser hecho Solo una persona encargada de realizar la priorización de trabajos El equipo elige el acumulado para el sprint - periodo de 30 días Periodo o sprint es el lapso que se da el Scrum para realizar un incremento este debe ser

de 30 días Este acumulado se firma por los miembros del equipo Solo este acumulado se trabaja durante el periodo

4.- Establecer y conducir la reunión diaria del Scrum

Diariamente se hace una reunión para checar el status del trabajo, donde el equipo informa de las actualizaciones , la reunión se enfoca en el trabajo que se esta realizando

Recomendaciones

Mismo tiempo y lugar

8

Evitar siempre buscar un lugar diario Evitar que los miembros del equipo se pregunten siempre donde y cuando son Todos los “pollos” deben saber donde y cuando son No debe durar mas de treinta minutos El Scrum máster debe preguntar las 3 cuestiones básicas ya dichas Scrum máster es el responsable de tomar decisiones y resolver los problemas de trabajo Todas las discusiones a las tres cuestiones postergar a posteriores reuniones

Ventajas del Scrum

Se enfoca en equipos de trabajo Hay una comunicación diaria Ofrece una dirección basada en experiencia y de bajo nivel Hace los obstáculos visibles Se toman decisiones y se resuelven problemas en tiempo real

Historias de Usuario

Basicamente es la misma referencia que en los proyectos XP, esto es deben ser breves y describir una funcionalidad del negocio que tenga valor, es una manera de describir un requerimiento funcional en la metodologia agil al igual que los casos de uso en las metodologias tradicionales

Se pueden obtner de entrevistas ,de reuniones de lluvia de ideas etc. , regularmente se anotan en una simple tarjeta de papel, y se colocan en un tablero (pizarron)

A estas historias se les da una priorizacion de acuerdo a la importancia, , y al alcance proporciandos por el dueño del producto, a la estimacion en tiempo , horas de trabajo por persona esta cantidad es dada por elquipo de trabajo,

Historias Tecnicas

Las historia tecnicas se refieren a aquellas historias que no describen una caracteristica del negocio o que aparentemente no dan valor al negocio, a estas actividades , como instalar un servidor, documentar el diseño general, optimizacion y limpieza del codigo, etc.

Estas historias se intentan evitar, una manera es tratando de convertirlas en historias normales con valor de negocio medible, no siempre es posible, el intentar priorizarlas junto con el resto de las historias es dificil porque el dueño del producto no las reconoce , lo que se puede hacer es mantener una lista aparte, el dueño del producto puede verla pero no modificarla, las actividades para estas historias se acomodan según convenga en la agenda del sprint

Se puede o no mantener informado al dueño del producto, aunque lo mejor es siempre mantenerlo informado

9

Elaboracion del sprint (carrera corta)

En base a las historias de usuario, las actividades de ingenieria (historias tecnicas) se definen las actividades a realizar para cada una

La elaboracion del sprint consiste en seleccionar en base a la importancia de negocio y al estimacion de esfuerzo de ingenieria, las mas adecuadas y comprometerse a solo elaborar esas durante el sprint

Sprint 0 y el DSDM

Se sugiere hacer un sprint 0, que es donde se hacen los analisis y diseños previos, es un sprint para trazar la ruta del proyecto. Esto se hace para poder ir de acuerdo al modelo de procesos DSDM dado por el DSDM Consotium

DSDM es el acrónimo que da nombre a un modelo de procesos para el desarrollo de sistemas de software, desarrollado y concebido por el denominado DSDM Consortium, que se fundó en Inglaterra en 1994, y que actualmente tiene presencia en Inglaterra, EE.UU. Benelux, Dinamarca, Francia y Suiza, Es un modelo que estuvo representado en la firma del Manifiesto Ágil. En 2001, año del Manifiesto Ágil, DSDM publicó la versión 4.1 de su modelo, y se consideró una metodología ágil; y aunque mantuvo las siglas, cambió la denominación original (Dynamis Systems Development Method) por Framework for Business Centred Development

Principios del DSDM

En su versión actual (4.2) el marco de procesos DSDM se basa en 9 principios.

La implicación activa de los usuarios es imprescindible. Los miembros de los equipos de desarrollo DSDM deben tener la autonomía y

potestad necesarias para tomar decisiones. Entrega frecuente de incrementos operativos del producto. El principal criterio de prioridad, desarrollo y validación de las entregas incrementales

es el objetivos y la salud del negocio. El desarrollo iterativo o incremental hace posible obtener la solución más adecuada a

las necesidades del negocio. Todos los cambios realizados en el desarrollo son reversibles. Los requisitos se establecen a un nivel general Las pruebas forman parte del ciclo de desarrollo Es imprescindible trabajar con espíritu de colaboración con todos los agentes

implicados en el sistema que se desarrolla.

Procesos del ciclo de desarrollo DSDM

10

El ciclo de desarrollo de DSDM está compuesto de 5 fases, precedidas de un pre-proyecto y un post-proyecto.

1. Pre-proyecto 2. Estudio de viabilidad 3. Estudio de negocio 4. Iteración de modelado funcional 5. Iteración de diseño y desarrollo 6. Implementación 7. Post-desarrollo

Observando el diseño del modelo de gestión ágil DSDM ( ) vemos que se incluye antes de comenzar con las iteraciones (funcional - Diseño - e implementación), un punto de inicio representado por un triángulo de su diagrama, en este triangulo vemos actividades que son :

Pre-proyecto Estudio de viabilildad Estudio de negocio

En ellos se debe realizar: Análisis ágil de viabilidad sobre las cuestiones: ¿El sistema propuest es técnicamente posible? Impacto en el proceso de negocio ¿Es DSDM el mejor ciclo de desarrollo para la solución del cliente? Análisis previo de los riesgos del proyecto

Y en el "estudio de negocio" : comprobar que el cliente dispone de una visión válida de lo que desea. Definir y validar la definición de alto nivel de la arquitectura del sistema. y generar un plan de desarrollo con las líneas de actividades en las iteraciones del

modelo, del diseño y de la implementación.

11

Este concepto de "validación inicial del proyecto" sería el equivalente al que la ingeniería del software ortodoxa cubre con el proceso de Adquisición, y que tiene como finalidad comprobar que todas las luces están verdes, antes de comenzar , aunque la metodologia agil pura no contiene estas fases el sprint 0 es usado para no romper la filosofia de la metodologia

Elaboracion de la pila de productos (backlog)

El backlog de productos es el corazon del scrum, es una lista priorizada de requisitos funcionales que pueden ser historias de usuario, cosas que el cliente quiere con su terminologia,esta lista puede contener varios campos para cada item o producto,estos serian ID el cual es el identificador unico del producto, su nombre, la importancia que le da el dueño del producto, la estimacion en horas, como se puede probar que la funcionalidad esta cubierta y nota, se pueden agregar mas campos, categoria de actividad (analisis,diseño etc.), usuario de la actividad etc, regularmente con los primeros seis esta bien

En base a las historias reunidas se seleccionan conforme a varios criterios (alcance, estimacion, importancia) las que van a ir en el sprint, en base a estas se definen las actividades que darian cumplimiento a esas historias , se descomponen en sub-actividades etc

Se pueden elaborar tarjetas de producto en papel, comunmente se ordenan en un tablero y se van marcando las que se van cumpliendo

El tablero nos indica que tareas estan en el sprint, cuales se estan realizando y cuales ya estan hechas

Ejemplo de tablero de Sprint

12

PRINCE2-Otras herramientas de procesos que se pueden utilizar

Es una metodología de gestión de proyectos que cubre la administración, control y organización de un proyecto. "PRINCE2" es una marca de la OGC del Reino Unido.En 1996 PRINCE2 fue introducido. La diferencia principal entre ambas versiones es que PRINCE2 no está orientado solamente a TIC. PRINCE2 es adecuado para todo tipo de proyectos. PRINCE2 es un método genérico de administración de proyectos. PRINCE2 puede ser utilizado conjuntamente con scrum

Modelo de procesos PRINCE2

PRINCE2 Hay ocho procesos, cada uno formado por una colección de procesos. La colección está basada en fases dentro del proyecto y las distintas orientaciones en contexto y responsabilidades. Cada proceso de máximo nivel está dividido en sub procesos.

El uso de componentes de procesos PRINCE2 puede ser util para reducir riesgos , cuando por ejemplo se comienza a implementar SCRUM

Figura para ilustrar el modelo PRINCE

13

Sin embargo el uso de actividades de estabilizacion de PRINCE2 tiene un costo en tiempo, un retraso en los sprint, ya que estas son incluidas dentro de las actividades de los sprint, Algunas organizaciones enmascaran el proceso de SCRUM en una fachada de PRINCE2

Herramientas de gestión de la metodología Scrum

Existen en el mercado herramientas de software para llevar a cabo una gestión de la metodología SCRUM entre estas están scrumdesk (scrumdesk.com) que tratan de documentar todos los conceptos del proyecto y de su ciclo de vida, la lista de tareas a ser realizadas (backlog) y las historias de usuario entre otras

Sin embargo se puede llevar la gestion incluso en una simple hoja de excel

14

Ampliando Historias de Usuario (Herramienta de las metodologías agiles)

Introducción

Las historias de usuario son la herramienta utilizada por las metodologías agiles para recoger los requerimientos del sistema, su objetivo es muy similar al de los casos de uso

Las historias de usuario nacen de la necesidad de una mejor comunicación, de un lenguaje común entre todos los involucrados, desarrolladores, usuarios etc. , es evitar el dominio del lenguaje de una de las partes involucradas, por ejemplo si el lenguaje de los desarrolladores predomina, ellos pierdan la oportunidad de escuchar lo que realmente se necesita

Anteriormente definimos a las historias de usuario, como la manera en que los usuarios pueden usar el sistema, las historias de usuario son escritas para los usuarios no para el equipo de desarrollo, es una narrativa mas coloquial y menos formal , que por ejemplo la dada en un caso de uso

Las historias de Usuario no son requerimientos detallados, pueden obtenerse durante las iteraciones, como una experiencia de uso del sistema resultado de una iteración, deben usar la terminología del usuario , un lenguaje de negocios , no la de un desarrollador, deben ser cortas un ejemplo ser algo simple

Aspectos de las historias de usuario

Una Historia de Usuario describe una funcionalidad, un propósito de un sistema o software, son tradicionalmente escritas a mano y se componen de tres aspectos

4. Uno que describa la historia y como un plan y como recordatorio

Este primer aspecto es el que se refleja en la llamada Story Card (Tarjeta de Historia), que son tradicionalmente escritas a mano, en papel a manera de nota, buenos ejemplos pudieran ser :

Story Card : historia de usuario en una nota

Un usuario puede mandar su resumen a través de una pagina Web

Un usuario puede buscar empleo

Una compañía puede publicar nuevas ofertas de trabajo

15

Un usuario puede limitar a quien pueda ver sus resúmenes

Un ejemplo de una mala nota, una historia de usuario mal hecha pudiera ser

El programa podría conectarse a la base de datos a través de una conexión

Es un mal ejemplo porque denota una funcionalidad del programa muy especifica

5. Conversaciones que puedan servir para reflejar detalles de la historia

Los detalles de las historias de usuario están en las conversaciones, las conversaciones tratan de responder preguntas acerca de la historia de usuario un ejemplo de preguntas a contestar para la historia de usuario 1 (búsqueda de empleo) pudiera ser :

¿Qué características del empleo busca el usuario ? ¿ciudad?¿estado?¿Qué información debe ser desplegada acerca del empleo?¿Puede guardarse el resultado de la búsqueda de empleo del usuario?¿Necesita ser miembro de la pagina el usuario ?

La respuesta a estas preguntas pudiera llevar a redactar mas historia de usuario, siempre será mejor tener historias cortas a largas, sin embargo no es necesario llegar a extremos, a tratar de llegar a historias mínimas, solo lo razonable

No es necesario tampoco el llegar a describir la historia de usuario de manera típica y formal esto es

Usuario puede ver información de un trabajo resultado de una búsqueda-Puede ver la descripción-De donde es el trabajo-Cual es el salario o rango

El objetivo no es documentarlas en papel, es el discutirlas con el cliente, tener una conversación de los detalles que se están volviendo importantes, no es el escribir anotaciones acerca de las discusiones en las tarjetas de historias

6. Test que puedan documentar cuando una historia ha sido completada

El reverso de una tarjeta de historia (story card) puede servir para apuntar pruebas que se pueden hacer acerca de la historia, para nuestro ejemplo de la busque de empleo podemos anotar al reverso por ejemplo

Reverso de Story Card 2 (búsqueda de empleo)

Intentar con una descripción del trabajo vacíaIntentar con una descripción del empleo demasiado largaIntentar con un salario que no exista

16

Intentar con un salario de seis dígitos

Estas descripciones son cortas e incompletas, mas pruebas puedes ser sumadas con el tiempo, el objetivo es enviar información a los desarrolladores para que sepan cuando una historia es cubierta, es el conocer las expectativas del cliente acerca de la historia una vez finalizada

Un proyecto que se este llevando a cabo en base a historia de usuario puede sentirse distinto, a la toma de requerimientos tradicional, el primer punto que se nota, es que los clientes o usuarios están involucrados durante toda la vida del proyecto, las historias de usuario son un buen comienzo para definir los tipos de usuario del sistema

Puede tenerse un proyecto inicial de historias pero pueden surgir otras durante todo el proyecto, pueden apilarse historias cortas durante una iteración para su atención, pueden priorizarse en pilas para su desarrollo en cada iteración

Puede tenerse un proyecto inicial de historias pero pueden surgir otras durante todo el proyecto, pueden apilarse historias cortas durante una iteración para su atención, pueden priorizarse en pilas para su desarrollo en cada iteración

Planeando liberaciones e Iteraciones

Un lanzamiento o liberación se organiza ya sea planeando una o mas iteraciones , en este plan de liberación el equipo del cliente intenta priorizar las historias, de acuerdo al deseo de alguna característica querida por una base de usuarios o un grupo pequeño y de acuerdo también a la cohesión con otras historias , el equipo de desarrollo escucha y sugiere acerca de esta priorización, y no se puede olvidar la importancia de los costos económicos

La priorización de las historias de usuario se refleja en puntos y se tabula

Historia Puntos

A 3

B 5

C 5

D 3

E 1

F 8

17

Un plan de liberación podría ser

No. Iteración Historias Puntos

1 A,B,C 13

2 D,E,F 12

Ventajas de las historias de usuario sobre la toma tradicional de requerimientos o casos de uso

Algunas de las ventajas son :

1. Comprensibles para usuarios y desarrolladores

2. Tienen el tamaño justo para la planeación

3. Enfatizan la comunicación verbal sobre la escrita

4. Trabajan para el desarrollo iterativo

5. Fomentan una mejor comprensión acerca de lo que realmente necesitas

Reuniendo Historias de Usuario

Existe un grupo de técnicas para reunir Historias de Usuario y estas son:

1. Entrevistas .- Esta técnica es la usada por default, es importante no solo preguntarle al usuario que necesita, entrevistar a usuarios reales de ser posible

2. Cuestionarios .- Técnica muy útil cuando se tiene demasiados posibles usuarios, útil para priorizar historias , pero no para atrapar nuevas, a diferencia de una conversación, el usuario no presta tanto interés, un buen cuestionario pudiera pedir la opinión de las características actuales del sistema y cual pudiera no necesitarse, preguntando el porque de esto mismo, esto pudiera ayudarnos a priorizar mejor una tarea

3. Observación .- Puede ayudarnos ver como los usuarios utilizan nuestro software para recoger indicios, siempre que se pueda hay que hacerlo, aunque no siempre se puede

4. Taller de escritura de historias .- Es una reunión, de clientes, desarrolladores, usuarios y otros participantes que pueden contribuir a escribir historias, se trata de que todos escriban historias como ellos puedan, dejando la priorización para después

18

19