UNIVERSIDAD VERACRUZANA TESINA. Licenciado en Sistemas Computacionales Administrativos. Itzel Yahana Medina Toledo. M. Rubén Álvaro González Benítez

Transcripción

1 UNIVERSIDAD VERACRUZANA Facultad de Contaduría y Administración Estudio y Uso de una Herramienta para la Gestión de Proyecto basados en Metodologías Agiles. TESINA Para obtener el título de: Licenciado en Sistemas Computacionales Administrativos Presenta: Itzel Yahana Medina Toledo Asesor: M. Rubén Álvaro González Benítez Cuerpo Académico: Tecnologías de la información y las Organizaciones inteligentes en la Sociedad del conocimiento. Xalapa-Enríquez, Veracruz Junio 2011

2

3 UNIVERSIDAD VERACRUZANA Facultad de Contaduría y Administración Estudio y Uso de una Herramienta para la Gestión de Proyecto basados en Metodologías Agiles. TESINA Para obtener el título de: Licenciado en Sistemas Computacionales Administrativos Presenta: Itzel Yahana Medina Toledo Asesor: M. Rubén Álvaro González Benítez Cuerpo Académico: Tecnologías de la información y las Organizaciones inteligentes en la Sociedad del conocimiento. Xalapa-Enríquez, Veracruz Junio 2011

4 DEDICATORIAS Y AGRADECIMIENTOS A MIS PADRES Y ABUELOS Por darme lo mas importante en la vida que es su amor, por darme consejos necesarios para salir adelante, por estar conmigo en los momentos difíciles dándome palabras de aliento para no rendirme ante las dificultades que han surgido, porque gracias a sus esfuerzos yo logre tener lo que desde niña había anhelado, mi formación profesional, pero sobre todo por poner su confianza en mí y decirme que lograría este sueño. AL MI DIRECTOR DE TESIS Por su gran confianza, dedicación, orientación y principalmente por el gran cariño que me ha demostrado hasta el día de hoy, ya que para mí no es solo mi profesor o director de tesis, sino, un gran amigo que en toda la carrera estuvo presente apoyándome en cualquier circunstancia. Gracias por compartir sus conocimientos conmigo y que por usted soy un mejor estudiante. A MI HERMANA Porque estuviste siempre conmigo en las buenas y en las malas, por convertirte en mi confidente y mi apoyo cuando estaba triste, por hacerme reír en los instantes difíciles y por compartir conmigo tantas etapas de mi vida. Gracias

5 A MIS MAESTROS Y SINODALES A todos mis profesores que me acompañaron en mi paso por la facultad, gracias por sus enseñanzas y sobre todo por la paciencia, así también gracias por orientarme cuando me encontraba en alguna dificultad o tenía alguna duda. Gracias también en especial a mis sinodales la profesora Alma Delia Otero Escobar y al profesor Jorge Iván por haberme apoyado en cada detalle. A MIS AMIGOS A todos mis amigos porque me acompañaron durante toda esta trayectoria, porque siempre que los necesite estuvieron ahí en cada momento. Gracias por brindarme su amistad, su cariño y confianza, gracias por hacer mis días más amenos y alegres con su compañía. Le doy gracias a dios por darme la fortuna de conocerlos.

6 INDICE RESUMEN. 1 INTRODUCCIÓN CAPITULO I. Metodologías para el desarrollo de sistemas Modelo del ciclo de vida Modelo en cascada o clásico Modelo evolutivo del proceso del proceso de software Modelo incremental Modelo en Espiral Modelo de construcción de prototipo El modelo DRA (desarrollo rápido de aplicaciones) Surgimiento de las metodologías ágiles para el desarrollo de sistemas Metodologías ágiles XP (xtreme programing) Scrum Crystal Clear DSDM (Método de Desarrollo de Sistema Dinámico) FDD (Feature Driven Development) ASD (Desarrollo de software Adaptable) comparativa de las metodologías agiles...61 III

7 CAPITULO II. Gestión de proyectos basados en metodologías agiles Origen de la gestión de proyectos Gestión predictiva o clásica Manifiesto ágil Gestión de proyectos agiles Gestión de proyectos predictiva o ágil?...89 CAPITULO III. Herramientas para la gestión de proyectos agiles: Pivotal Tracker Herramientas para la gestión de proyectos de software Herramientas para la gestión de proyectos basados en metodologías agiles Ventajas y desventajas de Pivotal Tracker Interacción con la herramienta Pivotal Tracker CAPITULO IV. Pivotal Tracker en el proyecto PIN PIN (Plataforma Integral de Negocios) Scrum como metodología ágil para la gestión del proyecto PIN Caso práctico con Scrum Gestión del proyecto PIN en la herramienta Pivotal Tracker utilizando Scrum CONCLUSIONES. 143 FUENTES DE INFORMACIÓN..148 IV

8 ÍNDICE DE FIGURAS..151 ÍNDICE DE TABLAS..153 V

9 RESUMEN Esta tesis titulada estudio y uso de una herramienta para la gestión de proyectos basados en metodologías ágiles trata de cómo se están implementando las nuevas tecnologías en este caso las metodologías ágiles en los proyectos de software y más aun cual es el lugar que ocupan las herramientas en la gestión de estos proyectos. En esta tesis se podrá identificar claramente la metodología realizada para la gestión de proyectos, así como el uso en las organizaciones de desarrollo. Ahora bien, el programa utilizad para el desarrollo de la misma consistió en lo siguiente: introducción a las metodologías de desarrollo donde se estudias las metodologías tradicionales y el surgimiento de las metodologías ágiles, así como el estudio de las principales, el segundo capítulo haba sobre la gestión de proyectos basados en metodologías ágiles donde también se da una introducción a los conceptos más importantes y de lo que trata la gestión de proyectos predictiva como ágil, el tercer capítulo habla sobre las herramientas para gestionar proyectos ágiles dando una introducción de lo que aportan las herramientas y destacando algunas de estas, y en el cuarto y último capítulo se hace un estudio sobre un proyecto y se gestiona el proyecto utilizando una herramienta y una metodología ágil 1

10 INTRODUCCIÓN

11 El uso de las metodologías ágiles es una actividad que no es muy común en nuestro país ya que su práctica está muy poco extendida. Este sería uno más de los temas tecnológicos en el cual nos encontramos en rezago en comparación con otros países similares a México, pareciera que tratamos de mantenernos al margen de las nuevas tecnologías, en muchas ocasiones porque no se cuentan con los conocimientos suficientes sobre el tema, y nos quedamos atascados perdiendo competitividad. La intención de este trabajo es que utilizando una herramienta para la gestión de proyectos basados en metodologías ágiles, se pueda gestionar un proyecto, o bien, mostrar cómo hacerlo. Es importante destacar que este trabajo puede sentar las bases para un proyecto de mayor magnitud para poder gestionar proyectos agiles usando herramienta que proporcionen un medio que sirva de ayuda y mejore la factibilidad y fiabilidad de este. Al documentar todos los pasos y técnicas que use a lo largo del proyecto, el proceso del cómo hacerlo estará libre para que cualquier persona pueda consultarlo y aplicarlo. A continuación explicaremos detalladamente el objetivo de esta tesina utilizando el prologo elaborado. Justificación de la modalidad La razón por la cual elegí cursar la experiencia recepcional en su modalidad de tesina es porque por medio de ella se pueden adquirir conocimientos haciendo una investigación documental que termine en el desarrollo de un trabajo practico en este caso aplicado a la gestión de un proyecto que esté basado en metodologías agiles (también conocido como desarrollo ágil). En esta modalidad se desarrollaran, aplicaran y reforzaran conocimientos adquiridos a lo largo de la carrera, así como también experimentar nuevas 3

12 tendencias para después presentar un trabajo practico que brinde una propuesta de mejora para la sociedad. El interés personal de la gestión de proyectos basado en metodologías agiles surge al llevar a cabo con el cuerpo académico Tecnologías de la información y las organizaciones inteligentes en la sociedad del conocimiento un proyecto denominado PIN (plataforma integral de negocios), en este proyecto se desarrollara una plataforma tecnológica Web para atender un tema de interés nacional respecto a las PYMES, este proyecto utilizará para su desarrollo una metodología ágil por lo que surge la idea de gestionar el proyecto con una herramienta basada en metodologías ágiles. De esta manera surge la idea de realizar el trabajo recepcional bajo la modalidad de tesina. Al final de la tesina, espero desenvolverme en ese ámbito de gestión de proyectos basado en metodologías ágiles, teniendo una formación formada por la experiencia y el estudio que me permita ayudar a transmitir una nueva visión de la utilización de estas aplicaciones. Introducción al trabajo Dentro de los planes de estudios de la Licenciatura de Sistemas Computacionales Administrativos no enfrentamos a algunas materias que nos dan a conocer cómo gestionar un proyecto, en este caso podemos mencionar: metodologías de la investigación, desarrollo emprendedor y gestión y evaluación de proyecto. Ahora muy aunado al tema en este trabajo recepcional se pone en práctica la gestión de proyectos usando las tecnologías de información (una herramienta) y además relacionado con las tendencias de las metodologías ágiles en la actualidad. Si hablamos de gestión de proyectos nos referimos a un entorno donde las aplicaciones estarán presentes en todas partes y en la infraestructura de las organizaciones facilitándoles cualquier tarea imaginable, ahora si hablamos de 4

13 gestionar proyectos basados en metodologías agiles abundamos mas el tema de TI por el hecho de pertenecer a una rama del desarrollo de las mismas. Muchas empresas de TI trabajan en escenarios muy diferentes a los que impulsaron a gestión de proyectos predictiva, por lo consiguiente se están otorgando estrategias diferentes para gestionar el lanzamiento de sus productos: estrategias que están siendo orientadas a la entrega temprana de resultados tangibles y que sean factibles al cambio para cubrir nuevas necesidades. La tesina con el nombre de uso y estudio de una herramienta para la gestión de proyectos basados en metodologías tiene como propósito mostrar al lector una visión de cómo ha ido evolucionando la forma de gestionar proyectos y el papel que juega la metodologías ágiles en estas, y que existen herramientas que nos brindan un apoyo en su aplicación. Este documento presentara un trabajo de investigación de la gestión de proyectos ágiles, metodologías ágiles que existe, y para concluir se utilizará una herramienta para gestionar un proyecto basado en metodologías ágiles, el cual apoyara a otro proyectos que tengan en mente el uso de una metodología ágil para el desarrollo. Formulación del problema La gestión de proyectos basado en metodologías agiles se ha enfrentado algunas dificultades ya que aunque no son tan nuevas se considera una tendencia en estos años, por lo cual su uso a despertado especulaciones tanto en su eficacia como en su realización por ello se presenta una herramienta que sirve para gestionar proyectos basados en metodologías agiles. 5

14 La problemática se concentra en el Uso y estudio de una herramienta para la gestión de proyectos basado en metodologías agiles, que permita con el uso de la TI gestionar de forma práctica y dinámica un proyecto que esté basado en alguna metodología ágil y con este efectuar una gestión más rápida y eficiente y apoyada de una herramienta. Objetivos de la investigación Objetivo General Estudiar y aplicar la gestión de proyectos basados en metodologías agiles por medio de una herramienta de Tecnologías de la Información. Objetivos especifico recopilar y analizar información metodologías de desarrollo de sistemas recopilar y analizar información sobre la gestión de proyectos recopilar y analizar información sobre metodologías agiles recopilar y analizar información sobre la gestión de proyectos agiles Analizar y estudiar una herramienta para la gestión de proyectos basados en metodologías ágiles Aplicar la herramienta para la gestión de proyectos agiles a el proyecto PIN 6

15 Justificación de la investigación En este trabajo de investigación, se pretende recopilar la información necesaria para poder ofrecer una fuente para todos aquellos que deseen gestionar proyectos basados en metodologías ágiles usando la herramienta Pivotal Tracker. Las metodologías ágiles aunque no son nuevas no han tenido mucha difusión, es por ello que no se cuenta con bibliografía suficiente y oportuna, por lo cual considero importante poder otorgar a esta casa de estudio y a los interesados información tanto teórica como práctica e importante. Las organizaciones están en constante competencia con aquellas que también van dirigidas a objetivos similares. Esto aplicado a la gestión de proyectos ágiles implica que si las organizaciones no incorporan las tendencias y no utilizan las TI no se pueden esperar resultados mejores a los tradicionales, y en consecuencia su permanencia en el mundo de las tecnologías de información dependerá de su adaptación. La elección del surge del interés de conocer más sobre las metodologías ágiles y abundando en el tema, aplicarlo a un proyecto usando una herramienta que gestionan proyectos basados en metodologías ágiles. Así fue como surge dicha investigación. La gestión de proyectos basado en metodologías ágiles ponen énfasis en la comunicación y en los resultados más que en la documentación. Las metodologías ágiles han sido un gran avance para las empresas que se dedican al desarrollo de software. El beneficio que me trae realizar este proyecto es poner en práctica conocimientos que me fueron adquiridos en la carrera, probar nuevas tendencias y mostrar que cuando uno se propone una meta, se puede lograr. 7

16 CAPITULO I. METODOLOGÍAS PARA EL DESARROLLO DE SISTEMAS

17 El desarrollo de software no es una tarea fácil. Prueba de ello es que existen numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo. Por una parte tenemos aquellas propuestas más tradicionales que se centran especialmente en el control del proceso, en la estandarización y en una forma secuencial, estableciendo rigurosamente las actividades involucradas, los artefactos que se deben producir, y las herramientas que se usarán. Estas propuestas han demostrado ser efectivas y necesarias en un gran número de proyectos, pero también han presentado problemas en otros muchos. Una posible mejora es incluir en los procesos de desarrollo, más actividades, más artefactos y más restricciones, basándose en los puntos débiles detectados. Sin embargo, el resultado final sería un proceso de desarrollo más complejo que puede incluso limitar la propia habilidad del equipo para llevar a cabo el proyecto. Otra aproximación es centrarse en otras dimensiones, como por ejemplo el factor humano o el producto software. Esta es la filosofía de las metodologías ágiles. Las metodologías ágiles dan mayor valor al individuo, a la colaboración con el cliente y al desarrollo incremental del software con iteraciones muy cortas. Este enfoque está mostrando su efectividad en proyectos con requisitos muy cambiantes y cuando se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Las metodologías ágiles están revolucionando la manera de producir software, y a la vez generando un amplio debate entre sus seguidores y quienes por escepticismo o convencimiento no las ven como alternativa para remplazar a las metodologías tradicionales. 9

18 En este capítulo se presenta resumidamente el contexto en el que surgen las metodologías ágiles, sus valores, principios y comparación con las metodologías tradicionales. 1.1 Metodologías tradicionales: Modelo del ciclo de vida Las metodologías empleadas a continuación se derivan del modelo de ciclo de vida y son denominadas metodologías tradicionales o casos predictivas. Las metodologías para el desarrollo de sistemas han estado presentes desde la aparición del desarrollo de software unas en forma práctica y otras más estandarizadas. Los modelos para el desarrollo de software han predominado en los llamados modelo de ciclo de vida que hasta en estos tiempos son los más reconocidos por los usuarios, aunque sin darse cuenta estos caen en el uso de las metodologías más nuevas. Un modelo de ciclo de vida de software se refiere a las actividades que ocurren durante el desarrollo de software, este trata de determinar el orden de las etapas involucradas y como va ir pasando de una etapa a otra etapa. Un modelo de ciclo de vida del software: Describe las fases principales de desarrollo de software. Define las fases primarias esperadas de ser ejecutadas durante esas fases. Ayuda a administrar el progreso del desarrollo, y Provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software. La vida de un producto software comienza con su desarrollo y continúa con su posterior mantenimiento. Como se menciono anteriormente comprende las 10

19 diferentes fases y actividades que están implicadas en las tareas de desarrollo y mantenimiento y este constituye un buen medio para estructurar dichas actividades, aunque el ciclo de vida del software se ha centrado principalmente en las actividades que están asociadas al desarrollo. Así, los modelos por una parte suministran una guía para los ingenieros de software con el fin de ordenar las diversas actividades técnicas en el proyecto, por otra parte suministran un marco para la administración del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance. (Alonso; Martínez; Segovia, 2005) Modelo en cascada o clásico En los años 70s se impuso un enfoque de desarrollo, introducido por Royce a través de un ciclo de vida denominado cascada. Este método fue de los primeros en surgir también es denominado clásico, modela un ciclo de vida convencional de la ingeniería de software; aplicando un enfoque sistemático y secuencial que comienza con la ingeniería de sistemas y progresa a través del análisis, diseño, codificación, pruebas y mantenimiento. El modelo en cascada es un proceso secuencial de desarrollo en el que los pasos de desarrollo son vistos hacia abajo (como en una cascada de agua). Las características de este modelo son: Cada fase empieza cuando se ha terminado la anterior. Para pasar a la fase posterior es necesario haber logrado los objetivos de la previa. Es útil como control de fechas de entregas. 11

20 Al final de cada fase el personal técnico y los usuarios tienen la oportunidad de revisar el progreso del proyecto. Según (Alonso; Martínez; Segovia, 2005) normalmente el ciclo de vida del software se suele dividir en tres fases: la primera es la planificación, la segunda de desarrollo y la tercera de mantenimiento estas a su vez engloban a las seis etapas que son la ingeniería del sistema, análisis de los requerimientos o requisitos, diseño, codificación, pruebas y mantenimiento. La primera fase que es la de planificación de software corresponde a las etapas de ingeniería del software o análisis del sistema en el cual se establecen los requisitos del sistema, y en el análisis de los requerimientos en el cual se va obtener una especificación de los requerimientos. La segunda fase que es la de desarrollo abarcan las tapas de diseño, codificación y pruebas, en la etapa de diseño se implementa la arquitectura del sistema como va a estar constituidos, se pueden emplear diagramas de flujo. El diseño está dividido en dos partes el diseño lógico y el diseño conceptual. En codificación se procederá a la elaboración del sistema en sí, que conocemos como programación. Con los que respeta a la tercera etapa del desarrollo las pruebas, se implementara el sistema y se probara para verificar que este cumpla con los requisitos que se pidieron. Por último está la fase de mantenimiento que nada mas contiene la etapa de mantenimiento, en esta etapa si el sistema presenta cambios o algún error esta etapa le da un seguimiento al sistema y verifica que esté funcionando correctamente. 12

