qwertyuiopasdfghjklzxcvbnmqw ertyuiopasdfghjklzxcvbnmqwert yuiopasdfghjklzxcvbnmqwertyui Desarrollo de software gil en colocaciones extremas dentro de la empresa opasdfghjklzxcvbnmqwertyuiopa Daniel Alejandro Aguirre Linares

sdfghjklzxcvbnmqwertyuiopasdf Carlos Micheas Alcal Snchez ghjklzxcvbnmqwertyuiopasdfghj Alejandro Pompa Lpez Marco Rene Villareal Huerta klzxcvbnmqwertyuiopasdfghjklz Darwin Isa Duarte Torres xcvbnmqwertyuiopasdfghjklzxcv bnmqwertyuiopasdfghjklzxcvbn mqwertyuiopasdfghjklzxcvbnmq wertyuiopasdfghjklzxcvbnmqwe rtyuiopasdfghjklzxcvbnmqwerty uiopasdfghjklzxcvbnmqwertyuio pasdfghjklzxcvbnmqwertyuiopas dfghjklzxcvbnmqwertyuiopasdfg

Introduccin El trabajo intenso de equipo es muy pesado. El nmero de herramientas que se adquieren son ayudan a solucionar la dicha problemtica sin embargo tambin se debe considerar, los costos y la calidad y cantidad de los integrantes del equipo. Una de las mayores dificultades de organizar el trabajo, es la mala organizacin o eleccin de los integrantes del equipo as como las fallas de comunicacin entre ellos [20]. En esta investigacin estudiaremos ms a detalle los resultados sobre un experimento sobre un equipo de desarrollo de software, donde se emple una nueva estrategia llamada radical collocation, en dicho experimento se utilizaron 6 equipos trabajando con esta nueva estrategia, que promete ser una excelente estrategia para desarrollo de software innovador. Explicaremos el desarrollo que se llev a cabo durante el tiempo del experimento enfocndonos en aspectos personales, de equipo, del proyecto, de las herramientas utilizadas as como tambin del diseo del inmueble donde se desarroll. Resumen Los equipos de desarrollo de software en equipos con metodologas y enfoques agiles dentro de una colocacin extrema permiten una productividad y eficiencia en cuanto tiempo, entrega y desarrollo de software estableciendo como prioridad al personal que labora en l, debido ala comunicacin constante entre los miembros del equipo y la obtencin de la informacin y ayuda de manera fcil y rpida debido a la ubicacin del equipo en un solo lugar (casa, hotel, etc.) de trabajo. Permitiendo que el trabajo pesado se pueda convertir en una trabajo ms ligero y menos cansado y desgastante tanto para la empresa como para el personal, aunque un se utilicen mtodos tradicionales que hacen el desarrollo de software un proceso mas pesado, tedioso y desgastante tanto para el personal como para la empresa, tomando el riesgo de entregar un proyecto que no cumpla con las necesidades del cliente

V Marco Terico Introduccin al modelo gil. El por qu de las metodologas giles Tradicionalmente se ha tendido a desarrollar software a travs de metodologas que encorsetaban el proceso de desarrollo de manera un tanto rgida que, cada vez ms, se demuestra errnea en las actuales caractersticas de dinamismo y variabilidad del mercado software. Como indica Boehm en la referencia se tiende hacia el rpido desarrollo de aplicaciones y la vida de los productos se acorta. En este entorno inestable, que tiene como factor inherente el cambio y la evolucin rpida y continua, la ventaja competitiva se encuentra en aumentar la productividad y satisfacer las variantes necesidades del cliente en el menor tiempo posible para proporcionar un mayor valor al negocio.

Sin embargo, las metodologas convencionales presentan diversos problemas a la hora de abordar un amplio rango de proyectos industriales en este turbulento entorno. Entre estos problemas podemos destacar los siguientes: Perciben la captura de requisitos del proyecto como una fase previa al desarrollo del mismo que, una vez completada, debe proporcionar una fotografa exacta de qu desea el cliente. Se trata de evitar a toda costa que se produzcan cambios en el conjunto de requisitos inicial, puesto que a medida que avanza el proyecto resulta ms costoso solucionar los errores detectados o introducir modificaciones , y pretenden delegar toda responsabilidad econmica en el cliente en caso de que estos cambios de requisitos se produzcan. Por este motivo, se les conoce tambin como metodologas predictivas. Sin embargo, el esfuerzo, tanto en coste como en tiempo, que supone hacer una captura detallada de todos los requisitos de un proyecto al comienzo del mismo es enorme y rara vez se ve justificado con el resultado obtenido. Adems, en muchas ocasiones el cliente no conoce sus propias necesidades con la profundidad suficiente como para definirlas de forma exacta a priori y, a menudo, estas necesidades y sus prioridades varan durante la vida del proyecto. Establecer mecanismos de control es una de las opciones existentes para protegerse de estos cambios, aunque frecuentemente provocan la insatisfaccin de los clientes, que perciben el desarrollo del proyecto como algo inflexible que no se adapta a sus necesidades y que si lo hace repercute negativamente en costes aadidos al presupuesto del proyecto. Por otro lado, en muchas ocasiones el proceso de desarrollo convencional est oprimido por excesiva documentacin no siempre til. Un porcentaje elevado del tiempo de desarrollo de un producto software se dedica o, desde el punto de vista de las metodologas giles, se malgasta en crear documentacin que finalmente no se utiliza y que, por tanto, no aporta valor al negocio. Adems, esta documentacin innecesaria entorpece las labores de mantenimiento de la propia documentacin til lo que provoca que en muchas ocasiones el mantenimiento de la documentacin se obvie agudizando, de este modo, el coste en las tareas de documentacin futuras. Evidentemente, estas circunstancias no se adaptan a las restricciones de tiempo del mercado actual. Otra dificultad aadida al uso de metodologas convencionales es la lentitud del proceso de desarrollo. Es difcil para los desarrolladores entender un sistema complejo en su

globalidad lo que provoca que las diferentes etapas del ciclo de vida convencional transcurran lentamente. Dividir el trabajo en mdulos abordables ayuda a minimizar los fallos y, por tanto, el coste de desarrollo. Adems, permite liberar funcionalidad progresivamente, segn indiquen los estudios de las necesidades del mercado que aportan mayor beneficio a la organizacin. En la feroz competencia del mercado vigente, en la que los productos quedan obsoletos rpidamente, se pide bsicamente rapidez, calidad y reduccin de costes, pero para asumir estos retos, es necesario tener agilidad y flexibilidad. Asimismo, las metodologas convencionales tienden a acumular los riesgos y dificultades que surgen en el desarrollo del producto al final del proyecto, repercutiendo en retrasos en la entrega de productos o influyendo en la incorrecta ejecucin de las ltimas fases del ciclo de vida. En contraposicin a las metodologas convencionales, las metodologas giles aparecen como alternativa atractiva para adaptarse a este entorno. Son apropiadas cuando los requisitos son emergentes y cambian rpidamente. De este modo, presentan diversas ventajas en el contexto actual:

Capacidad de respuesta a cambios a lo largo del desarrollo ya que no los perciben como un lastre sino como una oportunidad para mejorar el sistema e incrementar la satisfaccin del cliente, considerando la gestin de cambios como un aspecto caracterstico del propio proceso de desarrollo software. Entrega contina y en plazos breves de software funcional lo que permite al cliente verificar in situ el desarrollo del proyecto, ir disfrutando de la funcionalidad del producto progresivamente y comprobando si satisface sus necesidades, mejorando de esta forma su satisfaccin. Adems, el desarrollo en ciclos de corta duracin favorece que los riesgos y dificultades se repartan a lo largo del desarrollo del producto, principalmente al comienzo del mismo y permite ir aprendiendo de estos riesgos y dificultades Trabajo conjunto entre el cliente y el equipo de desarrollo con una comunicacin directa que pretende mitigar malentendidos, que constituyen una de las principales fuentes de errores en productos software, y exceso de documentacin improductiva.

Importancia de la simplicidad, eliminando el trabajo innecesario que no aporta valor al negocio. Atencin contina a la excelencia tcnica y al buen diseo para mantener una alta calidad de los productos. Mejora contina de los procesos y el equipo de desarrollo, entendiendo que el xito, depende de tres factores: xito tcnico, xito personal y xito organizacional.

El Manifiesto gil. Valores y principios Continuamente estamos utilizando el concepto de agilidad para definir estas metodologas, pero qu significa ser gil desde una perspectiva software? Basados en el consenso de varias definiciones contemporneas, Qumer y Henderson-Sellers ofrecieron la siguiente definicin de agilidad La agilidad es un comportamiento persistente o habilidad, de entidad sensible, que presenta flexibilidad para adaptarse a cambios, esperados o inesperados, rpidamente; persigue la duracin ms corta en tiempo; usa instrumentos econmicos, simples y de calidad en un ambiente dinmico; y utiliza los conocimientos y experiencia previos para aprender tanto del entorno interno como del externo. Por tanto, el desarrollo gil no especifica unos procesos o mtodos que seguir, aunque bien es cierto que han aparecido algunas prcticas asociadas a este movimiento. El desarrollo gil es ms bien una filosofa de desarrollo software. El punto de partida se establece en las ideas emanadas del Manifiesto gil tras la reunin de Utah , un documento que resume la filosofa agile estableciendo cuatro valores y doce principios. Segn el Manifiesto se valora: Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor de xito de un proceso software. Este primer valor expresa que es preferible utilizar un proceso indocumentado con buenas interacciones personales que un proceso documentado con interacciones hostiles. Se considera que no se debe pretender construir primero el entorno y esperar que el equipo se adapte automticamente sino al revs, construir primero el equipo y que ste configure su propio

entorno. El talento, la habilidad, la capacidad de comunicacin y de tratar con personas son caractersticas fundamentales para los miembros de un equipo gil. Desarrollar software que funcione por encima de una completa documentacin. Este valor es utilizado por muchos detractores de las metodologas giles que argumentan que stas son la excusa perfecta para aquellos que pretenden evitar las tareas menos gratificantes del desarrollo software como las tareas de documentacin. Sin embargo, el propsito de este valor es acentuar la supremaca del producto por encima de la documentacin. El objetivo de todo desarrollador es obtener un producto que funcione y cumpla las necesidades del cliente y la documentacin es un artefacto que utiliza para cumplir su objetivo. Por tanto, no se trata de no documentar sino de documentar aquello que sea necesario para tomar de forma inmediata una decisin importante. Los documentos deben ser cortos y centrarse en lo fundamental. Dado que el cdigo es el valor principal que se obtiene del desarrollo se enfatiza en seguir ciertos estndares de programacin para mantener el cdigo legible y documentado. La colaboracin con el cliente por encima de la negociacin contractual. Se propone una interaccin continua entre el cliente y el equipo de desarrollo de tal forma que el cliente forme un tndem con el equipo de desarrollo. Se pretende no diferenciar entre las figuras cliente y equipo de desarrollo sino que se apuesta por un solo equipo persiguiendo un objetivo comn. Responder a los cambios ms que seguir estrictamente un plan. Planificar el trabajo a realizar es muy til y las metodologas giles consideran actividades especficas de planificacin a corto plazo. No obstante, adaptarse a los cambios es vital en la industria software actual y, por tanto, tambin consideran mecanismos para tratar los cambios de prioridades. La regla es planificar es til. Seguir un plan es til hasta que el plan se distancia de la situacin actual. Pender de un plan desactualizado es caminar por un callejn sin salida. Para cumplir estos valores se siguen doce principios que establecen algunas diferencias entre un desarrollo gil y uno convencional: 1. La prioridad es satisfacer al cliente mediantes tempranas y continuas entregas de software que le aporten valor.

