La Utilización de los Métodos Ágiles. en las Empresas de Desarrollo de Software de Argentina. Andrea N. Alende. Universidad CAECE Mar del Plata

Transcripción

1 Utilización Métodos Ágiles La Utilización de los Métodos Ágiles en las Empresas de Desarrollo de Software de Argentina Andrea N. Alende Universidad CAECE Mar del Plata Trabajo presentado por requerimiento de la asignatura Práctica Profesional en Sistemas Profesora: Lic. Fabiana Escobar Profesora: Lic. Marcela Álvarez Profesor: Lic. Emiliano Ricci Licenciatura en Sistemas Mayo, 2010.

2 Utilización Métodos Ágiles Abstract El presente trabajo tiene como objetivo relevar el uso de las Metodologías Ágiles en empresas de desarrollo de software de la Argentina. Se pretende conocer cuales son los métodos y las técnicas ágiles mas utilizadas, como así también la conformación de los grupos de trabajo, los clientes y los proyectos a los que se aplican. Por último se indaga sobre certificaciones de calidad realizadas con estos métodos. El desarrollo contiene un resumen de las características principales de los métodos ágiles más conocidos, principalmente Scrum y Xp por ser los mas utilizados de acuerdo con los resultados obtenidos. Para realizar el relevamiento se realizaron encuestas a distintas empresas o instituciones que se sabía de antemano que utilizaban metodologías ágiles para desarrollo de software. El trabajo finaliza con las conclusiones a las que se pudo arribar sobre cada uno de los temas mencionados, luego de analizadas las respuestas de las empresas participantes. Palabras clave: Métodos o Metodologías Ágiles en Argentina, Agile, Scrum, XP, Extreme Programming, Adaptive Software Development, Agile Unified Process, Crystal Feature Driven Development, Dynamic Systems Development Method, Lean Development, CMMi, ISO. ii

3 Utilización Métodos Ágiles Agradecimientos Principalmente agradezco a mi esposo Alejandro y mis hijos, Federico y Franco, a los cuales les reste muchas horas para poder realizar no solo este trabajo, sino toda la carrera. Sin el apoyo y la paciencia de ellos no lo hubiera logrado. Le quiero agradecer a los encuestados, que me brindaron sin conocerme, parte de su valioso tiempo para responder las preguntas, y ofrecer su ayuda desinteresada. Por último, le agradezco a los profesores por ofrecerme la posibilidad y guiarme en el desarrollo del presente trabajo. iii

4 Utilización Métodos Ágiles Índice de Contenidos Agradecimientos Índice de Contenidos Índice de Figuras iii iv vii INTRODUCCIÓN 1 METODOLOGÍAS ÁGILES 3 Origen 3 Manifiesto Ágil para Desarrollo de Software 4 Las Metodologías 10 Adaptive Software Development (ASD) 11 Agile Unified Process (AUP) 13 Fases 14 Disciplinas 15 Crystal Methodologies 16 Roles 20 Estrategias 21 Técnicas 22 Feature Driven Development (FDD) 23 Desarrollar un Modelo Global 24 Construir una Lista por Rasgos 25 Planear por Rasgo 25 Diseñar por Rasgo y Construir por Rasgo 25 Roles y Responsabilidades 26 Reporte de las Tareas 29 Prácticas 30 iv

5 Utilización Métodos Ágiles Ámbito 32 Dynamic Systems Development Method (DSDM) 32 El Proceso 33 Roles y Responsabilidades 37 Adaptabilidad 38 Lean Development (LD) y Lean Software Development (LSD) 40 Principios 40 Herramientas 45 Value Stream Mapping 45 Kanban 45 Extreme Programming (XP) 48 Valores 50 Las Doce Prácticas de XP 51 Las Historias de Usuario 58 El Ciclo de Vida de XP 59 Roles y Responsabilidades 62 Scrum 64 Qué es Scrum 66 Requisitos para Poder Utilizar Scrum 69 Roles y Responsabilidades 74 Características de Scrum 80 El Proceso 87 Planificación de la Iteración (Sprint Planning) 87 Ejecución de la Iteración (Sprint) 98 Demostración de Requisitos Completados (Sprint Demonstration) 102 v

6 Utilización Métodos Ágiles Retrospectiva (Sprint Retrospective) 104 LAS ENCUESTAS 106 Introducción 106 Resultados Obtenidos 107 Las Respuestas 108 Pregunta 1 Metodologías utilizadas 108 Pregunta 2 Experiencia 112 Pregunta 3 Las Técnicas 116 Pregunta 4 Los Clientes 125 Pregunta 5 Los Grupos de trabajo 132 Pregunta 6 Certificaciones de Calidad 139 Pregunta 7 Casos de Éxito 142 Los Participantes 150 CONCLUSIONES 158 REFERENCIAS 161 vi

7 Utilización Métodos Ágiles Índice de Figuras Figura 1. Manifiesto para el desarrollo ágil del software 5 Figura 2. Comparación entre metodologías ágiles y tradicionales 10 Figura 3. El ciclo de vida adaptativo 12 Figura 4. Actividades del ciclo de vida adaptativo 13 Figura 5. Ciclo de vida de AUP 14 Figura 6. La familia de Métodos Crystal 17 Figura 7. Efectividad de comunicación entre miembros del equipo 18 Figura 8. Las cinco estrategias de Crystal 22 Figura 9. Los cinco procesos de FDD 24 Figura 10. Diseño y Construcción en FDD 26 Figura 11. Reportando el progreso al management y al cliente en FDD 29 Figura 12. Ejemplo de modelo de Dominio 30 Figura 13. Diagrama de procesos de DSDM 34 Figura 14. Tablero Kankan 47 Figura 15. Gestación de XP 49 Figura 16. Evolución de los ciclos de desarrollo en cascada a iterativos 50 Figura 17. El costo de un cambio 52 Figura 18. Las practicas se refuerzan entre si 58 Figura 19. Clasificación de las prácticas de XP 59 Figura 20. Ciclo de vida de XP 60 Figura 21. Formación de Scrum 65 Figura 22. El Proceso de Scrum 87 Figura 23. Las cartas de Planning Poker 89 Figura 24. La lista de requisitos priorizada 91 vii

8 Utilización Métodos Ágiles Figura 25. La lista de tareas de la iteración 95 Figura 26. Product burndown chart 96 Figura 27. Sprint burndown chart 97 Figura 28. El tablón de tareas 98 Figura 29. Distribución en el uso de los métodos ágiles 111 Figura 30. Comparación entre el uso de Scrum como único framework de trabajo 112 Figura 31. Años de experiencia en la aplicación de métodos ágiles 114 Figura 32. Años de experiencia y métodos utilizados 115 Figura 33. Utilización de los métodos ágiles con los clientes 131 Figura 34. Compromiso de los clientes con los proyectos. 131 Figura 35. Cantidad de integrantes por equipo de trabajo 137 Figura 36. Distribución geográfica de los equipos de trabajo 138 Figura 37. Distribución geográfica de los equipos de trabajo 139 Figura 38. Certificaciones de calidad 141 Figura 39. Certificaciones de calidad ISO CMMi 142 viii

9 Utilización Métodos Ágiles 1 INTRODUCCIÓN La presente introducción se divide en tres partes. La motivación del estudio, donde se da a conocer el porqué de la realización del presente trabajo, el objetivo general donde se explica qué se pretende conocer sobre la aplicación de las metodologías ágiles en el país luego de terminado el proyecto, y por último una breve descripción de los contenidos. Motivación del Estudio Iniciando el segundo cuatrimestre de 2009, el grupo de profesores del área de Ingeniería de Software le propone a la autora realizar una investigación sobre las metodologías ágiles utilizadas en las empresas dedicadas al desarrollo de software del país. Las metodologías ágiles no habían sido estudiadas en profundidad durante la carrera, por lo tanto antes de comenzar a entrevistar empresas, había que realizar una investigación y un estudio de las mismas. Habiendo aceptado el desafío se desarrolló el presente trabajo. Objetivo General El objetivo del trabajo es conocer cuales son las metodologías ágiles más utilizadas en el país, que experiencia de trabajo hay en la actualidad sobre el desarrollo de software con métodos ágiles, cuales son las técnicas más utilizadas, para que tipos de proyectos aplican, si sirven para todos los clientes y por último si se puede certificar la calidad de los procesos utilizando estos métodos. Contenido El trabajo comienza con la presente introducción, seguida a continuación por el desarrollo. Dicha sección se divide en dos partes. La primera es el marco teórico, donde se hace una introducción a las metodologías ágiles, y el Manifiesto Ágil, y seguidamente se describen las características principales de algunos de los métodos ágiles más conocidos, poniendo énfasis en los que más se mencionaron en las encuestas (Scrum y XP).

10 Utilización Métodos Ágiles 2 En la segunda parte se presentan las respuestas, el procesamiento y el análisis de las encuestas realizadas. También se describen las empresas y personas que fueron relevadas y autorizaron su mención. En la última parte del trabajo, se expresan, punto por punto las conclusiones a las que ha arribado la autora con los resultados obtenidos de las encuestas.

11 Utilización Métodos Ágiles 3 METODOLOGÍAS ÁGILES Origen Tradicionalmente se ha tendido a desarrollar software a través de metodologías basadas en procesos predefinidos con documentación muy precisa, y una detallada planificación inicial que debe seguirse estrictamente. Esta forma de trabajar surgió naturalmente hace unos cincuenta años como una adaptación del manejo de proyectos de ingeniería, que era lo más parecido a desarrollar programas que se conocía en ese momento, y funcionó razonablemente bien en un comienzo. Hay que tener en cuenta que las computadoras eran enormemente caras, la mayor parte de la inversión informática se la llevaban los equipos y por esta razón los programas se hacían a medida para las máquinas que se adquirían, para realizar tareas muy concretas (Colusso, s.f.). En este contexto se desarrollaron diferentes metodologías a lo largo de los años como el modelo en cascada, que sirvió luego como base para la formulación del análisis estructurado, el cual fue uno de los precursores en este camino hacia la aplicación de prácticas estandarizadas dentro de la ingeniería de software. El proceso era desarrollado en forma de cascada ya que se requería la finalización de la etapa anterior para empezar la siguiente. Esto generaba un congelamiento temprano de los requerimientos, los cuales al presentar cambios requerían gran esfuerzo para ser realizados. Como alternativa para solucionar estos inconvenientes, surgen los modelos iterativos e incrementales, como el modelo en espiral, RUP (Rational Unified Process), etc. La postura de estos modelos es la de basar el desarrollo en iteraciones e ir construyendo la aplicación en forma progresiva, agregando funcionalidad sucesivamente. Las iteraciones representan un mini-proyecto autocontenido el cual está compuesto por todas las fases del desarrollo (requerimientos, diseño, implementación, testing). Los incrementos están dados por la funcionalidad que se va agregando al software en forma iterativa. Gracias a estas iteraciones se logra entre otras cosas obtener el feedback necesario del cliente que era frenado en el modelo en

