1

Metodologas Agiles
Introduccin Una metodologa gil es una metodologa efectiva par a modelar y documentar un proyecto de software, es una coleccin de valores principios y practicas para modelar software que puede ser aplicados de manera simple y ligera. La metodologa Agil tiene varios principios que la diferencian sobre las metodologas 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 metodologa 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 documentacin 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 documentacin 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 documentacin podra ser innecesaria, por ejemplo una pequea aplicacin emergente, que una vez pasada la emergencia , esta aplicacin desaparece, el cargar de documentacin de requerimientos, arquitectura , testeo etc. Podra considerarse de sobra, sin embargo eso no quiere decir que no es necesaria la documentacin, esta debe existir pero solo la suficiente 3. Colaboracin 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 difcil ya que los clientes no estn acostumbrados, ellos estn 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 adaptacin, no decir NO A LOS CAMBIOS, aceptar las sugerencias de los usuarios, sin por eso hacer un lado la planificacin

Estos valores han dado lugar a doce principios que son : 1. La satisfaccin del cliente 2. Bienvenida a los cambios que puedan ocurrir 3. Entregar regularmente software que trabaje

2 4. Gente de negocios y desarrolladores trabajan diariamente en conjunto 5. Construccin de proyectos alrededor de individuos motivados para esto 6. Las comunicaciones cara a cara son las mejores 7. Software que trabaje es la mejor medida del progreso 8. Atencin continua a la excelencia y al buen diseo 9. Promover el desarrollo sostenible 10.Simplicidad 11.Las mejores arquitecturas, requerimientos , y diseos emergen de equipos auto-organizados 12.Introspeccin , los equipos deben regularmente hacerse una revisin 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 documentacin UML, se intenta promover procesos ligeros. Con la modelacin Agil se siguen tres objetivos que son: Promover y definir un grupo de valores, practicas y principios que ayudan a producir los modelos adecuados Orientacin de cmo aplicar el modelado de proyectos agiles Orientacin de cmo aplicar el modelado Agil a otro tipo de procesos o metodologas (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 propsito 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

3 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 confusin a las audiencias a las que van dirigidos. Deben ser lo suficientemente detallados, muchos detalles pueden ser irrelevante de acuerdo a quien se dirige el modelo. Tan simples como sea posible.

La documentacin de las metodologas 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 diseo, no crea documentacin innecesaria, se puede usar cualquier tipo de diseo o documentacin que nos ayude, puede haber procesos que sea difcil capturarlos con los diagramas conocidos, pero si otros, una metodologa Agil podra asociarlos. Ejemplos de metodologas consideradas Agil son Programacin Extrema Scrum MSF 4.0 Microsoft RAD * Cristal RUP Agil Otras ..

En este documento hablaremos de las primeras cuatro metodologas, estas metodologas pueden combinarse , por ejemplo Programacin 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 implantacin de una gestin gil de proyectos como Scrum:
Cultura de empresa basada en trabajo en equipo, delegacin, creatividad y mejora continua. Compromiso del cliente .- Scrum exige del cliente una alta implicacin y una dedicacin regular:. Compromiso de la Direccin de la organizacin para resolver problemas endmicos y realizar cambios organizativos, formando

4
equipos autogestionados y multidisciplinares y fomentando una

cultura de gestin basada en la colaboracin y en la facilitacin.

Compromiso conjunto y colaboracin de los miembros del equipo. Relacin 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 Tamao de cada equipo entre 5 y 9 personas (con tcnicas de colaboracin entre equipos que trabajan en el mismo proyecto). Equipo trabajando en un mismo espacio comn para maximizar la comunicacin. Dedicacin del equipo a tiempo completo.
Estabilidad de los miembros del equipo

Herramientas documentales - Historias de Usuario En la programacin 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 anecdtico, 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 terminologa 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 travs 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 propsito de un sistema o software, son tradicionalmente escritas a mano y se componen de tres aspectos 1. Uno que describa la historia y como planeacin y recordatorio 2. Conversaciones que puedan servir para reflejar detalles de la historia 3. Test que puedan documentar cuando una historia ha sido completada

5 Puede tenerse un proyecto inicial de historias pero pueden surgir otras durante todo el proyecto, pueden apilarse historias cortas durante una iteracin para su atencin, pueden priorizarse en pilas para su desarrollo en cada iteracin

Metodologa gil
Introduccin

- SCRUM

Scrum es una metodologa gil, que puede ser usada para manejar el desarrollo de productos complejos de software , en esta metodologa 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 adaptacin de los sistemas desarrollados Caractersticas Scrum por su proceso iterativo incremental produce un grupo de funcionalidades en cada fin de iteracin. Sus caractersticas son: Scrum es un proceso agile para el manejo y control del trabajo de desarrollo Scrum es un contenedor de practicas de ingeniera existentes Scrum es un enfoque basado en equipos , incrementa el desarrollo cuando los requerimientos cambian rpidamente Scrum es un proceso que controla el caos entre los conflictos de inters y las necesidades Scrum es un camino para mejorar las comunicaciones y maximiza r la cooperacin 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 construccin de proyectos exitosos en las organizacin, sin mayores cambios dentro de los 30 das 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

7 Scrum es un conjunto de prcticas interrelacionadas y reglas que optimizan el entorno de desarrollo, reducen la sobrecarga organizativa, y sincronizan los requisitos del mercado con los prototipos de cada iteracin . Basado en una teora 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 liberacin. Una funcionalidad del producto til es dada cada treinta das como requisito, la arquitectura, y el diseo aparecen, incluso cuando la tecnologas es inestable aun Scrum como lo muestra la ilustracin se basa en el equipo, en reuniones diarias presididas por el Scrum mster para establecer el estado del proyecto, y en la salida cada 30 das de caractersticas del proyecto finalizadas y listas para trabajar, el corazn del Scrum es la iteracin, que en cada iteracin presenta una mejora del funcionamiento del producto final, en cada iteracin se evala la tecnologa y capacidades requeridas, diariamente se pueden modificar el enfoque si se encuentran nuevas dificultades y tratar de remediarlas, el corazn del Scrum es la productividad Fig. Proceso de trabajo del Scrum

Las ms 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

8 Scrum ha sido usado producir productos financieros, productos de Internet . En cada ejemplo, la organizacin era incapaz producir productos utilizables en un perodo de tiempo largo, as que ingenieros, direccin, 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 investigacin de teora de procesos y en colaboracin 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 travs de tres roles considerados fundamentales, todas las responsabilidades de direccin 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 inversin (ROI), el backlog provedo 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 problemtica 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 diferencirsele a la persona cliente El Scrum mster Es el responsable de los procesos del Scrum, de que finalic exitosamente , el que ensea 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. Tambin puede ayudar al equipo a decidir cuales de los elementos (backlog) deben desarrollarse en cada iteracin (sprint) El equipo

9 Es el responsable del desarrollo, deben ser auto-dirigidos, autoorganizados, son los que sacan las caractersticas deseadas (el backlog) en cada iteracin, y son los responsables de esto mismo . Es el equipo el que decide que parte de la funcionalidad (backlog) debe sacarse en cada incremento Implementacin 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, cmo se llamara el restaurante?" La gallina contesta: "Por qu no lo llamamos "Huevos con jamn?" "Lo siento pero no", dice el cerdo, "Yo estara comprometido pero t solamente estaras involucrada Segn 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 Mster El Scrum mster es la persona que conduce las reuniones diarias, mide empricamente 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 reunin pasada, que problemas ha habido y que espera para la prxima reunin 3.-Identificar el acumulado Acumulado (Backlog ) es todo el trabajo pendiente para un rea del producto , bien definido en sus trminos

10 Listar todo el trabajo a ser realizado Agrupar todo el trabajo que puede hacerse en los 30 das 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 priorizacin de trabajos El equipo elige el acumulado para el sprint - periodo de 30 das Periodo o sprint es el lapso que se da el Scrum para realizar un incremento este debe ser de 30 das Este acumulado se firma por los miembros del equipo Solo este acumulado se trabaja durante el periodo

4.- Establecer y conducir la reunin diaria del Scrum Diariamente se hace una reunin para checar el status del trabajo, donde el equipo informa de las actualizaciones , la reunin se enfoca en el trabajo que se esta realizando Recomendaciones Mismo tiempo y lugar 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 mster debe preguntar las 3 cuestiones bsicas ya dichas Scrum mster es el responsable de tomar decisiones y resolver los problemas de trabajo Todas las discusiones a las tres cuestiones postergar a posteriores reuniones

11 Ventajas del Scrum Se enfoca en equipos de trabajo Hay una comunicacin diaria Ofrece una direccin basada en experiencia y de bajo nivel Hace los obstculos 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 dueo 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 diseo 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 dueo del producto no las reconoce , lo que se puede hacer es mantener una lista aparte, el dueo del producto puede verla pero no modificarla, las actividades para estas historias se acomodan segn convenga en la agenda del sprint Se puede o no mantener informado al dueo del producto, aunque lo mejor es siempre mantenerlo informado Elaboracion del sprint (carrera corta)

12 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 diseos 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 acrnimo 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, ao del Manifiesto gil, DSDM public la versin 4.1 de su modelo, y se consider una metodologa gil; y aunque mantuvo las siglas, cambi la denominacin original (Dynamis Systems Development Method) por Framework for Business Centred Development Principios del DSDM En su versin actual (4.2) el marco de procesos DSDM se basa en 9 principios. La implicacin activa de los usuarios es imprescindible. Los miembros de los equipos de desarrollo DSDM deben tener la autonoma y potestad necesarias para tomar decisiones. Entrega frecuente de incrementos operativos del producto. El principal criterio de prioridad, desarrollo y validacin de las entregas incrementales es el objetivos y la salud del negocio. El desarrollo iterativo o incremental hace posible obtener la solucin ms 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

13 Es imprescindible trabajar con espritu de colaboracin con todos los agentes implicados en el sistema que se desarrolla.

Procesos del ciclo de desarrollo DSDM 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. Iteracin de modelado funcional 5. Iteracin de diseo y desarrollo 6. Implementacin 7. Post-desarrollo

Observando el diseo del modelo de gestin gil DSDM ( ) vemos que se incluye antes de comenzar con las iteraciones (funcional - Diseo - e implementacin), un punto de inicio representado por un tringulo de su diagrama, en este triangulo vemos actividades que son : Pre-proyecto Estudio de viabilildad Estudio de negocio

En ellos se debe realizar:

14 Anlisis gil de viabilidad sobre las cuestiones: El sistema propuest es tcnicamente posible? Impacto en el proceso de negocio Es DSDM el mejor ciclo de desarrollo para la solucin del cliente? Anlisis previo de los riesgos del proyecto

Y en el "estudio de negocio" : comprobar que el cliente dispone de una visin vlida de lo que desea. Definir y validar la definicin de alto nivel de la arquitectura del sistema. y generar un plan de desarrollo con las lneas de actividades en las iteraciones del modelo, del diseo y de la implementacin. Este concepto de "validacin inicial del proyecto" sera el equivalente al que la ingeniera del software ortodoxa cubre con el proceso de Adquisicin, y que tiene como finalidad comprobar que todas las luces estn 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 dueo 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,diseo etc.), usuario de la actividad etc, regularmente con los primeros seis esta bien