2. Dar la bienvenida a los cambios de requisitos. Se capturan los cambios para que el cliente tenga una ventaja competitiva. 3. Liberar software que funcione frecuentemente, desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. 4. Los miembros del negocio y los desarrolladores deben trabajar juntos diariamente a lo largo del proyecto. 5. Construir el proyecto en torno a individuos motivados. Darles el entorno y apoyo que necesiten y confiar a en ellos para conseguir finalizar el trabajo. 6. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro de un equipo de desarrollo. 7. El software que funciona es la principal medida de progreso. 8. Los procesos giles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberan ser capaces de mantener una paz constante. 9. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. 10. La simplicidad es esencial. 11. Las mejores arquitecturas, requisitos y diseos surgen de los equipos que se auto organizan. 12. En intervalos regulares el equipo debe reflexionar sobre cmo ser ms efectivo y segn estas reflexiones ajustar su comportamiento.

Estos principios marcan el ciclo de vida de un desarrollo gil, as como las prcticas y procesos a utilizar. Cmo ser gil. Algunas prcticas Aunque el movimiento gil est sustentado por valores y principios para el desarrollo de productos software, la mayora de estas metodologas tienen asociadas un conjunto de prcticas, en muchos casos comunes, que buscan la agilidad en el desarrollo. En esta seccin vamos a analizar algunas de las ms relevantes: planificacin, programacin en parejas o pair programming, integracin continua, refactorizacin y desarrollo dirigido por pruebas (Test Driven Development).

Planificacin, Historias de usuario. Mientras que las metodologas convencionales centran la ingeniera de requisitos en habilidades de prediccin basndose en frreas planificaciones previas al desarrollo, las metodologas giles perciben la gestin de cambios como un aspecto inherente al proceso de desarrollo software, considerando planificaciones continuas, ms flexibles y en cortos plazos, que respondan mejor a los cambios en las necesidades del cliente. Con el objetivo de disminuir el coste, no siempre amortizable, que supone la etapa de planificacin en las metodologas convencionales, las giles simplifican las tareas de gestin y documentacin de las necesidades del sistema. Apuestan por involucrar de una forma ms intensa al cliente a lo largo de todo el proceso de desarrollo, de forma que, la comunicacin directa y frecuente retroalimentacin son las prcticas ms importantes para la planificacin y especificacin de requisitos en estas metodologas. En este proceso de definicin de las necesidades del sistema que guiar el desarrollo, se utilizan las llamadas historias de usuario para detallar, en un lenguaje cercano al cliente, la funcionalidad que debe satisfacer el sistema. Las historias de usuario se descomponen en tareas que debern ser realizadas para cumplir con la funcionalidad que se solicita. Ntese que la estimacin de tiempo no es una restriccin fija, simplemente constituye una aproximacin inicial. Se considera que las historias de usuario deben cumplir seis caractersticas: comprobables. Programacin en pareja (Pair Programming). Una de las prcticas ms utilizadas en metodologas giles, sobre todo en sistemas de alta complejidad, es la programacin en parejas, que establece que la produccin de cdigo se realice con trabajo en parejas de programadores. El utilizar Pair Programming en un proyecto no implica que todas las lneas de cdigo sean escritas por una pareja, ya que mientras una persona est escribiendo el cdigo, la otra puede estar verificando errores, pensando en alternativas mejores, identificando casos de prueba, pensando en aspectos de diseo, etc. El objetivo principal de esta tcnica es disminuir la tasa de errores, mejorar el diseo y aspectos como la satisfaccin de los programadores. No obstante, algunos estudios independientes, negociables, valorables, estimables, pequeas y

indican que se trata de una tcnica intensa y estresante para los propios programadores, aunque admiten que acelera el proceso de desarrollo. Otro detalle a tener en cuenta es las habilidades y capacidades de los miembros de la pareja. Si existe una diferencia importante entre ellos, puede llegar a ser una prctica frustrante para ambos. En este caso concreto, el Pair Programming ha de ser visto como una tcnica de aprendizaje. Integracin continua (Countinuous integration) La integracin continua pretende mitigar la complejidad que el proceso de integracin suele tener asociada en las metodologas convencionales, superando, en determinadas circunstancias, la propia complejidad de la codificacin. El objetivo es integrar cada cambio introducido, de tal forma que pequeas piezas de cdigo sean integradas de forma continua, ya que se parte de la base de que cuanto ms se espere para integrar ms costoso e impredecible se vuelve el proceso. As, el sistema puede llegar a ser integrado y construido varias veces en un mismo da. Para que esta prctica sea viable es imprescindible disponer de una batera de test, preferiblemente automatizados, de tal forma, que una vez que el nuevo cdigo est integrado con el resto del sistema se ejecute toda la batera de pruebas. Si son pasados todos los test del sistema, se procede a la siguiente tarea. En caso contrario, aunque no falle el nuevo modulo que se quiere introducir en el sistema, se ha de regresar a la versin anterior, pues sta ya haba pasado la batera de pruebas. Refactorizacin. Actividad constante en los desarrollos giles cuyo objetivo es mejorar el diseo de un sistema sin influir en su funcionalidad. Se pretende reestructurar el cdigo para eliminar duplicaciones, mejorar su legibilidad, simplificarlo y hacerlo ms flexible de forma que se faciliten los posteriores cambios. Recordemos que el cdigo que funciona es el principal aporte de valor para las metodologas giles, por encima de la documentacin, por lo que se enfatiza en que ste sea legible y permita la comunicacin entre desarrolladores. Desarrollo dirigido por pruebas (Test Driven Development).

Al utilizar esta prctica la produccin de cdigo est dirigida por las pruebas. Concretamente, se trata de escribir las pruebas que validarn el sistema antes de comenzar a construirlo, idealmente que sea el propio cliente quien las escriba. De esta forma, ante cada modificacin del sistema la batera completa de pruebas es ejecutada. Esta prctica constituye, por tanto, la primera lnea para garantizar la calidad del producto, pues sta se considera en trminos de la correcta funcionalidad que se le ofrece al cliente. Entre las ventajas que aporta el desarrollo dirigido por pruebas podemos destacar que disminuye el tiempo dedicado a solucionar errores y genera un sentimiento de confianza de xito del proyecto en el equipo. Tecnologas como JUnit son utilizadas para manejar y ejecutar conjuntos de pruebas automatizadas. No obstante, el hecho de que aspectos tan importantes como la cohesin o el acoplamiento de los mdulos pase a un segundo plano en el desarrollo a favor de la funcionalidad, implica la necesidad de realizar constantes etapas de refactorizacin que permitan mantener la calidad del cdigo. Como se puede apreciar, a pesar de la reciente aplicacin de las metodologas giles la mayora de las prcticas propuestas no so novedosas sino que de alguna manera ya haban sido propuestas en ingeniera del software. El mrito de las metodologas giles es proponer una aplicacin conjunta, equilibrada y efectiva de forma que se complementen con ideas desde la perspectiva del negocio, los valores humanos y el trabajo SCRUM SCRUM es el trmino que describe una forma para desarrollar productos iniciada en Japn. No se trata de un concepto nuevo, sino que ya en 1987 Ikujiro Nonaka y Hirotaka Takeuchi acuaron este trmino, una estrategia utilizada en rugby en la que todos los integrantes del equipo actan juntos para avanzar la pelota y ganar el partido, para denominar un nuevo tipo de proceso de desarrollo de productos. Escogieron este nombre por las similitudes que consideraban que existan entre el juego del rugby y el tipo de proceso que proponan: adaptable, rpido, auto-organizable y con pocos descansos. SCRUM es un proceso para la gestin y control del producto que trata de eliminar la complejidad en estas reas para centrarse en la construccin de software que satisfaga las necesidades del negocio. Es simple y escalable, ya que no establece prcticas de ingeniera

del software sino que se aplica o combina, fcilmente, con otras prcticas ingenieriles, metodologas de desarrollo o estndares ya existentes en la organizacin. SCRUM se concentra, principalmente, a nivel de las personas y equipo de desarrollo que construye el producto. Su objetivo es que los miembros del equipo trabajen juntos y de forma eficiente obteniendo productos complejos y sofisticados. Podramos entender SCRUM como un tipo de ingeniera social que pretende conseguir la satisfaccin de todos los que participan en el desarrollo, fomentando la cooperacin a travs de la autoorganizacin. De esta forma se favorece la franqueza entre el equipo y la visibilidad del producto. Pretende que no haya problemas ocultos, asuntos u obstculos que puedan poner en peligro el proyecto. Los equipos se guan por su conocimiento y experiencia ms que por planes de proyecto formalmente definidos. La planificacin detallada se realiza sobre cortos espacios de tiempo lo que permite una constante retroalimentacin que proporciona inspecciones simples y un ciclo de vida adaptable. As, el desarrollo de productos se produce de forma incremental y con un control emprico del proceso que permite la mejora continua Independientemente del tipo de metodologa que se utilice, cualquier desarrollo software parte siempre de un mismo problema: conocer las necesidades de los clientes. SCRUM, al igual que el resto de metodologas giles, pretende no centrar las tareas de desarrollo en un conjunto de requisitos formalmente definidos sino que aboga por la incorporacin del cliente como un miembro ms del equipo de desarrollo. De este modo, no se considera el proceso de definicin de requisitos como un fin dentro del desarrollo del proyecto, sino que los requisitos aparecen implcitamente dentro del contenido de las denominadas historias de usuario. Las historias de usuario son el elemento base que utiliza SCRUM para describir las caractersticas que el usuario espera que tenga el software que se va a desarrollar . Por lo tanto, pueden incorporar tanto cuestiones relacionadas con las funciones del sistema como con cualquier otro aspecto del mismo (restricciones, rendimiento, etc.). Las historias de usuario se presentan desde la perspectiva del usuario. As, no se describen utilizando una terminologa tcnica sino que se escriben utilizando un lenguaje cercano al dominio de la aplicacin que se est desarrollando de forma que sea comprensible por los clientes y por