12 Utilización Métodos Ágiles 4 cascada una vez se finalizaba la fase de requerimientos. Se puede decir que los modelos iterativos fomentan el cambio en forma temprana y proponen un control de cambio disciplinado que permita que el usuario ajuste sobre el desarrollo sus requerimientos. Esto se contrapone a la intolerancia del modelo en cascada para lidiar con dichos cambios (Schenone, 2004). Una de las principales desventajas que presentan estos últimos modelos es la gran cantidad de documentación que se debe elaborar para cada etapa del proceso de desarrollo. Los modelos como RUP son aplicables a proyectos de gran envergadura, donde trabajan muchas personas y sin el seguimiento de un proceso seria incontrolable. En los proyectos de menor tamaño resulta a veces engorroso seguir esta metodología rigurosamente. Para muchos de los proyectos actuales donde el entorno del sistema es muy cambiante, y en donde se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad estos métodos no son los más adecuados. En este escenario, las metodologías ágiles emergen como una posible respuesta para llenar ese vacío metodológico. Manifiesto Ágil para Desarrollo de Software. A mediados de los años 90 comenzó a forjarse una definición moderna de desarrollo ágil del software como una reacción contra las metodologías utilizadas hasta el momento, consideradas excesivamente pesadas y rígidas por su carácter normativo y fuerte dependencia de planificaciones detalladas previas al desarrollo. En febrero de 2001, tras una reunión celebrada en Utah (EEUU), nace el término ágil aplicado al desarrollo de software. En esta reunión participan un grupo de 17 expertos 1 de la industria del software, incluyendo algunos de los creadores o impulsores de metodologías de software. Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos 1 Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland y Dave Thomas.

13 Utilización Métodos Ágiles 5 desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Tras esta reunión se creó The Agile Alliance, una organización, sin ánimo de lucro, dedicada a promover los conceptos relacionados con el desarrollo ágil de software y ayudar a las organizaciones para que adopten dichos conceptos. El punto de partida fue el Manifiesto Ágil (Beck et al., 2001), un documento que resume la filosofía ágil. Figura 1. Manifiesto para el desarrollo ágil del software (Beck et al., 2001) En el Manifiesto Ágil se definen los cuatro valores y los doce principios por los que se deberían guiar las metodologías ágiles, extraído y adaptado de (Rodríguez González, 2008; Fernández González, 2006): 1. 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. Además una persona sola no realiza un proyecto, necesita de un entorno en el que desarrollar su trabajo y de un equipo con el que colaborar. Estas interacciones deben también cuidarse. Un factor clave

14 Utilización Métodos Ágiles 6 para el éxito es construir un buen equipo, que se lleven bien entre ellos, y que además sepan como construir su propio entorno de desarrollo. Es un error pretender construir primero el entorno y esperar que el equipo se adapte automáticamente sino que debe ser al revés, construir primero el equipo y que éste configure su propio entorno en base a sus necesidades y sus características personales. El talento, la habilidad, la capacidad de comunicación y de tratar con personas son características fundamentales para los miembros de un equipo ágil. 2. Desarrollar software que funcione por encima de una completa documentación. Uno de los objetivos de una buena documentación es poder ir a consultarla cuando haya que modificar algo del sistema. Si se tiene demasiada documentación sobre un proyecto, cada modificación debe ser plasmada en todos los artefactos, corriendo el riesgo de que con las presiones externas de tiempo esta quede desactualizada y obsoleta. En la filosofía ágil lo primordial es evitar estos fallos, la regla no escrita es no producir documentos superfluos. Este valor es utilizado por muchos detractores de las metodologías á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 documentación. Sin embargo, el propósito de este valor es acentuar la supremacía del producto por encima de la documentación. El objetivo de todo desarrollador es obtener un producto que funcione y cumpla las necesidades del cliente y la documentación 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 decisión importante. Los documentos deben ser cortos y centrarse en lo

15 Utilización Métodos Ágiles 7 fundamental. Dado que el código es el valor principal que se obtiene del desarrollo se enfatiza en seguir ciertos estándares de programación para mantener el código legible y documentado. 3. La colaboración con el cliente por encima de la negociación contractual. Se propone una interacción continua entre el cliente y el equipo de desarrollo de tal forma que el cliente debe ser y sentirse parte del equipo. Se pretende no diferenciar entre las figuras cliente y equipo de desarrollo sino que se apuesta por un solo equipo persiguiendo un objetivo común. 4. Responder a los cambios más que seguir estrictamente un plan. Planificar el trabajo a realizar es muy útil y las metodologías ágiles consideran actividades específicas de planificación a corto plazo. No obstante, adaptarse a los cambios es vital en la industria software actual y, por tanto, también consideran mecanismos para tratar los cambios de prioridades. La habilidad de responder a los cambios de requisitos, tecnología, presupuestarios o estrategia, marca sin duda el camino del éxito del proyecto. Como consecuencia de estos cuatro valores, el Manifiesto Ágil también enuncia los doce principios que caracterizan un proceso ágil diferenciándolo de otro convencional (Canós, Letelier y Penadés, s.f.): 1. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporten un valor. Un proceso es ágil si a las pocas semanas de empezar ya entrega software que funcione aunque sea rudimentario. El cliente decide si pone en marcha dicho software con la funcionalidad que ahora le proporciona o simplemente lo revisa e informa de posibles cambios a realizar.

16 Utilización Métodos Ágiles 8 2. Dar la bienvenida a los cambios de requisitos incluso cuando lleguen tarde durante el desarrollo. Se capturan los cambios para que el cliente tenga una ventaja competitiva. Este principio es una actitud que deben adoptar los miembros del equipo de desarrollo. Los cambios en los requisitos deben verse como algo positivo. Les va a permitir aprender más, a la vez que logran una mayor satisfacción del cliente. Este principio implica además que la estructura del software debe ser flexible para poder incorporar los cambios sin demasiado costo añadido. 3. Hacer entregas de software que funcione frecuentemente, desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. Se insiste en que las entregas al cliente sean software, no planificaciones, ni documentación de análisis o de diseño. 4. Los miembros del negocio y los desarrolladores deben trabajar juntos diariamente a lo largo del proyecto. El proceso de desarrollo necesita ser guiado por el cliente, por lo que la interacción con el equipo es muy frecuente. 5. Construir el proyecto en torno a individuos motivados. Darles el entorno y apoyo que necesiten y confiar en ellos para conseguir finalizar el trabajo. La gente es el principal factor de éxito, todo los demás (proceso, entorno, gestión, etc.) queda en segundo plano. Si cualquiera de ellos tiene un efecto negativo sobre los individuos debe ser cambiado. 6. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo. Los miembros de equipo deben hablar entre ellos, éste es el principal modo de comunicación. Se pueden crear documentos, pero no todo estará en ellos.

17 Utilización Métodos Ágiles 9 7. El software que funciona es la principal medida de progreso. El estado de un proyecto no viene dado por la documentación generada o la fase en la que se encuentre, sino por el código generado y en funcionamiento. Un proyecto se encuentra al 50% si el 50% de los requisitos ya están en funcionamiento. 8. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deben poder mantener un ritmo de trabajo constante de forma indefinida. No se trata de desarrollar lo más rápido posible, sino de mantener el ritmo de desarrollo durante toda la duración del proyecto, asegurando en todo momento que la calidad de lo producido es máxima. 9. La atención continua a la calidad técnica y al buen diseño mejora la agilidad. Producir código claro y robusto es la clave para avanzar más rápidamente en el proyecto. 10. La simplicidad es esencial. Se debe saber maximizar el trabajo que no se debe realizar. Tomar los caminos más simples que sean consistentes con los objetivos perseguidos. Si el código producido es simple y de alta calidad será más sencillo adaptarlo a los cambios que puedan surgir. 11. Las mejores arquitecturas, requisitos y diseños surgen de los equipos que se auto organizan. Todo el equipo es informado de las responsabilidades y éstas recaen sobre todos sus miembros. Es el propio equipo el que decide la mejor forma de organizarse, de acuerdo a los objetivos que se persigan.

18 Utilización Métodos Ágiles En intervalos regulares el equipo debe reflexionar sobre cómo ser más efectivo y ajustar su comportamiento para conseguirlo. Dado que el entorno está cambiando constantemente, el equipo también debe ajustarse al nuevo escenario de forma continua. Puede cambiar su organización, sus reglas, sus convenciones, sus relaciones, etc., para seguir siendo ágil. Estos principios marcan el ciclo de vida de un desarrollo ágil, así como las prácticas y procesos a utilizar. Figura 2. Comparación entre metodologías ágiles y tradicionales (Canós, Letelier y Penadés, s.f.) Las Metodologías A continuación se mencionan algunas de las metodologías ágiles, se hará una reseña de las primeras, y una descripción mas detallada de las últimas dos, por ser estas las más utilizadas según el relevamiento realizado para la presente investigación en las empresas de desarrollo de software de la Argentina. Adaptive Software Development (ASD).