15 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

PRINCE2-Otras herramientas de procesos que se pueden utilizar Es una metodologa de gestin de proyectos que cubre la administracin, control y organizacin 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 mtodo genrico de administracin de proyectos. PRINCE2 puede ser utilizado conjuntamente con scrum Modelo de procesos PRINCE2

16 PRINCE2 Hay ocho procesos, cada uno formado por una coleccin de procesos. La coleccin est basada en fases dentro del proyecto y las distintas orientaciones en contexto y responsabilidades. Cada proceso de mximo 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

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 gestin de la metodologa Scrum Existen en el mercado herramientas de software para llevar a cabo una gestin de la metodologa SCRUM entre estas estn 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

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

18

Ampliando Historias de Usuario (Herramienta de las metodologas agiles)

Introduccin
Las historias de usuario son la herramienta utilizada por las metodologas 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 comunicacin, de un lenguaje comn 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 iteracin, deben usar la terminologa 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 propsito 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 travs de una pagina Web

Un usuario puede buscar empleo

19

Una compaa puede publicar nuevas ofertas de trabajo

Un usuario puede limitar a quien pueda ver sus resmenes Un ejemplo de una mala nota, una historia de usuario mal hecha pudiera ser El programa podra conectarse a la base de datos a travs de una conexin 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 estn 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 (bsqueda de empleo) pudiera ser : Qu caractersticas del empleo busca el usuario ? ciudad?estado? Qu informacin debe ser desplegada acerca del empleo? Puede guardarse el resultado de la bsqueda 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 mnimas, solo lo razonable No es necesario tampoco el llegar a describir la historia de usuario de manera tpica y formal esto es Usuario puede ver informacin de un trabajo resultado de una bsqueda -Puede ver la descripcin -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 conversacin de los detalles que se estn volviendo importantes, no es el escribir anotaciones acerca de las discusiones en las tarjetas de historias