21 Se presentaron las fases con sus etapas correspondientes, a continuación se mostraran detalladamente: 1. Ingeniera del software o análisis del sistema El objetivo de esta etapa es otorgar un análisis global del sistema, estableciendo los requisitos de todos los elementos del sistema y luego asignar al software, esto cuando nos referimos a que existe una interrelación entre otros elementos como lo pueden ser personas, hardware y base de datos. En esta etapa el informático tiene que hacer un estudio a fondo del sistema, especializarse en su funcionamiento y terminología y realizar una interacción con el cliente, los usuarios y el experto en el sistema para que la percepción que tiene estos con el sistema coincida con la percepción que tiene el informático. El análisis del sistema es una etapa que de la fase de planificación y en ella se realiza un descripción en torno al software que se requiere obtener (Definición de los objetivos). 2. Análisis de los requerimientos El análisis de los requerimientos del software a diferencia del análisis del sistema es un proceso de descubrimiento y especificación que lleva a cabo el analista. Detalla con más refinamiento el problema que ya se había establecido en las especificaciones del sistema, también se analizan soluciones alternativas. En el análisis de los requisitos del software se pueden identificar cinco actividades (Pressman, 1993): 13

22 Reconocimiento del problema software; este consiste en comprender perfectamente el papel que va a desempeñar el software en el sistema. Evaluación del problema y la solución; para llevar a cabo este proceso el analista debe evaluar el flujo y la estructura de la información, entender cómo funciona el software (comportamiento), establecer las características de la interfaz del sistema y describir las restricciones del diseño. Modelado. Consiste en crear un modelo a lápiz del sistema que permita la comprensión de este. 3. Diseño Uno de las principales tareas en la etapa de diseño en crear una representación grafica por cada modulo y las especificaciones de estos. En esta etapa se recomienda construir un diseño de interfaz de usuario el cual se le otorgara al mismo usuario para que este pueda evaluarlo y pueda modificar su dicho diseño con forme a la evaluación y perspectiva que tuvo de la interfaz. Como resultado de esta etapa es un documento de diseño detallado, que como su nombre lo dice incorpora un diseño detallado de los datos, del diccionario de datos, de la interfaz y de la arquitectura modular del sistema, con la interfaz de los módulos así como el diseño procedimental de cada modulo. A en este documento también va a ir incorporado una especificación de las pruebas a realizar a nivel de modulo y de su integración del sistema. (Pressman, 1993 El diseño se podría decir que es la parte central de la ingeniería del software y merece tiempo y dedicación en su elaboración. 14

23 4. Codificación Esta etapa tiene como objetivo traducir en una forma legible para la computadora en diseño desarrollado en la etapa anterior, implica la creación de programas informáticos aplicando las estructuras de programación de algún paradigma y utilizando un lenguaje de programación, el producto de esta etapa es un listado fuente o bien conocido como código fuente. 5. Pruebas Al finalizar la codificación de cada modulo se realiza la prueba de unidad, este prueba va a comprobar que el modulo funcione correctamente. Las pruebas de unidad son de caja blanca y de caja negra y estas abarcan fundamentalmente: La interfaz del modulo, analizando que la información entra y sale correctamente del modulo. Las estructuras de datos locales, ya que son una fuente potencial de errores Los valores límites establecidos para el modulo El tratamiento de errores, comprobando que se ejecutan y son los adecuados. Se puede describir brevemente que a esta etapa se incorporan pruebas de unidad, de integración y de validación. Las pruebas de unidad validan la eficacia funcional de cada modulo del sistema 15

24 Las de integración validan la eficacia funcional de los subsistemas y de todo el sistema. Las pruebas de validación, validan que todos los requerimientos han sido incorporados. Para ello es necesario desarrollar en las etapas de análisis y diseño un plan y procedimiento de pruebas para cada una de estas validaciones. Por último mencionamos que las pruebas pueden realizarse de dos formas: Pruebas de caja negra. Las pruebas de caja negra se centran en lo que se espera de un módulo, es decir, intentan encontrar casos en que el módulo no se atiene a su especificación. Las pruebas de caja negra se apoyan en la especificación de requisitos del módulo. De hecho, se habla de cobertura de especificación para dar una medida del número de requisitos que se han probado. Pruebas de caja blanca. En estas pruebas estamos siempre observando el código, que las pruebas se dedican a ejecutar con ánimo de probarlo todo. Esta noción de prueba total se formaliza en lo que se llama cobertura y no es sino una medida porcentual de cuánto código hemos cubierto? 6. Mantenimiento El hecho de que exista la etapa de mantenimiento es por el hecho que del software siempre va a estar sujeto a cambios, estos se pueden producir por: Errores encontrados en el cual se aplicaría un mantenimiento correctivo Cambios en el entorno externo en el cual el sistema debe adaptarse (mantenimiento adaptativo) Que el cliente requiere ampliaciones o desea incrementar su rendimiento (mantenimiento perfectivo). 16

25 En esta etapa, por un lado, se desea comprobar que toda la documentación está disponible y es adecuada para las tareas de mantenimiento, y por otro lado, establecer un esquema de acciones para el caso de error o modificación del software y comunicar al usuario estas acciones. (Alonso; Martínez; Segovia, 2005) Modelo evolutivo del proceso del proceso de software Se reconoce que el software al igual que los sistemas complejos evoluciona con el tiempo. Los requisitos de gestión y de productos a menudo cambian conforme a que el desarrollo proceda haciendo que el camino que lleva a producto final no sea real; las estrictas fechas ya establecidas hacen que sea imposible finalizar un producto completo, por lo que se debe introducir una versión limitada para cumplir la presión competitiva y de gestión; se comprende perfectamente el conjunto de requisitos de productos centrales o del sistema, pero todavía se tienen que definir los detalles de extensiones del producto o sistema. En estas y en otras situaciones similares, los ingenieros del software necesitan un modelo de proceso que se ha diseñado explícitamente para acomodarse a un producto que evolucione con el tiempo. El modelo lineal secuencial (en cascada) se rediseña para el desarrollo en línea recta. Este esencia, este enfoque en cascada asume que se va a entregar un sistema completo una vez que la secuencia lineal se haya finalizado. El modelo de construcción de prototipos se diseña para ayudar al cliente a comprender los requisitos. En general, no se diseña para entregar un sistema de producción. En ninguno de los paradigmas de ingeniería del software se tiene en cuenta la naturaleza evolutiva del software. 17

26 Los modelos evolutivos son iterativos. Se caracterizan por la forma en que permiten a los ingenieros del software desarrollar versiones cada vez más completas del software (Pressman, 2002) Modelo incremental El modelo incremental combina elementos del modelo lineal secuencial con la filosofía iterativa de construcción de prototipos. El modelo incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. El modelo incremental entrega el software en partes pequeñas, pero utilizables, llamadas incrementos. En general, cada incremento se construye sobre aquel que ha sido entregado. Cuando se utiliza modelo incremental, el primer incremento a menudo es un producto esencial. Es decir, se afrontan requisitos básicos, pero muchas funciones suplementarias quedan sin extraer. El cliente utiliza el producto central. Como un resultado de utilización y/o de evaluación, se desarrollan un plan para el incremento siguiente. El plan afronta la modificación del producto central al fin de cumplir mejor las necesidades del cliente y la entrega de funciones y características adicionales. Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo. El modelo de proceso incremental, como la construcción de prototipos y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construcción de prototipos, el modelo incremental se centra en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporciona al usuario la 18

27 funcionalidad que precisa y también una plataforma para la evaluación. El desarrollo incremental es particularmente útil cuando la dotación de personal no está disponible para una implementación completa en la fecha límite que se haya establecido para el proyecto. Los primeros incrementos se pueden implementar con menos personas. En la figura 1.1 se muestra un claro ejemplo de cómo funciona el modelo incremental (Pressman, 2002). Ing. De sistemas/información Análisis Diseño Incremento 1 Código Prueba Entrega de 1er incremento Incremento 2 Análisis Diseño Código Prueba Entrega de 2do incremento Incremento 3 Análisis Diseño Código Prueba Entrega de 3er incremento Incremento 4 Análisis Diseño Código Prueba Entrega de 4to incremento Tiempo en calendario Figura 1.1 Modelo incremental. (Pressman, 2002) Modelo en Espiral Del modelo en espiral desarrollado por Boehm, surgió una de las ideas fundamentales que las metodologías posteriores adoptarían: el temprano análisis de riesgos. Es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software. En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones, la versión incremental podría ser un modelo en papel o un 19

28 prototipo. Durante las últimas iteraciones, se producen versiones cada vez más complejas del sistema diseñado. Figura 1.2 Modelo en espiral de siete fases. (Pressman, 2002) El modelo en espiral se divide en un numero de actividades llamadas regiones de tareas, generalmente existen entre tres y seis regiones de tareas. El modelo en espiral de la figura 1.2 contiene seis regiones de tareas: Comunicación con el cliente - las tareas requeridas para establecer comunicación entre el desarrollador y el cliente. Planificación las tareas requeridas definir recursos, el tiempo y otra información relacionadas con el proyecto. Análisis de riesgos - las tareas requeridas para evaluar riesgos técnicos y de gestión. Ingeniería - las tareas requeridas para construir una o más representaciones de la aplicación. 20

29 Construcción y acción las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario (por ejemplo: documentación y práctica). Evaluación del cliente las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creada durante la etapa de ingeniería e implementada durante la etapa de instalación. Cada unas de las regiones están compuestas por un conjunto de tareas del trabajo, llamado conjunto de tareas, que se adaptan a las características del proyecto que va a emprenderse. Para proyectos pequeños, el número de tareas de trabajo y su formalidad es bajo. Para proyectos mayores y más críticos cada región de tareas contiene tareas de trabajo que se definen para lograr un nivel más alto de formalidad. En todos los casos, se aplican las actividades de protección (por ejemplo: gestión de configuración de software y garantía de calidad del software). Cuando empieza este proceso evolutivo, el equipo de ingeniería del software gira alrededor de la espiral en la dirección de la agujas del reloj, comenzando por el centro. El primer circuito de la espiral, puede producir el desarrollo de una especificación de productos; los pasos siguientes en la espiral se podrían utilizar para desarrollar un prototipo y progresivamente versiones más sofisticadas del software. Cada paso por la región de planificación produce ajustes en el plan del proyecto. El costo y la planificación se ajustan con la realimentación ante la evaluación del cliente. Además, el gestor del proyecto ajusta el número planificado de iteraciones requeridas para a completar el software. A diferencia del proceso clásico que determina cuando se entrega el software, el modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora. En la figura 1.2 cada uno de los cubos situados a lo 21

30 largo del eje puede usarse para representar el punto de arranque para diferentes tipos de proyectos. El modelo en espiral es un enfoque realista en el desarrollo de sistemas y de software de gran escala. Como el software evoluciona a medida que progresa el proceso el desarrollador y el cliente reaccionan mejor ante riesgos en cada unos de los niveles evolutivos. Este modelo utiliza la construcción de prototipos como mecanismos de reducción de riesgos, pero, permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto. Mantiene el enfoque sistemático de los pasos sugeridos por el ciclo de vida clásico, pero la incorpora al marco de trabajo iterativo que refleja de forma más realista el mundo real. También este modelo demanda una consideración directa de los riesgos en todas las etapas del proyecto, y, si se aplican correctamente, deben reducir los riesgos antes de que se conviertan en problemáticos (Pressman, 2002) Modelo de construcción de prototipo Un cliente a menudo define un conjunto de objetivos generales para el software, pero no identifican los requisitos detallados de entrada, proceso y salida. En otros casos, el responsable del desarrollo del desarrollo del software puede no estar seguro de la eficacia de un algoritmo, de la capacidad de adaptación de un sistema operativo, o de la forma en que debería tomarse la interacción hombremáquina. En esta y en otras muchas situaciones, un modelo de construcción de prototipos puede ofrecer el mejor enfoque. El modelo de construcción de prototipos comienza con la recolección de requisitos (figura 1.3). El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria más definición. Entonces aparece un diseño rápido. El diseño rápido se centra en una representación de esos aspectos del 22

31 software que serán vivibles para el usuario/cliente. El diseño rápido lleva a la construcción de un prototipo. El prototipo lo evalúa el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar. La iteración ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda lo mejor que se necesita hacer. Cuando el cliente tiene una necesidad legítima, pero está desorientado sobre los detalles, el primer paso es desarrollar un prototipo. Lo ideal sería que el prototipo sirviera como un mecanismo para identificar los requisitos del software. Si se construye un prototipo de trabajo, el desarrollador intenta hacer uso de los fragmentos del programa ya existente o aplica herramientas (generadores de informes y gestores de ventanas) que permiten generar rápidamente programas de trabajo. Figura 1.3 Modelo de prototipo de tres fases. (Pressman, 2002) Según (Pressman, 2002) se hace la siguiente pregunta: Pero Qué hacemos con el prototipo una vez que ha servido para el propósito descrito anteriormente? Se proporciona una respuesta: 23

32 En la mayoría de los proyectos, el primer sistema construido apenas se puede utilizar. Puede ser demasiado lento, demasiado grande o torpe en su uso, o las tres a la vez, no hay otra alternativa que comenzar de nuevo, aunque nos duela pero es más inteligente, y construir una versión rediseñada en la que se resuelvan estos problemas cuando se utiliza un concepto nuevo de sistema o una tecnología nueva, se tiene que construir un sistema que no sirva y se tenga que tirar, porque incluso la mejor planificación no es omnisciente como para que este perfecta a la primera vez. Por lo tanto la pregunta de la gestión no es si construir un sistema piloto y tirarlo. Tendremos que hacerlo. La única pregunta es si planificar de antemano construir un desechable, o prometer entregárselo a los cliente. El prototipo puede servir como primer sistema, el que en lo comentado en el párrafo anterior se recomienda tirar. Es verdad que a los clientes y a los que desarrollan les gusta el paradigma de construcción de prototipo aunque a los usuarios les gusta más el sistema real y a los que desarrollan les gusta el paradigma de construcción de prototipos, les gusta construir algo inmediatamente. Sin embargo, la construcción de prototipo también puede ser problemática por las siguientes razones: El cliente ve lo que parece ser una versión de trabajo del software, sin tener conocimientos que con la prisa de hacer que funcione no se ha tenido en cuenta la calidad del software global o la facilidad de mantenimiento a largo plazo. Cuando se informa de que el producto se debe construir otra vez para que se puedan mantener los niveles altos de calidad, el cliente no lo entiende y pide que se apliquen unos justes para que se puede hacer del prototipo un producto final. De forma demasiado frecuente la gestión de desarrollo del software es muy lenta. 24

33 El desarrollador, a menudo, hace compromisos de implementación para hace que el prototipo funcione rápidamente. Se puede utilizar un sistema operativo o lenguaje de programación inadecuado simplemente porque está disponible y porque es conocido; un algoritmo eficiente se puede implementar simplemente para demostrar la capacidad. Después de algún tiempo el desarrollador debe familiarizarse con estas selecciones, y olvidarse de las razones por las que son inadecuadas. La selección menos ideal ahora es una parte integral del sistema. Aunque puedan surgir problemas, la construcción de prototipos puede ser un paradigma efectivo para la ingeniería del software. La clave es definir las reglas del juego al comienzo; es decir, el cliente y el desarrollador se deben poner de acuerdo en que el prototipo se construya para servir como un mecanismo de definición de requisitos (Pressman, 2002) El modelo DRA (desarrollo rápido de aplicaciones) El desarrollo rápido de aplicaciones (DRA) es un modelo de proceso de desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. El modelo DRA es una adaptación a alta velocidad del modelo lineal secuencial en el que se logra el desarrollo rápido utilizando una construcción basada en componentes. Si se comprenden bien los requisitos y si limita el ámbito del proyecto, el proceso DRA permitirá al equipo (como se muestra en la figura 1.4) de desarrollo crear un sistema completamente funcional dentro de periodos cortos de tiempo. Cuando se utiliza principalmente para aplicaciones de sistemas de información el DRA comprende las siguientes fases: Modelado de Gestión. El flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: Qué información produce el proceso de gestión? Qué información se 25

34 genera? Quién la genera? A dónde va la información? Quién la procesa? Modelado de datos. El flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características de cada uno de los objetos y las relaciones entre estos objetos. Modelado del proceso. Los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Generación de aplicaciones. El DRA en lugar de crear software con lenguaje de programación de tercera generación, proceso DRA trabaja para volver a utilizar componentes de programas ya existentes o a crear componentes reutilizables. En todos los casos se utilizan herramientas para facilitar la construcción del software. Pruebas y entrega. Como el proceso DRA enfatiza la utilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfaces a fondo (Pressman, 2002). 26

35 Equipo 1 Equipo 2 Equipo 3 Modelado de Gestión Modelado de datos Modelado de procesos días Modelado de gestion Generación de aplicaciones Modelado de datos Pruebas y entrega Modelado de procesos Modelado de gestión Generación de aplicaciones Modelado de datos Pruebas y entrega Modelado de procesos Generación de aplicaciones Pruebas y entrega Figura 1.4. Modelo DRA (desarrollo rápido de aplicaciones. (Pressman, 2002). 1.2 Surgimiento de las metodologías ágiles para el desarrollo de sistemas El desarrollo de software no es una tarea fácil. Prueba de ello es que existen numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo. Por una parte tenemos aquellas propuestas más tradicionales que se centran especialmente en el control del proceso, estableciendo rigurosamente las actividades involucradas, los artefactos que se deben producir, y las herramientas y notaciones que se usarán. Estas propuestas han demostrado ser efectivas y necesarias en un gran número de proyectos, pero también han presentado problemas en otros muchos. Una posible mejora es incluir en los procesos de desarrollo más actividades, más artefactos y más restricciones, basándose en los puntos débiles detectados. Sin embargo, el resultado final sería un proceso de desarrollo más complejo que puede incluso limitar la propia 27

36 habilidad del equipo para llevar a cabo el proyecto. Otra aproximación es centrarse en otras dimensiones, como por ejemplo el factor humano o el producto software. Esta es la filosofía de las metodologías ágiles, las cuales dan mayor valor al individuo, a la colaboración con el cliente y al des arrollo incremental del software con iteraciones muy cortas. Este enfoque está mostrando su efectividad en proyectos con requisitos muy cambiantes y cuando se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Las metodologías ágiles están revolucionando la manera de producir software, y a la vez generando un amplio debate entre sus seguidores y quienes por escepticismo o convencimiento no las ven como alternativa para las metodologías tradicionales. En este trabajo se presenta resumidamente el contexto en el que surgen las metodologías ágiles, sus valores, principios y comparación con las metodologías tradicionales. Además se describen brevemente las principales propuestas, especialmente programación. El tema es de vanguardia. La curiosidad que siente la mayor parte de ingenieros de software, profesores, e incluso alumnos, sobre los métodos ágiles hace prever una fuerte proyección industrial de las metodologías ágiles. Por un lado, para muchos equipos de desarrollo el uso de metodologías tradicionales les resulta muy lejano a su forma de trabajo actual considerando las dificultades de su introducción e inversión asociada en formación y herramientas. Por otro, las características de los proyectos para los cuales las metodologías ágiles han sido especialmente pensadas se ajustan a un amplio rango de proyectos industriales de desarrollo de software; aquellos en los cuales los equipos de desarrollo son pequeños, con plazos reducidos, requisitos volátiles y nuevas tecnologías. Esto último abriría interesantes canales de cooperación entre la industria y la universidad (Canós; Letelier; Penadés, 2011). 28

37 1.3 Metodologías ágiles En las dos últimas décadas las notaciones de modelado y posteriormente las herramientas pretendieron ser las pionera para el éxito en el desarrollo de software, sin embargo, las expectativas no fueron satisfechas. Esto se debe en gran parte a que otro importante elemento, la metodología de desarrollo, había sido postergado. De nada sirven buenas notaciones y herramientas si no se proveen directivas para su aplicación. Así, esta década ha comenzado con un creciente interés en metodologías de desarrollo. Hasta hace poco el proceso de desarrollo llevaba asociada un marcado énfasis en el control del proceso mediante una rigurosa definición de roles, actividades y artefactos, incluyendo modelado y documentación detallada. Este esquema tradicional para abordar el desarrollo de software ha demostrado ser efectivo y necesario en proyectos de gran tamaño (respecto a tiempo y recursos), donde por lo general se exige un alto grado de ceremonia en el proceso. Sin embargo, este enfoque no resulta ser el más adecuado para muchos de los proyectos actuales donde entorno del sistema es muy cambiante, y en donde se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Ante las dificultades para utilizar metodologías tradicionales con estas restricciones de tiempo y flexibilidad, muchos equipos de desarrollo se resignan a prescindir de hacer el sistema con calidad como lo afirma la ingeniería del software, asumiendo el riesgo que ello conlleva. En este escenario, las metodologías ágiles emergen como una posible respuesta para llenar ese vacío metodológico. Por estar especialmente orientadas para proyectos pequeños, las metodologías ágiles constituyen una solución a medida para ese entorno, aportando una elevada simplificación que a pesar de ello no renuncia a las prácticas esenciales para asegurar la calidad del producto. Las metodologías ágiles son sin duda uno de los temas recientes en ingeniería de software que están acaparando gran interés. 29

38 En febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace el término ágil aplicado al desarrollo de software. En esta reunión participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologías de software. Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales, caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de las actividades desarrolladas. Tras esta reunión se creó The Agile Alliance3, una organización, sin ánimo de lucro, dedicada a promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las organizaciones para que adopten dichos conceptos. El punto de partida es fue el Manifiesto Ágil, un documento que resume la filosofía ágil (canos; Letelier; Penades, 2011). Las metodología tradicionales han tenido evoluciones y diferentes formas de aplicación aun así llamadas agiles, en la siguiente sección mostraremos las metodologías agiles más conocidas y mencionadas en la actualidad por diversos grupos de desarrollo XP (xtreme programing) La programación extrema es una metodología de desarrollo ágil basada en una serie de valores y de prácticas que persigue el objetivo de aumentar la productividad a la hora de desarrollar programas. Este modelo de programación se basa en una serie de metodologías de desarrollo de software en la que se da prioridad a los trabajos que dan un resultado directo y que reducen la burocracia que hay alrededor de la programación. 30

39 Una de las características principales de este método de programación, es que sus ingredientes son conocidos desde el principio de la informática. Los autores de XP han seleccionado aquellos que han considerado mejores y han profundizado en sus relaciones y en cómo se refuerzan los unos con los otros. El resultado de esta selección ha sido esta metodología única y compacta. Por esto, aunque no está basada en principios nuevos, sí que el resultado es una nueva manera de ver el desarrollo de software. El objetivo que se perseguía en el momento de crear esta metodología era la búsqueda de un método que hiciera que los desarrollos fueran más sencillos. Aplicando el sentido común. Con el poco tiempo que hace que existe esta metodología, ya se ha generado una gran controversia en la comunidad de ingeniería del software. Hay opiniones de todos los gustos de quienes lo prueban. Las opiniones negativas mayoritarias alegan lo siguiente: Los programadores tienen un acusado sentimiento de posesión del código y esta postura no encaja con la filosofía de X.P. También se ve un fuerte sentimiento para respectar las 40 horas semanales, y X.P. no lo garantiza. Los jefes de proyecto también expresan su descontento con este método tan poco tradicional. En cambio una visión más optimista dice que: X.P. sólo funcionará con gente buena, es decir, profesionales que son capaces de hacer un buen diseño, sencillo y a la vez fácilmente ampliable. Por otro lado se ha de recalcar que XP no ha inventado ningún método nuevo, sencillamente ha recogido métodos ya existentes y los ha agrupado, y ha comprobado que funcionen. Y para terminar, mencionar que el creador de XP asegura que se garantiza un rato si más no divertido. 31

40 La Programación Extrema, como proceso de creación de software diferente al convencional, nace de la mano de Kent Beck (gurú de la XP y autor de los libros más influyentes sobre el tema). Chrysler Corporation hacía tiempo que estaba desarrollando una aplicación de nóminas, pero sin demasiado éxito por parte de la gente que tenía en el proyecto. El verano de 1996, Beck entró en nómina en la compañía y se le pidió de hacer esta aplicación como trabajo. Es en esta aplicación cuando nace la Programación Extrema como tal. Beck reconoció que el proceso (o metodología) de creación de software o la carencia de este era la causa de todos los problemas y llegó a la conclusión que para proporcionar un proceso que fuera flexible era necesario realizar ciertos cambios en la estructura o manera de hacer de los programadores, los cuales se tenían que acomodar al cambio a realizar. El tenía varias ideas de metodologías para la realización de programas que eran cruciales para el buen desarrollo de cualquier sistema. Las ideas primordiales de su sistema las comunicó en la revista C++ Magazine en una entrevista que ésta le hizo el año En ésta decía que él estaba convencido que la mejor metodología era un proceso que enfatizase la comunicación dentro del equipo, que la implementación fuera sencilla, que el usuario tenía que estar muy informado y implicado y que la toma de decisiones tenía que ser muy rápida y efectiva. Los autores (o mejor dicho, los propulsores como el propio Kent Beck, Ward Cunningham o Ron Jeffries entre otros) de la Programación Extrema, fueron a la web Portland Pattern Repository y empezaron a hablar de ella y promocionarla, de lo que era y cómo realizarla. Estos propulsores de la XP hablaban de ella en cada ocasión que tenían y en cada página que, poco o mucho hablara de temas de programación. Este hecho, llegó a molestar a buena parte de la comunidad que intentaba discutir sobre temas de programación. Fue tanta esta molestia que nació el fenómeno XP Free Zone (zona libre de XP) en determinadas webs como petición de no hablar de Programación Extrema en ella. La discusión sobre temas de diseño de modelos de programación sobre los cambios recientes se hizo tema difícil porque la mayoría de la actividad fue 32

41 relacionada con la Programación Extrema. Eventualmente, y debido a esto, la mayoría de la gente que solía discutir sobre los temas de diseño de modelos de programación fue apartándose de este ambiente para discutir sus ideas en otros ambientes más reservados. (kniberg, 2007) La Programación Extrema se basa en 12 principios básicos agrupados en cuatro categorías: Retroalimentación a escala fina. 1. El principio de pruebas: se tiene que establecer un período de pruebas de aceptación del programa (llamado también período de caja negra) donde se definirán las entradas al sistema y los resultados esperados de estas entradas. Es muy recomendable automatizar estas pruebas para poder hacer varias simulaciones del sistema en funcionamiento. Para hacer estas simulaciones automatizadas, se pueden utilizar Ambientes de Prueba (Unit testing frameworks). 2. Proceso de planificación: en esta fase, el usuario tendrá que escribir sus necesidades, definiendo las actividades que realizará el sistema. Se creará un documento llamado Historias del usuario (User Stories). Entre 20 y 80 historias (todo dependiendo de la complejidad del problema) se consideran suficientes para formar el llamado Plan de Liberación, el cual define de forma específica los tiempos de entrega de la aplicación para recibir retroalimentación por parte del usuario. Por regla general, cada una de les Historias del usuario suelen necesitar de una a tres semanas de desarrollo. Son muy importantes y tienen que ser una constante las reuniones periódicas durante esta fase de planificación. Estas pueden ser a diario, con todo el equipo de desarrollo para identificar problemas, proponer soluciones y señalar aquellos puntos a los que se les ha de dar más importancia por su dificultad o por su punto crítico. 33

42 3. El cliente en el sitio: se le dará poder para determinar los requerimientos, definir la funcionalidad, señalar las prioridades y responder las preguntas de los programadores. Esta fuerte interacción cara a cara con el programador disminuye el tiempo de comunicación y la cantidad de documentación, junto con los altos costes de su creación y mantenimiento. Este representante del cliente estará con el equipo de trabajo durante toda la realización del proyecto. 4. Programación en parejas: uno de los principios más radicales y en el que la mayoría de gerentes de desarrollo pone sus dudas. Requiere que todos los programadores XP escriban su código en parejas, compartiendo una sola máquina. De acuerdo con los experimentos, este principio puede producir aplicaciones más buenas, de manera consistente, a iguales o menores costes. Aunque el pair-programming puede no ser para todo el mundo, la evidencia anecdótica en la lista de correo de XP demuestra un gran éxito. Proceso continuo en lugar de por lotes 1. Integración continua: permite al equipo hacer un rápido progreso implementando las nuevas características del software. En lugar de crear builds (o versiones) estables de acuerdo a un cronograma establecido, los equipos de programadores XP pueden reunir su código y reconstruir el sistema varias veces al día. Esto reduce los problemas de integración comunes en proyectos largos y estilo cascada. 2. Refactorización: permite a los equipos de programadores XP mejorar el diseño del sistema a través de todo el proceso de desarrollo. Los programadores evalúan continuamente el diseño y recodifican lo necesario. La finalidad es mantener un sistema enfocado a proveer el valor de negocio mediante la minimización del código duplicado y/o ineficiente. 34

43 3. Entregas pequeñas: colocan un sistema sencillo en producción rápidamente que se actualiza de forma rápida y constante permitiendo que el verdadero valor de negocio del producto sea evaluado en un ambiente real. Estas entregas no pueden pasar las 2 o 3 semanas como máximo. Entendimiento compartido. 1. Diseño simple: se basa en la filosofía de que el mayor valor de negocio es entregado por el programa más sencillo que cumpla los requerimientos. Simple Design se enfoca en proporcionar un sistema que cubra las necesidades inmediatas del cliente, ni más ni menos. Este proceso permite eliminar redundancias y rejuvenecer los diseños obsoletos de forma sencilla. 2. Metáfora: desarrollada por los programadores al inicio del proyecto, define una historia de cómo funciona el sistema completo. XP estimula historias, que son breves descripciones de un trabajo de un sistema en lugar de los tradicionales diagramas y modelos UML (Unified Modeling Language). La metáfora expresa la visión evolutiva del proyecto que define el alcance y propósito del sistema. Las tarjetas CRC (Clase, Responsabilidad y Colaboración) también ayudarán al equipo a definir actividades durante el diseño del sistema. Cada tarjeta representa una clase en la programación orientada a objetos y define sus responsabilidades (lo que ha de hacer) y las colaboraciones con las otras clases (cómo se comunica con ellas). 3. Propiedad colectiva del código: un código con propiedad compartida. Nadie es el propietario de nada, todos son el propietario de todo. Este método difiere en mucho a los métodos tradicionales en los que un simple programador posee un conjunto de código. Los defensores de XP argumentan que mientras haya más gente trabajando en una pieza, menos errores aparecerán. 35

44 4. Estándar de codificación: define la propiedad del código compartido así como las reglas para escribir y documentar el código y la comunicación entre diferentes piezas de código desarrolladas por diferentes equipos. Los programadores las han de seguir de tal manera que el código en el sistema se vea como si hubiera estado escrito por una sola persona. Bienestar del programador. 1. La semana de 40 horas: la programación extrema sostiene que los programadores cansados escriben código de menor cualidad. Minimizar las horas extras y mantener los programadores frescos, generará código de mayor calidad. Como dice Beck, está bien trabajar tiempos extra cuando es necesario, pero no se ha de hacer durante dos semanas seguidas. La programación extrema parte del caso habitual de una compañía que desarrolla software, normalmente a medida, en la que hay diferentes roles: un equipo de gestión (o diseño), uno de desarrollo y los clientes finales. La relación entre el equipo de diseño, los que desarrollan el software y clientes es totalmente diferente al que se ha producido en las metodologías tradicionales, que se basaba en una fase de captura de los requisitos previa al desarrollo, y de una fase de validación posterior al mismo. (Ferrer, 2002) La primera fase de la programación extrema es la Interacción con el cliente: aunque mejor se le daría el nombre de pasos para hacer programación extrema. En este tipo de programación el cliente pasa a ser parte implicada en el equipo de desarrollo. Su importancia es máxima en el momento de tratar con los usuarios y en efectuar las reuniones de planificación. Tiene un papel importante de interacción con el equipo de programadores, sobre todo después de cada cambio, y de cada posible problema localizado, mostrando las prioridades, expresando sus 36

45 sensaciones. En este tipo de programación existirán pruebas de aceptación de la programación que ayudarán a que su labor sea lo más provechosa posible. Al fin y al cabo, el cliente se encuentra mucho más cerca del proceso de desarrollo. Se elimina la fase inicial de recopilación de requerimientos, y se permite que éstos se vayan cogiendo a lo largo del proyecto, de una manera ordenada. De esta forma se posibilita que el cliente pueda ir cambiando de opinión sobre la marcha, pero a cambio han de estar siempre disponibles para solucionar las dudas del equipo de desarrollo. En XP aparece un nuevo concepto llamado Historia de usuario. Se trata de una lista de características que el cliente necesita que existan en el producto final. Estas constan de dos fases. 1. En la primera fase, el cliente describe con sus propias palabras las características y, es el responsable del equipo, el encargado de informarlo de las dificultades técnicas de cada una de ellas y de su coste. A consecuencia de este diálogo, el cliente deja por escrito un conjunto de historias y las ordena en función de la prioridad que tienen pera él. De esta manera ya es posible definir unas fechas aproximadas para ellos. 2. En la segunda fase, el cliente cogerá las primeras historias a implementar y las dividirá en trabajos a realizar. El cliente también participa, pero hay más peso por parte del equipo de desarrolladores, esto dará como resultado una planificación más exacta. Este método se repetirá para cada historia. A diferencia de otras técnicas, en el caso de XP, se exige que sea el cliente el encargado de escribir los documentos con las especificaciones de lo que realmente quiere, como un documento de requisitos de usuario. En esta fase, el equipo técnico será el 'encargado de catalogar las historias del cliente y asignarles una duración. La norma es que cada historia de usuario tiene que poder ser 37

46 realizable en un espacio entre una y tres semanas de programación. Las que requieran menos tiempo serán agrupadas, y las que necesiten más serán modificadas o divididas. Finalmente decir que las historias de los usuarios serán escritas en tarjetas, lo que facilitará que el cliente pueda especificar la importancia relativa entre las diferentes historias de usuario, así como el trabajo de los programadores que podrán catalogarlas correctamente. Este formato también es muy útil en el momento de las pruebas de aceptación. El segundo paso es la planificación del proyecto: En este punto se tendrá que elaborar la planificación por etapas, donde se aplicarán diferentes iteraciones. Para hacerlo será necesaria la existencia de reglas que se han de seguir por las partes implicadas en el proyecto para que todas las partes tengan voz y se sientan realmente partícipes de la decisión tomada. Las entregas se tienen que hacer cuanto antes mejor, y con cada iteración, el cliente ha de recibir una nueva versión. Cuanto más tiempo se tarde en introducir una parte esencial, menos tiempo se tendrá para trabajar con ella después. Se aconseja muchas entregas y muy frecuentes. De esta manera un error en la parte inicial del sistema tiene más posibilidades de detectarse rápidamente. Una de las máximas a aplicar es, los cambios, no han de suponer más horas de programación para el programador, ya que el que no se termina en un día, se deja para el día siguiente. Se ha de tener asumido que en el proceso de planificación habrán errores, es más, serán comunes, y por esto esta metodología ya los tiene previstos, por lo tanto se establecerán mecanismos de revisión. Cada tres o cinco iteraciones es normal revisar las historias de los usuarios, y renegociar la planificación. Cada iteración necesita también ser planificada, es lo que se llama planificación iterativa, en la que se anotarán las historias de usuarios que se 38

47 consideren esenciales y las que no han pasado las pruebas de aceptación. Estas planificaciones también se harán en tarjetas, en las que se escribirán los trabajos que durarán entre uno y tres días. Es por esto que el diseño se puede clasificar como continuo. Añade agilidad al proceso de desarrollo y evita que se mire demasiado hacia delante, desarrollando trabajos que aún no han estado programados. Este tipo de planificación en iteraciones y el diseño iterativo, hace que aparezca una práctica que no existía en la programación tradicional. Se trata de las discusiones diarias informales, para fomentar la comunicación, y para hacer que los desarrolladores tengan tiempo de hablar de los problemas a los que se enfrentan y de ver cómo van con sus trabajos. El tercer paso es el Diseño, desarrollo y pruebas: El desarrollo es la parte más importante en el proceso de la programación extrema. Todos los trabajos tienen como objetivo que se programen lo más rápidamente posible, sin interrupciones y en dirección correcta. También es muy importante el diseño, y se establecen los mecanismos, para que éste sea revisado y mejorado de manera continuada a lo largo del proyecto, según se van añadiendo funcionalidades al mismo. La clave del proceso de desarrollar XP es la comunicación. La mayoría de los problemas en los proyectos son por falta de comunicación en el equipo. En XP, aparece un nuevo concepto llamado Metáfora. Su principal objetivo es mejorar la comunicación entre todos los integrantes del equipo, al crear una visión global y común de lo que se quiere desarrollar. La metáfora tiene que ser expresada en términos conocidos por los integrantes del equipo, por ejemplo comparando el sistema que se desarrollará con alguna cosa de la vida real. Antes de empezar a codificar se tienen que hacer pruebas unitarias, es decir: Cada vez que se quiere implementar una parte de código, en XP, se tiene que escribir una 39

48 prueba sencilla, y después escribir el código para que la pase. Una vez pasada se amplía y se continúa. En XP hay una máxima que dice "Todo el código que puede fallar tiene que tener una prueba". Con estas normas se obtiene un código simple y funcional de manera bastante rápida. Por esto es importante pasar las pruebas al 100%. (Hernán, 2004) Respecto a la integración del software, en XP se ha de hacer una integración continua, es decir, cada vez se tienen que ir integrando pequeños fragmentos de código, para evitar que al finalizar el proyecto se tenga que invertir grandes esfuerzos en la integración final. En todo buen proyecto de XP, tendría que existir una versión al día integrada, de manera que los cambios siempre se realicen en esta última versión. Otra ventaja de XP es que cada programador puede trabajar en cualquier parte del programa. De esta manera se evita que haya partes propietarias de cada programador. Por esto es tan importante la integración diaria. Para terminar, otra ventaja que tiene la XP. La de fomentar la programación en parejas, es decir, hacer que los programadores no trabajen en solitario, sino que siempre estarán con otra persona. Una pareja de programadores ha de compartir el teclado, el monitor y el ratón. El principio fundamental de este hecho es realizar de manera continua y sin parar el desarrollo de código. Las parejas tienen que ir cambiando de manera periódica, para hacer que el conocimiento se difunda en el grupo. Está demostrado que de esta manera el trabajo es más eficaz y también se consigue más y mejor código (Palacio; Ruata, 2011) Scrum Scrum es una metodología ágil de desarrollo de proyectos que toma su nombre y principios de los estudios realizados sobre nuevas prácticas de producción por Hirotaka Takeuchi e Ikujijo Nonaka a mediados de los 80. Aunque surgió como 40

49 modelo para el desarrollo de productos tecnológicos, también se emplea en entornos que trabajan con requisitos inestables y que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados sistemas de software. Jeff Sutherland aplicó el modelo Scrum al desarrollo de software en 1993 en Easel Corporation (Empresa que en los macro-juegos de compras y fusiones se integraría en VMARK, luego en Informix y finalmente en Ascential Software Corporation). En 1996 lo presentó junto con Ken Schwaber como proceso formal, también para gestión del desarrollo de software en OOPSLA 96. Más tarde, en 2001 serían dos de los promulgadores del Manifiesto ágil. En el desarrollo de software scrum está considerado como modelo ágil por la Agile Alliance. (Palacio; Ruata, 2011). Scrum es una metodología de desarrollo muy simple, que requiere trabajo duro porque no se basa en el seguimiento de un plan, sino en la adaptación continua a las circunstancias de la evolución del proyecto. Scrum es una metodología ágil, y como tal: Es un modo de desarrollo de carácter adaptable más que predictivo. Orientado a las personas más que a los procesos. Emplea la estructura de desarrollo ágil: incremental basada en iteraciones y revisiones. Se comienza con la visión general del producto, especificando y dando detalle a las funcionalidades o partes que tienen mayor prioridad de desarrollo y que pueden llevarse a cabo en un periodo de tiempo breve (normalmente de 30 días). Cada uno de estos periodos de desarrollo es una iteración que finaliza con la producción de un incremento operativo del producto. Estas iteraciones son la base del desarrollo ágil, y Scrum gestiona su evolución a través de reuniones breves diarias en las que todo el equipo revisa el trabajo realizado el día anterior y el previsto para el día siguiente. 41

50 Scrum controla de forma empírica y adaptable la evolución del proyecto, empleando las siguientes prácticas de la gestión ágil: 1. Revisión de las Iteraciones: Al finalizar cada iteración (normalmente 30 días) se lleva a cabo una revisión con todas las personas implicadas en el proyecto. Este es el periodo máximo que se tarda en reconducir una desviación en el proyecto o en las circunstancias del producto 2. Desarrollo incremental: Durante el proyecto, las personas implicadas no trabajan con diseños o abstracciones. El desarrollo incremental implica que al final de cada iteración se dispone de una parte del producto operativa que se puede inspeccionar y evaluar. 3. Desarrollo evolutivo: Los modelos de gestión ágil se emplean para trabajar en entornos de incertidumbre e inestabilidad de requisitos. Intentar predecir en las fases iniciales cómo será el producto final, y sobre dicha predicción desarrollar el diseño y la arquitectura del producto no es realista, porque las circunstancias obligarán a remodelarlo muchas veces. Para qué predecir los estados finales de la arquitectura o del diseño si van a estar cambiando. En Scrum se toma a la inestabilidad como una premisa, y se adoptan técnicas de trabajo para permitir esa evolución sin degradar la calidad de la arquitectura que se irá generando durante el desarrollo. El desarrollo Scrum va generando el diseño y la arquitectura final de forma evolutiva durante todo el proyecto. No los considera como productos que deban realizarse en la primera fase del proyecto. (El desarrollo ágil no es un desarrollo en fases) 4. Auto-organización: Durante el desarrollo de un proyecto son muchos los factores impredecibles que surgen en todas las áreas y niveles. La gestión predictiva confía la responsabilidad de su resolución al gestor 42

51 de proyectos. En Scrum los equipos son auto-organizados (no autodirigidos), con margen de decisión suficiente para tomar las decisiones que consideren oportunas. 5. Colaboración: Las prácticas y el entorno de trabajo ágiles facilitan la colaboración del equipo. Ésta es necesaria, porque para que funcione la auto organización como un control eficaz cada miembro del equipo debe colaborar de forma abierta con los demás, según sus capacidades y no según su rol o su puesto. Scrum denomina sprint a cada iteración de desarrollo y recomienda realizarlas con duraciones de 30 días. El sprint es por tanto el núcleo central que proporciona la base de desarrollo iterativo e incremental (Hernán, 2004) Los elementos que conforman el desarrollo Scrum son: 1. Las reuniones Planificación de sprint: Jornada de trabajo previa al inicio de cada sprint en la que se determina cuál va a ser el trabajo y los objetivos que se deben cumplir en esa iteración. Reunión diaria: Breve revisión del equipo del trabajo realizado hasta la fecha y la previsión para el día siguiente. Revisión de sprint: Análisis y revisión del incremento generado. 2. Los elementos Pila del producto: lista de requisitos de usuario que se origina con la visión inicial del producto y va creciendo y evolucionando durante el desarrollo. Pila del sprint: Lista de los trabajos que debe realizar el equipo durante el sprint para generar el incremento previsto. 43

52 Incremento: Resultado de cada sprint 3. Los roles Scrum clasifica a todas las personas que intervienen o tienen interés en el desarrollo del proyecto en: propietario del producto, equipo, gestor de Scrum (también Scrum Manager o Scrum Master) y otros interesados. Los tres primeros grupos (propietario, equipo y gestor) son los responsables del proyecto. Propietario del producto: El responsable de obtener el mayor valor de producto para los clientes, usuarios y resto de implicados. Equipo de desarrollo: grupo o grupos de trabajo que desarrollan el producto. Scrum Manager: gestor de los equipos que es responsable del funcionamiento de la metodología Scrum y de la productividad del equipo de desarrollo. El ciclo de vida de Scrum por así llamado consta de 4 puntos y son: 1. Pre juego Planteamiento: Aquí se debe establecer la visión, definir expectativas y asegurarse la inversión. 2. Pre juego Montaje: El propósito de este apartado es identificar más requerimientos y prevalecer las tareas para la primera iteración. Las actividades son planificación, diseño exploratorio y prototipos. 3. Juego Desarrollo: Se implementa un sistema listo para entrega en una serie de iteraciones de treinta días llamadas: corridas (sprints). Las actividades son un encuentro de planeamiento de corridas en cada iteración, la definición del registro de acumulación de corridas y los estimados, y encuentros diarios de Scrum. 44

53 4. Post juego: Liberación.- Su propósito es el despliegue operacional. Las actividades, documentación, entrenamiento, mercadeo y venta Crystal Clear Es el propulsor detrás de la serie de metodologías cristal. Estas presentan un enfoque ágil con gran énfasis en la comunicación y con cierta tolerancia que la hace ideal en los casos en que sea inaplicable la disciplina requerida por XP. La misma se define con mucho énfasis en la comunicación y de forma muy liviana en relación a los entregables. Cristal maneja iteraciones cortas con feedback frecuente por parte de los usuarios/clientes, minimizando de una forma la necesidad de productos intermedios. Otras de las cuestiones planteadas es de disponer de un usuario real aunque sea de forma part time para realizar validaciones sobre a interface del usuario para participar en la definición de requerimientos funcionales y no funcionales del software. Una cuestión interesante que surge del análisis de la serie crystal es el pragmatismo con el que customatiza el proceso. Las personas involucradas escogen aquellos principios que les resultan efectivos y mediante la aplicación de la metodología en diversos proyectos agregan o remueven principios en base al conceso grupal del equipo de desarrollo. (Hernán, 2004) Cristal no define una metodología cerrada sino un conjunto de ellas, junto con los criterios para seleccionar y adecuar la más apropiada a cada proyecto. Los parámetros de criticidad y tamaño del sistema son los que determinan cual de las metodologías de la familia Crystal resulta más adecuada. 45

54 CRITICIDAD DEL SISTEMA 4(L) L6 L20 L40 L80 3(E) E6 E20 E40 E80 2(D) D6 D20 D40 D80 1(C) C6 C20 C40 C80 TAMAÑO DEL SISTEMA Figura 1.5 parámetros de criticidad y tamaño (Palacio; Ruata, 2011). Los criterios empleados en la figura 1.5 para la medición de estos parámetros son: 1. Criticidad (dimensión de las pérdidas que ocasionaría un mal funcionamiento del sistema). 1(c):perdida de conford o usabilidad o 2(d): pérdidas económicas moderadas 3(e): pérdidas económicas graves. Estos criterios corresponden a los niveles de integridad de un sistema definidos por el estándar IEE Dimensión: cristal determina el tamaño del sistema por el número de personas empleadas en su desarrollo. ( ) (Hernán, 2004). 46

55 Fundamentos de Crystal: Desarrollo iterativo e incremental. Duración máxima: 4 meses recomienda entre 1 y 3 meses. Especial énfasis en la importancia de de las personas sobre los procesos Especial énfasis en la comunicación directa Modelo abierto a la adaptación e introducción de prácticas de otros modelos agiles(programación extrema y scrum) DSDM (Método de Desarrollo de Sistema Dinámico) DSDM es la única de las metodologías aquí planteadas surgidas por un consorcio, formado originalmente por 17 miembros fundadores. El objetivo de este consorcio era producir una metodología de dominio público que fuera independiente de las herramientas y que pudiera ser utilizado por proyectos de tipo RAD (Rapid application Development). El consorcio tomando la best practice que se conocían en la industria y la experiencia traída por los fundadores libero la primera versión de DSDM. Dado el enfoque hacia los proyectos de características RAD esta metodología cuadrada perfectamente en el movimiento de metodologías agiles. La estructura del método fue guiada por estos ocho principios: 1. El involucramiento de los usuarios es imperativo 2. Los equipos de DSDM deben tener el poder de tomar decisiones. 3. El foco esta puesto en la entrega frecuente de productos 4. La conformidad con los propósitos del negocio es el criterio esencial para la aceptación de los entregables. 5. Todos los cambios sobre el desarrollo son reversibles. 6. Los requerimientos están especificados a un alto nivel. 7. El testing es integrado atreves del ciclo de vida 47

56 8. Un enfoque colaborativo y cooperativo entre todos los interesados es esencial. En la metodología ágil DSDM define cinco fases en la construcción del sistema estas son: Estudio de la factibilidad: el estudio de la factibilidad es una pequeña que propone DSDM para determinar si la metodología se ajusta al proyecto en cuestión. Estudio del negocio: durante esta fase se involucra al cliente para de forma temprana, para tratar de entender la operatoria que el sistema deberá automatizar. Este estudio sienta las bases para iniciar el desarrollo, definiendo las características de alto nivel que deberá contener el software. Iteración del modelo funcional: se bajara a detalle las características identificadas anteriormente Iteración del diseño y construcción: se realizara el diseño de los mismos mencionados anteriormente y se construirán los componentes del software. Implantación: se implantara el sistema en producción con previa aceptación del cliente 48

57 Figura 1.6 fases del proceso de desarrollo DSDM. (Palacio; Ruata, 2011). Descontando la primera fase que es realizada una única vez al principio del proyecto para analizar la factibilidad desde el punto de vista del negocio de desarrollo (figura 1.6), las demás frases presentan las características del modelo iterativo e incremental ya tratado, sin embargo lo que diferencia a DSDM de dicho modelo son los principios alrededor de los cuales se estructura y que hacen énfasis en los equipos de desarrollo, en la retroalimentación con el cliente, en las entregas frecuentes de productos. Para resolver la cuestión de la aplicabilidad de DSDM a un proyecto convendrá responder las siguientes preguntas: Será la funcionalidad razonablemente visible en la interface de usuario? Se pueden identificar todas las clases de usuarios finales? Es la aplicación computacionalmente compleja? 49

58 Es la aplicación potencialmente grave? Si los es, puede ser particionada en componentes funcionales más pequeños? Está el proyecto realmente acotado en el tiempo? Son los requerimientos flexibles y solos especificados a un alto nivel? Las mismas refieren a las características que se deben cumplir en los proyectos para poder utilizar el enfoque RAD de construcción. Se observan que aquellos proyectos que califiquen afirmativamente de acuerdo a dichas preguntas tendrán las siguientes características que refieren a la aplicabilidad DSDM: Son proyectos interactivos con la funcionalidad visible en la interface de usuario De baja o mediana complejidad computacional Particionables en componentes de funcionalidad más pequeños si la aplicación es de gran tamaño Acotados en el tiempo Con flexibilidad en los requerimientos Con grupo de usuarios bien definidos y comprometidos al proyecto De esta forma observamos que DSDM deja las bases sentadas para el análisis de su aplicabilidad a un espectro bien definido de proyectos de software. Sin embargo, la metodología no tiene ni una prescripción respecto a las técnicas a ser usadas en el proyecto, ni siquiera impone el desarrollo bajo un paradigma especifico, funciona tanto para el modelo de orientación a objetos como para el modelo estructurado. Algo que si sugiere el método es la generación de un conjunto mínimo de modelos necesarios para la sana progresión de la entrega del software y facilidad en el mantenimiento. Estos modelos esenciales deberán ser revisados en las sucesivas iteraciones para validar su contenido. El concepto de timebox es algo que está embebido en DSDM y en todas las metodologías ágiles, en las cuales también se conocen como iteración, ciclo, 50

59 intervalo. La consecuencia de utilizarlos es el feedback frecuente que brinda visibilidad a los stakeholders para que verifiquen el progreso y puedan tomar acciones correctivas a tiempo. También permiten controlar la calidad de los productos intermedios que se van generando, y realizar estimaciones de esfuerzo más precisas. Asimismo, cada timebox está compuesta por actividades definidas en relación a entregables en vez de tareas. Cada entregable generado durante el mismo es testeado/revisado dentro del timebox. En DSDM, un timebox consta de tres fases que son: Investigación, Refinamiento y Consolidación. Durante la Investigación se chequean que las actividades que componen el timebox se condicen con la arquitectura del sistema. Esta es una fase de carácter exploratorio, en la que se fijan los objetivos de la iteración, los entregables a ser producidos, efectuándose revisiones sobre las iteraciones anteriores a la actual. La siguiente fase, Refinamiento, consiste en la producción propiamente dicha de los artefactos planificados. DSDM destaca la necesidad de colocar componentes de distinta prioridad en un mismo timebox, de manera de poder posponer a futuras iteraciones aquellos con menor prioridad, en caso que surjan imprevistos o se materialicen riesgos. Finalmente, la fase de Consolidación consiste en completar los entregables, verificando la calidad de los mismos. En esta fase que posee el hito de finalización del timebox se demostrará que se satisficieron los requerimientos de calidad definidos durante la Investigación. DSDM incluye roles claves en relación al management del proyecto. Identifica al visionario como el encargado de asegurar que se satisfacen las necesidades del negocio; el usuario embajador que equivaldría al on-site customer de XP, que brinda el conocimiento del negocio y define los requerimientos del software; el coordinador técnico que es la persona encargada de mantener la arquitectura y verificar la consistencia de los componentes construidos respecto a esta y al cumplimiento de los estándares técnicos. 51

60 Algunas técnicas sugeridas en DSDM son las sesiones JAD para capturar los requerimientos del software y la realización de prototipos para descifrar aquellas ambigüedades que se presentan en el relevamiento y también para derribar las barreras comunicacionales entre analistas y usuarios. El enfoque propuesto consiste en la utilización de un prototipo evolutivo, el cual se va refinando hasta tenerse la aplicación deseada. El énfasis queda en manifiesto en los prototipos que se sugieren para cada etapa: negocio, usabilidad, performance y capacidad, y diseño. En resumen, encontramos en DSDM una metodología ágil creada en el Reino Unido a partir de un consorcio con participación de empresas de primera línea. El mismo contiene las características principales de las metodologías ágiles y contiene prácticas tendientes al enfoque RAD. Algo que es importante de DSDM ha sido su aceptación en la industria y su refinamiento continuo lo que indica que las metodologías ágiles no son solo dominio de pequeños grupos de desarrollo sino que están siendo adoptadas por pesos pesados en las industrias(hernán, 2004) FDD (Feature Driven Development) Peter Coad es considerado uno de los referentes más importantes dentro de la ingeniería de software. Coad ha sido uno de los principales pioneros detrás del movimiento de la orientación a objetos y empezó a trabajar con Ed Yourdon (uno de los creadores del Análisis Estructurado) a principios de los noventa, cuando este último pidió ayuda a alguien de la comunidad de objetos para desarrollar una nueva metodología, basada en el paradigma de OO. Posteriormente, Coad junto con Jeff De Luca y otros, participaría en la creación de FDD, una metodología desarrollada 52

61 Alrededor del año 1998 que presenta las características de un proceso ágil [Coad, 1998]. La misma derivó del trabajo de Coad sobre las Feature Lists (Listas de Funcionalidades). FDD se estructura alrededor de la definición de features que representan la funcionalidad que debe contener el sistema, y tienen un alcance lo suficientemente corto como para ser implementadas en un par de semanas. FDD posee también una jerarquía de features, siendo el eslabón superior el de feature set que agrupa un conjunto de features relacionadas con aspectos en común del negocio. Por último, establece el major feature set como el más alto nivel de agrupación de funcionalidad que abarca diferentes feature sets que contribuyen a proveer valor al cliente en relación a un subdominio dentro del dominio completo de la aplicación. Una de las ventajas de centrarse en las features del software es el poder formar un vocabulario común que fomente que los desarrolladores tengan un diálogo fluido con los clientes, desarrollando entre ambos un modelo común del negocio. Este tema será tratado más adelante en relación al enfoque de las metodologías ágiles en los productos entregados. La jerarquía de los features utiliza los siguientes formatos: Para features: <acción> el <resultado> <de para sobre por> un <objeto> Para feature sets: <acción><-endo> un <objeto> Para major feature sets: administración de <acción> Ejemplos: Calcular el total de la facturación de Noviembre (feature) Modificar el estado de las facturas de producción (feature) Administrar el perfil de los proveedores (feature) Haciendo una venta a un cliente (feature set) Cargando la facturación de los proveedores (feature set) Administración de Bancos (mayor feature set) 53

62 El ciclo de vida propuesto por FDD se puede observar en la Figura 1.7 y está compuesto por cinco procesos, dos de las cuales se realizan tantas veces como iteraciones se planifiquen en el desarrollo. Figura 1.7 ciclo de vida de FDD de cinco procesos. (Palacio; Ruata, 2011). La primera actividad consiste en Desarrollar un Modelo Global, que sugiere un cierto paralelismo con la construcción de la arquitectura del software. En la creación de este modelo participan tanto los expertos en el dominio como los desarrolladores. Mediante el esfuerzo de ambas partes se intenta lograr lo que el modelo en espiral proponía con sus primeras iteraciones: un conocimiento global de la aplicación a construir, el entendimiento del negocio en que esta embebida, un primer bosquejo de las features del software, y la definición de restricciones y cuestiones no funcionales. Para esto, se desarrollarán: diagramas de los paquetes, con las clases esenciales y las responsabilidades de las mismas; un documento similar al de Visión en donde se plasmen los objetivos del proyecto y como el mismo ayuda al negocio; un documento con los requerimientos no funcionales detectados; por último, el documento que podríamos llamar 54

63 arquitectura y en el que figuran las opciones de modelado surgidas durante esta actividad. La segunda actividad, Construir una Lista de Features, comienza tomando el bosquejo de features formulado durante la actividad anterior para refinar las funcionalidades incluidas. Una vez que se han identificado las mismas se las agrupa jerárquicamente para poder estructurar el trabajo de desarrollo; se realiza la priorización de las mismas basándose en la satisfacción al cliente las prioridades sugeridas para las features por FDD son: A (debe tener), B (sería útil tener), C (agregar si es posible), o D (futuro); finalmente, se pondera la importancia de cada una para su posterior implementación en caso que existan features que requieran más de dos semanas de desarrollo en esta actividad se peticionarán para lograr ubicarlos en iteraciones. La tercera actividad, Planificar por Feature, toma como input la lista priorizada de la fase anterior y establece los tiempos las futuras iteraciones. En esta actividad participan el líder de proyecto, el líder de desarrollo y el programador jefe. A medida que se realiza la planificación se delinean los hitos de finalización de las iteraciones, dejando asentado cuales son los features y features sets que estarán construidos en dichos hitos. Parte de también incluye la delegación de responsabilidades a los programadores jefe que serán dueños de los features, estos a su vez asignarán las clases a dueños de clases seleccionados del equipo. Las últimas dos actividades, Diseñar por Feature y Construir por Feature, están relacionadas con la parte productiva del proceso en que se construye la aplicación de manera incremental. Empezando por el diseño que toma los features correspondientes a la iteración, el equipo de programadores liderado por el programador jefe identifica las clases, atributos y métodos que realizan la funcionalidad requerida. Mediante la utilización de diagramas de secuencia de 55

64 UML, se verifica que el diseño pueda ser implementado. Se realizará también una inspección del diseño en los casos en que la complejidad de la funcionalidad lo requiera. Posteriormente, en la fase de Construir por Feature, se procede a desarrollar las clases definidas en la actividad anterior. Cada programador implementará los métodos de las clases por las que este es responsable, extendiendo las clases base de prueba para construir las pruebas unitarias. Una vez que la clase pasa todas las pruebas, se inspecciona el código. Esta actividad será realizada por el equipo asignado al feature en cuestión, y una vez que finaliza se promueve el código al Build correspondiente, siendo entregado a Administración de la Configuración. En relación a las actividades de management en FDD se recomienda una reunión semanal entre el Líder de proyecto y los programadores jefe; la misma debe ser breve, de no más de 30 minutos, y en la cual se reporta el status de los features que están siendo construidos por cada grupo. Por cada feature set que es implementado se tendrá la información como indica la Figura 2.8 para medir el avance del proyecto, dándole visibilidad al management superior y al cliente. Figura 1.8 Medición del avance del proyecto. (Palacio; Ruata, 2011). 56

65 En conclusión, encontramos en FDD un proceso ágil orientado a la funcionalidad del software por sobre las tareas, sobre las cuales da guías mínimas. El proceso sugiere organizar bloques de features a ser construidos en forma incremental mediante iteraciones de dos semanas; provee estrategias de planeamiento para el líder de proyecto; fomenta la colaboración mediante la creación de equipos dirigidos por un programador jefe (Hernán, 2004) ASD (Desarrollo de software Adaptable) Jim Highsmith en su libro (Highsmith, 1999) es la mente detrás de este proceso ágil. ASD consiste en un cambio de filosofía en las organizaciones pasando de la transición del modelo Comando-Control al modelo Liderazgo-Colaboración. Basado en los conceptos de los Sistemas Adaptativos Complejos relacionada con la Inteligencia Artificial, Highsmith lleva los mismos al campo de la Ingeniería de Software en particular. Dada la complejidad inherente al software concluye que la aplicación de esta teoría es esencial para el nuevo escenario que plantea la economía global. Comenzando por un cambio en el modelo de desarrollo determinista, tomado del ciclo de Deming, en que se aplica la secuencia Planificar- Ejecutar-Evaluar. Dicho esquema es llevado a la práctica con el modelo en cascada, en que se realiza una precisa planificación inicial mediante el WBS, el Gantt, y el Pert definiendo las tareas a realizar en detalle, luego se tiene las fases de construcción, y finalmente, se tiene el testing que brinda el feedback en relación al producto construido. ASD propone utilizar en cambio el ciclo de vida de la Figura 2.7, Especular, Colabora y Aprender. El proyecto comienza con una fase de especulación en que en que se lleva a cabo la planificación tentativa del proyecto en función de las entregas que se irán realizando. La utilización del verbo Especular demuestra el interés de Highsmith en demostrar la naturaleza impredecible de los sistemas complejos. En esta etapa se fija un rumbo determinado a ser seguido en el desarrollo, sabiendo a partir de ese momento que no será el lugar en que 57

66 finalizará el proyecto. En cada iteración, se aprenderán nuevas funcionalidades, se entenderán viejas cuestiones, y cambiarán los requerimientos. Gracias a centrarse en la especulación, ASD permite administrar estos proyectos de alto cambio y rápido desarrollo que se encuentran en el borde del caos. Respecto a la especulación, se recomienda realizar un component breakdown structure en vez del muy conocido y tradicional work breakdown structure (WBS) en el cual mediante una grilla u hoja de cálculo se pueda conocer la funcionalidad a ser liberada en cada ciclo. Sin embargo, no es más que una especulación ya que el carácter adaptativo del proceso permite pequeñas desviaciones en un sentido por lo que Highsmith sugiere que cada ciclo se componga de un mixto entre funcionalidades críticas, útiles, y opcionales, previendo los posibles retrasos que puedan existir mediante el movimiento de las funcionalidades de menor prioridad a futuros ciclos y grandes desviaciones en otro, las cuales son utilizadas para la exploración del dominio y de la aplicación, que puede llevar a cambiar el rumbo del proyecto, estos desvíos está representado por las flechas de divergencia en la figura 1.9 (Hernán, 2004). Figura 1.9 proceso de ASD (Palacio; Ruata, 2011). 58

67 La siguiente fase del ciclo de vida, Colaborar, es aquella en la que se construye la funcionalidad definida durante la especulación. ASD define un Componente como un grupo de funcionalidades o entregables a ser desarrollados durante un ciclo iterativo. Durante cada iteración el equipo colabora intensamente para liberar la funcionalidad planificada. También, existe la posibilidad de explorar nuevas alternativas, realizar pruebas de concepto, pudiendo eventualmente alterar el rumbo del proyecto profundamente. ASD no propone técnicas ni prescribe tareas al momento de llevar a cabo la construcción simplemente mencionando que todas las prácticas que sirvan para reforzar la colaboración serán preferidas, siguiendo de esta forma la línea de las metodologías ágiles respecto a la orientación a componentes. El énfasis se ubica en la relaciones entre las personas que deben estar lo suficientemente lubricadas para generar una propiedad imprescindible de los organismos complejos: emergencia. La emergencia es una propiedad de los sistemas adaptativos complejos que crea alguna propiedad más grande del todo (comportamiento del sistema) a partir de la interacción entre las partes (comportamiento auto-organizativo de los agentes). Gracias a esta propiedad los grupos de desarrollo logran sacar lo mejor de sí en la el borde del caos. La fase final de ASD, Aprender, consiste en la revisión de calidad que se realiza al final de cada ciclo. En la misma se analizan cuatro categorías de cosas para aprender (Highsmith, 2000): Calidad del resultado de la desde la perspectiva del cliente Calidad del resultado de la desde la perspectiva técnica El funcionamiento del equipo de desarrollo y las prácticas que este utiliza El status del proyecto 59

68 Para evaluar la calidad desde el punto de vista del cliente se sugieren utilizar grupos de enfoque en el cliente, mediante los cuales se explora un modelo de la aplicación y se anotan los requerimientos de cambio del cliente. Las revisiones al diseño, al código o a las pruebas permitirán aprender sobre la calidad de los mismos. En este caso, el énfasis estará puesto en aprender cuales han sido los errores o desvíos y poder resolverlos, y no en encontrar culpables. Asimismo, está es la etapa en que se evaluarán las exploraciones que se hayan realizado dando la Capacidad de poder modificar la arquitectura del sistema si se ha encontrado algún camino que se ajusta mejor a lo que necesita el usuario o si han cambiado los requerimientos. El tercer proceso de feedback está relacionado con la interacción entre las partes, la dinámica de grupo, y las técnicas empleadas. Para medir la performance y el grado de cohesión del mismo, se podrán realizar al final de cada ciclo pequeñas reuniones de postmortem. En las mismas se discuten los aspectos del proceso que contribuyen al desarrollo y aquellos que deben ser descartados por su influencia negativa. En relación al status del proyecto, se realizarán revisiones para determinar el estado del mismo en relación a lo planificado. En este momento, se detectarán posibles diferencias que pueden surgir de la exploración y que cambiarán el rumbo a que apuntaba el proyecto. En la Figura 1.10 se puede ver el detalle interno de cada fase como ya fue explicado, mostrándose con una flecha que trasciende las tres fases en sentido inverso, el bucle de aprendizaje. Este bucle es algo crítico para ASD ya que denota un cambio en el esquema tradicional de la vista de un sistema en que se tenía un bucle de control para detectar diferencias y corregirlas. Es decir, en las metodologías tradicionales las diferencias respecto a lo planificado eran vistas 60

69 como errores que debían ser enmendados para que cumplieran lo pautado. ASD y las metodologías ágiles plantean la necesidad de que el feedback necesario sea para aprender, nos da la posibilidad de entender más respecto al dominio y construir la aplicación que mejor satisfaga las necesidades del cliente. Highsmith lo expone claramente en la siguiente frase: En ambientes complejos, el seguir un plan al pie de la letra produce el producto que pretendíamos, pero no el producto que necesitamos (Hernán, 2004). Figura 1.10 detalle interno de las fases de ASD. (Hernán, 2004). En conclusión, tenemos en ASD un marco filosófico basado en la teoría de Sistemas Adaptativos Complejos que nos permite encarar la construcción de software en forma ágil utilizando las prácticas que nos resulten convenientes en cada caso. En este sentido resulta similar a Scrum (Hernán, 2004). 1.4 comparativa de las metodologías agiles A continuación se presenta una comparativa de las metodologías agiles ya mencionadas. Para ello es necesario determinar un conjunto de criterios que se consideran relevantes y que nos ayudan a ver parámetros fundamentales de las 61

70 metodologías, como su estado actual, fases que ocupan, que procesos describen, como miden la calidad, etc. Creado XP SCRUM CRYSTAL CLEAR DSDM FDD ASD Kent Beck Jeff Alistair Jennifer Jeff de James r/autor Sutherland Cockburn Stapleton Luca y Highsmit Kent Peter h Schwaber Coad Año Historia Sus raíces yacen en la comunidad de Smalltalk. Formulada por Kent Beck, autor del primer libro sobre la materia, extreme programming (1999) Caracte rísticas más importa ntes Pruebas unitarias, refabricación, programación en pares, comunicación entre usuarios y desarrollador es, retroalimenta ción Surge en 1986 de un artículo de la Harvard Business Review titulado The new new product Developmen t Game de Hirotaka Takeuchi, apartor de ahí Jeff Sutherland y Kent Schwaber formalizan el proceso Scrum en 1995 Define un conjunto de prácticas y roles. Método iterativo e incremental que enfatiza prácticas y valores de administraci ón de proyectos por sobre las Creado por una persona en particular Alistair Cockburn, el cual la creo en base al análisis de distintos proyectos de desarrollo de software y su propia experiencia Metodologí a ágil con énfasis en modelo de ciclos. Maneja iteraciones cortas con feedback frecuente por parte de los usuarios/cli entes Nace en 1994 con el objetivo de crear una metodolog ía RAD unificada Es un proceso iterativo e increment al, el equipo de desarrollo y el usuario trabajan juntos El desarrollo manejado por rasgos fue desarrollad o por Jeff De Luca y Peter Coad. Como las otras metodologí as adaptables, se enfoca en iteraciones cortas que entregan funcionalid ad tangible. Iterativo, orientado a los component es software más que a las tareas y tolerante a los cambios Fue desarroll ada por James Highsmit con la intención de ofrecer una alternati va a la idea de que la optimiza ción es la única solución para problem as compleji dad crecient e de Guiado por los riesgos Iterativo, tolerante a cambios 62

71 demás Etapas/ fases 1.- Planificación de proyectos 2.- Diseño 3.- Codificación 4.- Pruebas 1.- Pre-juego Planteamien to 2.- Prejuego Montaje 3.- Juego o desarrollo 4.- Posjuego Liberación 1.- Entrega frecuente 2.- Comunicac ión osmótica 3.- Mejora reflexiva 4.- Seguridad personal 5.- Foco 6.- Fácil acceso a usuarios expertos 7.- Ambiente técnico con prueba automatiza da 1.- Estudio viabilidad 2.- Estudio del negocio 3.- Modelado funcional 4.- Diseño y construcci ón 5.- Implement ación 1.- Desarrollar un Modelo Global 2.- Construir una Lista de features 3.- Planificar por feature 1.- Especul ar 2.- Colabor ar 3.- Aprende r Tabla 1.1 cuadro comparativo general Metodología Explicación Estado ASD A pesar de existir desde el año 2000, no ha mostrado la actividad académica o empresarial suficiente como para considerarse activa o ya establecida. En construcción 63

72 Crystal Clear DSDM SCRUM FDD XP Activa con respecto a Orange y Clear, en construcción en cuanto a familia de metodologías incompleta. Siendo una de las metodologías con mayor adopción en el Reino Unido y disponiendo de un gran número de experiencias se considera metodología activa. Una de las metodologías más antiguas y que más de moda esta últimamente, actualmente podemos encontrar muchos estudios y experiencias con Scrum. La podemos encontrar en un gran número de proyectos, muchas veces de la mano de XP. Desde 1999 se ha convertido en la punta del iceberg de las metodologías ágiles, es la primera en internet, en adopciones y experiencias y la primera en estudios. En construcción/activa Activa Activa Activa Activa Tabla 1.2 estado actual de las metodologías 64

73 Metodología Calidad en la metodología ASD Conformidad a los requisitos. Mantiene la vista siempre en la visión y establece un rol responsable del producto. Usabilidad mediante la eficiencia. Utilización de tarjetas de especificación de rendimiento. Satisfacción cliente. Crystal Conformidad a los requisitos y consistencia y precisión Clear (Fiabilidad), mediante pruebas de funcionalidad, automáticas y regresivas. Satisfacción del cliente, práctica dos usuarios revisan y valoran las versiones liberadas. Usabilidad, cumpliendo el parámetro de claridad y precisión documentación, ya que exigen generación guía de usuario. DSDM Conformidad a los requisitos, los documentos de especificación en DSDM deben tener criterios de calidad especificados, mediante las diferentes revisiones se comprueban. La fiabilidad del producto mediante su atributo de consistencia y precisión, con la realización de pruebas dinámicas y prototipos. SCRUM Conformidad a los requisitos. Mediante la utilización del rol de product owner y demos de producto. Satisfacción del cliente, a través de las reuniones y demos presentadas. FDD Fiabilidad Usabilidad Mantenimiento Adaptabilidad XP Satisfacción del cliente. Los clientes son una pieza clave y son requeridos en diferentes fases de XP. 65

74 Conformidad a los requisitos. En el juego de planificación, los clientes escogen objetivos. Tabla 1.3 calidad de las metodologías agiles Como conclusión de esta comparativa de las metodologías agiles recalcamos que las metodologías ágiles no contemplan todo el ciclo de vida tal y como lo hemos visto tradicionalmente, si queremos seguir todas y cada una de las fases de este necesitamos utilizar otras metodologías o complementarlas, combinándolas entre ellas. El estado actual de las metodologías ágiles es activo y ganando cada vez más adeptos. Las metodologías que hemos seleccionado no podían sino indicarnos esto, ya que fue uno de los criterios de selección de la misma, pero como poco, podemos afirmar que cinco de las seis metodologías elegidas gozan de buena salud y que son una realidad del panorama del software actual. Por regla general, las metodologías ágiles no presentan guías prescriptivas y son ajustables y adaptables una vez el proyecto se ha iniciado a situaciones cambiantes. Crystal es una excepción. Las metodologías ágiles están orientadas a la productividad y a sacar el proyecto hacia adelante. Su modo de alcanzar la calidad es mediante la interacción continua con el usuario y la mejora incremental del producto en cada iteración. XP sin proponerse como objetivo la calidad consigue de un modo excepcional cubrir la mayoría de los parámetros de la calidad, gracias a su técnica de implementar primero las pruebas. 66

75 CAPITULO II. GESTIÓN DE PROYECTOS BASADOS EN METODOLOGÍAS AGILES

76 El desarrollo de productos, la presentación de servicios, o incluso la organización de la misma son trabajos que pueden tomar la forma de proyectos o de operaciones. Ambos comparten tres características: La realizan personas Se emplean recursos limitados Se llevan a cabo siguiendo una estrategia de actuación Aunque comparten estas tres características, la diferencia clave entre operaciones y proyectos es que: Las operaciones se ejecutan de forma repetitiva para obtener resultados de similares características y los proyectos producen resultados mínimos. Se considera proyectos a la ejecución de un trabajo que además de requerir personas, recursos y ejecución controlada consta de las siguientes características: Es un desarrollo único Se desarrollo en un marco preestablecido La teoría clásica de gestión de proyectos, añade a la característica anterior otra, que desde la perspectiva tiene sentido, pero no tanto, como se verá, desde la perspectiva de gestión de proyectos ágil. La definición clásica de proyecto: conjunto único de actividades necesarias para producir un resultado definido en un rango de fechas determinados y con una asignación especifica de recursos. 68

77 Un proyecto tiene objetivos y características únicas. Algunos necesitan el trabajo de una sola personas y otros el de cientos de ellas. Unos pueden durar días y otros años. Según (Palacio; Ruata, 2011). La gestión eficaz de un proyecto especialmente de software se centra en las tres pes : personal, problema y proceso. Personal: el factor humano es tan importante que el instituto de ingeniería del software ha desarrollado un Modelo de madurez de la capacidad de la gestión del personal (MMCGP) para aumentar la preparación de organizaciones del software para llevar a cabo las cada vez más complicadas aplicaciones ayudando a atraer, aumentar, motivar desplegar y retener el talento necesario para mejorar su capacidad de desarrollo de software. Este modelo defines las siguientes áreas claves para el personal que desarrolla software: reclutamiento, selección, gestión de rendimiento, entrenamiento, retribución, desarrollo de la carrera, diseño de la organización y del trabajo y desarrollo cultural y de espíritu de equipo. Problema: antes de poder establecer un proyecto se deben identificar sus objetivos y su ámbito, se deberían considerar soluciones alternativas e identificar las dificultades técnicas y de gestión, sin esta información es imposible definir unas estimaciones razonables del costo, una valoración efectiva del riego y una planificación del proyecto asequible, que proporcione una valoración efectiva del proyecto. El proceso: un proceso de software proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo de software, un pequeño número de actividades estructurales se puede aplicar a todos los proyectos de software, sin tener en cuenta su tamaño o complejidad. Diferentes conjuntos de tareas, hitos, entregas y garantía de calidad, permiten a las actividades adaptarse a las características del proyecto de software y a los requisitos del equipo de 69

78 software. Finalmente las actividades protectoras tales como garantía de calidad de software, gestión de la configuración del software y medición cubren el modelo de proceso. Las actividades protectoras son independientes de las estructurales y tiene lugar a lo largo del proceso. 2.1 Origen de la gestión de proyectos Los proyectos han existido siempre. Cualquier trabajo para desarrollar algo único es un proyecto, pero la gestión de proyectos es una disciplina relativamente reciente que comenzó a forjarse en los años sesenta. La necesidad de su profesionalización surgió en el ámbito militar. En los 50, el desarrollo de complejos sistemas militares, requería coordinar el trabajo conjunto de equipos y disciplinas diferentes, en la construcción de sistemas únicos. Bernard Schriever, arquitecto del desarrollo de misiles balísticos Polaris, es considerado el padre de la gestión de proyectos, por la introducción del concepto de concurrencia, para integrar todos los elementos del plan del proyecto en un solo programa y presupuesto. El objetivo de la concurrencia era ejecutar las diferentes actividades de forma simultánea, y no secuencialmente, y al aplicarla en los proyectos Thor, Atlas y Minuteman se redujeron considerablemente los tiempos de ejecución. La industria del automóvil siguió los pasos de la militar, aplicando técnicas de gestión de proyectos para la coordinación del trabajo entre áreas y equipos diferentes. Comenzaron a surgir técnicas específicas, histogramas, cronogramas, los conceptos de ciclo de vida del proyecto o descomposición en tareas (WBS Work Breakdown Structure). En 1960, Meter Norden, del laboratorio de investigación de IBM, en su seminario de Ingeniería de Presupuesto y Control presentado ante American Management Association, indicó: 70

79 Es posible relacionar los nuevos proyectos con otros pasados y terminados para estimar sus costes Se producen regularidades en todos los proyectos Es absolutamente necesario descomponer los proyectos en partes de menor dimensión para realizar planificaciones. La construcción de sistemas complejos que requerían el trabajo sincronizado de varias disciplinas hizo evidente en los 60 la necesidad de nuevos métodos de organización para evitar problemas recurrentes: Desbordamiento de agendas. Desbordamiento de costes. Calidad o utilidad del resultado obtenido. Para dar respuesta a esta necesidad, desde los años 60 han surgido organizaciones que contribuyen al desarrollo del cuerpo de conocimiento de una gestión de proyectos, para ofrecer garantías de previsibilidad y calidad de los resultados. Este conocimiento se ha configurando como el currículo de una nueva profesión: La gestión de proyectos predictiva. Las organizaciones más relevantes en esta línea son: International Project Management Association (IPMA), fundada en 1965 Project Management Institute (PMI) constitution en 1969 Más tarde surgió PRINCE2, que comenzó a trabajar en IPMA y PMI surgieron como organizaciones profesionales para desarrollar metodologías y procesos para la gestión de proyectos. OGC ha tenido la evolución inversa. Comenzó siendo un método (precursor de PRINCE), alrededor del cual se ha terminado creando una organización. Se desarrolla en 1975, pero no es hasta 1989 que pasa a llamarse PRINCE y es en 1996 cuando toma la denominación PRINCE2 y la orientación a todo tipo de proyectos. 71

80 También en este sentido la evolución ha sido diferente para PRINCE2: PMI e IPMA tuvieron desde el principio como finalidad el desarrollo de un conocimiento de gestión válido para cualquier proyecto. Sin embargo, PRINCE2 comenzó siendo un modelo de referencia para proyectos específicos de Tecnologías de la Información, desarrollado por la Central Computer and Telecommunications Agency (CCTA) del Gobierno Británico; y a partir de una revisión llevada a cabo en 1996 se decidió ampliar su ámbito de validez, para cualquier tipo de proyecto (Palacio; Ruata, 2011). 2.2 Gestión predictiva o clásica La gestión de proyectos predictiva o también llamada clásica es una disciplina formal de gestión, basada en la planificación, ejecución y seguimiento a través de procesos sistemáticos y repetibles. En los 80 se definieron los objetivos que la gestión de proyectos debía cumplir para poder considerar que el trabajo concluye con éxito: Se ejecuta en el tiempo planificado. Sin desbordar el presupuesto estimado. Satisfaciendo las necesidades del cliente o Realiza las funcionalidades que necesita. o Las realiza correctamente y sin errores. En la actualidad, según el estudio periódico, que desde 1994 realiza Standish Group, escasamente uno de cada tres proyectos de desarrollo de software termina en éxito (Palacio; Ruata, 2011). 72

81 La gestión de proyectos predictiva establece como criterios de éxito: obtener el producto definido, en el tiempo previsto y con el coste estimado. Asume que el proyecto se desarrolla en un entorno estable y predecible. El objetivo de su esfuerzo es mantener el cronograma, el presupuesto y los recursos. Divide el desarrollo en fases a las que considera ciclo de vida, con una secuencia de tipo: concepto, requisitos, diseño, planificación, desarrollo, cierre. Como consecuencia de las premisas a las que debía dar solución la gestión de proyectos tradicional, sus características son: 1. Universalidad. Los proyectos, pese a su diversidad, comparten patrones comunes de ejecución y regulares. Las prácticas de gestión trabajan sobre esos patrones comunes y resultan válidas para cualquier tipo de proyecto. 2. Carácter predictivo. La gestión predictiva define con detalle cuál es el producto previsto y elabora un plan de desarrollo a partir del cual calcula costes y fechas. Durante la ejecución realiza actividades de seguimiento y vigilancia para evitar desviaciones sobre lo planificado. Hay otras premisas que cimientan el desarrollo de la gestión de proyectos. 1. Los proyectos comparten los mismos patrones de ejecución 2. El objetivo es el producto definido en costes y fechas Es cierto que muchas características que diferencian unos proyectos de otros son superficiales y resultan indiferentes para el modelo de gestión; pero hay otras que permiten adoptar estrategias de gestión muy diferentes según los casos. La gestión de proyectos predictiva, al auto considerarse válida para cualquier proyecto no considera que según las características del proyecto puedan resultar más apropiados otros criterios de gestión. 73

82 No aplica prácticas diferentes según el nivel de innovación que se desee, porque no considera que el nivel de innovación obtenido sea uno de sus objetivos. Los requisitos permanecen estables durante el desarrollo. Si no ocurre esto presupone que se debe a deficiencias en el proceso de la fase de requisitos; porque no se cuestionan posibles evoluciones rápidas o inestabilidades del entorno tecnológico o de negocio. El objetivo es la eficiencia, el cumplimiento del plan, y no el valor del producto. Desde este punto de vista, el re-trabajo siempre es caro. No se considera la relación entre el coste del re-trabajo y el valor proporcionado. La gestión de proyectos predictiva pide al equipo de trabajo el cumplimiento del plan. La gestión adaptable pide al equipo el mayor valor posible para una visión de producto. Cuándo y porque emplear uno u otro estilo gestión? para obtener los mayores beneficios que cada estilo de gestión puede ofrecer éste tiene que ser compatible no sólo con las características del proyecto, sino también con las de la organización que las va a aplicar. Las características relevantes para el estilo de gestión adoptado son: Prioridad del negocio: Cuál es la principal prioridad para los intereses de negocio del cliente? Qué tiene más importancia, cumplimiento de agendas y fechas o valor innovador para el producto? Este es el primer aspecto que se debe considerar. La gestión predictiva es una herramienta construida y especializada para garantizar el cumplimiento de los planes. 74

83 La gestión adaptable es una herramienta construida y especializada para dar el mayor valor posible al producto. Por supuesto los dos objetivos son deseables, pero hay que elegir, porque simplemente son excluyentes. No se pueden planificar diagramas de Gantt o rutas críticas sobre un concepto. Cuanto mayor valor se desea en uno u otro extremo (valor o predicción), más contraproducente resulta emplear el estilo de gestión inadecuado. Estabilidad de los requerimientos: Se puede obtener una descripción de requisitos detallada al inicio del proyecto, y ésta se mantendrá estable durante el desarrollo? O lo que es lo mismo, Se puede saber con certeza y detalle qué es lo que se quiere construir, y no es probable que cambien los criterios o las necesidades? Rigidez del producto: Cómo de fácil resulta modificar el producto? Esta es una razón importante, porque no es lo mismo modificar software, circuitos electrónicos, construcciones civiles Modificar la estructura de una base de datos para añadir algunas tablas más no es lo mismo que modificar la estructura de un edificio para rectificar el nº de plantas. Costo de prototipo: Otra cuestión relevante para el modelo de gestión ágil es la relación: costo de prototipar / valor conseguido para el producto. Este factor suele estar relacionado con la rigidez del producto. Ver, tocar, e interactuar con las partes ya desarrolladas o con simulaciones o prototipos hace surgir ideas y posibilidades que sobre el concepto inicial y el papel no llegan a concebirse. El prototipo y el feedback que proporciona son extremadamente importantes especialmente en el desarrollo de nuevos productos o de sistemas innovadores. A medida que el equipo lo va tocando y probando surgen funcionalidades y posibilidades nuevas que aportan mayor valor al concepto inicial. En este sentido, el argumento la forma más eficiente 75

84 de desarrollar un trabajo es hacerlo bien a la primera, que se emplea con frecuencia para defender la validez de la gestión predictiva en cualquier proyecto, resulta tendencioso. La afirmación per se es obviamente cierta; pero también son ciertas dos circunstancias relacionadas, la primera, si se puede hacer bien a la primera cuando es posible conocer con detalle el resultado sin necesidad de hacer pruebas antes. La segunda, las posibilidades al hacer un trabajo no son sólo bien o mal. Bien es un término amplio. Puede ser aceptable o suficientemente bien, o lo mejor posible. Estos factores, junto con la relación entre coste de prototipado y valor que aporta deben tenerse también en cuenta para elegir el modelo de gestión más adecuado para el proyecto. Criticidad del sistema: Cuál es el grado de criticidad del sistema que va a desarrollar? Considerando por análisis de criticidad: La evaluación estructurada de las características del producto (p. ej. Seguridad, complejidad, rendimiento) para determinar la severidad del impacto de un fallo del sistema, de su degradación o de su no cumplimiento con los requisitos o los objetivos del sistema. O lo que es lo mismo: Si el sistema falla, se degrada o no consigue realizar las funciones de los requisitos, qué impacto tiene en la seguridad o en el rendimiento? Un ejemplo de criterios de criticidad, ordenados de mayor a menor podría ser. Si el sistema falla las consecuencias serán: o Causará daño a las personas o Causará daño al medio ambiente o Producirá pérdidas económicas graves o Producirá pérdidas económicas o Fallará la finalidad principal del sistema o Fallarán funcionalidades auxiliares del sistema 76

85 o Se producirán fallos ergonómicos o de comodidad para los usuarios. Tamaño del sistema: Una de las principales bases del desarrollo ágil es la preferencia de la comunicación e interacción directa de los implicados en el proyecto. Los grandes proyectos implican equipos numerosos y en ocasiones físicamente distantes, circunstancias que dificultan la comunicación directa. No obstante hay desarrollos incipientes de prácticas ágiles que implantan esquemas de agrupamiento y comunicación directa en estructuras celulares de equipos de hasta 60 personas (Palacio; Ruata, 2011). 2.3 Manifiesto ágil El Manifiesto para el Desarrollo Ágil de Software es de suma importancia dentro del movimiento de las metodologías ágiles. El mismo representa una iniciativa conjunta entre los principales responsables de los procesos ágiles mencionados anteriormente para lograr unificar principios compartidos por las diversas metodologías de manera de crear un framework de trabajo que contribuya al mejoramiento del desarrollo ágil. Uno de los principales objetivos del encuentro en que se generó el Manifiesto fue el de extraer un factor común de los principios esenciales que servirían de guía para cualquier metodología que se identifique como ágil. Esto concluyó en la declaración de lo que podríamos denominar el prólogo del Manifiesto (Palacio; Ruata, 2011): Estamos descubriendo mejores maneras de desarrollar software mediante su construcción y ayudando a que otras personas lo construyan. A través de este trabajo hemos llegado a valorar: Individuos e interacciones sobre procesos y personas 77

86 Software funcionando sobre documentación comprensiva Colaboración del cliente sobre negociación de contrato Responder al cambio sobre seguir un plan Esto es, mientras que existe valor en los ítems de la derecha, valoramos más los ítems de la izquierda. Analizando los factores mencionados en detalle vemos que los mismos forman parte esencial de las metodologías descriptas. En los mismos se plasman aquellas razones que impulsaron a Beck, Highsmith, y otros, a construir metodologías ágiles. El énfasis sobre las personas esta emblematizado en la primer oración respecto a los valores de las metodologías. El énfasis en el código por sobre los documentos es una propuesta eficaz para lograr el rápido feedback requerido por la agilidad. La participación del cliente es fundamental para el éxito de los proyectos ya que ellos definen la funcionalidad a construir y guían el desarrollo de las pruebas funcionales. La importancia de responder al cambio indica que el desarrollo de software no es más que un proceso de aprendizaje en que cada cambio nos permite conocer más en detalle el dominio de la aplicación. En marzo de 2001 diecisiete críticos de los modelos de mejora del desarrollo de software basados en procesos, convocados por Kent Beck, quien había publicado un par de años antes Extreme Programming Explained, libro en el que exponía una nueva metodología denominada Extreme Programming, se reunieron en Salt Lake City para tratar sobre técnicas y procesos para desarrollar software. En la reunión se acuñó el término Métodos Ágiles para definir a los métodos que estaban surgiendo como alternativa a las metodologías formales (CMMI, SPICE) a las que consideraban excesivamente pesadas y rígidas por su carácter normativo y fuerte dependencia de planificaciones detalladas previas al desarrollo. Los integrantes de la reunión resumieron los principios sobre los que se basan los métodos alternativos en cuatro postulados, lo que ha quedado denominado como Manifiesto Ágil (Cano; Letelier; Penadés, 2011). 78

87 Hasta 2005 han sido frecuentes las posturas radicales entre los defensores de los modelos de procesos y los defensores de modelos ágiles, quizá más ocupados en descalificar al otro que en estudiar sus métodos y conocerlos para mejorar los propios. En el Manifesto Ágil, firmado por Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland y Dave Thomas, se expone que: Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar: A los individuos y su interacción, por encima de los procesos y las herramientas. El software que funciona, por encima de la documentación exhaustiva. La colaboración con el cliente, por encima de la negociación contractual. La respuesta al cambio, por encima del seguimiento de un plan. Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda(cano; Letelier; Penadés, 2011). Los Valores del manifiesto ágil son los siguientes: 1. Valorar más a los individuos y su interacción que a los procesos y las Herramientas: Este es posiblemente el principio más importante del manifiesto. Por supuesto que los procesos ayudan al trabajo. Son una guía de operación. Las herramientas mejoran la eficiencia, pero sin personas con conocimiento técnico y actitud adecuada, no producen resultados. 79

88 Las empresas suelen predicar muy alto que sus empleados son lo más importante, pero la realidad es que en los años 90 la teoría de producción basada en procesos, la re-ingeniería de procesos ha dado a éstos más relevancia de la que pueden tener en tareas que deben gran parte de su valor al conocimiento y al talento de las personas que las realizan. Los procesos deben ser una ayuda y un soporte para guiar el trabajo. Deben adaptarse a la organización, a los equipos y a las personas; y no al revés. La defensa a ultranza de los procesos lleva a postular que con ellos se pueden conseguir resultados extraordinarios con personas mediocres, y lo cierto es que este principio es peligroso cuando los trabajos necesitan creatividad e innovación. 2. Valorar más el software que funciona que la documentación exhaustiva: Poder ver anticipadamente cómo se comportan las funcionalidades que se esperan sobre prototipos o sobre partes ya elaboradas del sistema final ofrece un "feedback" muy estimulante y enriquecedor que genera ideas y posibilidades imposibles de concebir en un primer momento, y difícilmente se podrían incluir al redactar un documento de requisitos detallados antes de comenzar el proyecto. El manifiesto no afirma que no hagan falta. Los documentos son soporte de documentación, permiten la transferencia del conocimiento, registran información histórica, y en muchas cuestiones legales o normativas son obligatorios, pero se resalta que son menos importantes que los productos que funcional. Menos trascendentales para aportar valor al producto. Los documentos no pueden sustituir, ni pueden ofrecer la riqueza y generación de valor que se logra con la comunicación directa entre las personas y a través de la interacción con los prototipos. Por eso, siempre que sea posible debe preferirse, y reducir al mínimo indispensable el uso de documentación, que genera trabajo que no aporta un valor directo al producto. Si la organización y los equipos se comunican a través de documentos, además de perder la riqueza que 80

89 da la interacción con el producto, se acaba derivando a emplear a los documentos como barricadas entre departamentos o entre personas. 3. Valorar más la colaboración con el cliente que la negociación contractual: Las prácticas ágiles están especialmente indicadas para productos difíciles de definir con detalle en el principio, o que si se definieran así tendrían al final menos valor que si se van enriqueciendo con retro-información continua durante el desarrollo. También para los casos también en los que los requisitos van a ser muy inestables por la velocidad del entorno de negocio. Para el desarrollo ágil el valor del resultado no es consecuencia de haber controlado una ejecución conforme a procesos, sino de haber sido implementado directamente sobre el producto. Un contrato no aporta valor al producto. Es una formalidad que establece líneas divisorias entre responsabilidades, que fija los referentes para posibles disputas contractuales entre cliente y proveedor. En el desarrollo ágil el cliente es un miembro más del equipo, que se integra y colabora en el grupo de trabajo. Los modelos de contrato por obra no encajan. 4. Valorar más la respuesta al cambio que el seguimiento de un plan: Para un modelo de desarrollo que surge de entornos inestables, que tienen como factor inherente al cambio y la evolución rápida y continua, resulta mucho más valiosa la capacidad de respuesta que el de seguimiento y aseguramiento de planes preestablecidos. Los principales valores de la gestión ágil son la anticipación y la adaptación; diferentes a los de la gestión de proyectos ortodoxa: planificación y control para evitar desviaciones sobre el plan (Palacio; Ruata, 2011). Tras los cuatro valores descritos, los firmantes redactaron los siguientes, como los principios que de ellos se derivan: 81

90 Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos ágiles se doblegan al cambio como ventaja competitiva para el cliente. Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par de meses, con preferencia en los periodos breves. Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a través del proyecto. Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el respaldo que necesitan y procurándoles confianza para que realicen la tarea. La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo de desarrollo es mediante la conversación cara a cara. El software que funciona es la principal medida del progreso. Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida. La atención continua a la excelencia técnica enaltece la agilidad. La simplicidad como arte de maximizar la cantidad de trabajo que se hace, es esencial. Las mejores arquitecturas, requisitos y diseños emergen de equipos que se auto organizan. En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo ajusta su conducta en consecuencia. 82

91 2.4 Gestión de proyectos agiles Muchas empresas trabajan en escenarios que se parecen ya muy poco a los que impulsaron la gestión de proyectos predictiva y necesitan estrategias diferentes para gestionar el lanzamiento de sus productos: estrategias orientadas a la entrega temprana de resultados tangibles, y con la suficiente agilidad y flexibilidad para trabajar en entornos inestables y rápidos. Ahora necesitan construir el producto al mismo tiempo que cambian y aparecen nuevos requisitos; y como las circunstancias de los mercados y de las empresas no se pueden cambiar, son las formas en las que gestionan sus proyectos las que tienen que cambiar para dar respuesta a las nuevas necesidades. El cliente conoce la visión de su producto pero por la novedad, el valor de innovación que necesita y la velocidad a la que se va a mover el escenario tecnológico y de negocio, durante el desarrollo, no puede detallar cómo será el producto final. Existe el producto final? Quizá ya no hay productos finales, sino productos en evolución, mejora o incremento continuo, desde la primera versión beta. El resultado es la gestión ágil de proyectos, que no se formula sobre el concepto de anticipación (requisitos, diseño, planificación y seguimiento) sino sobre el de adaptación (visión, exploración y adaptación). La gestión ágil de proyectos tiene como objetivos dar garantías a las cuatro demandas principales de la industria en la que se ha generado: Valor, reducción del tiempo de desarrollo, agilidad y fiabilidad. Valor: La gestión ágil es necesaria en mercados rápidos. Su objetivo es dar el mayor valor posible al producto; y en el mercado en el que trabaja, este valor es directamente proporcional a la respuesta que pueda ofrecer en: 83

92 Innovación: La permanencia de estas empresas depende de su capacidad de innovación continua. Del lanzamiento continuo de novedades, que tienen que competir con los productos de una competencia que a su vez también innova sus productos de forma continua. Flexibilidad. En las circunstancias de velocidad del mercado actual, no sólo es importante el valor en el momento del lanzamiento, sino también su capacidad de adaptación y evolución a través de versiones, modificaciones, actualizaciones o ampliaciones; porque ahora no ocurre como en los años 50 en los que un modelo de auto-radio permanecía años sin desfasarse. Ahora como en Alicia en el país de las maravillas: necesitas correr todo lo que puedas para permanecer en el mismo lugar. Reducción del tiempo de desarrollo: En la década de 1990 la media de la salida de un nuevo producto al mercado en U.S. se redujo de 35,5 meses a 11 meses1 Esta reducción es una fortaleza competitiva muy importante en determinados sectores. (Hernán, 2004). Las estrategias de la gestión ágil para producir resultados en menos tiempo que la gestión tradicional son: Solapamiento de las fases de desarrollo. Entrega temprana de los primeros incrementos funcionales de producto, que corresponden con las partes que con mayor urgencia necesita el cliente, de forma que pueda lanzar la primera versión de producto con la mayor rapidez. Agilidad: Capacidad para adaptar el curso del desarrollo a la evolución de los requisitos y a las circunstancias del entorno. 84

93 Resultados fiables: Los procesos de producción empleados por la gestión de proyectos tradicional tienen como finalidad la repetitividad de los resultados: conseguir el trabajo planificado (y conocido de antemano) en el plazo planificado y por el coste previsto. La gestión ágil no tiene un carácter predictivo o de anticipación. No conoce de antemano el detalle del producto o servicio que va a desarrollar; por eso su objetivo no es la fiabilidad en el cumplimiento de los planes, sino en el valor del resultado y el tiempo de salida al mercado. Los procesos de la gestión tradicional son buenos cuando consiguen desarrollar de forma repetible los productos especificados en el tiempo y con los costes previstos. Los procesos de la gestión ágil son buenos, cuando consiguen entregar de forma repetible valor innovador. La gestión ágil, a diferencia de la tradicional, refleja las preferencias declaradas por el manifiesto ágil: La capacidad de respuesta al cambio, sobre el seguimiento de un plan. Los Productos que funcionan frente a especificaciones y documentaciones innecesarias. La colaboración con el cliente frente a la negociación contractual. A las personas y su interacción por encima de los procesos y las herramientas. El desarrollo ágil parte de la visión del concepto general del producto o servicio, y sobre ella el equipo va desarrollando pequeños incrementos en la dirección apuntada por la visión, y en el orden de prioridad que necesita el negocio 85

94 del cliente. Los ciclos breves de desarrollo, se denominan iteraciones y se realizan hasta que se decide no evolucionar más el producto generado. Este esquema de desarrollo está formado por cinco fases: 1.- Concepto: En la fase de concepto se crea la visión del producto o servicio que quiere obtener. Se decide y selecciona al equipo de personas que lo llevarán a cabo. Partir sin una visión determinada genera esfuerzo baldío. Del mismo modo que en términos de empresa, la visión es un factor crítico para el éxito del proyecto. Se necesita tener la visión de lo que se quiere, y conocer el alcance del proyecto. Esta información la deben compartir todos los integrantes del equipo 2.- Especulación Una vez que se sabe qué es lo que hay que desarrollar, el equipo especula y construye hipótesis sobre la información de la visión, que per se es muy general e insuficiente para determinar las implicaciones de un desarrollo (requisitos, diseño, costos). En esta fase se determinan las limitaciones impuestas por el entorno de negocio (costes y agendas principalmente) y se especula la primera aproximación de lo que se puede producir. La gestión ágil investiga y desarrolla tomando como partida la visión del producto. Durante el desarrollo confronta la realidad de lo que va obteniendo. Su valor, posibilidades y la situación de negocio del entorno en cada momento. La fase de especulación se repite en cada iteración del desarrollo, y teniendo como referencia la visión y el alcance del proyecto consiste en: Desarrollo / revisión de los requisitos generales del producto. Desarrollo de una lista con las funcionalidades esperadas Construcción de un plan de entrega: Fechas en las que se necesitan las versiones, hitos e iteraciones del desarrollo. Este plan refleja ya el esfuerzo que consumirá el proyecto durante el tiempo. 86

95 En función de las características del modelo de gestión y del proyecto puede incluir también una estrategia o planes para la gestión de riesgos. Si las exigencias de cumplimiento de la organización lo requieren, también se generan información administrativa y financiera. 3.- Exploración: Se desarrollan las funcionalidades de un incremento del producto, que han sido determinadas por el equipo en la fase anterior 4.- Revisión: El equipo y los usuarios revisan las funcionalidades construidas hasta ese momento. Trabajan y operan con el producto real para determinar su alineación y dirección con el objetivo. 5.- Cierre: Al llegar a la fecha de entrega de una versión de producto (fijada en la fase de concepto y revisada en las diferentes fases de especulación), se obtiene el producto esperado. Posiblemente éste seguirá en el mercado, y si se emplea gestión ágil es presumible que se trata de un producto que necesita versiones y mejoras frecuentes para no quedar obsoleto. No quiere decir necesariamente que se ha terminado el proyecto. Lo que se denomina mantenimiento supondrá la continuidad del proyecto en ciclos incrementales hacia la siguiente versión para ir acercándose a la visión del producto, que también es posible que vaya evolucionando con el tiempo conforme cambia el entorno tecnológico. 87

96 Figura 2.1 Esquema de desarrollo ágil de cinco fases (Hernán, 2004). Resumiendo decimos que la gestión ágil de proyectos no es una gestión de anticipación (requisitos, diseño, planificación y seguimiento) sino de adaptación (visión, exploración y adaptación). La gestión ágil tiene como objetivos: valor, reducción del tiempo de desarrollo, agilidad, flexibilidad y fiabilidad. La gestión ágil se basa en los principios del manifiesto ágil y centra el valor: o Más en las personas y su interacción que en los procesos y las herramientas o Más en los resultados que funcionan que en la documentación exhaustiva o Más en la colaboración con el cliente que en la negociación contractual 88

97 o Más en la capacidad de respuesta al cambio que en el seguimiento de un plan El desarrollo ágil comprende cinco fases: concepto, especulación, exploración, revisión y cierre. El desarrollo ágil surgió en empresas de productos tecnológicos, fue identificado por Nonaka y Takeuchi en los años 80 y a partir de los 90 diferentes profesionales del desarrollo del software incorporaron sus principios en sus entornos de trabajo. De esas implementaciones ágiles, las que abordan la gestión del 2.5 Gestión de proyectos predictiva o ágil? Al surgir en los 80 una nueva forma de gestionar proyectos, se hizo necesario añadir un nuevo apellido al término gestión de proyectos para matizar si se refiere a la nueva o a la de siempre. La nueva, al autodenominarse ágil, obligó a dar un apellido al modelo de gestión de proyectos que hasta entonces, por único, no lo había necesitado. Por lo tanto que a la gestión de proyectos de siempre se le dieron distintas denominaciones como: clásica, tradicional, formal y predictiva y a la gestión de proyectos nueva se le dio el nombre de ágil y adaptable. La gestión ágil y la gestión predictiva tienen grandes diferencias. Mientras que en la gestión predictiva o en cascada el proceso de desarrollo se realiza a través de fases en forma secuencial (la salida o producto desarrollado por una fase es la entrada o el producto de consumo de la siguiente), en la gestión ágil o adaptable la fases del proyecto pasan a ser tareas que se ejecutan cuando es necesario por lo tanto, la ejecución de las fases del proyecto se solapan entre si durante todo el desarrollo del mismo. 89

98 En la muestra siguiente tabla 2.1 se muestran algunos de contrastes entre las distintas metodologías. los muchos Contrastes entre desarrollo tradicional y ágil Desarrollo Tradicional Especialización Fases Requerimientos Detallados Seguimiento del plan Desarrollo Ágil Equipo multidisciplinar Solapamiento Visión de producto Adaptación a los cambios Tabla 2.1 contrastes entre desarrollo tradicional y ágil Mientras que el modelo tradicional se basa en la especialización de funciones donde cada departamento realiza la fase de desarrollo para la cual es especialista, en el modelo ágil el desarrollo lo realiza un solo equipo formado por personas muy competentes, con perfiles y conocimientos que cubren las disciplinas necesarias para construir el producto. Mientras que en el modelo tradicional, los diferentes equipos especialistas pasan el producto de su trabajo al siguiente equipo especialista para que acometa el comienzo de la siguiente fase de desarrollo (del equipo de analistas al equipo de codificadores por ejemplo), en el modelo ágil las fases no existen, éstas son tareas que se ejecutan cuando es necesario. No se hace primero el diseño del concepto o la captura de requerimientos, más tarde el análisis, luego el desarrollo, etc., sino que se acometen las diferentes tareas de todas esas disciplinas conforme el equipo de desarrollo las va necesitando. Mientras que en el modelo tradicional es imprescindible que exista tanto una descripción lo más detallada posible del producto final, sus requerimientos y sus funcionalidades que serán separadas más tarde en tareas más pequeñas y 90

99 estimables en dimensión, en el modelo ágil el dueño del producto (es decir, el cliente) avanza en la definición del producto y de su funcionalidad y comportamiento a la medida que va probando/tocando el producto en sí, retroalimentando al equipo de desarrollo con útiles feedbacks que sirven para mejorar el producto y evitar problemas futuros. Mientras que en el modelo tradicional existe un plan exquisitamente trazado que debe de ser seguido por todo el equipo de desarrollo en sus correspondientes fases con todo lujo de detalle, en el modelo ágil se parte desde una perspectiva de visión general del producto, el descubrimiento paulatino durante el desarrollo y las circunstancias que se irán produciendo en el entorno, dibujarán el detalle de forma paralela al desarrollo. Visto esto, podemos afirmar sin temor a réplica que la gestión ágil de proyectos es especialmente eficaz en condiciones donde el entorno no es estable y existe una clara incertidumbre con respecto al producto y su mercado. Una vez conocidas las diferencias principales entre ambos modelos de gestión podemos hacer una inmersión en el que para mi opinión es la mejor metodología de trabajo en el modelo ágil, esta es Scrum, pero esa inmersión en detalle la dejaremos para la próxima entrega de esta serie de artículos 91

100 CAPITULO III. HERRAMIENTAS PARA LA GESTIÓN DE PROYECTOS AGILES: PIVOTAL TRACKER

101 3.1 Herramientas para la gestión de proyectos de software La Gestión de Proyectos es el proceso por el cual los proyectos se definen, planean, controlan, y se entregan, para fines establecidos. La gestión de proyectos también incluye técnicas y herramientas para describir, controlar y entregar una serie de actividades con resultados, plazos y presupuestos. Con el incremento de la demanda de Gestión de Proyectos en todas las áreas en general, y aún más en la industria del software en particular; las necesidades de mejores herramientas de software en éste campo, también han incrementado. El objetivo es mostrar los distintos problemas pueden surgir en un proyecto de software y la forma en que se pueden suavizar o resolver utilizando herramientas para la gestión de proyectos. Más concretamente, los objetivos que se persiguen son los siguientes: Qué se entiende por una herramienta de gestión de proyectos. Importancia de los entornos de desarrollo, pre-producción y producción. Beneficios de trabajar con una herramienta 93

102 Mostrar las ventajas que aporta la utilización de un sistema de seguimiento Presentar las herramientas de seguimiento más conocidas. Cómo afecta el uso de una herramienta de trabajo en grupo a la coordinación de sus miembros. Integración de sistemas de seguimiento y control de errores y sistemas de control de versiones con una herramienta de gestión de proyectos. Primeramente que entendemos como herramientas para la gestión de proyectos, Una herramienta es según la definición de la Real Academia de la lengua Española (RAE), un instrumento del cual nos servimos para hacer algo. Por tanto, si aplicamos esta definición a las herramientas que utilizamos en el desarrollo de un proyecto software, lo que obtenemos es que una herramienta es un instrumento del cual nos servimos para construir software y que es utilizado en cualquiera de las fases de su desarrollo. Estos instrumentos generalmente son aplicaciones software, pero también pueden ser cualquier otro tipo de instrumento que nos ayude en el desarrollo de nuestro producto, como una calculadora o un simple bolígrafo, estas últimas no las tendremos en cuenta. El concepto que realmente nos interesa en este capítulo es el de herramientas de ingeniería del software, ya que el desarrollo del software debe ser una actividad desarrollada por personas que utilizan técnicas, métodos y herramientas adecuadas para cada solución. Una herramienta de ingeniería del software es un recurso que ayuda a las personas a realizar su trabajo de ingeniería del software. Para el propósito de este capítulo definiremos herramienta como: Una aplicación software que se utiliza para desarrollar, probar, analizar o mantener otra aplicación software o su documentación. Esta definición la deberíamos extender de tal manera que la aplicación que denominamos herramienta pueda ser utilizada a lo largo de todo el proceso de desarrollo del 94

103 producto o aplicación software final y por tanto, incluir tareas como la gestión de los procesos o detección de los requisitos. Desde hace algunos años se han comenzado a crear múltiples herramientas para administrar archivos de texto, planillas de cálculos o presentaciones de diapositivas. La mayoría de las que están disponibles hoy en internet, tienen sus antecesores en los paquetes de software de oficina, que son conocidas como Herramientas ofimáticas, también llamadas suites de oficina. Actualmente existen algunas alternativas de trabajo para la gestión de contenidos en línea, que nos permiten prescindir de un paquete de software del tipo Suite de Oficina como los descriptos en el cuadro anterior. Estas alternativas se basan en una gestión y muchas veces almacenamiento de la información de manera remota (en internet), y no local (en una computadora en particular como en el caso de los paquetes de oficina tradicionales). De esta manera, los documentos que trabajemos estarán accesibles desde cualquier computadora del mundo conectada a internet. Así como existen las ya mencionadas suites de oficina en línea, también es posible acceder a través de internet a una multiplicidad de servicios gratuitos, que permiten realizar alguna tarea en particular, sin llegar a ser todo un paquete, sirven para trabajos donde se requiera de una herramienta específica (un editor de textos, una planilla de cálculos, un programa para presentaciones). Es muy importante tener presente que este tipo de herramientas, si bien son gratuitas y están completamente disponibles en internet, nos reclaman ciertos requerimientos o condiciones tecnológicas básicas. 95

104 Debemos comenzar a experimentar herramientas, de manera tal que esta experiencia sirva para futuros aprendizajes. Entendemos este tipo de aprendizajes como una habilitación de oportunidades para continuar aprendiendo, y manejarnos con herramientas sencillas y poderosas que pueden potenciar nuestra capacidad creativa a la hora de innovar. La posibilidad de tener diversas oportunidades de aprendizaje, se tornará muy importante a la hora de poner en práctica (de aplicar en procesos de enseñanza y aprendizaje) aquello que forma parte de nuestra cultura referido a las Nuevas Tecnologías. Y contar con un historial importante de habilidades (competencias) para trabajar con otros y colaborar en experiencias de aprendizaje, será un valor agregado cada vez más necesario en la Sociedad del Conocimiento. 3.2 Herramientas para la gestión de proyectos basados en metodologías agiles Como se ha estudiado en capítulos anteriores a las metodologías agiles, se explico que objetivo de los métodos ágiles es permitir que una empresa sea ágil, pero, qué significa ser ágil? ser ágil significa ser capaz de entrega rápida, cambio rápido y cambio constante. Mientras que las técnicas ágiles pueden variar en su ejecución y en su énfasis, todas ellas comparten características, incluyendo el desarrollo iterativo y que están centradas en la interacción, comunicación, y en la reducción de la creación de artefactos intermedios. Desarrollar mediante iteraciones permite al equipo de desarrollo adaptarse a los cambios de los requisitos. Trabajar con un alto grado de comunicación permite que el equipo pueda tomar decisiones y aplicarlas inmediatamente. La reducción de artefactos intermedios que no dan valor añadido al producto final, nos permite asignar más recursos al producto en sí y podrá ser acabado antes. 96

105 Una herramienta ágil es capaz de llevar a cabo y en orden adecuado cada uno de las actividades que se deben efectuar en el desarrollo para cumplir a medida la entrega rápida, cambio rápido y cambio constante. Las herramientas, como aplicaciones de software que son, han ido evolucionando a lo largo de estos últimos años y adaptándose a las necesidades y tendencias de cada momento. Actualmente nos encontramos en una época dominada por las aplicaciones web y por metodologías de desarrollo que tienden a realizar iteraciones cortas, tal y como hemos podido ver en los capítulos anteriores que hacen las metodologías ágiles. Dentro de este nuevo entorno, necesitamos herramientas que se adapten a los procesos ágiles que se dan en el ciclo de vida del desarrollo del software, estas como hemos visto requieren muchas veces de actividades muy concretas y mecanismos sofisticados de integración. Podemos observar como la popularidad del desarrollo del software de una forma distribuida o colaborativa es cada vez mayor, ya sea a través del outsourcing, comunicación a distancia o equipos de desarrollo virtuales, incrementando la demanda de intercambio de información y trabajo apoyado en herramientas colaborativas. No solo se han modificado los procesos de desarrollo del software, sino que los productos que desarrollamos ahora no son los mismos que desarrollábamos hace 15 años, tal y como hemos comentado al principio de esta sección, actualmente las aplicaciones web ocupan la mayoría de los recursos de las consultorías informáticas. Pero no es tan solo eso, sino que las aplicaciones actuales cada vez son más grandes, complejas y diversas, utilizan nuevas tecnologías, componentes y métodos, que obviamente necesitan herramientas nuevas y específicas. Los desarrolladores tienen nuevas necesidades, ahora requieren de mejores herramientas para especificar, diseñar, generar, probar y desplegar complejos sistemas distribuidos e integrar diferentes tecnologías de sistemas heredados. Necesitan soporte para el diseño de interfaces de usuario cada vez más exigentes, control de versionado, gestión de la configuración, 97

106 documentación y reutilización de un gran número de artefactos. En definitiva, los procesos y productos generados son más complejos que hace años y es necesaria la utilización de herramientas que nos faciliten la realización de los proyectos mejor, más rápidamente y de un modo más eficiente. Algunas herramientas para la gestión de proyectos agiles son: Green Hopper truly agile Project management: es una herramienta para la gestión de proyectos ágiles de la compañía ATLASSIAN. Es una herramienta potente y configurable para la gestión técnica de proyectos con enfoque Scrum. Ofrece las siguientes características: Poder configurar tu Board: por ejemplo si eres gestor te interesará ver el avance, si eres responsable de desarrollo las incidencias Gestión de las Tareas Consultas personalizadas Explotación de datos de diversas formas: gráficos, informes No es una herramienta gratuita AgileTrack: Herramienta para planificación y seguimiento de proyectos, de interfaz sencillo. Para desarrollo de software en equipos reducidos con metodologías ágiles, especialmente extreme Programming. Gestiona ciclos de desarrollo basados en iteraciones, con seguimiento de historias de usuario, tareas y bugs. Multiplataforma para Windows y Linux, consta de dos módulos: el servidor que trabaja con MySQL, y el cliente para el seguimiento de los proyectos. Es un desarrollo Open Source, de uso gratuito con licencia AFL. Desde el web del proyecto, sobre un navegador (máquina virtual Java) se puede ejecutar una demo del cliente completamente operativa. 98

107 PPTS: Project Planning and Tracking System (PPTS) es una herramienta de gestión ágil de proyectos para equipos que trabajan con Scrum y/o Extreme Programming. Es un sistema web, accesible con un navegador que puede instalarse sobre servidor Linux o Windows (con php y MySQL) y de uso libre, con licencia GNU (GPL). Funcionalidades: Administración de las iteraciones. Requisitos (pila de producto, historias de usuario, product backlog) WBS (pila de sprint, sprint backlog) Gráficos de seguimiento Métricas de velocidad y avance Agenda Asignación de personas XPWeb: Plataforma web para gestión de proyectos con Extreme Programming, de uso gratuito con licencia GNU. Requisitos: PHP4 (recomendado 5), Apache, MySQL (también postgresql). Hay versión en español y cubre todas las funcionalidades básicas para dar soporte a las prácticas de Extreme Programming. Integra una ayuda muy completa. En conclusión las metodologías ágiles nos proponen un conjunto de técnicas y métodos que varían el flujo tradicional del ciclo de vida de un proyecto software, a la vez que introducen conceptos novedosos que requieren de herramientas específicas. Así las herramientas para la gestión de proyectos agiles han estado evolucionando con forme a como han estado evolucionando las metodologías de desarrollo. Estas han jugado y juegan un papel fundamental en todas las áreas, ya que siempre han buscado facilitar, agilizar y reducir tiempos. 99

108 3.3 Pivotal Tracker como gestor de proyectos agiles En este capítulo vamos a hablar de la herramienta Pivotal Tracker. Esta es una herramienta de gestión de proyectos ágiles, esta herramienta se utiliza para gestionar proyectos hechos en Scrum, xtreame programing, entre otros antes ya mencionados y estudiados. Esta herramienta está teniendo una gran acogida por que ofrece muchas opciones, es muy completa en la gestión de pilas, su forma de aprendizaje es muy sencilla, pero dispone de muchas opciones que la hacen ser una gran fuente de información y métricas. A Pivotal Tracker le faltan algunos elementos importantes, como es la posibilidad de invitar a los clientes o agentes externos a las pilas de productos. No se tienen en cuenta otros departamentos, aparte del de desarrollo. Es un gestor de proyectos con una fuerte orientación a metodologías ágiles. Las tareas no se estiman en horas, sino en puntos, que determinan, tras un tiempo de rodaje, la velocidad del equipo. Es una manera más acorde a la vida diaria de entender los proyectos, ya que las personas, a diferencia de las máquinas, no rendimos a un ritmo previsible, como tampoco son previsibles nuestros resultados. Se trata de un servicio gratuito, también en la nube, con posibilidad de crear múltiples proyectos y de asignarles personas con diversos roles. Las tareas se crean en la nevera (the Icebox) y se van organizando dinámicamente en función de parámetros variables, como los hitos definidos, el ritmo del equipo y las tareas pendientes. Antes la costumbre era que una sola persona creara el calendario del proyecto y asignara puestos y tiempos lo cual a veces resultaba en una terrible 100

109 falta de comunicación y por ende problemas a la hora de hacer entregas o avances. Bien pues Pivotal Tracker permite crear proyectos y tareas asignando prioridades y recursos para que de esta forma calcule fechas (o las asignes manualmente), posteriormente agregar a los interesados en el proyecto para que de esta forma trabajen en su tarea, envíen bocetos, avances y el administrador apruebe que la tarea esta completa o bien la rechace y la tarea sea reiniciada. Entre las novedades esta un Dashboard muy completo en el cual administras los proyectos, usuarios, tareas, graficas. También cuenta en cada proyecto con la capacidad de poder retroalimentar en base a comentarios a lo largo del desarrollo. Una vez que una tarea fue finalizada se entrega al cliente o a otra persona encargada de retroalimentar y si es correcta pasa a estado de terminada. Pivotal automáticamente calcula nuevas iteraciones en base a las entrega de sistema de puntos. El sistema de puntos actúa como un indicador en base al esfuerzo y riesgo que hay en cada tarea. También permite agregar distintos tipos de tareas como Característica que son tareas que deben ser revisadas y aprobadas y que serán parte del avance del proyecto, otro tipo de tarea son las rutinas, tareas que no necesitan una aprobación, pero que igual deben aparecer en la historia del proyecto. Los bugs son otro tipo de tareas disponibles, las cuales al igual que características deben ser entregadas, aceptadas y finalmente darlas por terminadas Ventajas y desventajas de Pivotal Tracker Este tracker o gestor de proyectos es un proyecto demasiado completo, con opciones como el chat y avisos vía a los integrantes del proyecto es una gran ayuda para evitar errores de comunicación a la hora de llevar proyectos de desarrollo. Entre los puntos malos, es está totalmente en inglés y que es 101

110 totalmente una cloud app (proyecto en la nube), es decir si no existe un enlace a la web no se puede usar. De esta herramienta podemos destacar frente a otras ya puestas en el mercado lo siguiente: Es gratis y no tiene ningún tipo de limitación. Es decir no hay licencia para la comunidad y ni empresarial. Está en la nube. Con lo que no tenemos que instalar nada en nuestros ordenadores, todo lo haremos a través del navegador web. Se centra en algo muy interesante que es la gestión de la pila de producto, y métricas como la velocidad. Es decir, se han visto muchas herramientas de este estilo y la mayoría intentan simular los post-it de la pared. Quedan muy bien, pero no son prácticas porque la mejor manera de usar los post-it es ponerlos en la pared. Se puede usar para trabajo con equipos descentralizados, puesto que está en internet (en las nubes). Además se puede crear varios perfiles de acceso por lo que podría haber usuarios que, por ejemplo, sólo tienen permiso para ver las cosas, pero no para modificarlas. Guarda histórico de nuestras acciones. Esto es bastante importante si se tiene, por ejemplo, alguna certificación de calidad, como puede ser ISO, que siempre exigen trazabilidad del trabajo aunque teniendo o no la certificación siempre debe haber trazabilidad Interacción con la herramienta Pivotal Tracker Pivotal Tracker está en la nube, la aplicación no requiere de instalación ni de ningún tipo de mantenimiento. Basta con ir a la página de Pivotal Tracker ( y registrarnos totalmente gratis. Nos mandarán un para la confirmación del registro. Y una vez confirmado el registro ya se puede ingresar con la cuenta creada y empezar a crear proyectos. 102

111 Ya que se encuentren registrados aparecerá la pantalla siguiente para poder ingresar (figura: 3.1) Figura 3.1 pantalla de ingreso a la herramienta Pivotal Tracker A continuación parecerá la siguiente pantalla (figura 3.2) donde se podrá crear el proyecto a que se va a gestionar. Pivotal Tracker dan la opción de crear un proyecto de prueba de forma automática. Para ello nada mas entramos en el panel de control el Dashboard y vemos una opción de sample project. Si pulsamos este enlace se nos creará un proyecto con algunos datos ficticios para poder interactuar con la interface y la herramienta. 103

112 Figura 3.2 pantalla inicial al ingresar a la herramienta Al entrar por primera vez en el proyecto de prueba se arroja una ventana por si queremos ver un vídeo del uso básico indicado en la figura 3.3. Figura 3.3 pantalla de muestra de video 104

113 Una vez dentro del proyecto veremos algo de este estilo: Figura 3.4 pantalla de ejemplo de un proyecto A continuación se van a ir describiendo algunos puntos 1. Las pilas Todas las historias de usuario se ordenan en varias pilas que podemos ver en la zona principal de la aplicación: Current: Son las historias de usuario que tenemos planificadas para el sprint en el que estamos. Backlog: Son las historias de usuario que tenemos planificadas para sprints futuros. Vemos como Pivotal Tracker nos va marcando donde empiezan los sprints. Esto lo hace de forma automática en función de nuestra velocidad media. Por ejemplo si insertamos una nueva historia de usuario en mitad de un sprint, en función de la estimación de esta nueva historia, moverá las historias posteriores para ajustarlas a los sprints en función de nuestra 105

114 velocidad. Esto por ejemplo podemos ver de un vistazo una estimación a largo plazo de nuestro proyecto. Icebox: Son historias de usuario que todavía no tenemos planificadas. Digamos que aquí meteríamos la lista de los reyes magos, pero que todavía no tenemos pensado cuando las vamos a hacer. Done: Esta pila por defecto no se muestra, pero si la activamos nos enseñaría los sprint que ya han pasado, aquí podemos ver cuándo se hizo qué. Podemos determinar que pilas son las que se muestran con los botones que encontramos arriba a la izquierda. Las historias de usuario las vamos moviendo entre estas pilas, tan fácil como pinchar y arrastrar. Tanto para cambiar la prioridad (el orden en la pila) como para cambiarlas de una pila a otra. 2. Tipos de historias de usuarios Figura 3.5 pantalla de tipos de historias de usuarios Feature: son las representadas por una estrella. Son las que representan requisitos de usuario y las únicas que se estiman (es decir podríamos decir que son lo que Scrum entiende como Historia de Usuario ). Bueno, esto no es del todo cierto, porque podemos cambiar 106

115 la configuración para que no sean las únicas que se estiman, pero desde Pivotal Tracker nos recomiendan no cambiarlas, no por un tema técnico sino porque el resto de historias no aportan valor de negocio al usuario y estimarlas rompería un poco con la idea de Scrum (nuestra velocidad se debería medir en funcionalidad de negocio que somos capaces de hacer en un sprint). Bugs: Son las representadas por la mariquita. Son deuda técnica, cosas que hemos hecho mal. Chore (faena, trabajo rutinario): Son las representadas por una rueda dentada. Representan tareas que tenemos que hacer pero que ni aportan valor de negocio ni son errores, por ejemplo montar un servidor de integración continua, preparar el entorno de producción. Release: Son las representadas por una bandera. Marcan hitos en el tiempo y se tienen en cuenta en la planificación y cálculo de velocidad. Por ejemplo, cuando se crea una Release, se le indica la fecha, si todo va bien saldrá en azul (como se ve en la imagen de arriba), pero sí según nuestra velocidad no nos va a dar tiempo a terminar todas las historias que hay por delante nos la marcará en rojo. Cualquier tipo de historia de usuario lo podemos convertir a cualquier otro tipo. Esto lo hacemos desde el detalle de la historia de usuario, que podemos ver si hacemos doble click sobre la historia, o un solo click sobre el triángulo que tenemos a la izquierda. 107

116 Figura 3.6 Configuración de historias de usuario En general vemos en la figura 3.6 como en el detalle de la historia de usuario podemos cambiar cualquier propiedad, meter una descripción, comentarios, adjuntar fichero y también podemos ver como abajo del todo tenemos un enlace que nos lleva directamente a esta historia. Esto es especialmente útil para integrar con otras herramientas. 108

117 Además las historias de usuario tienen un pequeño workflow. Por ejemplo, los estados para una historia de usuario de tipo Feature (las representadas por la estrella) serían: Not Yet Started: Cuando todavía no se ha empezado a trabajar sobre esta historia. Puede estar en cualquier pila menos en la de Done que es la de cosas terminadas. La historia de usuario mostrará un botón Start que pasa la historia al estado siguiente. Started: Sólo puede haber historias en este estado en la pila Current ya que es en lo que actualmente estamos trabajando. Si desde la pila Backlog o Icebox se da al botón Start de una historia, esta pasará automáticamente a la pila de Current. Finished: Es cuando hemos terminado de resolver la historia. Es decir, ya hemos hecho commit en el repositorio, pero todavía no está en ninguna release que se pueda entregar. Delivered: Es cuando ya está entregada, es decir cuando está en una release que se puede entregar al cliente. Accepted: Es cuando el cliente acepta la historia como buena (por ejemplo en la demo al final del sprint). En este caso la historia acabará yéndose a la pila de Done cuando termine este sprint. Rejected: Es cuando el cliente no acepta la historia como terminada. En este caso nos aparecerá un botón de Restart que si lo pulsamos es como si volviéramos al estado Started indicado más arriba. En la figura 3.7 se muestra un diagrama que representaría el camino natural (recordar que, como ya dijimos antes, manualmente podemos poner cualquier historia en cualquier estado, esto lo haríamos desde dentro del detalle de la historia). 109

118 Figura 3.7 camino natural de una historia de usuario. 3. Planificación y calculo de velocidad La estimación de las historias de usuario se hace en puntos de historia figura 4.7 (cómo es recomendable), por defecto tenemos los valores 0, 1, 2, 3, y son los cuadraditos azules que vemos a la derecha de la historia de usuario. Figura 3.8 Estimación de historias de usuario 110