19 Utilización Métodos Ágiles 11 Agile Unified Process (AUP). Crystal Methodologies. Feature Driven Development (FDD). Dynamic Systems Development Method (DSDM). Lean Development (LD) y Lean Software Development (LSD) Extreme Programming (XP) Scrum Adaptive Software Development (ASD) La técnica de Adaptive Software Development fue desarrollada por Jim Highsmith (Highsmith, 2000). Se basa en la adaptación continua a circunstancias cambiantes. En ella no hay un ciclo de planificación-diseño-construcción del software, sino un ciclo de tres fases: especular, colaborar y aprender, extraídas de (Armour, 2004). Especular Una primera fase de iniciación para establecer los principales objetivos y metas del proyecto en su conjunto y comprender las limitaciones o zonas de riesgo con las que operará el proyecto. En ASD se realizan estimaciones de tiempo sabiendo que pueden sufrir desviaciones. Sin embargo, estas son necesarias para la correcta atención de los trabajadores que se mueven dentro de plazos de forma que puedan priorizar sus tareas. Se decide el número de iteraciones para consumir el proyecto, prestando atención a las características que pueden ser utilizadas por el cliente al final de la iteración. Son por tanto necesarios, marcar objetivos prioritarios dentro de las mismas iteraciones. Estos pasos se pueden volver a examinar varias veces antes de que el equipo y los clientes estén satisfechos con el resultado.

20 Utilización Métodos Ágiles 12 Colaborar Es la fase donde se centra la mayor parte del desarrollo manteniendo una componente cíclica. Un trabajo importante es la coordinación que asegure que lo aprendido por un equipo se transmite al resto y no tenga que volver a ser aprendido por los otros equipos. Aprender La última etapa termina con una serie de ciclos de colaboración, su trabajo consiste en capturar lo que se ha aprendido, tanto positivo como negativo. Es un elemento crítico para la eficacia de los equipos. Figura 3. El ciclo de vida adaptativo (Highsmith, 2000) Highsmith (2000) identifica cuatro tipos de aprendizaje en esta etapa: 1. Calidad del resultado de la desde la perspectiva del cliente 2. Calidad del resultado de la desde la perspectiva técnica 3. El funcionamiento del equipo de desarrollo y las prácticas que este utiliza 4. El status del proyecto En la Figura 4 se puede ver el detalle interno de cada fase explicado, mostrándose con una flecha que trasciende las tres fases en sentido inverso, el bucle de aprendizaje. Este bucle es algo crítico para ASD ya que denota un cambio en el esquema tradicional de la vista de un sistema en que se tenía un bucle de control para detectar diferencias y corregirlas. Es decir, en las metodologías tradicionales las diferencias respecto a lo planificado eran vistas como

21 Utilización Métodos Ágiles 13 errores que debían ser enmendados para que cumplieran lo pautado. ASD y las metodologías ágiles plantean la necesidad de que el feedback necesario sea para aprender, nos da la posibilidad de entender más respecto al dominio y construir la aplicación que mejor satisfaga las necesidades del cliente (Schenone, 2004). Figura 4. Actividades del ciclo de vida adaptativo (Highsmith, 2000) Agile Unified Process (AUP). AUP es una versión simplificada del Rational Unified Process (RUP). Describe en forma simple y fácil de comprender el enfoque al desarrollo de software para aplicaciones empresariales utilizando las técnicas y conceptos de agilidad y manteniéndose fiel a las prácticas de RUP. El presente resumen es una traducción de (Ambler, 2005) Scott W. Ambler es el autor de este método. Comenzó a escribir en 2001 artículos en la Web sobre como agilizar RUP, y luego en 2002 publicó su libro (Ambler, 2002). El enfoque aplica técnicas ágiles que incluyen Test Driven Development (TDD), Agile Model Driven Development (AMDD), gestión del cambio ágil, y refactorización de bases de datos para mejorar su productividad. El la figura 5 se describe el ciclo de vida de AUP. Las disciplinas han cambiado con respecto a RUP. En primer lugar, la disciplina de Modelado, abarca las disciplinas de RUP Modelo de negocios, Requisitos, Análisis y Diseño. Modelado es una parte importante de la AUP, como se puede ver, pero no dominan el proceso, que desea mantener la agilidad en la

22 Utilización Métodos Ágiles 14 creación de modelos y documentos con lo justo y necesario. En segundo lugar, las disciplinas de Configuration and Change Management se fusionan en la nueva disciplina Configuration Management. En el desarrollo ágil las actividades de gestión del cambio suelen formar parte de la gestión de requisitos, que es parte de la disciplina de modelado. Figura 5. Ciclo de vida de AUP (Ambler, 2005) Fases La naturaleza serial de AUP es capturada en sus cuatro fases: 1. Inception. El objetivo es identificar el alcance inicial del proyecto, la potencial arquitectura del sistema, y obtener la financiación inicial del proyecto y la aceptación de los stakeholders. 2. Elaboration. El objetivo es probar la arquitectura del sistema. 3. Construction. El objetivo es construir software funcional sobre una base regular, incremental, que cumpla con la más alta prioridad las necesidades de los stakeholders del proyecto. 4. Transition. El objetivo es validar y desplegar el sistema en su entorno de producción.

23 Utilización Métodos Ágiles 15 Disciplinas Las disciplinas se llevan a cabo de manera iterativa, definiendo las actividades que realizan los miembros del equipo de desarrollo para construir, validar y entregar software funcional que responda a las necesidades de los stakeholders. Model El objetivo de esta disciplina es entender el negocio de la organización, el dominio del problema que aborda el proyecto, y definir una solución viable para hacer frente al mismo. Implementation El objetivo de esta disciplina es transformar el modelo en código ejecutable y realizar un nivel básico de las pruebas, en particular tests unitarios. Test El objetivo de esta disciplina consiste en realizar una evaluación objetiva para garantizar la calidad. Esto incluye encontrar defectos, validar que el sistema funciona según lo previsto, y verificar que se cumplan los requisitos. Deployment El objetivo de esta disciplina planear para la entrega del sistema y ejecutar el plan para poner el sistema a disposición de los usuarios finales. Configuration Management El objetivo de esta disciplina es la gestión de acceso a los artefactos del proyecto. Esto incluye no sólo el seguimiento de las versiones de los artefactos en el tiempo, sino también el control y la administración de los cambios que se les han hecho. Project Management El objetivo de esta disciplina es dirigir las actividades que lleva a cabo en el proyecto. Esto incluye la gestión de riesgos, la dirección de las personas (la asignación de tareas, el

24 Utilización Métodos Ágiles 16 seguimiento del progreso, etc.), y la coordinación de las personas y los sistemas fuera del alcance del proyecto para asegurarse de que es entregado a tiempo y dentro del presupuesto. Environment El objetivo de esta disciplina es apoyar el resto los esfuerzos garantizando que el proceso apropiado, normas de orientación (y directrices), y herramientas (hardware, software, etc.) están disponibles para el equipo según sea necesario. Scott Ambler define a AUP como un proceso entre XP y el RUP tradicional. Muchas organizaciones se resisten a XP, ya que parece ser muy liviano. En XP no se muestran de forma explícita cómo crear algunos de los artefactos que la administración esta acostumbrada a ver. En el otro extremo está RUP, que a la administración parece que le encanta, pero a los desarrolladores no tanto debido a la gran cantidad de artefactos. AUP surge entre los dos, con la adopción de muchas de las técnicas ágiles de XP y otros procesos ágiles que todavía conservan algo de la formalidad de RUP. Crystal Methodologies Es un conjunto de metodologías ágiles para equipos de diferentes tamaños y con distintas características de criticidad. Fue propulsada por uno de los padres del Manifiesto Agil, Alistair Cockburn, que consideraba que la metodología debe adaptarse a las personas que componen el equipo utilizando políticas diferentes para equipos diferentes. Estas políticas dependerán del tamaño del equipo, estableciéndose una clasificación por colores: Crystal Clear (3 a 8 miembros), Crystal Yellow (10 a 20 miembros), Crystal Orange descripto en (Cockburn, 1997) (25 a 50 miembros), Crystal Red (50 a 100 miembros) y Crystal Blue (para más de 100 miembros) (Rodriguez Gonzalez, 2008). Cada miembro de la familia de Crystal está marcado con un color que indica la "pesadez" de la metodología, es decir, cuanto más oscuro el color más pesada la metodología. Cristal sugiere elegir el color adecuado para cada proyecto basándose en su tamaño y

25 Utilización Métodos Ágiles 17 criticidad. En los proyectos mas grandes es probable que se necesite mas coordinación y metodologías mas pesadas que en los mas pequeños. Cuanto mas crítico es el sistema a desarrollar, mayor rigor se necesita en la metodología. En la figura 6, se puede observar que moviéndose hacia la derecha en el eje X, el número de personas en el proyecto aumenta lo que resulta en una disminución de las comunicaciones cara a cara entre los miembros del equipo. Esto también significa que se debe utilizar una metodología mas pesada. El eje Y denota la potencialidad del sistema y el rango desde perder confort hasta incluso la vida. En términos de la analogía de cristal, esto significa que el grado de "dureza" del proyecto se incrementa desplazándose hacia arriba en el eje Y. El contexto exterior determina los elementos necesarios en la metodología y los productos derivados de los proyectos en el rango superior del eje Y. Proyectos de este tipo incluyen proyectos médicos, proyectos de control aéreo, etc. Figura 6. La familia de Métodos Crystal (Cockburn, 2003)

26 Utilización Métodos Ágiles 18 El eje Z refleja las diferentes prioridades como tiempo de salida al mercado, reducción de costos o responsabilidad legal. Los cuadros indican la clase de proyectos en los que el tamaño, la criticidad y los objetivos intersectan. En los términos de colores que propone Crystal, los cuadros C6 y D6 son de Crystal Clear, aunque admite que podría extenderse para incluir el cuadro de E6. Los cuadros C20, D20 y E20 son agrupados bajo la denominación Crystal Yellow, los cuadros C40, D40 y E40 pertenecen a Crystal Orange y C100, D100 y E100 son de Crystal Red. Crystal Magenta and Crystal Blue abarcarían proyectos mas grandes. Crystal da vital importancia a las personas que componen el equipo de un proyecto, y por tanto sus puntos de estudio son: 1. Aspecto humano del equipo 2. Tamaño de un equipo (número de componentes) 3. Comunicación entre los componentes 4. Distintas políticas a seguir 5. Espacio físico de trabajo Figura 7. Efectividad de comunicación entre miembros del equipo (Fernandez Enrich, 2003)