los desarrolladores. Las historias de usuario se construyen bajo un mismo esqueleto que centra el foco de las caractersticas del producto. - Primero se determina quin propone la historia de usuario, - Luego se describe la caracterstica que se cubre con la historia de usuario y - Finalmente se especifica la razn por la que dicha caracterstica es necesaria. El proceso comienza con la fase de Pre-game, en la que se realiza de forma conjunta con el cliente una definicin sencilla y clara de las caractersticas que debe tener el sistema que vaya a ser desarrollado, definiendo las historias de usuario que van a guiar el proceso de desarrollo. Posteriormente, cada historia de usuario se refina de manera que se identifican las tareas que son necesarias para llevar a cabo el desarrollo de la historia de usuario. En un principio no es necesario detallar de forma completa todas las historias de usuario sino slo las que tienen un mayor nivel de prioridad por parte del usuario. Esto permite que el proceso de desarrollo pueda adaptarse a posteriores modificaciones de las necesidades de usuario, de forma que el proceso de desarrollo se vuelve ms flexible. El resultado de esta fase de Pre-game es lo que se denomina en SCRUM Product Backlog, que contiene una lista de todas las historias de usuario priorizadas as como de las tareas que se deben llevar a cabo para la realizacin del proyecto. Este enfoque basado en quin, qu y por qu facilita la tarea de priorizacin de las historias de usuario, lo que permite realizar la planificacin inicial del proyecto. Como puede deducirse de lo anteriormente expuesto, la obtencin del Product Backlog se realiza con la ayuda del cliente/usuario del sistema que se va a desarrollar, por lo que puede considerarse que se realiza en directo y, por lo tanto, las posibles dudas en el establecimiento de las historias de usuario pude resolverse en ese mismo instante. Una vez identificadas y priorizadas las historias de usuario del Product Backlog, se realiza la separacin de historias de usuario en etapas de corta duracin (no ms de 30 das) denominadas sprints. Para cada sprint se realiza una reunin de planificacin de lo que se va a llevar a cabo en ese sprint y se establece la fecha de finalizacin del mismo. El objetivo es mover aquellas historias de usuario con mayor prioridad para el cliente al denominado Sprint Backlog, que contiene el conjunto de tareas a desarrollar en ese sprint, incluyendo diseo, desarrollo, pruebas, integracin, etc. Las historias de usuario.

se congelan en el Sprint Backlog de forma que durante dicho periodo no puedan producirse cambios sobre los aspectos que se encuentran en fase de desarrollo. De forma iterativa, todos los das que dure el sprint, se realiza una reunin operativa, informal y gil con el equipo de desarrollo, de un mximo de quince minutos, en la que a cada integrante del equipo se le hacen tres preguntas: - Qu tareas ha hecho desde la ltima reunin? Es decir, tareas realizadas en un da. - Qu tareas va ha hacer hoy? - Que ayuda necesita para poder realizar este trabajo? Es decir, identificacin de obstculos o riesgos que impiden o pueden impedir el normal avance. Una vez finalizado el sprint se debera obtener parte del producto, un entregable o algo que se pueda mostrar y que ensee los avances acometidos en el Sprint. En este punto se procede a una fase de revisin del proyecto para mostrar dichos avances e incorporar, si fuera necesario, nuevas historias de usuario al Product Backlog. Para mantener la calidad del producto se establece que una historia de usuario est 100% completa si supera los test unitarios, pasa las pruebas de aceptacin, supera los test adicionales para mantener la calidad del producto, el cdigo est construido e integrado satisfactoriamente, est basado en un diseo factorizado sin duplicaciones, el cdigo es claro, estructurado y autodocumentado y, por supuesto, es aceptado por el cliente. Adems, tras la realizacin de cada sprint se lleva a cabo una reunin retrospectiva que permite aprender de los conocimientos y experiencias adquiridas hasta el momento y mejorar de forma continua el proceso de desarrollo. Se revisar con el equipo los objetivos marcados inicialmente en el Sprint Backlog concluido, se aplicarn los cambios y ajustes si son necesarios, y se marcarn los aspectos positivos (para repetirlos) y los aspectos negativos (para evitar que se repitan) del Sprint, que servirn de retroalimentacin para el siguiente sprint. Los elementos que servirn de entrada y guiarn la planificacin de un nuevo sprint sern el Product Backlog, las capacidades o habilidades del equipo, las condiciones que en ese momento se den del negocio, el avance tecnolgico que se haya podido producir y el incremento que se pretenda hacer al producto que se est desarrollando. De esta forma, en contraposicin con las metodologas convencionales, el

proceso de desarrollo adquiere flexibilidad, agilidad y capacidad para adaptarse a su entorno. Para orquestar este proceso SCRUM distingue distintos actores con diferentes papeles dentro del proceso. De forma general, podemos distinguir propietario del producto Product Owner, maestro de scrum Scrum Master, equipo de desarrollo Scrum Team y cliente o usuario. El Product Owner es la nica persona encargada de la direccin y control del Product Backlog, es decir, de las historias de usuario que debe cumplir el sistema. Se trata de una persona fsica (solamente una persona para eliminar las posibles confusiones o interferencias), no una organizacin o comit. Bien puede ser el propio cliente in situ en el lugar de desarrollo u otra persona que tenga el conocimiento suficiente sobre el producto o pueda estar en continuo contacto con el cliente para marcar las prioridades del proyecto. Es, por tanto, la persona oficialmente responsable del proyecto que de forma visible, vocal y objetiva debe tomar todas las decisiones de negocio para el producto. Para que el Product Owner tenga xito, el resto del equipo de la organizacin tiene que respetar sus decisiones. En cuanto a su implicacin debe estar en contaste interaccin con el equipo de desarrollo. Debe asistir, al menos, a las reuniones de planificacin y de revisin de cada sprint y estar en continuo contacto con el equipo para proporcionar detalles sobre las historias de usuario y constante retroalimentacin que dirija el desarrollo del sprint. El Scrum Master es la persona responsable del xito al aplicar la metodologa SCRUM en el desarrollo del proyecto o producto, asegurando que los valores, prcticas y reglas son seguidos por el resto del equipo. En concreto, es la persona que asegura el seguimiento de la metodologa guiando las reuniones, ayudando al equipo ante cualquier problema que pueda aparecer y controlando que el trabajo sigua el ritmo adecuado. Por tanto debe tomar decisiones inmediatas y eliminar los impedimentos que vayan surgiendo en el momento, aunque en ocasiones no cuente con toda la informacin necesaria. Su responsabilidad es entre otras, la de hacer de paraguas ante las presiones externas y motivar al resto del equipo. Por tanto, la labor de Scrum Master requiere una fuerte personalidad ya que debe facilitar el trabajo del equipo sin imponer autoridad. Las personas que ejercen este role deben ser capaces de hacer cualquier cosa por ayudar al equipo de desarrollo, incluso

aunque estas acciones estn enfrentadas con sus propios intereses. Deben ser personas poco conformistas y con mucha iniciativa. Eliminar impedimentos requiere determinacin y tenacidad. La metfora utilizada por Kent Beck refleja perfectamente este papel: El Scrum Master es el perro pastor que hace cualquier cosa para proteger al rebao, y nunca se distrae de su deber. El Scrum Team lo conforman las personas responsables de implementar la funcionalidad o funcionalidades elegidas por el Product Owner. Debe ser un conjunto de personas motivadas con habilidades y capacidades complementarias que estn comprometidos por un propsito comn, cumplir el objetivo del sprint. El equipo tiene plena autoridad para tomar todas las decisiones que consideren adecuadas en el desarrollo del proyecto, auto-organizndose y auto-disciplinndose. As, por ejemplo, en las reuniones de planificacin el Product Owner y el Scrum Team deben llegar a un acuerdo realista sobre las historias de usuario que se van a completar en el siguiente sprint y si en algn momento el Scrum Team considera que algunas de las prioridades del Product Owner no es razonable dispone de libertad absoluta para resear esta circunstancia y obligar al propietario del producto a variar sus prioridades. Tericamente, se estima que debera estar formado por un nmero de entre 7 u 8 miembros como mximo y 2 como mnimo. Finalmente, el cliente es o son los beneficiarios finales del producto, y quienes viendo los progresos, pueden aportar ideas, sugerencias o necesidades. Su participacin es importantsima e imprescindible en esta metodologa. La efectividad de la metodologa para la gestin de proyectos se basa en un conjunto de valores fundamentales que deben seguir todos los integrantes del equipo, principios sobre los que reposan el resto de prcticas: compromiso, esmero, franqueza, respeto y valor. Los miembros del equipo deben estar dispuestos a comprometerse con el objetivo de cada sprint y del proyecto en general. SCRUM proporciona al equipo toda la autoridad que necesiten para obtener a cambio su compromiso. El equipo se tiene que comprometer a hacer su trabajo. Cada miembro debe concentrar todos sus esfuerzos y habilidades en cumplir con el trabajo que se han comprometido a realizar sin desviarse en otros aspectos, realizando todas sus labores con esmero. Todos los aspectos del proyecto son visibles para todo el equipo por lo que un valor fundamental es tambin la franqueza. Adems, los miembros del equipo estn avalados por sus conocimientos y experiencias, el respeto es un valor fundamental

con cada uno de ellos. Finalmente, cada miembro del equipo tiene que tener el coraje suficiente para comprometerse, actuar, ser transparente en el desarrollo y respetar y hacer que le respeten. Una revisin de otras metodologas giles Aunque el manifiesto gil es la piedra angular sobre la que cimientan todas las metodologas giles, cada una tiene unas caractersticas propias y hace hincapi en algunos aspectos ms especficos. En esta seccin se describen, a grandes rasgos, las particularidades fundamentales de algunas otras metodologas giles, que actualmente tienen gran aceptacin en el mercado, como eXtreme Programming, Cristal, Dynamic Software Development Method (DSDM), Feature-driven Development y Lean Software Development. eXtreme Programming tambin conocida como XP, es una metodologa gil

centrada en potenciar las relaciones interpersonales como clave para el xito en desarrollo software. Aspectos como el trabajo en equipo, el aprendizaje de los desarrolladores y propiciar un buen clima de trabajo son pilares en esta metodologa. Oficialmente fue creada en 1999 por Kent Beck, con la publicacin de su libro Extreme Programming Explained. XP se centra en la continua retroalimentacin entre el cliente y el equipo de desarrollo, la comunicacin fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. Se define como una metodologa especialmente adecuada para proyectos con requisitos muy cambiantes e imprecisos, donde existe un alto riesgo tcnico. Como metodologa pragmtica, recoge las que considera mejores prcticas para el desarrollo software, cuya aplicacin disciplinada pretende disminuir la curva exponencial del costo del cambio a lo largo del proyecto. Se trata de doce prcticas: el juego de la planificacin, entregas pequeas, metfora, diseo simple, pruebas, refactorizacin, programacin en parejas, propiedad colectiva del cdigo, integracin continua, 40 horas por semana, cliente in-situ y estndares de programacin. Una posterior revisin de la metodologa clasific las prcticas en primarias, aquellas que segn Beck proporcionan una mejora inmediata independientemente de la metodologa que se est siguiendo, y secundarias, que implican una mayor dificultad si no se tiene experiencia en las prcticas primarias. Siguiendo esta clasificacin, las prcticas primarias