20 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 (bsqueda de empleo) Intentar con una descripcin del trabajo vaca Intentar con una descripcin del empleo demasiado larga Intentar con un salario que no exista Intentar con un salario de seis dgitos

Estas descripciones son cortas e incompletas, mas pruebas puedes ser sumadas con el tiempo, el objetivo es enviar informacin 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 estn 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 iteracin para su atencin, pueden priorizarse en pilas para su desarrollo en cada iteracin Puede tenerse un proyecto inicial de historias pero pueden surgir otras durante todo el proyecto, pueden apilarse historias cortas durante una iteracin para su atencin, pueden priorizarse en pilas para su desarrollo en cada iteracin

Planeando liberaciones e Iteraciones

Un lanzamiento o liberacin se organiza ya sea planeando una o mas iteraciones , en este plan de liberacin el equipo del cliente intenta priorizar las historias, de acuerdo al deseo de alguna caracterstica querida por una base de usuarios o un grupo pequeo y de acuerdo tambin a la cohesin con otras

21 historias , el equipo de desarrollo escucha y sugiere acerca de esta priorizacin, y no se puede olvidar la importancia de los costos econmicos La priorizacin de las historias de usuario se refleja en puntos y se tabula Historia A B C D E F Puntos 3 5 5 3 1 8

Un plan de liberacin podra ser No. Iteracin 1 2 Historias A,B,C D,E,F Puntos 13 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 tamao justo para la planeacin 3. Enfatizan la comunicacin verbal sobre la escrita 4. Trabajan para el desarrollo iterativo 5. Fomentan una mejor comprensin acerca de lo que realmente necesitas Reuniendo Historias de Usuario Existe un grupo de tcnicas para reunir Historias de Usuario y estas son: 1. Entrevistas .- Esta tcnica es la usada por default, es importante no solo preguntarle al usuario que necesita, entrevistar a usuarios reales de ser posible

22 2. Cuestionarios .- Tcnica muy til cuando se tiene demasiados posibles usuarios, til para priorizar historias , pero no para atrapar nuevas, a diferencia de una conversacin, el usuario no presta tanto inters, un buen cuestionario pudiera pedir la opinin de las caractersticas actuales del sistema y cual pudiera no necesitarse, preguntando el porque de esto mismo, esto pudiera ayudarnos a priorizar mejor una tarea 3. Observacin .- 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 reunin, 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 priorizacin para despus

23