27 Utilización Métodos Ágiles 19 Crystal Clear descripto en (Cockburn, 2001; Cockburn, 2004), es la metodología más ligera de este conjunto, y esta dirigida a la comunicación de equipos pequeños que desarrollan software cuya criticidad no es elevada. Tiene asociadas siete características, traducidas de (Marcos, 2009): 1. Liberación frecuente de funcionalidad. La propiedad más importante de cualquier proyecto es hacer entregas, cada pocos meses, de código testeado y funcionando a usuarios reales. Algunas de las ventajas son: Los sponsors reciben comentarios críticos sobre la tasa del progreso del equipo. Los usuarios tienen la oportunidad de descubrir si sus requerimientos originales eran lo que realmente necesitaban y se plasma su feedback en el desarrollo. Los desarrolladores mantienen su enfoque, superando bloqueos de indecisión Los equipos depuran su desarrollo y el proceso de implementación. 2. Mejora reflexiva. Un equipo de desarrollo puede revertir su suerte de falla catastrófica a éxito, si se reúnen y analizan si su trabajo esta funcionando o no, discutir que puede funcionar mejor y luego hacer los cambios en la próxima iteración, en otras palabras, reflexionar y mejorar. 3. Comunicación osmótica. La información fluye en el entorno de trabajo, por lo tanto los miembros del equipo adquieren información relevante por ósmosis. Esto es una consecuencia de estar todos sentados en el mismo espacio de trabajo.

28 Utilización Métodos Ágiles 20 Entonces, cuando un miembro hace una pregunta, los otros pueden contestar o no, contribuyendo a la discusión o continuando con su trabajo. 4. Seguridad personal. La seguridad personal se basa en ciertos niveles de confianza. Es importante porque con ella, el equipo puede descubrir y mejorar sus debilidades. Sin ella, las personas no se comunican, y las debilidades continuaran dañando al equipo. 5. Enfoque. El enfoque en Crystal se refiere a dos puntos; el primero es enfocarse en una sola tarea en un proyecto por el tiempo suficiente para lograr algún progreso, y segundo, se refiere a la dirección que el proyecto esta tomando. 6. Fácil acceso a usuarios expertos. Esto implica que los desarrolladores trabajen con una persona con experiencia en el área del proyecto, así les puede responder sus consultas, sugerir soluciones a los problemas, etc. Se debe hacer como mínimo una reunión de dos horas, una vez por semana con el experto del negocio, y tener posibilidad de comunicarse telefónicamente cuando sea necesario. 7. Entorno técnico con pruebas automatizadas, administración de la configuración e integración continua. Debe haber integración continua y testeo, de modo que si los cambios se hacen, los errores pueden ser anticipados. Si esto se hace regularmente es menos probable que los errores se hagan mayores y puedan ser resueltos en forma temprana. Roles Los roles de Crystal Clear son (Fernandez Enrich, 2003):

29 Utilización Métodos Ágiles 21 Executive Sponsor (Patrocinador Ejecutivo) Project Manager (Jefe de Proyecto) Domain Expert (Experto en el Dominio) Usage Expert (Experto de uso) Designer-Programmer (Programador Diseñador) Designer (UI Diseñador) Tester (Realizador de Pruebas) Technical (Programador Técnico) Estrategias Ni las estrategias ni las técnicas son mandatarias para Crystal Clear. Pero es bueno tener en cuenta alguna de ellas al momento de empezar a trabajar (Morales, 2007). Tres de las estrategias que están más relacionadas son las de apuntar a tener "Victorias Tempranas", arrancar el desarrollo de lo que se denomina un "Esqueleto que Camine" y pensar siempre en hacer "Rearquitectura Incremental" van de la mano.. Figura 8. Las cinco estrategias de Crystal (Morales, 2007) El poder arrancar el proceso a partir de un esqueleto sobre el cual se irá agregando funcionalidad en cada una de las entregas ayuda a que se vean los avances desde el comienzo (aunque sea una simple pantalla de ABM que se conecta con la base de datos y muestra un solo dato). A medida que se avanza en el proceso, la rearquitectura permitirá ir agregando más "cuerpo" al esqueleto inicial.

30 Utilización Métodos Ágiles 22 Todas describen una forma de tomar ventaja del desarrollo incremental para establecer valor desde el principio. Técnicas Igual que con las estrategias, hay una lista de técnicas propuestas por Crystal Clear, de las cuales se pueden ir tomando las más convenientes según el momento en que se encuentra el proceso de desarrollo del proyecto (Morales, 2007). Reuniones diarias. Acompañan el seguimiento y mantienen el foco en el próximo paso a seguir, y también permiten la discusión productiva de líneas a seguir. Reuniones de reflexión. Las reuniones de reflexión periódicas son fundamentales para que los miembros del equipo se expresen abiertamente, para revisar el trabajo hecho y evaluar qué cosas dan resultado y cuáles no o de empezar a trabajar. Programación side-by-side. Consiste en dos personas sentadas lo suficientemente cerca como para ver la pantalla del otro fácilmente, pero cada una trabajando en su propia tarea, es una alternativa menos intensiva que la programación de a pares. Todo esto permite ir armando una metodología de trabajo que se adecue al equipo, el proyecto y los tiempos que se manejen. En Resumen la guía de trabajo que presenta Crystal Clear es altamente recomendable para equipos pequeños. Da flexibilidad y prioriza la parte humana, apuntando a lograr eficiencia, habitabilidad y confianza en los miembros del equipo. Presta especial importancia a la ubicación física del grupo, donde la comunicación cumple el rol principal. La entrega frecuente de código confiable y funcionando mantiene el foco y evita distracciones. El equipo es el que elige qué técnicas aplicar según lo que consideren apropiado en cada proyecto.

31 Utilización Métodos Ágiles 23 Feature Driven Development (FDD). El FDD (Desarrollo Manejado por Rasgos) fue reportado por primera vez en (Coad, Lefebrve y De Luca, 1999); luego fue desarrollado con amplitud en un proyecto mayor de desarrollo por DeLuca, Coad y Stephen Palmer. Su implementación de referencia, fue el Singapore Project; DeLuca había sido contratado para salvar un sistema muy complicado para el cual el contratista anterior había producido, luego de dos años, 3500 páginas de documentación y ninguna línea de código. Naturalmente, el proyecto basado en FDD fue todo un éxito, y permitió fundar el método en un caso real de misión crítica (Reynoso, 2004). En 2002, Palmer y Felsing publicaron un nuevo libro desarrollando esta metodología. FDD se basa en un proceso iterativo con iteraciones cortas que producen un software funcional que el cliente y la dirección de la empresa pueden ver y monitorizar. Las iteraciones se deciden en base a features o funcionalidades, que son pequeñas partes del software con significado para el cliente. En el caso del FDD las iteraciones duran dos semanas (Molpeceres, 2003). El FDD tiene cinco procesos. Los primeros tres se hacen al principio del proyecto. 1. Desarrollar un Modelo Global 2. Construir una Lista de los Rasgos 3. Planear por Rasgo 4. Diseñar por Rasgo 5. Construir por Rasgo Los últimos dos se hacen en cada iteración. Este proceso iterativo soporta desarrollo ágil con adaptaciones rápidas a cambios de último momento y requerimientos del negocio. Cada proceso se divide en tareas y se da un criterio de comprobación.

32 Utilización Métodos Ágiles 24 Figura 9. Los cinco procesos de FDD (Palmer y Felsing, 2002) Los cinco procesos se describen de acuerdo con (Palmer y Felsing, 2002), traducidos de (Abrahamsson et al., 2002). Desarrollar un Modelo Global. Cuando comienza el desarrollo del modelo global, los expertos del dominio ya son conscientes del alcance, el contexto y los requerimientos del sistema que se va a construir. Los requerimientos documentados como los casos de uso o las especificaciones funcionales ya deben existir. Sin embargo, FDD no aborda específicamente el tema de la recolección y gestión de los requerimientos. Los expertos del dominio presentan un walkthrough 2 donde los miembros del equipo y el jefe de arquitectos son introducidos a una descripción de alto nivel del sistema. El dominio global es dividido en diferentes áreas y se realiza un walkthrough detallado para cada una de dichas áreas por parte de los expertos del dominio. Luego de cada walkthrough, un equipo de desarrollo trabaja en pequeños grupos con el fin de producir modelos de objetos para cada área de dominio en las que se dividió el dominio global. Por ultimo el grupo de desarrollo discute y decide cual es el modelo de objetos apropiado para cada una de las áreas de dominio. Simultáneamente, el modelo global del sistema es construido. 2 Tutorial Ensayo Descripción de un proceso paso a paso

33 Utilización Métodos Ágiles 25 Construir una Lista de los Rasgos Los walkthroughs, modelos de objeto y documentación de requerimientos proporcionan la base para construir una amplia lista de rasgos. En dicha lista, el equipo de desarrolladores presenta cada una de las funcionalidades evaluadas por el cliente. Dicha lista es divida en subconjuntos en base a la funcionalidad. Una vez que se han identificado se los agrupa jerárquicamente para poder estructurar el trabajo de desarrollo; se realiza la priorización de los mismos basándose en la satisfacción al cliente, las prioridades sugeridas por FDD son: A (debe tener), B (sería útil tener), C (agregar si es posible), o D (futuro). La lista de rasgos es revisada por los usuarios y sponsors para asegurar su validez y exhaustividad. Planear por Rasgo En esta etapa se incluye la creación de un plan de alto nivel, en el que los conjuntos de rasgos se ponen en secuencia conforme a su prioridad y dependencia, y se asigna a los programadores jefes. Por otro lado, las clases identificadas en el primer paso son asignadas a los distintos desarrolladores. Asimismo, se pueden fijar en esta etapa, el calendario y los hitos más importantes para los conjuntos de rasgos. Diseño por Rasgos y Construcción por Rasgos Se selecciona un pequeño grupo de rasgos del conjunto y los equipos de necesarios para el desarrollo de las funciones seleccionadas son armados por los propietarios de las clases. Los procesos de diseño y construcción son procedimientos iterativos durante los cuales son producidos los rasgos seleccionados. Una iteración puede tomar de unos pocos días un máximo de dos semanas. Puede haber varios equipos diseñando y construyendo concurrentemente su propio set de rasgos. Este proceso iterativo incluye inspección de diseño, codificación, pruebas unitarias, integración e inspección de código. Luego de una iteración satisfactoria, los rasgos completos son promovidos al proyecto principal mientras la