consideradas fueron la adecuacin del lugar de trabajo, sentarse juntos, entorno de trabajo informativo, sentimiento de equipo, trabajo enrgico, programacin en parejas, user stories, iteraciones cortas, integracin continua, pruebas primero, diseo incremental y refactorizacin. El conjunto de prcticas secundarias qued compuesto por la involucracin del cliente, continuidad del equipo, equipos retractiles, cdigo compartido y alcance del contrato negociado. Crystal Methodologies es un conjunto de metodologas giles para equipos de diferentes tamaos y con distintas caractersticas de criticidad. Fue propulsada por uno de los padres del Manifiesto Agil, Alistair Cockburn, que consideraba que la metodologa debe adaptarse a las personas que componen el equipo utilizando polticas diferentes para equipos diferentes. Estas polticas dependern del tamao del equipo, establecindose una clasificacin por colores: Crystal Clear (3 a 8 miembros), Crystal Yellow (10 a 20 miembors), Crystal Orange (25 a 50 miembros), Crystal Red (50 a 100 miembros) y Crystal Blue (para ms de 100 miembros). Por ejemplo, Crystal Clear, la metodologa ms ligera de este conjunto, esta dirigida a la comunicacin de equipos pequeos que desarrollan software cuya criticidad no es elevada. Tiene asociadas siete caractersticas: liberacin frecuente de funcionalidad, mejora reflexiva, comunicacin osmtica, seguridad personal, atencin, fcil acceso para usuario expertos y requisitos para el entorno tcnico. Dynamic Software Development Method (DSDM) puede considerarse un marco para el proceso de produccin de software, ms que una metodologa. Naci en 1994 con el objetivo de crear una metodologa RAD (Rapid Application Development) unificada. Divide el proyecto en tres fases: pre-proyecto, ciclo de vida del proyecto y post-proyecto especificando de forma rigurosa la arquitectura y gestin del proyecto. As, propone cinco fases en el desarrollo del proyecto: estudio de la viabilidad y estudio del negocio que constituyen la etapa de pre-proyecto; y, de forma iterativa, modelado funcional, diseo y construccin y finalmente implementacin, adems de una adecuada retroalimentacin a todas las fases. Sus principales caractersticas son interaccin con el usuario, poder del equipo de desarrollo, liberaciones frecuentes de funcionalidad, regirse siguiendo las necesidades del negocio, desarrollo iterativo e incremental, adaptacin a los cambios

reversibles, fijar el nivel de alcance al comienzo del proyecto, pruebas durante todo el desarrollo y eficiente y efectiva comunicacin. Feature-driven Development Esta metodologa, ideada por Jeff De Luca y Peter Coad, combina el desarrollo dirigido por modelos con el desarrollo gil. Se centra en el diseo de un modelo inicial, cuyo desarrollo ser dividido en funcin a las caractersticas que debe cumplir el software e, iterativamente, se disear cada una de estas caractersticas. Por tanto, cada iteracin consta de dos partes, diseo e implementacin de cada caracterstica. Este tipo de metodologa est dirigido al desarrollo de aplicaciones con un alto grado de criticidad. Lean Software Development es una metodologa de desarrollo dirigida especialmente al desarrollo de sistemas cuyas caractersticas varan constantemente. Fue definida por Bob Charettes a partir de su experiencia en proyecto industriales, constituyendo una adaptacin para el desarrollo software de las lecciones aprendidas en la industria, en particular, en el sistema de produccin automovilista japonesa de 7

Toyota. La metodologa establece que todo cambio en el desarrollo software conlleva riesgos, pero si se manejan adecuadamente pueden convertirse en oportunidades que mejoren la productividad del cliente. Consta de siete principios dirigidos a gestionar los cambios: eliminacin de todo aquello que no aporte valor al negocio, conocimiento incremental, toma de decisiones tan tarde como sea posible, deliberar funcionalidad tan pronto como sea posible, poder del equipo, construccin incremental del producto y perspectiva global del proyecto. Estudios empricos de aplicacin de Metodologas giles Las metodologas giles son sin duda uno de los temas emergentes en ingeniera del software que est acaparando gran inters investigador. De hecho, estn ocupando un espacio destacado en la mayora de conferencias y workshops celebrados en los ltimos aos. Aunque algunas crticas argumentan que no son ms que viejo vino presentado en botellas nuevas7, otros estudios reflejan que el desarrollo de productos en entornos giles es muy diferente al desarrollo de productos en entornos convencionales, y que, por tanto, se necesitan estudios que indaguen en este sentido.

En lnea con este ltimo estudio, la mayor parte de las investigaciones relacionadas con las metodologas giles se centran en describir experiencias exitosas que surgen al utilizar dichas metodologas Por ejemplo, Mann y Maurer presentan un estudio del

overtime y la satisfaccin del cliente al utilizar SCRUM como metodologa de desarrollo, concluyendo que los retrasos se reducen y que tras la realizacin del estudio todos los desarrolladores recomiendan la utilizacin de SCRUM como metodologa de desarrollo. No obstante, muchos de estos estudios no proporcionan informacin suficiente sobre el contexto en el que se establece la experiencia, ni resultados cuantitativos junto a las observaciones que permitan la replicacin del estudio para validar sus conclusiones. Uno de los aspectos que ha sido estudiado con mayor inters en los ltimos aos es la productividad que permiten alcanzar las metodologas giles. En se compar la productividad de dos proyectos similares. Un equipo utiliz una metodologa tradicional y el otro XP. Encontraron que, en general, el equipo XP obtuvo una productividad 42% mayor que la del equipo tradicional. No obstante, en la primera iteracin, la productividad del equipo XP fue mucho mayor y en la ltima no hubo apenas diferencia. Dalcher et al. realizaron un experimento en el que 15 equipos desarrollaron productos software similares. Los modelos utilizados fueron: Modelo en V, Incremental, Evolutivo, y XP. La mayor diferencia recay entre los equipos que utilizaron XP y los equipos que utilizaron el Modelo en V. Los primeros tuvieron una productividad 337% mayor. No obstante escribieron 3.5 veces ms lneas de cdigo sin implementar ms funcionalidad. Al contrario que los estudios citados anteriormente, Wellington et al. encontraron un 44% menos productividad en equipos que utilizaban XP. Svensson y Host no observaron diferencia notable entre metodologas agiles y tradicionales. Publicaciones coetneas con resultados tan contradictorios reflejan claramente la necesidad de realizar nuevos estudios que permitan profundizar en este aspecto. Por otro lado, respecto al rea de ingeniera de requisitos, una de las etapas ms conflictivas en agile, an hay muy pocos estudios sobre cmo los proyectos reales que utilizan metodologas giles realizan este proceso. Ciertos detractores argumentan que las metodologas giles podran impactar negativamente en los principios de resolucin, adecuacin y veracidad de los requisitos. Por otro lado, estudios recientes comienzan a identificar y dar solucin a algunos de los problemas detectados en esta fase. Por ejemplo,

en se propone realizar una negociacin de requisitos explcita con el cliente o en incorporar una fase de especificacin de requisitos similar a la llevada a cabo en metodologas convencionales. En se propone incorporar conceptos de orientacin a aspectos y en establecer trazabilidad. En se muestra el resultado de un experimento al aplicar el proceso de Gestin de la Interaccin de Requisitos (RIM) donde se proponen modificaciones al proceso de requisitos en las metodologas giles, particularmente en eXtreme Programming. No obstante, muchos de estos artculos solicitan explcitamente la realizacin de nuevos estudios en este sentido que permitan dar nuevas y eficaces soluciones a los problemas encontrados. Finalmente, respecto a las metodologas giles analizadas en las investigacionesEste reciente estudio revisa el estado actual de la investigacin respecto a las metodologas giles. De los estudios considerados, aquellos de mayor calidad, el 76% fueron realizados utilizando XP. Metodologas como SCRUM y Lean Software Development apenas contaron con un artculo de inters cada una.

V Marco Terico Introduccin al modelo gil. El por qu de las metodologas giles Tradicionalmente se ha tendido a desarrollar software a travs de metodologas que encorsetaban el proceso de desarrollo de manera un tanto rgida que, cada vez ms, se demuestra errnea en las actuales caractersticas de dinamismo y variabilidad del mercado software. Como indica Boehm en la referencia se tiende hacia el rpido desarrollo de aplicaciones y la vida de los productos se acorta. En este entorno inestable, que tiene como factor inherente el cambio y la evolucin rpida y continua, la ventaja competitiva se encuentra en aumentar la productividad y satisfacer las variantes necesidades del cliente en el menor tiempo posible para proporcionar un mayor valor al negocio. Sin embargo, las metodologas convencionales presentan diversos problemas a la hora de abordar un amplio rango de proyectos industriales en este turbulento entorno. Entre estos problemas podemos destacar los siguientes:

Perciben la captura de requisitos del proyecto como una fase previa al desarrollo del mismo que, una vez completada, debe proporcionar una fotografa exacta de qu desea el cliente. Se trata de evitar a toda costa que se produzcan cambios en el conjunto de requisitos inicial, puesto que a medida que avanza el proyecto resulta ms costoso solucionar los errores detectados o introducir modificaciones , y pretenden delegar toda responsabilidad econmica en el cliente en caso de que estos cambios de requisitos se produzcan. Por este motivo, se les conoce tambin como metodologas predictivas. Sin embargo, el esfuerzo, tanto en coste como en tiempo, que supone hacer una captura detallada de todos los requisitos de un proyecto al comienzo del mismo es enorme y rara vez se ve justificado con el resultado obtenido. Adems, en muchas ocasiones el cliente no conoce sus propias necesidades con la profundidad suficiente como para definirlas de forma exacta a priori y, a menudo, estas necesidades y sus prioridades varan durante la vida del proyecto. Establecer mecanismos de control es una de las opciones existentes para protegerse de estos cambios, aunque frecuentemente provocan la insatisfaccin de los clientes, que perciben el desarrollo del proyecto como algo inflexible que no se adapta a sus necesidades y que si lo hace repercute negativamente en costes aadidos al presupuesto del proyecto. Por otro lado, en muchas ocasiones el proceso de desarrollo convencional est oprimido por excesiva documentacin no siempre til. Un porcentaje elevado del tiempo de desarrollo de un producto software se dedica o, desde el punto de vista de las metodologas giles, se malgasta en crear documentacin que finalmente no se utiliza y que, por tanto, no aporta valor al negocio. Adems, esta documentacin innecesaria entorpece las labores de mantenimiento de la propia documentacin til lo que provoca que en muchas ocasiones el mantenimiento de la documentacin se obvie agudizando, de este modo, el coste en las tareas de documentacin futuras. Evidentemente, estas circunstancias no se adaptan a las restricciones de tiempo del mercado actual. Otra dificultad aadida al uso de metodologas convencionales es la lentitud del proceso de desarrollo. Es difcil para los desarrolladores entender un sistema complejo en su globalidad lo que provoca que las diferentes etapas del ciclo de vida convencional transcurran lentamente. Dividir el trabajo en mdulos abordables ayuda a minimizar los fallos y, por tanto, el coste de desarrollo. Adems, permite liberar funcionalidad

progresivamente, segn indiquen los estudios de las necesidades del mercado que aportan mayor beneficio a la organizacin. En la feroz competencia del mercado vigente, en la que los productos quedan obsoletos rpidamente, se pide bsicamente rapidez, calidad y reduccin de costes, pero para asumir estos retos, es necesario tener agilidad y flexibilidad. Asimismo, las metodologas convencionales tienden a acumular los riesgos y dificultades que surgen en el desarrollo del producto al final del proyecto, repercutiendo en retrasos en la entrega de productos o influyendo en la incorrecta ejecucin de las ltimas fases del ciclo de vida. En contraposicin a las metodologas convencionales, las metodologas giles aparecen como alternativa atractiva para adaptarse a este entorno. Son apropiadas cuando los requisitos son emergentes y cambian rpidamente. De este modo, presentan diversas ventajas en el contexto actual:

Capacidad de respuesta a cambios a lo largo del desarrollo ya que no los perciben como un lastre sino como una oportunidad para mejorar el sistema e incrementar la satisfaccin del cliente, considerando la gestin de cambios como un aspecto caracterstico del propio proceso de desarrollo software. Entrega contina y en plazos breves de software funcional lo que permite al cliente verificar in situ el desarrollo del proyecto, ir disfrutando de la funcionalidad del producto progresivamente y comprobando si satisface sus necesidades, mejorando de esta forma su satisfaccin. Adems, el desarrollo en ciclos de corta duracin favorece que los riesgos y dificultades se repartan a lo largo del desarrollo del producto, principalmente al comienzo del mismo y permite ir aprendiendo de estos riesgos y dificultades Trabajo conjunto entre el cliente y el equipo de desarrollo con una comunicacin directa que pretende mitigar malentendidos, que constituyen una de las principales fuentes de errores en productos software, y exceso de documentacin improductiva. Importancia de la simplicidad, eliminando el trabajo innecesario que no aporta valor al negocio. Atencin contina a la excelencia tcnica y al buen diseo para mantener una alta calidad de los productos.

Mejora contina de los procesos y el equipo de desarrollo, entendiendo que el xito, depende de tres factores: xito tcnico, xito personal y xito organizacional.

El Manifiesto gil. Valores y principios Continuamente estamos utilizando el concepto de agilidad para definir estas metodologas, pero qu significa ser gil desde una perspectiva software? Basados en el consenso de varias definiciones contemporneas, Qumer y Henderson-Sellers ofrecieron la siguiente definicin de agilidad La agilidad es un comportamiento persistente o habilidad, de entidad sensible, que presenta flexibilidad para adaptarse a cambios, esperados o inesperados, rpidamente; persigue la duracin ms corta en tiempo; usa instrumentos econmicos, simples y de calidad en un ambiente dinmico; y utiliza los conocimientos y experiencia previos para aprender tanto del entorno interno como del externo. Por tanto, el desarrollo gil no especifica unos procesos o mtodos que seguir, aunque bien es cierto que han aparecido algunas prcticas asociadas a este movimiento. El desarrollo gil es ms bien una filosofa de desarrollo software. El punto de partida se establece en las ideas emanadas del Manifiesto gil tras la reunin de Utah , un documento que resume la filosofa agile estableciendo cuatro valores y doce principios. Segn el Manifiesto se valora: Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor de xito de un proceso software. Este primer valor expresa que es preferible utilizar un proceso indocumentado con buenas interacciones personales que un proceso documentado con interacciones hostiles. Se considera que no se debe pretender construir primero el entorno y esperar que el equipo se adapte automticamente sino al revs, construir primero el equipo y que ste configure su propio entorno. El talento, la habilidad, la capacidad de comunicacin y de tratar con personas son caractersticas fundamentales para los miembros de un equipo gil. Desarrollar software que funcione por encima de una completa documentacin. Este valor es utilizado por muchos detractores de las metodologas giles que argumentan que stas

son la excusa perfecta para aquellos que pretenden evitar las tareas menos gratificantes del desarrollo software como las tareas de documentacin. Sin embargo, el propsito de este valor es acentuar la supremaca del producto por encima de la documentacin. El objetivo de todo desarrollador es obtener un producto que funcione y cumpla las necesidades del cliente y la documentacin es un artefacto que utiliza para cumplir su objetivo. Por tanto, no se trata de no documentar sino de documentar aquello que sea necesario para tomar de forma inmediata una decisin importante. Los documentos deben ser cortos y centrarse en lo fundamental. Dado que el cdigo es el valor principal que se obtiene del desarrollo se enfatiza en seguir ciertos estndares de programacin para mantener el cdigo legible y documentado. La colaboracin con el cliente por encima de la negociacin contractual. Se propone una interaccin continua entre el cliente y el equipo de desarrollo de tal forma que el cliente forme un tndem con el equipo de desarrollo. Se pretende no diferenciar entre las figuras cliente y equipo de desarrollo sino que se apuesta por un solo equipo persiguiendo un objetivo comn. Responder a los cambios ms que seguir estrictamente un plan. Planificar el trabajo a realizar es muy til y las metodologas giles consideran actividades especficas de planificacin a corto plazo. No obstante, adaptarse a los cambios es vital en la industria software actual y, por tanto, tambin consideran mecanismos para tratar los cambios de prioridades. La regla es planificar es til. Seguir un plan es til hasta que el plan se distancia de la situacin actual. Pender de un plan desactualizado es caminar por un callejn sin salida. Para cumplir estos valores se siguen doce principios que establecen algunas diferencias entre un desarrollo gil y uno convencional: 1. La prioridad es satisfacer al cliente mediantes tempranas y continuas entregas de software que le aporten valor. 2. Dar la bienvenida a los cambios de requisitos. Se capturan los cambios para que el cliente tenga una ventaja competitiva. 3. Liberar software que funcione frecuentemente, desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas.

4. Los miembros del negocio y los desarrolladores deben trabajar juntos diariamente a lo largo del proyecto. 5. Construir el proyecto en torno a individuos motivados. Darles el entorno y apoyo que necesiten y confiar a en ellos para conseguir finalizar el trabajo. 6. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro de un equipo de desarrollo. 7. El software que funciona es la principal medida de progreso. 8. Los procesos giles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberan ser capaces de mantener una paz constante. 9. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. 10. La simplicidad es esencial. 11. Las mejores arquitecturas, requisitos y diseos surgen de los equipos que se auto organizan. 12. En intervalos regulares el equipo debe reflexionar sobre cmo ser ms efectivo y segn estas reflexiones ajustar su comportamiento.

Estos principios marcan el ciclo de vida de un desarrollo gil, as como las prcticas y procesos a utilizar. Cmo ser gil. Algunas prcticas Aunque el movimiento gil est sustentado por valores y principios para el desarrollo de productos software, la mayora de estas metodologas tienen asociadas un conjunto de prcticas, en muchos casos comunes, que buscan la agilidad en el desarrollo. En esta seccin vamos a analizar algunas de las ms relevantes: planificacin, programacin en parejas o pair programming, integracin continua, refactorizacin y desarrollo dirigido por pruebas (Test Driven Development). Planificacin, Historias de usuario. Mientras que las metodologas convencionales centran la ingeniera de requisitos en habilidades de prediccin basndose en frreas planificaciones previas al desarrollo, las metodologas giles perciben la gestin de cambios como un aspecto inherente al proceso

de desarrollo software, considerando planificaciones continuas, ms flexibles y en cortos plazos, que respondan mejor a los cambios en las necesidades del cliente. Con el objetivo de disminuir el coste, no siempre amortizable, que supone la etapa de planificacin en las metodologas convencionales, las giles simplifican las tareas de gestin y documentacin de las necesidades del sistema. Apuestan por involucrar de una forma ms intensa al cliente a lo largo de todo el proceso de desarrollo, de forma que, la comunicacin directa y frecuente retroalimentacin son las prcticas ms importantes para la planificacin y especificacin de requisitos en estas metodologas. En este proceso de definicin de las necesidades del sistema que guiar el desarrollo, se utilizan las llamadas historias de usuario para detallar, en un lenguaje cercano al cliente, la funcionalidad que debe satisfacer el sistema. Las historias de usuario se descomponen en tareas que debern ser realizadas para cumplir con la funcionalidad que se solicita. Ntese que la estimacin de tiempo no es una restriccin fija, simplemente constituye una aproximacin inicial. Se considera que las historias de usuario deben cumplir seis caractersticas: comprobables. Programacin en pareja (Pair Programming). Una de las prcticas ms utilizadas en metodologas giles, sobre todo en sistemas de alta complejidad, es la programacin en parejas, que establece que la produccin de cdigo se realice con trabajo en parejas de programadores. El utilizar Pair Programming en un proyecto no implica que todas las lneas de cdigo sean escritas por una pareja, ya que mientras una persona est escribiendo el cdigo, la otra puede estar verificando errores, pensando en alternativas mejores, identificando casos de prueba, pensando en aspectos de diseo, etc. El objetivo principal de esta tcnica es disminuir la tasa de errores, mejorar el diseo y aspectos como la satisfaccin de los programadores. No obstante, algunos estudios indican que se trata de una tcnica intensa y estresante para los propios programadores, aunque admiten que acelera el proceso de desarrollo. Otro detalle a tener en cuenta es las habilidades y capacidades de los miembros de la pareja. Si existe una diferencia importante entre ellos, puede llegar a ser una prctica frustrante independientes, negociables, valorables, estimables, pequeas y

para ambos. En este caso concreto, el Pair Programming ha de ser visto como una tcnica de aprendizaje. Integracin continua (Countinuous integration) La integracin continua pretende mitigar la complejidad que el proceso de integracin suele tener asociada en las metodologas convencionales, superando, en determinadas circunstancias, la propia complejidad de la codificacin. El objetivo es integrar cada cambio introducido, de tal forma que pequeas piezas de cdigo sean integradas de forma continua, ya que se parte de la base de que cuanto ms se espere para integrar ms costoso e impredecible se vuelve el proceso. As, el sistema puede llegar a ser integrado y construido varias veces en un mismo da. Para que esta prctica sea viable es imprescindible disponer de una batera de test, preferiblemente automatizados, de tal forma, que una vez que el nuevo cdigo est integrado con el resto del sistema se ejecute toda la batera de pruebas. Si son pasados todos los test del sistema, se procede a la siguiente tarea. En caso contrario, aunque no falle el nuevo modulo que se quiere introducir en el sistema, se ha de regresar a la versin anterior, pues sta ya haba pasado la batera de pruebas. Refactorizacin. Actividad constante en los desarrollos giles cuyo objetivo es mejorar el diseo de un sistema sin influir en su funcionalidad. Se pretende reestructurar el cdigo para eliminar duplicaciones, mejorar su legibilidad, simplificarlo y hacerlo ms flexible de forma que se faciliten los posteriores cambios. Recordemos que el cdigo que funciona es el principal aporte de valor para las metodologas giles, por encima de la documentacin, por lo que se enfatiza en que ste sea legible y permita la comunicacin entre desarrolladores. Desarrollo dirigido por pruebas (Test Driven Development). Al utilizar esta prctica la produccin de cdigo est dirigida por las pruebas. Concretamente, se trata de escribir las pruebas que validarn el sistema antes de comenzar a construirlo, idealmente que sea el propio cliente quien las escriba. De esta forma, ante cada modificacin del sistema la batera completa de pruebas es ejecutada. Esta prctica