34 Utilización Métodos Ágiles 26 iteración de diseño y construcción comienza con un nuevo grupo de rasgos tomados del set. La figura 10 detalla como se desarrollan las iteraciones 4 y 5. Figura 10. Diseño y Construcción en FDD (Abrahamsson et al., 2002). Roles y Responsabilidades El FDD clasifica sus roles en las siguientes tres categorías (Calabria, 2003): 1. Key roles: Project manager. Es el líder administrativo y financiero del proyecto. Una de sus tareas principales es proteger al equipo de distracciones externas y permitir que el equipo de pueda trabajar en las condiciones apropiadas. En el FDD el Project Manager tiene la última palabra sobre temas referidos al alcance, tiempo y personal. Chief architect. Es el responsable por el diseño global del sistema y de la ejecución de todas las etapas del diseño. También tiene la última palabra sobre las decisiones del diseño de todo el sistema. Si es necesario, este rol puede ser dividido en dos roles como ser Domain Architect y Tecnical Architect. Development manager. Lleva diariamente las actividades de desarrollo y resuelve cualquier conflicto que pueda ocurrir con el equipo. Además, este rol

35 Utilización Métodos Ágiles 27 incluye la responsabilidad de resolver problemas referentes a los recursos. Las tareas de este rol pueden ser combinadas con las del Chief Architect o el Proyect Manager. Chief programmer. Es un desarrollador con experiencia, el cual participa en el análisis de los requerimientos y el diseño del proyecto. El Chief Programmer es el responsable de guiar a pequeños equipos en el análisis, diseño y desarrollo de nuevas funcionalidades. Además, selecciona las funcionalidades a desarrollar de la lista de funcionalidades de la próxima iteración en la última fase del FDD, identifica las clases y el Class Owner que se necesita en el equipo para la iteración. Con la ayuda de otros Chief Programmers resuelve problemas técnicos y de recursos, y reporta el progreso del equipo durante la semana. Class owner. Trabaja bajo la guía del Chief Programmer en las tareas de diseño, codificación, testing y documentación. Él es responsable del desarrollo de las clases que se le asignaron como propias. Para cada iteración los Class Owner participan en la decisión de que clase será incluida en la lista de funcionalidades de la próxima iteración. Domain Experts. Los expertos del dominio pueden ser un usuario, un cliente, un sponsor, un analista del negocio o una mezcla de estos. Su tarea es poseer el conocimiento de los diferentes requerimientos del sistema. El experto del dominio pasa el conocimiento a los desarrolladores de manera tal que asegure que estos entreguen un sistema completo. 2. Supporting roles:

36 Utilización Métodos Ágiles 28 Realese manager. Controla el avance del proceso mediante la revisión de los reportes del Chief Programmer y realiza pequeñas reuniones con él. Además, reporta el progreso del proyecto al gerente. Languaje Sawyer / language guru. Es un miembro del equipo responsable de poseer un vasto conocimiento en, por ejemplo, un específico lenguaje de programación o tecnología. Este rol es particularmente importante cuando el equipo trabaja con una nueva tecnología. Build engineer. Es la persona responsable de preparar, mantener y correr el proceso de construcción, incluidas las tareas de mantenimiento de las versiones y la publicación de la documentación. Toolsmith. Es un rol para la construcción de herramientas específicas para el desarrollo, conversión de datos y testeo. Además, puede trabajar en la preparación y mantenimiento tanto de bases de datos o sitios Web destinados al proyecto. System Administrator. La tarea del administrador del sistema es configurar, administrar y reparar los servidores, estaciones de trabajo y equipos de desarrollo y testeo utilizados por el equipo. 3. Additional roles Tester. Verifica que el sistema recién creado cumpla con los requerimientos del cliente. Puede llegar a ser una persona independiente del equipo del proyecto. Deployer. Es el encargado de convertir la información existente requerida por el nuevo sistema y participa en el lanzamiento de los nuevos productos.

37 Utilización Métodos Ágiles 29 Techical writer. Se encarga de preparar la documentación para los usuarios, quienes pueden formar parte o no del equipo del proyecto. Vale la pena aclarar que un miembro de un equipo puede ejercer varios roles y un rol pude ser compartido por varias personas. Reporte de las Tareas El Release Manager se reúne con los Chief Programmers para que éstos reporten como es el avance de las tareas. En esta reunión, que tiene una duración de 30 minutos o menos, cada Chief Programmer informa de manera verbal el avance de sus rasgos. Hacer esto de forma verbal es bueno para que cada uno de los Chief Programmers se tome el tiempo de escuchar a los otros y saber donde están situados los demás en el proceso de desarrollo. Figura 11. Reportando el progreso al management y al cliente en FDD (Coad, 2000). Al final de la entrevista, el release manager anota los resultados, actualiza la base de datos y genera los reportes. El release manager reporta los resultados obtenidos semanalmente, tanto para el equipo, para el cliente y para el Project Manager. Para los clientes y los gerentes, el reporte debe incluir el porcentaje de avance de cada rasgo. Para el equipo se informa cual es el desempeño del mismo.

38 Utilización Métodos Ágiles 30 Prácticas. FDD consiste de un conjunto de mejores prácticas y los desarrolladores del método destacan que a pesar de que las prácticas seleccionadas no son nuevas, la mezcla específica de estos ingredientes hace que los cinco procesos de FDD sean únicos para cada caso. Palmer y Felsing (2002) sostienen que las prácticas disponibles deben ser utilizadas para obtener el mayor beneficio del método y no que una sola práctica domine todo el proceso. FDD consiste en las siguientes prácticas: 1. Modelo de Objetos del Dominio. Exploración y explicación del dominio del problema a resolver. Su resultado es un framework donde se agregan los rasgos del sistema. La técnica que recomiendan los autores es modelar en colores, en la figura 12 se puede observar un ejemplo de un caso real. Figura 12. Ejemplo de modelo de Dominio. 2. Desarrollo por rasgos. Desarrollo y seguimiento del progreso a través de una lista de funciones descompuestas por funcionalidad y valoración del cliente. Es importante restringir la lista a las funcionalidades que el cliente pueda entender, por eso se

39 Utilización Métodos Ágiles 31 denomina a esta lista funciones valoradas por el cliente o simplemente rasgos. 3. Propietario individual de la clase (código). Una sola persona es propietaria de una clase y es el único responsable de mantener su consistencia, performance e integridad conceptual. 4. Equipos por rasgos. Se refiere a pequeños grupos dinámicos, bajo la supervisión de un Chief Programmer. Los propietarios de las clases trabajan todos juntos y comparten sus ideas, los Chief Programmers también pueden ser propietarios de clases. Cuando el rasgo se completa se pueden rearmar los grupos. 5. Inspecciones. Se refiere al uso de mecanismos bien conocidos para la detección de defectos. Las inspecciones tienen dos beneficios adicionales: transferencia de conocimiento y cumplimiento de los estándares. 6. Construir regularmente. Se refiere a asegurarse que siempre hay una versión del sistema disponible para mostrar. Las construcciones regulares son la base donde se agregan los nuevos rasgos al sistema. 7. Administración de la configuración. Permite la identificación y seguimiento del historial de las últimas versiones de cada archivo fuente terminado. Provee un seguimiento histórico de todos los artefactos que contienen la información del proyecto. 8. Reportar el progreso. El progreso es reportado basándose en trabajo terminado a todos los niveles de la organización que sea necesario. Los reportes deben ser frecuentes,

40 Utilización Métodos Ágiles 32 apropiados al nivel que se esta informando y precisos. Permiten a los distintos niveles llevar un seguimiento de los resultados. El equipo debe poner todas estas reglas en práctica para cumplir con FDD, sin embargo se le permite adaptarlas según su nivel de experiencia y necesidades del proyecto. Ámbito. FDD no cubre todo el proceso de desarrollo de software, se enfoca en las fases de diseño y construcción. Nada dice sobre la captura de requerimientos, el diseño de las interfaces ni la implementación. Con respecto al tamaño de los proyectos, es muy efectivo en proyectos grandes con una lógica de negocio compleja. Es apropiado para desarrollar sistemas críticos como así también para actualizar código existente y hacer segundas versiones. Un rasgo llamativo de FDD es que no exige la presencia del cliente como otros métodos ágiles. Dynamic Systems Development Method (DSDM) El DSDM (Dynamic Systems Development Method) empezó en Gran Bretaña en 1994 como un consorcio de compañías del Reino Unido que querían construir sobre RAD (Rapid Applications Development) Desarrollo Rápido de Aplicaciones y desarrollo iterativo. Habiendo empezado con 17 fundadores ahora tiene más de mil miembros y ha crecido fuera de sus raíces británicas. Siendo desarrollado por un consorcio, tiene un sabor diferente a muchos de los otros métodos ágiles. Tiene una organización de tiempo completo que lo apoya con manuales, cursos de entrenamiento, programas de certificación y demás (DSDM Consortium y Stapleton, 2003). El Consorcio, tomando las mejores prácticas que se conocían en la industria y la experiencia traída por sus fundadores, liberó la primera versión de DSDM a principios de A partir de ese momento el método fue bien acogido por la industria, que empezó a utilizarlo y a capacitar a su personal en las prácticas y valores de DSDM.

41 Utilización Métodos Ágiles 33 Debido a este éxito, el Consorcio comisionó al Presidente del Comité Técnico, Jennifer Stapleton (1997), la creación de un libro que explorara la realidad de implementar el método (Schenone, 2004). La estructura del método fue guiada por estos nueve principios: 1. El involucramiento del usuario es imperativo. 2. Los equipos de DSDM deben tener el poder de tomar decisiones. 3. El foco está puesto en la entrega frecuente de productos. 4. La conformidad con los propósitos del negocio es el criterio esencial para la aceptación de los entregables. 5. El desarrollo iterativo e incremental es necesario para converger hacia una correcta solución del negocio. 6. Todos los cambios durante el desarrollo son reversibles. 7. Los requerimientos están especificados a un alto nivel. 8. El testing es integrado a través del ciclo de vida. 9. Un enfoque colaborativo y cooperativo entre todos los interesados es esencial. El Proceso DSDM define cinco fases en la construcción de un sistema como se puede observar en la figura 13. Las mismas son: a) estudio de factibilidad, b) estudio del negocio, c) iteración del modelo funcional, d) iteración del diseño y e) construcción, implantación. Las primeras dos fases son secuenciales y se hacen solo una vez. Las últimas tres fases, durante las cuales se hace el desarrollo del sistema, son iterativas e incrementales. DSDM considera las iteraciones como timeboxes. Un timebox dura por un periodo predefinido de tiempo, y la iteración tiene que finalizar dentro del timebox. El tiempo permitido para cada iteración esta planeado de antemano, junto con los resultados que la

42 Utilización Métodos Ágiles 34 iteración garantiza producir. En DSDM, un la duración típica de un timebox es de unos pocos días a unas pocas semanas. Figura 13. Diagrama de procesos de DSDM (Stapleton, 1997) A continuación se desarrollan las fases del proceso, traducidas de (Abrahamsson et al., 2002): 1. Estudio de factibilidad. El estudio de factibilidad es una pequeña fase que propone DSDM para determinar si la metodología se ajusta al proyecto en cuestión. Durante el estudio del negocio se involucra al cliente de forma temprana, para tratar de entender la operatoria que el sistema deberá automatizar. Este estudio sienta las bases para iniciar el desarrollo, definiendo las características de alto nivel que deberá contener el software. Dos artefactos se realizan en esta fase, el reporte de factibilidad y un esbozo del plan de desarrollo. Opcionalmente se puede desarrollar un prototipo si el negocio o la tecnología no son bien conocidas y no permiten decidir la factibilidad del proyecto. Este estudio de factibilidad no debe llevar más que unas pocas semanas.

43 Utilización Métodos Ágiles Estudio del negocio. En esta fase se analizan las características del negocio y de la tecnología. Se recomienda realizar pequeños workshops 3 donde un número suficiente de clientes expertos se reúnen y son capaces de considerar todos los aspectos relevantes del sistema, y se ponen de acuerdo en las prioridades de desarrollo. Los procesos de negocio y las clases de usuarios son definidos en la Definición del Área de Negocio. Descripciones de alto nivel de los procesos de negocio son plasmadas en este documento, en la forma más apropiada, como pueden ser diagramas entidad-relación, modelo de objetos de negocio, etc. Otras dos salidas son producidas en esta fase, la Definición de la Arquitectura del sistema, y un bosquejo del Plan de Prototipo. La definición de la arquitectura es el primer boceto, por lo que puede ser modificada durante el curso del proyecto. El plan de prototipo debería establecer una estrategia para la creación de los prototipos en las próximas etapas y un plan para la gestión de la configuración. 3. Iteración del modelo funcional. Es la primera fase iterativa e incremental. En cada iteración, se planea el contenido y el enfoque de la misma, se ejecuta la iteración y se analizan los resultados para las siguientes iteraciones. Se analiza y se codifica, se construyen prototipos y las experiencias ganadas son utilizadas para mejorar los modelos de análisis. Los prototipos nos son descartados por completo, poco a poco se van refinando y pueden ser incluidos en el sistema final. Un Modelo Funcional se produce como salida de esta fase, el cual contiene el 3 Talleres de trabajo.

44 Utilización Métodos Ágiles 36 código del prototipo y los modelos de análisis. El testeo es también una parte esencial de esta fase. Otros cuatro documentos son realizados en esta fase, en distintos momentos de la iteración. Un lista de las funciones priorizadas que serán entregadas al final de la iteración, un documento de revisión de la funcionalidad de los prototipos, donde se plasman comentarios de los usuarios sobre el prototipo actual y que sirve como entrada para próximas iteraciones. Se listan los requerimientos no funcionales sobre todo para ser tratados en la siguiente fase. El análisis de riesgos, para seguir el desarrollo es un documento muy importante en al fase de iteración del modelo funcional, ya que a partir próxima fase (iteración del diseño y construcción) en adelante, los problemas que se encuentren serán más difíciles de abordar. 4. Iteración del diseño y construcción. Es en esta fase donde se crea principalmente el sistema. La salida es un Sistema Testado que cumpla al menos con el mínimo de los requisitos acordados. El diseño y la construcción son iterativos, el diseño y los prototipos funcionales son revisados por los usuarios, y el desarrollo se basa en los comentarios de los usuarios. 5. Implantación. En esta fase el sistema se transfiere del ambiente de desarrollo al ambiente de producción. Se entrenan los usuarios en el uso del sistema. Si el número de usuarios es muy grande y la implantación puede ser hecha gradualmente, se pueden hacer iteraciones. Aparte del sistema entregado, como salida de esta fase también se incluye un Manual de Usuario y un Informe de Revisión del proyecto. Este último resume los resultados del proyecto y basándose en estos

45 Utilización Métodos Ágiles 37 resultados se estable el curso del desarrollo. DSDM define cuatro posibles cursos de desarrollo. Si el sistema cumple con todos los requerimientos, no hay más que hacer. Si una cantidad considerable de requerimientos se dejaron de lado, por ejemplo, porque no fueron descubiertos hasta que el sistema estuvo terminado, entonces el proceso vuelve a comenzar desde el principio. Si alguna funcionalidad no crítica fue omitida, el proceso puede iniciarse otra vez desde la fase de iteración del modelo funcional en adelante. Por último, si algunas cuestiones técnicas no pueden abordarse por falta de tiempo, pueden hacerse en este punto iterando nuevamente, comenzando desde la fase de iteración del diseño y construcción. Roles y Responsabilidades. DSDM define 15 roles para usuarios y desarrolladores (Stapleton, 1997). Los más relevantes son descriptos a continuación, traducidos de (Abrahamsson et al., 2002): Desarrolladores y Desarrolladores Senior Son los únicos roles de desarrollo. La categoría de senior se basa en la experiencia en las tareas que competen al desarrollador. Esta categoría también indica un nivel de liderazgo en el grupo. Estos dos roles cubren todo el staff de desarrollo, ya sean analistas, diseñadores, programadores o testers. Coordinador Técnico Este define la arquitectura del sistema y es responsable de la calidad técnica del proyecto. También es responsable del control técnico del proyecto, como el uso del software para gestión de la configuración. Usuario Embajador De los roles de usuario este es el mas importante. Su tarea es traer al grupo de desarrollo el conocimiento de la comunidad de usuarios, y diseminar la información sobre el

46 Utilización Métodos Ágiles 38 progreso del proyecto al resto de los usuarios. Esto asegura el feedback necesario para el proyecto. Este usuario debe provenir de la comunidad de usuarios que eventualmente usaran el sistema. Usuario Asesor Dado que el usuario embajador no puede representar todos los puntos de vista del resto de los usuarios, aparece este rol. Puede ser cualquier usuario que represente un punto de vista importante para el proyecto. Por ejemplo el auditor financiero, el staff IT, etc. Visionario Es el usuario que tiene la percepción mas precisa de los objetivos del negocio del sistema y del proyecto. Es probablemente la persona que inicialmente tuvo la idea de construir el sistema. Su tarea es asegurar que los requerimientos esenciales son encontrados al principio del proyecto y que el proyecto se esta desarrollando en la dirección correcta desde el punto de vista de esos requerimientos. Sponsor Ejecutivo Es la persona de la organización del usuario que tiene la responsabilidad y autoridad financiera. Tiene la última palabra en la toma de decisiones. Adaptabilidad Para resolver la cuestión de la aplicabilidad de DSDM a un proyecto convendrá responder las siguientes preguntas (Schenone, 2004): Será la funcionalidad razonablemente visible en la interfase del usuario? Se pueden identificar todas las clases de usuarios finales? Es la aplicación computacionalmente compleja? Es la aplicación potencialmente grande? Si lo es, puede ser particionada en componentes funcionales más pequeños? Está el proyecto realmente acotado en el tiempo?

47 Utilización Métodos Ágiles 39 Son los requerimientos flexibles y sólo especificados a un alto nivel? Las mismas refieren a las características que se deben cumplir en los proyectos para poder utilizar el enfoque RAD de construcción. Se observa que aquellos proyectos que califiquen afirmativamente de acuerdo a dichas preguntas tendrán las siguientes características que refieren a la aplicabilidad de DSDM: Son proyectos interactivos con la funcionalidad visible en la interfase de usuario 1. De baja o media complejidad computacional. 2. Particionables en componentes de funcionalidad más pequeños si la aplicación es de gran tamaño. 3. Acotados en el tiempo. 4. Con flexibilidad en los requerimientos. 5. Con un grupo de usuarios bien definidos y comprometidos al proyecto. De esta forma observamos que DSDM deja las bases sentadas para el análisis sobre su aplicabilidad a un espectro bien definido de proyectos de software. Sin embargo, la metodología no tiene ninguna prescripción respecto a las técnicas a ser usadas en el proyecto, ni siquiera impone el desarrollo bajo un paradigma específico, funciona tanto para el modelo de orientación a objetos como para el modelo estructurado. Algo que sí sugiere el método es la generación de un conjunto mínimo de modelos necesarios para la sana progresión de la entrega del software y facilidad en el mantenimiento. Estos modelos esenciales deberán ser definidos antes que comience el desarrollo, y deberán ser revisados en las sucesivas iteraciones para validad su contenido. Se ha elaborado en particular la combinación de DSDM con XP y se ha llamado a esta mixtura EnterpriseXP, término acuñado por Mike Griffiths de Quadrus Developments. Se atribuye a Kent Beck haber afirmado que la comunidad de DSDM ha construido una imagen corporativa mejor que la del mundo XP y que sería conveniente aprender de esa experiencia.