constituye, por tanto, la primera lnea para garantizar la calidad del producto, pues sta se considera en trminos de la correcta funcionalidad que se le ofrece al cliente. Entre las ventajas que aporta el desarrollo dirigido por pruebas podemos destacar que disminuye el tiempo dedicado a solucionar errores y genera un sentimiento de confianza de xito del proyecto en el equipo. Tecnologas como JUnit son utilizadas para manejar y ejecutar conjuntos de pruebas automatizadas. No obstante, el hecho de que aspectos tan importantes como la cohesin o el acoplamiento de los mdulos pase a un segundo plano en el desarrollo a favor de la funcionalidad, implica la necesidad de realizar constantes etapas de refactorizacin que permitan mantener la calidad del cdigo. Como se puede apreciar, a pesar de la reciente aplicacin de las metodologas giles la mayora de las prcticas propuestas no so novedosas sino que de alguna manera ya haban sido propuestas en ingeniera del software. El mrito de las metodologas giles es proponer una aplicacin conjunta, equilibrada y efectiva de forma que se complementen con ideas desde la perspectiva del negocio, los valores humanos y el trabajo SCRUM SCRUM es el trmino que describe una forma para desarrollar productos iniciada en Japn. No se trata de un concepto nuevo, sino que ya en 1987 Ikujiro Nonaka y Hirotaka Takeuchi acuaron este trmino, una estrategia utilizada en rugby en la que todos los integrantes del equipo actan juntos para avanzar la pelota y ganar el partido, para denominar un nuevo tipo de proceso de desarrollo de productos. Escogieron este nombre por las similitudes que consideraban que existan entre el juego del rugby y el tipo de proceso que proponan: adaptable, rpido, auto-organizable y con pocos descansos. SCRUM es un proceso para la gestin y control del producto que trata de eliminar la complejidad en estas reas para centrarse en la construccin de software que satisfaga las necesidades del negocio. Es simple y escalable, ya que no establece prcticas de ingeniera del software sino que se aplica o combina, fcilmente, con otras prcticas ingenieriles, metodologas de desarrollo o estndares ya existentes en la organizacin. SCRUM se concentra, principalmente, a nivel de las personas y equipo de desarrollo que construye el producto. Su objetivo es que los miembros del equipo trabajen juntos y de

forma eficiente obteniendo productos complejos y sofisticados. Podramos entender SCRUM como un tipo de ingeniera social que pretende conseguir la satisfaccin de todos los que participan en el desarrollo, fomentando la cooperacin a travs de la autoorganizacin. De esta forma se favorece la franqueza entre el equipo y la visibilidad del producto. Pretende que no haya problemas ocultos, asuntos u obstculos que puedan poner en peligro el proyecto. Los equipos se guan por su conocimiento y experiencia ms que por planes de proyecto formalmente definidos. La planificacin detallada se realiza sobre cortos espacios de tiempo lo que permite una constante retroalimentacin que proporciona inspecciones simples y un ciclo de vida adaptable. As, el desarrollo de productos se produce de forma incremental y con un control emprico del proceso que permite la mejora continua Independientemente del tipo de metodologa que se utilice, cualquier desarrollo software parte siempre de un mismo problema: conocer las necesidades de los clientes. SCRUM, al igual que el resto de metodologas giles, pretende no centrar las tareas de desarrollo en un conjunto de requisitos formalmente definidos sino que aboga por la incorporacin del cliente como un miembro ms del equipo de desarrollo. De este modo, no se considera el proceso de definicin de requisitos como un fin dentro del desarrollo del proyecto, sino que los requisitos aparecen implcitamente dentro del contenido de las denominadas historias de usuario. Las historias de usuario son el elemento base que utiliza SCRUM para describir las caractersticas que el usuario espera que tenga el software que se va a desarrollar . Por lo tanto, pueden incorporar tanto cuestiones relacionadas con las funciones del sistema como con cualquier otro aspecto del mismo (restricciones, rendimiento, etc.). Las historias de usuario se presentan desde la perspectiva del usuario. As, no se describen utilizando una terminologa tcnica sino que se escriben utilizando un lenguaje cercano al dominio de la aplicacin que se est desarrollando de forma que sea comprensible por los clientes y por los desarrolladores. Las historias de usuario se construyen bajo un mismo esqueleto que centra el foco de las caractersticas del producto. - Primero se determina quin propone la historia de usuario, - Luego se describe la caracterstica que se cubre con la historia de usuario y

- Finalmente se especifica la razn por la que dicha caracterstica es necesaria. El proceso comienza con la fase de Pre-game, en la que se realiza de forma conjunta con el cliente una definicin sencilla y clara de las caractersticas que debe tener el sistema que vaya a ser desarrollado, definiendo las historias de usuario que van a guiar el proceso de desarrollo. Posteriormente, cada historia de usuario se refina de manera que se identifican las tareas que son necesarias para llevar a cabo el desarrollo de la historia de usuario. En un principio no es necesario detallar de forma completa todas las historias de usuario sino slo las que tienen un mayor nivel de prioridad por parte del usuario. Esto permite que el proceso de desarrollo pueda adaptarse a posteriores modificaciones de las necesidades de usuario, de forma que el proceso de desarrollo se vuelve ms flexible. El resultado de esta fase de Pre-game es lo que se denomina en SCRUM Product Backlog, que contiene una lista de todas las historias de usuario priorizadas as como de las tareas que se deben llevar a cabo para la realizacin del proyecto. Este enfoque basado en quin, qu y por qu facilita la tarea de priorizacin de las historias de usuario, lo que permite realizar la planificacin inicial del proyecto. Como puede deducirse de lo anteriormente expuesto, la obtencin del Product Backlog se realiza con la ayuda del cliente/usuario del sistema que se va a desarrollar, por lo que puede considerarse que se realiza en directo y, por lo tanto, las posibles dudas en el establecimiento de las historias de usuario pude resolverse en ese mismo instante. Una vez identificadas y priorizadas las historias de usuario del Product Backlog, se realiza la separacin de historias de usuario en etapas de corta duracin (no ms de 30 das) denominadas sprints. Para cada sprint se realiza una reunin de planificacin de lo que se va a llevar a cabo en ese sprint y se establece la fecha de finalizacin del mismo. El objetivo es mover aquellas historias de usuario con mayor prioridad para el cliente al denominado Sprint Backlog, que contiene el conjunto de tareas a desarrollar en ese sprint, incluyendo diseo, desarrollo, pruebas, integracin, etc. Las historias de usuario. se congelan en el Sprint Backlog de forma que durante dicho periodo no puedan producirse cambios sobre los aspectos que se encuentran en fase de desarrollo.

De forma iterativa, todos los das que dure el sprint, se realiza una reunin operativa, informal y gil con el equipo de desarrollo, de un mximo de quince minutos, en la que a cada integrante del equipo se le hacen tres preguntas: - Qu tareas ha hecho desde la ltima reunin? Es decir, tareas realizadas en un da. - Qu tareas va ha hacer hoy? - Que ayuda necesita para poder realizar este trabajo? Es decir, identificacin de obstculos o riesgos que impiden o pueden impedir el normal avance. Una vez finalizado el sprint se debera obtener parte del producto, un entregable o algo que se pueda mostrar y que ensee los avances acometidos en el Sprint. En este punto se procede a una fase de revisin del proyecto para mostrar dichos avances e incorporar, si fuera necesario, nuevas historias de usuario al Product Backlog. Para mantener la calidad del producto se establece que una historia de usuario est 100% completa si supera los test unitarios, pasa las pruebas de aceptacin, supera los test adicionales para mantener la calidad del producto, el cdigo est construido e integrado satisfactoriamente, est basado en un diseo factorizado sin duplicaciones, el cdigo es claro, estructurado y autodocumentado y, por supuesto, es aceptado por el cliente. Adems, tras la realizacin de cada sprint se lleva a cabo una reunin retrospectiva que permite aprender de los conocimientos y experiencias adquiridas hasta el momento y mejorar de forma continua el proceso de desarrollo. Se revisar con el equipo los objetivos marcados inicialmente en el Sprint Backlog concluido, se aplicarn los cambios y ajustes si son necesarios, y se marcarn los aspectos positivos (para repetirlos) y los aspectos negativos (para evitar que se repitan) del Sprint, que servirn de retroalimentacin para el siguiente sprint. Los elementos que servirn de entrada y guiarn la planificacin de un nuevo sprint sern el Product Backlog, las capacidades o habilidades del equipo, las condiciones que en ese momento se den del negocio, el avance tecnolgico que se haya podido producir y el incremento que se pretenda hacer al producto que se est desarrollando. De esta forma, en contraposicin con las metodologas convencionales, el proceso de desarrollo adquiere flexibilidad, agilidad y capacidad para adaptarse a su entorno.

Para orquestar este proceso SCRUM distingue distintos actores con diferentes papeles dentro del proceso. De forma general, podemos distinguir propietario del producto Product Owner, maestro de scrum Scrum Master, equipo de desarrollo Scrum Team y cliente o usuario. El Product Owner es la nica persona encargada de la direccin y control del Product Backlog, es decir, de las historias de usuario que debe cumplir el sistema. Se trata de una persona fsica (solamente una persona para eliminar las posibles confusiones o interferencias), no una organizacin o comit. Bien puede ser el propio cliente in situ en el lugar de desarrollo u otra persona que tenga el conocimiento suficiente sobre el producto o pueda estar en continuo contacto con el cliente para marcar las prioridades del proyecto. Es, por tanto, la persona oficialmente responsable del proyecto que de forma visible, vocal y objetiva debe tomar todas las decisiones de negocio para el producto. Para que el Product Owner tenga xito, el resto del equipo de la organizacin tiene que respetar sus decisiones. En cuanto a su implicacin debe estar en contaste interaccin con el equipo de desarrollo. Debe asistir, al menos, a las reuniones de planificacin y de revisin de cada sprint y estar en continuo contacto con el equipo para proporcionar detalles sobre las historias de usuario y constante retroalimentacin que dirija el desarrollo del sprint. El Scrum Master es la persona responsable del xito al aplicar la metodologa SCRUM en el desarrollo del proyecto o producto, asegurando que los valores, prcticas y reglas son seguidos por el resto del equipo. En concreto, es la persona que asegura el seguimiento de la metodologa guiando las reuniones, ayudando al equipo ante cualquier problema que pueda aparecer y controlando que el trabajo sigua el ritmo adecuado. Por tanto debe tomar decisiones inmediatas y eliminar los impedimentos que vayan surgiendo en el momento, aunque en ocasiones no cuente con toda la informacin necesaria. Su responsabilidad es entre otras, la de hacer de paraguas ante las presiones externas y motivar al resto del equipo. Por tanto, la labor de Scrum Master requiere una fuerte personalidad ya que debe facilitar el trabajo del equipo sin imponer autoridad. Las personas que ejercen este role deben ser capaces de hacer cualquier cosa por ayudar al equipo de desarrollo, incluso aunque estas acciones estn enfrentadas con sus propios intereses. Deben ser personas poco conformistas y con mucha iniciativa. Eliminar impedimentos requiere determinacin y tenacidad. La metfora utilizada por Kent Beck refleja perfectamente este papel: El Scrum

Master es el perro pastor que hace cualquier cosa para proteger al rebao, y nunca se distrae de su deber. El Scrum Team lo conforman las personas responsables de implementar la funcionalidad o funcionalidades elegidas por el Product Owner. Debe ser un conjunto de personas motivadas con habilidades y capacidades complementarias que estn comprometidos por un propsito comn, cumplir el objetivo del sprint. El equipo tiene plena autoridad para tomar todas las decisiones que consideren adecuadas en el desarrollo del proyecto, auto-organizndose y auto-disciplinndose. As, por ejemplo, en las reuniones de planificacin el Product Owner y el Scrum Team deben llegar a un acuerdo realista sobre las historias de usuario que se van a completar en el siguiente sprint y si en algn momento el Scrum Team considera que algunas de las prioridades del Product Owner no es razonable dispone de libertad absoluta para resear esta circunstancia y obligar al propietario del producto a variar sus prioridades. Tericamente, se estima que debera estar formado por un nmero de entre 7 u 8 miembros como mximo y 2 como mnimo. Finalmente, el cliente es o son los beneficiarios finales del producto, y quienes viendo los progresos, pueden aportar ideas, sugerencias o necesidades. Su participacin es importantsima e imprescindible en esta metodologa. La efectividad de la metodologa para la gestin de proyectos se basa en un conjunto de valores fundamentales que deben seguir todos los integrantes del equipo, principios sobre los que reposan el resto de prcticas: compromiso, esmero, franqueza, respeto y valor. Los miembros del equipo deben estar dispuestos a comprometerse con el objetivo de cada sprint y del proyecto en general. SCRUM proporciona al equipo toda la autoridad que necesiten para obtener a cambio su compromiso. El equipo se tiene que comprometer a hacer su trabajo. Cada miembro debe concentrar todos sus esfuerzos y habilidades en cumplir con el trabajo que se han comprometido a realizar sin desviarse en otros aspectos, realizando todas sus labores con esmero. Todos los aspectos del proyecto son visibles para todo el equipo por lo que un valor fundamental es tambin la franqueza. Adems, los miembros del equipo estn avalados por sus conocimientos y experiencias, el respeto es un valor fundamental con cada uno de ellos. Finalmente, cada miembro del equipo tiene que tener el coraje suficiente para comprometerse, actuar, ser transparente en el desarrollo y respetar y hacer que le respeten.