48 Utilización Métodos Ágiles 40 También hay documentos conjuntos de DSDM y Rational, con participación de Jennifer Stapleton, que demuestran la compatibilidad del modelo DSDM con RUP, a pesar de sus fuertes diferencias terminológicas (Reynoso, 2004). Lean Development (LD) y Lean Software Development (LSD) Lean Development fue iniciado por Bob Charette y se inspira en el éxito del proceso industrial Lean Manufacturing, bien conocido en la producción automotriz y en manufactura desde la década de Este proceso tiene como precepto la eliminación de residuos a través de la mejora constante, haciendo que el producto fluya a instancias del cliente para hacerlo lo más perfecto posible. Los procesos a la manera americana corrían con sus máquinas al 100% de capacidad y mantenían inventarios gigantescos de productos y suministros; Toyota, en contra de la intuición, resultaba más eficiente manteniendo suministros en planta para un solo día, y produciendo sólo lo necesario para cubrir las órdenes pendientes. Esto es lo que se llama Just in Time Production. Con JIT se evita además que el inventario degrade o se torne obsoleto, o empiece a actuar como un freno para el cambio. Otros aspectos esenciales de Lean Manufacturing son la relación participativa con el empleado y el trato que le brinda la compañía, así como una especificación de principios, disciplinas y métodos iterativos, adaptativos, auto-organizativos e interdependientes en un patrón de ciclos de corta duración que tiene algo más que un aire de familia con el patrón de procesos de los Métodos Ágiles. Existe unanimidad de intereses, consistencia de discurso y complementariedad entre las comunidades Lean de manufactura y desarrollo de software (Reynoso, 2004). Principios Aunque Charette fue quien desarrollo el método, no hay mucha bibliografía escrita por él en la actualidad, por lo que se van a desarrollar los principios de Lean según lo

49 Utilización Métodos Ágiles 41 describen Tom y Mary Poppendieck (2003, 2006) en su libros, tomado de la traducción realizada en (De Seta, 2009). Eliminar el Desperdicio Brindar un liderazgo técnico y de mercado. La organización puede ser exitosa si produce productos innovadores y tecnológicamente avanzados, pero es importante comprender lo que valoran los clientes y conocer la tecnología que se está usando. Crear solamente cosas de valor. Hay que ser cuidadoso con todos los procesos que se siguen. Por ejemplo, debe asegurarse que todos los procesos son útiles y están enfocados en crear valor. Escribir menos código. Mientras más código se tenga, más pruebas se van a necesitar, por lo que se necesitará más trabajo. Si se escriben pruebas para funcionalidad que no se necesitan, esta perdiendo el tiempo. Los principales tipos de desperdicios son: 1. Funcionalidad que se desarrolla y no se utiliza en producción. Esto genera código extra, el cual tuvo que seguirse, compilarse y testearse, el mismo incrementa la complejidad y es un posible punto de fallo. 2. La documentación. Consume recursos, demoras, se pierde y se vuelve obsoleta. Si se utiliza, que sea solo la necesaria. 3. Asignar una misma persona a múltiples proyectos. Cada vez que el desarrollador de software tiene que cambiar entre tareas, pierde un tiempo significativo para recordar de que se trataba el proyecto. Pertenecer a diferentes equipos de trabajo causa más interrupciones que beneficios. 4. Las Esperas

50 Utilización Métodos Ágiles 42 Uno de los grandes desperdicios, en cuanto a tiempo, es esperar a que sucedan cosas: se espera al comienzo del proyecto, en la definición de requerimientos, en el armado de la excesiva documentación, en la codificación, en revisión y aprobación, en testeo, etc. 5. Puesta en marcha. Cuando un desarrollador tiene una pregunta, cuanto cuesta encontrar la respuesta? Los requerimientos van a los analistas, de los analistas a los diseñadores, de aquí a los desarrolladores y luego al testeo, en cada pasaje es probable que se pierda algo, ya que un porcentaje de conocimiento tácito queda con el creador del documento y no se transmite. 6. Errores en el Software. El porcentaje de desperdicio causado por un error se puede medir como el impacto del mismo por el tiempo sin ser detectado. Hay que encontrarlos en cuanto ocurran, corregirlos, testearlos y actualizar la versión en producción. Crear Conocimiento Crear equipos de diseño y construcción. El líder del equipo de desarrollo tiene que escuchar a los miembros y hacerles preguntas inteligentes que los incite a buscar respuestas y volver lo más pronto posible con los problemas que surgen, o con las soluciones inventadas. Mantener una cultura de mejora continua. Crear un ambiente en donde las personas estén mejorando continuamente en lo que trabajan, deben saber que no son y no deben ser perfectas, y que siempre tienen algún área que pueden mejorar. Enseñar métodos de resolución de problemas. Los equipos de desarrollo deberían comportarse como pequeños centros de investigación, estableciendo hipótesis y realizando varios experimentos rápidos para verificar su validez.

51 Utilización Métodos Ágiles 43 Construir con Calidad Código Prueba y Error usando Test Driven Development. Escribir especificaciones ejecutables en lugar de requerimientos. Automatizar. Automatizar las pruebas, la construcción, las instalaciones, y cualquier cosa que sea rutinaria. Hay que automatizar de una manera inteligente, de forma que las personas puedan mejorar el proceso y cambiar cualquier cosa que quieran sin preocuparse por si el cambio hace que las cosas dejen de funcionar. Refactorizar. Eliminar la duplicación. Cada vez que aparezca la oportunidad, realizar la refactorización del código, de las pruebas y de la documentación para minimizar la complejidad. Postergar el Compromiso Agendar las decisiones irreversibles hasta el último momento responsable. Debe saber hacia donde quiere ir pero no conoce el camino del todo, lo va descubriendo día a día, lo más importante es mantener la dirección correcta. Romper con las dependencias. Los componentes deben estar lo más desacoplados posibles para que puedan implementarse en cualquier orden. Mantener opciones. Desarrollar múltiples soluciones para todas las decisiones críticas y ver cuales funcionan mejor. Optimizar el Total Enfocarse en el flujo completo de valor. Enfocarse en ganar la carrera completa (que es el software). No hay que gastar esfuerzo en optimizar ineficiencias locales, sino en ver el todo y optimizar a la organización en su totalidad. Entregar un producto completo. Los equipos necesitan tener buenos líderes, y también buenos ingenieros, vendedores, especialistas de marketing, secretarias, etc. Todos juntos pueden entregar un gran producto final a los clientes.

52 Utilización Métodos Ágiles 44 Entregar Rápido. Trabajar en bloques pequeños. Reducir el tamaño del proyecto, acortar los ciclos de entrega, estabilizar el ambiente de trabajo, repetir lo bueno y erradicar las prácticas que crean obstáculos. Limitar el trabajo a la capacidad. Limitar la cola de tareas al mínimo (una o dos iteraciones por delante es suficiente), no hay que tener miedo al quitar elementos de la cola, rechazar cualquier trabajo hasta que se haya vaciado un lugar en la cola. Enfocarse en el tiempo del ciclo, no en la utilización. Agregar tareas pequeñas a la cola que no puedan atascar al proceso por un tiempo largo, reducir el tiempo del ciclo y tener pocas cosas para procesar en la cola. Respetar a las Personas. Capacitar a los líderes de equipo. Darles a los líderes de equipo entrenamiento, guías y espacio libre para implementar el pensamiento Lean en su ambiente. Mover la responsabilidad y la toma de decisiones al nivel más bajo posible. Dejar que las personas piensen y decidan por su cuenta, ellos saben mejor que nadie cómo implementar algoritmos difíciles y aplicar tecnologías de última generación. Fomentar orgullo por el trabajo. Fomentar la pasión y la participación del equipo hacia lo que hacen y cómo lo hacen. La aplicación de los principios Lean en el desarrollo de software permite mejorar los procesos y así obtener mejores resultados. Aumenta la calidad del producto, posibilitando bajar los costos y acortar los tiempos de desarrollo. Lo importante es poder entender y adoptar la esencia de los principios Lean. Es claro que su aplicación puede ser difícil en algunas compañías, ya que requiere un cambio importante en la cultura y en los hábitos organizacionales. Pero las mejoras que se pueden

53 Utilización Métodos Ágiles 45 lograr son importantísimas, no solo en el producto final sino también en su evolución, en la participación, compromiso y satisfacción de las personas involucradas. Herramientas A continuación se mencionan dos herramientas de las que se vale Lean para implementar sus principios. Value Stream Mapping (Mapa de la cadena de valor). Es una herramienta fundamental en la aplicación del Lean Manufacturing, que permite tener una visión clara de toda la cadena de valor, desde que el cliente hace un pedido hasta la entrega del producto o servicio. El VSM, es un mapa que muestra todas las acciones (de valor añadido y sin valor añadido) necesarias en términos de flujo del material físico y flujo de información para entregar un producto al cliente. Esta herramienta de lápiz y papel, ha sido desarrollada por el Profesor Mike Rother junto con James Womack y Dan Jones (co-autores del libro Lean Thinking). Es una herramienta estratégica y operativa que permite englobar la situación actual de la empresa y, a la vez, mostrar los puntos clave de mejora con el fin de llegar a un estado futuro ideal de flujo, y perfección en las cadenas de valor ( Optimización de Procesos operativos, s.f.). Kanban. La palabra kanban proviene del japonés y parte de las palabras kan que significa visual y ban que significa tarjeta o tablero. Es un sistema para gestionar procesos, basándose en técnicas como just-in-time (JIT), inventado por Taichi Ohno en Toyota (hace 50 años). Los principios que promueve son: Calidad perfecta. Todo lo que se hace, debe de intentar hacerse bien, no rápido, ya que cuesta más tiempo hacer algo rápido y tener que arreglarlo después, que hacerlo bien desde el principio.