Una revisin de otras metodologas giles Aunque el manifiesto gil es la piedra angular sobre la que cimientan todas las metodologas giles, cada una tiene unas caractersticas propias y hace hincapi en algunos aspectos ms especficos. En esta seccin se describen, a grandes rasgos, las particularidades fundamentales de algunas otras metodologas giles, que actualmente tienen gran aceptacin en el mercado, como eXtreme Programming, Cristal, Dynamic Software Development Method (DSDM), Feature-driven Development y Lean Software Development. eXtreme Programming tambin conocida como XP, es una metodologa gil

centrada en potenciar las relaciones interpersonales como clave para el xito en desarrollo software. Aspectos como el trabajo en equipo, el aprendizaje de los desarrolladores y propiciar un buen clima de trabajo son pilares en esta metodologa. Oficialmente fue creada en 1999 por Kent Beck, con la publicacin de su libro Extreme Programming Explained. XP se centra en la continua retroalimentacin entre el cliente y el equipo de desarrollo, la comunicacin fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. Se define como una metodologa especialmente adecuada para proyectos con requisitos muy cambiantes e imprecisos, donde existe un alto riesgo tcnico. Como metodologa pragmtica, recoge las que considera mejores prcticas para el desarrollo software, cuya aplicacin disciplinada pretende disminuir la curva exponencial del costo del cambio a lo largo del proyecto. Se trata de doce prcticas: el juego de la planificacin, entregas pequeas, metfora, diseo simple, pruebas, refactorizacin, programacin en parejas, propiedad colectiva del cdigo, integracin continua, 40 horas por semana, cliente in-situ y estndares de programacin. Una posterior revisin de la metodologa clasific las prcticas en primarias, aquellas que segn Beck proporcionan una mejora inmediata independientemente de la metodologa que se est siguiendo, y secundarias, que implican una mayor dificultad si no se tiene experiencia en las prcticas primarias. Siguiendo esta clasificacin, las prcticas primarias consideradas fueron la adecuacin del lugar de trabajo, sentarse juntos, entorno de trabajo informativo, sentimiento de equipo, trabajo enrgico, programacin en parejas, user stories, iteraciones cortas, integracin continua, pruebas primero, diseo incremental y

refactorizacin. El conjunto de prcticas secundarias qued compuesto por la involucracin del cliente, continuidad del equipo, equipos retractiles, cdigo compartido y alcance del contrato negociado. Crystal Methodologies es un conjunto de metodologas giles para equipos de diferentes tamaos y con distintas caractersticas de criticidad. Fue propulsada por uno de los padres del Manifiesto Agil, Alistair Cockburn, que consideraba que la metodologa debe adaptarse a las personas que componen el equipo utilizando polticas diferentes para equipos diferentes. Estas polticas dependern del tamao del equipo, establecindose una clasificacin por colores: Crystal Clear (3 a 8 miembros), Crystal Yellow (10 a 20 miembors), Crystal Orange (25 a 50 miembros), Crystal Red (50 a 100 miembros) y Crystal Blue (para ms de 100 miembros). Por ejemplo, Crystal Clear, la metodologa ms ligera de este conjunto, esta dirigida a la comunicacin de equipos pequeos que desarrollan software cuya criticidad no es elevada. Tiene asociadas siete caractersticas: liberacin frecuente de funcionalidad, mejora reflexiva, comunicacin osmtica, seguridad personal, atencin, fcil acceso para usuario expertos y requisitos para el entorno tcnico. Dynamic Software Development Method (DSDM) puede considerarse un marco para el proceso de produccin de software, ms que una metodologa. Naci en 1994 con el objetivo de crear una metodologa RAD (Rapid Application Development) unificada. Divide el proyecto en tres fases: pre-proyecto, ciclo de vida del proyecto y post-proyecto especificando de forma rigurosa la arquitectura y gestin del proyecto. As, propone cinco fases en el desarrollo del proyecto: estudio de la viabilidad y estudio del negocio que constituyen la etapa de pre-proyecto; y, de forma iterativa, modelado funcional, diseo y construccin y finalmente implementacin, adems de una adecuada retroalimentacin a todas las fases. Sus principales caractersticas son interaccin con el usuario, poder del equipo de desarrollo, liberaciones frecuentes de funcionalidad, regirse siguiendo las necesidades del negocio, desarrollo iterativo e incremental, adaptacin a los cambios reversibles, fijar el nivel de alcance al comienzo del proyecto, pruebas durante todo el desarrollo y eficiente y efectiva comunicacin. Feature-driven Development Esta metodologa, ideada por Jeff De Luca y Peter Coad, combina el desarrollo dirigido por modelos con el desarrollo gil. Se centra en el

diseo de un modelo inicial, cuyo desarrollo ser dividido en funcin a las caractersticas que debe cumplir el software e, iterativamente, se disear cada una de estas caractersticas. Por tanto, cada iteracin consta de dos partes, diseo e implementacin de cada caracterstica. Este tipo de metodologa est dirigido al desarrollo de aplicaciones con un alto grado de criticidad. Lean Software Development es una metodologa de desarrollo dirigida especialmente al desarrollo de sistemas cuyas caractersticas varan constantemente. Fue definida por Bob Charettes a partir de su experiencia en proyecto industriales, constituyendo una adaptacin para el desarrollo software de las lecciones aprendidas en la industria, en particular, en el sistema de produccin automovilista japonesa de 7

Toyota. La metodologa establece que todo cambio en el desarrollo software conlleva riesgos, pero si se manejan adecuadamente pueden convertirse en oportunidades que mejoren la productividad del cliente. Consta de siete principios dirigidos a gestionar los cambios: eliminacin de todo aquello que no aporte valor al negocio, conocimiento incremental, toma de decisiones tan tarde como sea posible, deliberar funcionalidad tan pronto como sea posible, poder del equipo, construccin incremental del producto y perspectiva global del proyecto. Estudios empricos de aplicacin de Metodologas giles Las metodologas giles son sin duda uno de los temas emergentes en ingeniera del software que est acaparando gran inters investigador. De hecho, estn ocupando un espacio destacado en la mayora de conferencias y workshops celebrados en los ltimos aos. Aunque algunas crticas argumentan que no son ms que viejo vino presentado en botellas nuevas7, otros estudios reflejan que el desarrollo de productos en entornos giles es muy diferente al desarrollo de productos en entornos convencionales, y que, por tanto, se necesitan estudios que indaguen en este sentido. En lnea con este ltimo estudio, la mayor parte de las investigaciones relacionadas con las metodologas giles se centran en describir experiencias exitosas que surgen al utilizar dichas metodologas Por ejemplo, Mann y Maurer presentan un estudio del

overtime y la satisfaccin del cliente al utilizar SCRUM como metodologa de desarrollo,

concluyendo que los retrasos se reducen y que tras la realizacin del estudio todos los desarrolladores recomiendan la utilizacin de SCRUM como metodologa de desarrollo. No obstante, muchos de estos estudios no proporcionan informacin suficiente sobre el contexto en el que se establece la experiencia, ni resultados cuantitativos junto a las observaciones que permitan la replicacin del estudio para validar sus conclusiones. Uno de los aspectos que ha sido estudiado con mayor inters en los ltimos aos es la productividad que permiten alcanzar las metodologas giles. En se compar la productividad de dos proyectos similares. Un equipo utiliz una metodologa tradicional y el otro XP. Encontraron que, en general, el equipo XP obtuvo una productividad 42% mayor que la del equipo tradicional. No obstante, en la primera iteracin, la productividad del equipo XP fue mucho mayor y en la ltima no hubo apenas diferencia. Dalcher et al. realizaron un experimento en el que 15 equipos desarrollaron productos software similares. Los modelos utilizados fueron: Modelo en V, Incremental, Evolutivo, y XP. La mayor diferencia recay entre los equipos que utilizaron XP y los equipos que utilizaron el Modelo en V. Los primeros tuvieron una productividad 337% mayor. No obstante escribieron 3.5 veces ms lneas de cdigo sin implementar ms funcionalidad. Al contrario que los estudios citados anteriormente, Wellington et al. encontraron un 44% menos productividad en equipos que utilizaban XP. Svensson y Host no observaron diferencia notable entre metodologas agiles y tradicionales. Publicaciones coetneas con resultados tan contradictorios reflejan claramente la necesidad de realizar nuevos estudios que permitan profundizar en este aspecto. Por otro lado, respecto al rea de ingeniera de requisitos, una de las etapas ms conflictivas en agile, an hay muy pocos estudios sobre cmo los proyectos reales que utilizan metodologas giles realizan este proceso. Ciertos detractores argumentan que las metodologas giles podran impactar negativamente en los principios de resolucin, adecuacin y veracidad de los requisitos. Por otro lado, estudios recientes comienzan a identificar y dar solucin a algunos de los problemas detectados en esta fase. Por ejemplo, en se propone realizar una negociacin de requisitos explcita con el cliente o en incorporar una fase de especificacin de requisitos similar a la llevada a cabo en metodologas convencionales. En se propone incorporar conceptos de orientacin a aspectos y en establecer trazabilidad. En se muestra el resultado de un experimento al aplicar el proceso

de Gestin de la Interaccin de Requisitos (RIM) donde se proponen modificaciones al proceso de requisitos en las metodologas giles, particularmente en eXtreme Programming. No obstante, muchos de estos artculos solicitan explcitamente la realizacin de nuevos estudios en este sentido que permitan dar nuevas y eficaces soluciones a los problemas encontrados. Finalmente, respecto a las metodologas giles analizadas en las investigacionesEste reciente estudio revisa el estado actual de la investigacin respecto a las metodologas giles. De los estudios considerados, aquellos de mayor calidad, el 76% fueron realizados utilizando XP. Metodologas como SCRUM y Lean Software Development apenas contaron con un artculo de inters cada una.
VI OBJETIVOS Como ya sabemos un equipo de trabajo es un grupo de personas organizadas, que trabajan juntas para
lograr una meta, en el contexto de desarrollo de sistemas, la meta seria desarrollar software de calidad por medio de una buena metodologa para formar grupos de trabajo que se desarrollen de una manera ms eficiente. Nuestro objetivo general en este trabajo de investigacin es crear un mtodo adecuado a las necesidades especficas de equipos de trabajo en el contexto especfico de desarrollo de software para incrementar la productividad en el desarrollo de las aplicaciones de software Los objetivos especficos o secundarios de la misma investigacin son los siguientes: Reducir el tiempo de desarrollo de los sistemas. Ordenar los procesos implicados en el desarrollo de sistemas. La correcta documentacin de cada proyecto. Mejorar los precios y costos. Mejorar la calidad del producto.

JUSTIFICACION La aplicacin del mtodo de desarrollo servir para imponer orden en el trabajo de desarrollo y evitar la prdida as como el exceso de documentacin. As mismo, para mantener respaldos controlados y actualizados del desarrollo que se encuentra en produccin. La implementacin de un mtodo de desarrollo gil, especfico para equipos pequeos, permitir a las empresas de desarrollo de software aproximarse a una solucin de una manera distinta en la creacin de sistemas, la cual dejar abierta la posibilidad de cambio. Esto, a su vez, reducir el tiempo de desarrollo y por lo tanto el costo de las aplicaciones.

IMPACTO

El software es parte de la vida actual, evoluciona velozmente mas de lo que nos podemos imaginar, de ah la importancia de las empresas desarrolladoras de software, y mas aun de las metodologas agiles. Estamos en el apogeo de la revolucin informtica esta empez a mediados de siglo XX, los clientes quieren ideas nuevas, frescas quieren nuevo software, y no hay mejor manera de desarrollar un software para el cliente que con las metodologas agiles. Son muy poco usadas actualmente, pero eso no significa que no sean efectivas.

METODOLOGIAS A UTILIZAR

La metodologa propuesta se desagrega por etapas, una propuesta conforme a una serie de pasos: Eleccin del tema: El tema fue seleccionado ya que se a probado que las metodologas agiles para desarrollar software son eficientes y su funcionamiento es correcto sin embargo en Mexico no se a implementado este tipo de metodologas a pesar de cmo ya se dijo son muy eficientes. Planteamiento del problema: El desarrollo de software suele ser muy complejo en algunos casos, encontrar un buen equipo de trabajo y que trabajen eficientemente en conjunto puede llegar a ser muy difcil, desarrollar un software que no contenga fallas y que se adecue perfectamente a las necesidades del cliente puede ser casi imposible; es por eso que se comenzaron a utilizar las metodologas agiles para el desarrollo de software las cuales optimizan el desarrollo del software para poder resolver o al menos hacer ms eficiente el trabajo del equipo de desarrolladores y as poder desarrollar un software ms eficiente y sin menos fallos. Recopilacin de datos: Entre los datos mas relevantes para desarrollar software se encuentran: las interacciones del equipo de desarrollo sobre el proceso y las herramientas, Desarrollar software que funcione por encima de una completa documentacin, La colaboracin con el cliente por encima de la negociacin contractual, Responder a los cambios ms que seguir estrictamente un plan. Anlisis e interpretacin de datos: Se concluy con los datos recabados que hay 12 principios que diferencian una metodologa agil de una convencional:

1. La prioridad es satisfacer al cliente mediantes tempranas y continuas entregas de software que le aporten valor. 2. Dar la bienvenida a los cambios de requisitos. Se capturan los cambios para que el cliente tenga una ventaja competitiva. 3. Liberar software que funcione frecuentemente, desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. 4. Los miembros del negocio y los desarrolladores deben trabajar juntos diariamente a lo largo del proyecto. 5. Construir el proyecto en torno a individuos motivados. Darles el entorno y apoyo que necesiten y confiar a en ellos para conseguir finalizar el trabajo. 6. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro de un equipo de desarrollo. 7. El software que funciona es la principal medida de progreso. 8. Los procesos giles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberan ser capaces de mantener una paz constante. 9. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. 10. La simplicidad es esencial. 11. Las mejores arquitecturas, requisitos y diseos surgen de los equipos que se auto organizan. 12. En intervalos regulares el equipo debe reflexionar sobre cmo ser ms efectivo y segn estas reflexiones ajustar su comportamiento. Formulacin de recomendaciones e implantacin. Dicho marco permite identificar claramente los factores bajo estudio y analizar en forma ordenada y sistemtica sus componentes del modo ms racional utilizando las tcnicas ms adecuadas. Se determino la metodologa a seguir de la investigacin despus de un anlisis y examinacin de las etapas propuestas por varios autores expertos en la materia los cules se presentan en el marco metodolgico y de acuerdo a estas propuestas y a las caractersticas del estudio.
CRONOGRAMA DE ACTIVIDADES

Actividades Enero Febrero Marzo Abril Mayo Junio Definicin de Tema 20-28 Recolectar Informacin 26 10 Seleccin del material 10-30 Envi de la primera parte del ante proyecto 7 Envi de la segunda parte del ante proyecto 14 Envi de la tercera parte del ante proyecto 30 Envi de la cuarta parte del ante proyecto 26 Envi de la quinta parte del ante proyecto 3 Envi de la sexta parte del ante proyecto 10 Envi de la sptima parte del ante proyecto 17 Envi de la octava parte del ante proyecto 24 Exposicin del ante proyecto 31

References
1.Ishii, H., Kobayashi, M., Arita, K., and Yagi, T (1997) Iterative design of seamless collaboration media. en K. Finn, A. J. Sellen, y S. B. Wilbur, Comunicacion por medio de videollamada. Mahwah, NJ: Lawrence Erlbaum Associates. p.435-456. 2.Johnson, J., CHAOS: The dollar drain of IT project failures, Hilos en el desarrollo de aplicaciones, 1995, p. 41-44. 3.Jones, C., (1996) Applied Software Measurement: Assuring Productivity and Quality, McGraw-Hill Book Co., New York. 4 .Sun Journal (1999) How to jump-start Java computing Initiatives. November 5, 1999. Solia estar Disponible en: http://www.sun.com/SunJournal/v1n4/global2.html 5.Kraut, R.E. and Streeter, L.A. (1995) Coordination in Large Scale Software Development, Comunicaciones del ACM, (38:7), pp.69-81.. 1. Albrecht, A., y Gaffney, J. (1983) "Software Function, Source Lines of code, and Development Effort Prediction: A Software Science Validation," IEEE Transactions on Software Engineering, Noviembre, p. 639-647. 2. Allen, T. J. (1977) Managing the Flow of Technology: Technology Transfer and the Dissemination of Technological Information Within the R&D Organization. : MIT Press, Cambridge, MA.

3. Banker, R. D., Datar, S., Kemerer, C. F., and Zweig, D. (1993) "Software complexity and software maintenance costs," Comunicacion del ACM, (36), Noviembre, p. 81-93. 4. Barstow, D., (1987) Artificial Intelligence and Software Engineering, Procedimientos de la Novena Conferencia Internacional de la Ingenieria de Software, p. 541-561. 5. Boehm, B. W. (1981) Software Engineering Economics, Prentice-Hall, Inc., NJ. 6. Brinck, T. and Gomez, L (1992) A collaborative medium for the support of conversational props. CSCW92. 7. Covi, L. M., Olson, J. S., y Rocco, E. (1998) A room of your own: What do we learn about support of teamwork from assessing teams in dedicated project rooms? (Eds.) Cooperative Buildings. Amsterdam: SpringerVerlag. p. 53-65. 8. Damm, C. H., Hansen, K. M., Thomsen, M. (2000) Tool support for cooperative object-oriented design: Gesture based modeling on an electronic whiteboard. Procedimientos de CHI'2000, p. 518-525. 9. Engestrom, Y., and Middleton, D.(1996) Cognition and Communication at Work. Cambridge University Press, Cambridge. 10.Fish, R. S., Kraut, R. E., Root, R., & Rice, R. E. (1993) Video as a technology for informal communication. Communications of the ACM, p. 36, 8-61. 11.Gibbs, W. W. (1994) Softwares chronic crisis, Cientifico Americacno, Septiembre, p. 86-95 . 12.Giglio, C. M. (1999) Business is war, but you can fight back with a killer.a virtual war room. Infoworld,, p. 72. 13.Hoch, D. J., Roeding, C. R., Purket, G. y Lindner, S. K., (2000) Secrets of Software Success, Harvard Business School Press, Boston, MA. 14.Hutchins, E. (1995) Cognition in the wild. Cambridge, MA: MIT Press 15.Hutchins, E. (1997) Constructing meaning from space gesture, and speech, en Discurso, herramientas y razonamiento. Resnick, R. Saljo, C. Pontecorvo, and B. Burge, Springer, Berlin, p. 23-40

Referencias Marco Teorico

[1] Boehm, B.: A View of 20th and 21st Century Software Engineering. In: 28th international conference on Software engineering, pp. 12--29. Shanghai, China (2006) [2] Dalcher, D., Benediktsson, O., y Thorbergsson, H., Development Life Cycle Management: A Multiproject Experiment, Proceedings of the 12th International Conference and Workshops on the Engineering of Computer Based Systems (ECBS05), 2005 [3] Wellington, A., Briggs, T., y Girard, C.D., Comparison of Student Experiences with PlanDriven and Agile Methodologies, Proceedings of the 35th ASEE/IEEE Frontiers in Education Conference, 2005. [4] ITEA 2 Flexi. In: http://www.flexi-itea2.org/index.php [5] Fleeger, P.: "Software Engineering. 3ed." Prentice Hall, 1999. [6] Dyba, T., Dingsoyr, T.: Empirical Studies of Agile Software Development: A Systematic Review, Information and Software Technology doi: 10.1016/j.infsof.2008.01.006 (2008) [7] Capiluppi, A., Fernandez-Ramil, J., Higman, J., Sharp, H.C., Smith, N.: An empirical study of the evolution of an agile-developed software system. In: 29th International Conference on Software Engineering (ICSE), pp. 511{518. (2007) [8] Mann, C., Maurer, F.: A case Study on the Impact of Scrum on Overtime and Customer Satisfaction. In: Proceedings of the Agile Development Conference (ADC05). IEEE Computer Society (2005) [9] www.agilealliance.org [10] Boehm, B.W.: Software Engineering Economics. In: Prentice Hall (1981). ISBN: 0138221227 [11] Lindvall, et al..: Empirical Findings in Agile Methods. In: Lecture Notes In Computer Science; Vol. 2418. Proc. of the Second XP Universe and First Agile Universe Conference on Extreme Programming and Agile Methods - XP/Agile Universe. Berlin, Germany (2002) [12] Nerur, S., Mahapatra, R., Mangalaraj, G.: Challenges of migrating to agile methodologies. In: Commun. ACM, vol. 48, no. 5, pp. 72-78 (2005) [13] Qumer, A., Henderson-Sellers, B.: An evaluation of the degree of agility in six agile methods and its applicability for method engineering. In: Information and Software Technology. (2007) [14] Beck, K., et al.: The Agile Manifesto. Manifesto for Agile Software Development. www.agilemanifesto.org [15] Cao, L., Ramesh, B.: Agile Requirements Engineering Practices: An Empirical Study. In: IEEE Computer Society Press Los Alamitos, CA, vol 25, pp-60-67 (2008) [16] Robinson, H. Sharp, L., The social side of technical practices in eXtreme Programming and Agile Processes in Software Engineering, Lecture Notes in Computer Science. Berlin: Springer Verlag, 2005, pags 139-147.