54 Utilización Métodos Ágiles 46 Minimización del desperdicio. Hacer lo justo y necesario (y hacerlo bien, como se decía antes) y no entretenerse en otras tareas secundarias o no necesarias (principio YAGNI). Mejora continua. Ir mejorando continuamente los desarrollos, según los objetivos a lograr y alcanzar. Flexibilidad. Lo siguiente a realizar se decide del backlog pendiente, con lo que las tareas entrantes se pueden priorizar y condicionar según las necesidades puntuales. Construcción y mantenimiento de una relación a largo plazo con los proveedores. En el desarrollo del software, el sistema kanban se puede resumir como la visualización de las tareas mediante un tablero, en el que se van moviendo entre los sectores delimitados, con el objetivo de tener siempre presente el trabajo a realizar y lo que hace cada uno. Que nadie se quede sin trabajo y que todas las tareas importantes se realicen primero. El tablero de kanban, el cual debe estar visible a todo el equipo de trabajo, tiene la peculiaridad de ser un tablero continuo. Esto quiere decir que, no se rellena con tarjetas y se van desplazando hasta que toda la actividad ha quedado realizada (como pasa en Scrum), sino que a medida que se avanza, las nuevas tareas (mejoras, fallos o tareas del proyecto) se van acumulando en la sección inicial, en las reuniones periódicas con el dueño de producto (o el cliente) se priorizan las más importantes, y se encolan en las siguientes zonas. Además, las secciones que se pueden incluir en el tablero, además de diseño, desarrollo y pruebas, son las de paso a producción, con lo que, se tendrían todas las tareas en un seguimiento exhaustivo, desde que se piensan que deben de hacerse, hasta el punto en que se ha llevado a producción. Como se puede ver en la figura 14, cada sección vertical, puede anidarse en conjuntos, de modo que la tarea de desarrollo, por ejemplo, pueda descomponerse en otras más significativas como: en cola y en desarrollo. Los grandes grupos verticales, pueden pertenecer incluso a grupos de desarrollo diferentes, por ejemplo, un grupo de desarrollo puede encargarse del desarrollo, y otro de las

55 Utilización Métodos Ágiles 47 pruebas y subida a producción, o incluso entre departamentos, tomando un último grupo para puesta en producción o incluso un primer grupo para la toma de propuestas y priorización de tareas. Lo más corriente es que exista un grupo inicial, el dueño del producto, que se encargue de organizar las propuestas o entradas, y sea el propio cliente o incluso, si es para desarrollos internos, los departamentos de comercial y/o marketing. Figura 14. Tablero Kanban La importancia de la identificación rápida de tarjetas, en un tablero de amplias dimensiones es vital para ahorrar tiempo, con lo que, se pueden asignar colores, como pueden ser: verde para las mejoras, amarillo para las tareas del proyecto y rojo para los errores. Además de esto, las tarjetas de kanban suelen tener bastante más información, ya que el método consiste en tener todo visual, para saber de forma rápida la carga total de trabajo, ya sea de los grupos, como del departamento, etc. Es importante destacar que las tarjetas deben de tener la estimación de tiempo que tiene asignada la tarea, así como se pueden anotar las fechas de entrada en cada cuadrante, para tener información, al término de la tarea, de si ha sido una buena estimación, así como obtener el rendimiento del equipo de trabajo. El sistema kanban, no se dedica a llevar la pista de un solo proyecto, sino que se pueden entremezclar tareas y proyectos. El método se basa en tener a los trabajadores con un flujo de trabajo constante, las tareas más importantes en cola para ser realizadas y un seguimiento pasivo, a modo de no tener que interrumpir al trabajador para saber qué hace en cada momento.

56 Utilización Métodos Ágiles 48 El sistema de kanban tiene ciertas ventajas con relación a otras metodologías, ya que permite no solo llevar el seguimiento de un proyecto de forma individual, sino también de las incidencias que se van sucediendo, así como otros proyectos paralelos que tenga que hacer el mismo equipo de desarrollo, por lo que se puede deducir es que no se lleva pista de los proyectos, sino de los equipos de trabajo. Los conceptos de kankan fueron tomados de (Rubio Jiménez, 2009). Extreme Programming (XP) A mediados de la década de 1980, Kent Beck y Ward Cunningham trabajaban en un grupo de investigación de Tektronix; allí idearon las tarjetas CRC y sentaron las bases de lo que después serían los patrones de diseño y XP. Los patrones y XP no necesitan presentación, pero las tarjetas CRC tal vez sí. Se trata de simples tarjetas de papel para fichado, de 4x6 pulgadas; CRC denota Clase-Responsabilidad-Colaboración, y es una técnica que reemplaza a los diagramas en la representación de modelos. En las tarjetas se escriben las Responsabilidades, una descripción de alto nivel del propósito de una clase y las dependencias primarias. En su economía sintáctica y en su abstracción, prefiguran a lo que más tarde serían las tarjetas de historias de XP. En la década siguiente, Beck fue empleado por Chrysler para colaborar en el sistema de liquidación de sueldos en Smalltalk que se conoció como el proyecto C3 (Chrysler Comprehensive Compensation). Más tarde se unieron al proyecto Ron Jeffries y Martin Fowler, ulterior líder de Cutter Consortium 4. Previsiblemente, terminaron desarrollando C3 en una especie de proto-xp. La primera fase del C3 fue muy exitosa y comenzó a principios de El proyecto continuó desde entonces y después se encontró con dificultades, lo que resultó en la cancelación del desarrollo en 1999 (Reynoso, 2004). 4 Es una firma de consultoría IT compuesta por un grupo de mas de 150 expertos reconocidos internacionalmente, que se han unido para ofrecer investigación, consultoría y formación a sus clientes

57 Utilización Métodos Ágiles 49 En la gestación de C3 se encuentra no sólo la raíz de XP, sino el núcleo primitivo de la comunidad ágil. De la mano de Kent Beck, XP ha conformado un extenso grupo de seguidores en todo el mundo, disparando una gran cantidad de libros a los que dió comienzo el mismo Beck con la publicación de su libro (Beck, 1999) y posteriormente (Beck y Andrés, 2004). Inclusive Addison-Wesley ha creado una serie de libros denominada The XP Series. Fue la misma gente del proyecto C3 la que produjo también otro de los libros importantes de XP (Jeffries, Anderson y Hendrickson, 2000), en el que se bajaban los conceptos de Beck a la puesta en práctica en un proyecto. Figura 15. Gestación de XP (Abrahamsson et al., 2002) La imagen mental de Beck al crear XP era la de perillas en un tablero de control. Cada perilla representaba una práctica que de su experiencia sabía que trabajaba bien. Entonces, Beck decidió girar todas las perillas al máximo para ver que ocurría. Así fue como dio inicio a XP. (Schenone, 2004). XP se centra en la continua retroalimentación entre el cliente y el equipo de desarrollo, la comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. Se define como una metodología especialmente adecuada para proyectos con requisitos muy cambiantes e imprecisos, donde existe un alto riesgo técnico.

58 Utilización Métodos Ágiles 50 Figura 16. Evolución de los largos ciclos de desarrollo en cascada (a) a ciclos iterativos más cortos (b) y a la mezcla que hace XP (Acebal y Cueva, 2002) Valores. La programación extrema, lejos de ser un proceso incontrolado, es una metodología muy disciplinada y que se apoya en cinco valores fundamentales (Berrueta, 2006 ; Calero Solís, 2003): 1. Comunicación. Se hace énfasis en que la comunicación, para ser efectiva, debe involucrar a todos los participantes en el proyecto, y debe ser libre y sincera. Cada uno es parte de un equipo se comunican cara a cara todos los días. Trabajan todos juntos desde los requerimientos hasta la codificación. Entre todos deben crear la mejor solución para el problema. 2. Simplicidad. Nunca debe perderse de vista que el objetivo de un proyecto es proporcionar valor al cliente; no es demostrar la pericia técnica del equipo ni construir una aplicación que resuelva más problemas que los del cliente. La sencillez y la comunicación se complementan, cuanto mas simple es el sistema menos tienes que comunicar de él.

59 Utilización Métodos Ágiles Retroalimentación. No se puede dirigir adecuadamente un proceso si no se dispone de retroalimentación permanente sobre su progreso. Puede provenir del cliente, de los programadores, de herramientas automáticas, etc. La retroalimentación actúa junto con la sencillez y la comunicación, cuanto mayor retroalimentación más fácil es la comunicación. Cuanto mas simple un sistema mas fácil de probar. 4. Valentía. A veces, hacer lo que es correcto requiere valor. Se debe hacer frente a los cambios cualquiera sea el momento del proceso en el que lleguen. 5. Respeto. Todos deben dar y recibir el respeto que merecen como un valorado miembro del equipo. Todos contribuyen valor cualquiera sea su rol. Los desarrolladores respetan la experiencia de los clientes y viceversa. La dirección respeta el derecho a aceptar responsabilidad y recibir autoridad sobre el trabajo realizado. (Wells, 2009). Estos valores dan origen a cinco principios básicos: conseguir retroalimentación rápida, no complicar las cosas con suposiciones (asumir que las cosas son simples), realizar cambios incrementales, abrazar el cambio y generar productos de calidad. Los cinco principios se manifiestan a través de las prácticas de la programación extrema. Las Doce Prácticas de XP La principal suposición que se realiza en XP es la posibilidad de disminuir la mítica curva exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseño evolutivo funcione. XP apuesta por un crecimiento lento del costo del cambio y con un comportamiento asintótico. Esto se consigue gracias a las tecnologías disponibles para

60 Utilización Métodos Ágiles 52 ayudar en el desarrollo de software y a la aplicación disciplinada de las prácticas (Letelier y Penadés, s.f.). Las doce prácticas de la programación extrema tienen su origen en prácticas bien conocidas en la ingeniería del software y en el sentido común, y por tanto, no pueden resultar extrañas. Sin embargo, lo que caracteriza a este conjunto es la cohesión de todos los elementos, y que cada práctica ha sido llevada al extremo (Berrueta, 2006). Figura 17. El costo de un cambio. A continuación se desarrollan las doce prácticas según (Beck, 1999), tomadas de (Abrahamsson et al., 2002; Letelier y Penadés, s.f.; Programación en pares, 2005; Reynoso, 2004). El Juego de la Planificación. Es un espacio frecuente de comunicación entre el cliente y los programadores. El equipo técnico realiza una estimación del esfuerzo requerido para la implementación de las historias de usuario y los clientes deciden sobre el ámbito y tiempo de las entregas y de cada iteración. Esta práctica se puede ilustrar como un juego, donde existen dos tipos de jugadores: Cliente y Programador. El cliente establece la prioridad de cada historia de usuario, de