Utilizacin Mtodos giles

La Utilizacin de los Mtodos 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 Prctica Profesional en Sistemas

Profesora: Lic. Fabiana Escobar Profesora: Lic. Marcela lvarez Profesor: Lic. Emiliano Ricci

Licenciatura en Sistemas Mayo, 2010.

Utilizacin Mtodos giles Abstract El presente trabajo tiene como objetivo relevar el uso de las Metodologas giles en empresas de desarrollo de software de la Argentina. Se pretende conocer cuales son los mtodos y las tcnicas giles mas utilizadas, como as tambin la conformacin 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 mtodos. El desarrollo contiene un resumen de las caractersticas principales de los mtodos giles ms 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 saba de antemano que utilizaban metodologas 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: Mtodos o Metodologas 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

Utilizacin Mtodos 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

Utilizacin Mtodos giles ndice de Contenidos Agradecimientos ndice de Contenidos ndice de Figuras INTRODUCCIN METODOLOGAS GILES Origen Manifiesto gil para Desarrollo de Software Las Metodologas Adaptive Software Development (ASD) Agile Unified Process (AUP) Fases Disciplinas Crystal Methodologies Roles Estrategias Tcnicas Feature Driven Development (FDD) Desarrollar un Modelo Global Construir una Lista por Rasgos Planear por Rasgo Disear por Rasgo y Construir por Rasgo Roles y Responsabilidades Reporte de las Tareas Prcticas iii iv vii 1 3 3 4 10 11 13 14 15 16 20 21 22 23 24 25 25 25 26 29 30

iv

Utilizacin Mtodos giles mbito Dynamic Systems Development Method (DSDM) El Proceso Roles y Responsabilidades Adaptabilidad Lean Development (LD) y Lean Software Development (LSD) Principios Herramientas Value Stream Mapping Kanban Extreme Programming (XP) Valores Las Doce Prcticas de XP Las Historias de Usuario El Ciclo de Vida de XP Roles y Responsabilidades Scrum Qu es Scrum Requisitos para Poder Utilizar Scrum Roles y Responsabilidades Caractersticas de Scrum El Proceso Planificacin de la Iteracin (Sprint Planning) Ejecucin de la Iteracin (Sprint) 32 32 33 37 38 40 40 45 45 45 48 50 51 58 59 62 64 66 69 74 80 87 87 98

Demostracin de Requisitos Completados (Sprint Demonstration) 102

Utilizacin Mtodos giles Retrospectiva (Sprint Retrospective) LAS ENCUESTAS Introduccin Resultados Obtenidos Las Respuestas Pregunta 1 Metodologas utilizadas Pregunta 2 Experiencia Pregunta 3 Las Tcnicas Pregunta 4 Los Clientes Pregunta 5 Los Grupos de trabajo Pregunta 6 Certificaciones de Calidad Pregunta 7 Casos de xito Los Participantes CONCLUSIONES REFERENCIAS 104 106 106 107 108 108 112 116 125 132 139 142 150 158 161

vi

Utilizacin Mtodos giles ndice de Figuras Figura 1. Manifiesto para el desarrollo gil del software Figura 2. Comparacin entre metodologas giles y tradicionales Figura 3. El ciclo de vida adaptativo Figura 4. Actividades del ciclo de vida adaptativo Figura 5. Ciclo de vida de AUP Figura 6. La familia de Mtodos Crystal Figura 7. Efectividad de comunicacin entre miembros del equipo Figura 8. Las cinco estrategias de Crystal Figura 9. Los cinco procesos de FDD Figura 10. Diseo y Construccin en FDD Figura 11. Reportando el progreso al management y al cliente en FDD Figura 12. Ejemplo de modelo de Dominio Figura 13. Diagrama de procesos de DSDM Figura 14. Tablero Kankan Figura 15. Gestacin de XP Figura 16. Evolucin de los ciclos de desarrollo en cascada a iterativos Figura 17. El costo de un cambio Figura 18. Las practicas se refuerzan entre si Figura 19. Clasificacin de las prcticas de XP Figura 20. Ciclo de vida de XP Figura 21. Formacin de Scrum Figura 22. El Proceso de Scrum Figura 23. Las cartas de Planning Poker Figura 24. La lista de requisitos priorizada 5 10 12 13 14 17 18 22 24 26 29 30 34 47 49 50 52 58 59 60 65 87 89 91

vii

Utilizacin Mtodos giles Figura 25. La lista de tareas de la iteracin Figura 26. Product burndown chart Figura 27. Sprint burndown chart Figura 28. El tabln de tareas Figura 29. Distribucin en el uso de los mtodos giles 95 96 97 98 111

Figura 30. Comparacin entre el uso de Scrum como nico framework de trabajo 112 Figura 31. Aos de experiencia en la aplicacin de mtodos giles Figura 32. Aos de experiencia y mtodos utilizados Figura 33. Utilizacin de los mtodos giles con los clientes Figura 34. Compromiso de los clientes con los proyectos. Figura 35. Cantidad de integrantes por equipo de trabajo Figura 36. Distribucin geogrfica de los equipos de trabajo Figura 37. Distribucin geogrfica de los equipos de trabajo Figura 38. Certificaciones de calidad Figura 39. Certificaciones de calidad ISO CMMi 114 115 131 131 137 138 139 141 142

viii

Utilizacin Mtodos giles INTRODUCCIN La presente introduccin se divide en tres partes. La motivacin del estudio, donde se da a conocer el porqu de la realizacin del presente trabajo, el objetivo general donde se explica qu se pretende conocer sobre la aplicacin de las metodologas giles en el pas luego de terminado el proyecto, y por ltimo una breve descripcin de los contenidos. Motivacin del Estudio Iniciando el segundo cuatrimestre de 2009, el grupo de profesores del rea de Ingeniera de Software le propone a la autora realizar una investigacin sobre las metodologas giles utilizadas en las empresas dedicadas al desarrollo de software del pas. Las metodologas giles no haban sido estudiadas en profundidad durante la carrera, por lo tanto antes de comenzar a entrevistar empresas, haba que realizar una investigacin y un estudio de las mismas. Habiendo aceptado el desafo se desarroll el presente trabajo. Objetivo General El objetivo del trabajo es conocer cuales son las metodologas giles ms utilizadas en el pas, que experiencia de trabajo hay en la actualidad sobre el desarrollo de software con mtodos giles, cuales son las tcnicas ms 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 mtodos. Contenido El trabajo comienza con la presente introduccin, seguida a continuacin por el desarrollo. Dicha seccin se divide en dos partes. La primera es el marco terico, donde se hace una introduccin a las metodologas giles, y el Manifiesto gil, y seguidamente se describen las caractersticas principales de algunos de los mtodos giles ms conocidos, poniendo nfasis en los que ms se mencionaron en las encuestas (Scrum y XP).

Utilizacin Mtodos giles

En la segunda parte se presentan las respuestas, el procesamiento y el anlisis de las encuestas realizadas. Tambin se describen las empresas y personas que fueron relevadas y autorizaron su mencin. 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.

Utilizacin Mtodos giles METODOLOGAS GILES Origen

Tradicionalmente se ha tendido a desarrollar software a travs de metodologas basadas

en procesos predefinidos con documentacin muy precisa, y una detallada planificacin inicial que debe seguirse estrictamente. Esta forma de trabajar surgi naturalmente hace unos cincuenta aos como una adaptacin del manejo de proyectos de ingeniera, que era lo ms parecido a desarrollar programas que se conoca 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 inversin informtica se la llevaban los equipos y por esta razn los programas se hacan a medida para las mquinas que se adquiran, para realizar tareas muy concretas (Colusso, s.f.).
En este contexto se desarrollaron diferentes metodologas a lo largo de los aos como el modelo en cascada, que sirvi luego como base para la formulacin del anlisis estructurado, el cual fue uno de los precursores en este camino hacia la aplicacin de prcticas estandarizadas dentro de la ingeniera de software. El proceso era desarrollado en forma de cascada ya que se requera la finalizacin de la etapa anterior para empezar la siguiente. Esto generaba un congelamiento temprano de los requerimientos, los cuales al presentar cambios requeran 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 aplicacin en forma progresiva, agregando funcionalidad sucesivamente. Las iteraciones representan un mini-proyecto autocontenido el cual est compuesto por todas las fases del desarrollo (requerimientos, diseo, implementacin, testing). Los incrementos estn 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

Utilizacin Mtodos giles

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 documentacin 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 tamao resulta a veces engorroso seguir esta metodologa rigurosamente. Para muchos de los

proyectos actuales donde el entorno del sistema es muy cambiante, y en donde se exige reducir drsticamente los tiempos de desarrollo pero manteniendo una alta calidad estos mtodos no son los ms adecuados. En este escenario, las metodologas giles emergen como una posible respuesta para llenar ese vaco metodolgico. Manifiesto gil para Desarrollo de Software.
A mediados de los aos 90 comenz a forjarse una definicin moderna de desarrollo gil del software como una reaccin contra las metodologas utilizadas hasta el momento, consideradas excesivamente pesadas y rgidas por su carcter normativo y fuerte dependencia de planificaciones detalladas previas al desarrollo.

En febrero de 2001, tras una reunin celebrada en Utah (EEUU), nace el trmino gil aplicado al desarrollo de software. En esta reunin participan un grupo de 17 expertos1 de la industria del software, incluyendo algunos de los creadores o impulsores de metodologas de software. Su objetivo fue esbozar los valores y principios que deberan permitir a los equipos

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.

Utilizacin Mtodos giles desarrollar software rpidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Tras esta reunin se cre The Agile Alliance, una organizacin, 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 filosofa 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 deberan guiar las metodologas giles, extrado y adaptado de (Rodrguez Gonzlez, 2008; Fernndez Gonzlez, 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. Adems 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 tambin cuidarse. Un factor clave

Utilizacin Mtodos giles para el xito es construir un buen equipo, que se lleven bien entre ellos, y que adems sepan como construir su propio entorno de desarrollo. Es un error pretender construir primero el entorno y esperar que el equipo se adapte

automticamente sino que debe ser al revs, construir primero el equipo y que ste configure su propio entorno en base a sus necesidades y sus caractersticas personales. El talento, la habilidad, la capacidad de comunicacin y de tratar con personas son caractersticas fundamentales para los miembros de un equipo gil. 2. Desarrollar software que funcione por encima de una completa documentacin. Uno de los objetivos de una buena documentacin es poder ir a consultarla cuando haya que modificar algo del sistema. Si se tiene demasiada documentacin sobre un proyecto, cada modificacin 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 filosofa 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 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

Utilizacin Mtodos giles 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. 3. 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 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 comn. 4. 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 habilidad de responder a los cambios de requisitos, tecnologa, presupuestarios o estrategia, marca sin duda el camino del xito del proyecto. Como consecuencia de estos cuatro valores, el Manifiesto gil tambin enuncia los doce principios que caracterizan un proceso gil diferencindolo de otro convencional (Cans, Letelier y Penads, 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.

Utilizacin Mtodos giles 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 ms, a la vez que logran una mayor satisfaccin del cliente. Este principio implica adems que la estructura del software debe ser flexible para poder incorporar los cambios sin demasiado costo aadido. 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 documentacin de anlisis o de diseo. 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 interaccin 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 dems (proceso, entorno, gestin, etc.) queda en segundo plano. Si cualquiera de ellos tiene un efecto negativo sobre los individuos debe ser cambiado. 6. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro de un equipo de desarrollo. Los miembros de equipo deben hablar entre ellos, ste es el principal modo de comunicacin. Se pueden crear documentos, pero no todo estar en ellos.

Utilizacin Mtodos giles 7. El software que funciona es la principal medida de progreso. El estado de un proyecto no viene dado por la documentacin generada o la fase en la que se encuentre, sino por el cdigo generado y en funcionamiento. Un proyecto se encuentra al 50% si el 50% de los requisitos ya estn 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 ms rpido posible, sino de mantener el ritmo de desarrollo durante toda la duracin del proyecto, asegurando en todo momento que la calidad de lo producido es mxima. 9. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. Producir cdigo claro y robusto es la clave para avanzar ms rpidamente en el proyecto. 10. La simplicidad es esencial. Se debe saber maximizar el trabajo que no se debe realizar. Tomar los caminos ms simples que sean consistentes con los objetivos perseguidos. Si el cdigo producido es simple y de alta calidad ser ms sencillo adaptarlo a los cambios que puedan surgir. 11. Las mejores arquitecturas, requisitos y diseos 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.

Utilizacin Mtodos giles

10

12. En intervalos regulares el equipo debe reflexionar sobre cmo ser ms efectivo y ajustar su comportamiento para conseguirlo. Dado que el entorno est cambiando constantemente, el equipo tambin debe ajustarse al nuevo escenario de forma continua. Puede cambiar su organizacin, 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 prcticas y procesos a utilizar.

Figura 2. Comparacin entre metodologas giles y tradicionales (Cans, Letelier y Penads, s.f.) Las Metodologas A continuacin se mencionan algunas de las metodologas giles, se har una resea de las primeras, y una descripcin mas detallada de las ltimas dos, por ser estas las ms utilizadas segn el relevamiento realizado para la presente investigacin en las empresas de desarrollo de software de la Argentina. Adaptive Software Development (ASD).

Utilizacin Mtodos giles 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 tcnica de Adaptive Software Development fue desarrollada por Jim Highsmith

11

(Highsmith, 2000). Se basa en la adaptacin continua a circunstancias cambiantes. En ella no hay un ciclo de planificacin-diseo-construccin del software, sino un ciclo de tres fases: especular, colaborar y aprender, extradas de (Armour, 2004). Especular Una primera fase de iniciacin 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 atencin de los trabajadores que se mueven dentro de plazos de forma que puedan priorizar sus tareas. Se decide el nmero de iteraciones para consumir el proyecto, prestando atencin a las caractersticas que pueden ser utilizadas por el cliente al final de la iteracin. 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 estn satisfechos con el resultado.

Utilizacin Mtodos giles Colaborar

12

Es la fase donde se centra la mayor parte del desarrollo manteniendo una componente cclica. Un trabajo importante es la coordinacin 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 colaboracin, su trabajo consiste en capturar lo que se ha aprendido, tanto positivo como negativo. Es un elemento crtico 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 tcnica 3. El funcionamiento del equipo de desarrollo y las prcticas que este utiliza 4. El status del proyecto En la Figura 4 se puede ver el detalle interno de cada fase explicado, mostrndose con una flecha que trasciende las tres fases en sentido inverso, el bucle de aprendizaje. Este bucle es algo crtico para ASD ya que denota un cambio en el esquema tradicional de la vista de un sistema en que se tena un bucle de control para detectar diferencias y corregirlas. Es decir, en las metodologas tradicionales las diferencias respecto a lo planificado eran vistas como

Utilizacin Mtodos giles

13

errores que deban ser enmendados para que cumplieran lo pautado. ASD y las metodologas giles plantean la necesidad de que el feedback necesario sea para aprender, nos da la posibilidad de entender ms respecto al dominio y construir la aplicacin 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 versin simplificada del Rational Unified Process (RUP). Describe en forma simple y fcil de comprender el enfoque al desarrollo de software para aplicaciones empresariales utilizando las tcnicas y conceptos de agilidad y mantenindose fiel a las prcticas de RUP. El presente resumen es una traduccin de (Ambler, 2005) Scott W. Ambler es el autor de este mtodo. Comenz a escribir en 2001 artculos en la Web sobre como agilizar RUP, y luego en 2002 public su libro (Ambler, 2002). El enfoque aplica tcnicas giles que incluyen Test Driven Development (TDD), Agile Model Driven Development (AMDD), gestin del cambio gil, y refactorizacin 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, Anlisis y Diseo. Modelado es una parte importante de la AUP, como se puede ver, pero no dominan el proceso, que desea mantener la agilidad en la

Utilizacin Mtodos giles

14

creacin 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 gestin del cambio suelen formar parte de la gestin 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 financiacin inicial del proyecto y la aceptacin 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 ms alta prioridad las necesidades de los stakeholders del proyecto. 4. Transition. El objetivo es validar y desplegar el sistema en su entorno de produccin.

Utilizacin Mtodos giles 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

15

El objetivo de esta disciplina es entender el negocio de la organizacin, el dominio del problema que aborda el proyecto, y definir una solucin viable para hacer frente al mismo. Implementation El objetivo de esta disciplina es transformar el modelo en cdigo ejecutable y realizar un nivel bsico de las pruebas, en particular tests unitarios. Test El objetivo de esta disciplina consiste en realizar una evaluacin objetiva para garantizar la calidad. Esto incluye encontrar defectos, validar que el sistema funciona segn 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 disposicin de los usuarios finales. Configuration Management El objetivo de esta disciplina es la gestin de acceso a los artefactos del proyecto. Esto incluye no slo el seguimiento de las versiones de los artefactos en el tiempo, sino tambin el control y la administracin 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 gestin de riesgos, la direccin de las personas (la asignacin de tareas, el

Utilizacin Mtodos giles seguimiento del progreso, etc.), y la coordinacin de las personas y los sistemas fuera del

16

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 orientacin (y directrices), y herramientas (hardware, software, etc.) estn disponibles para el equipo segn 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 explcita cmo crear algunos de los artefactos que la administracin esta acostumbrada a ver. En el otro extremo est RUP, que a la administracin parece que le encanta, pero a los desarrolladores no tanto debido a la gran cantidad de artefactos. AUP surge entre los dos, con la adopcin de muchas de las tcnicas giles de XP y otros procesos giles que todava conservan algo de la formalidad de RUP. 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 miembros), Crystal Orange descripto en (Cockburn, 1997) (25 a 50 miembros), Crystal Red (50 a 100 miembros) y Crystal Blue (para ms de 100 miembros) (Rodriguez Gonzalez, 2008). Cada miembro de la familia de Crystal est marcado con un color que indica la "pesadez" de la metodologa, es decir, cuanto ms oscuro el color ms pesada la metodologa. Cristal sugiere elegir el color adecuado para cada proyecto basndose en su tamao y

Utilizacin Mtodos giles criticidad. En los proyectos mas grandes es probable que se necesite mas coordinacin y metodologas mas pesadas que en los mas pequeos. Cuanto mas crtico es el sistema a desarrollar, mayor rigor se necesita en la metodologa. En la figura 6, se puede observar que movindose hacia la derecha en el eje X, el nmero de personas en el proyecto aumenta lo que resulta en una disminucin de las comunicaciones cara a cara entre los miembros del equipo. Esto tambin significa que se debe utilizar una metodologa mas pesada. El eje Y denota la potencialidad del sistema y el rango desde perder confort hasta

17

incluso la vida. En trminos de la analoga de cristal, esto significa que el grado de "dureza" del proyecto se incrementa desplazndose hacia arriba en el eje Y. El contexto exterior determina los elementos necesarios en la metodologa y los productos derivados de los proyectos en el rango superior del eje Y. Proyectos de este tipo incluyen proyectos mdicos, proyectos de control areo, etc.

Figura 6. La familia de Mtodos Crystal (Cockburn, 2003)

Utilizacin Mtodos giles El eje Z refleja las diferentes prioridades como tiempo de salida al mercado, reduccin de costos o responsabilidad legal. Los cuadros indican la clase de proyectos en los que el tamao, la criticidad y los objetivos intersectan. En los trminos de colores que propone Crystal, los cuadros C6 y D6

18

son de Crystal Clear, aunque admite que podra extenderse para incluir el cuadro de E6. Los cuadros C20, D20 y E20 son agrupados bajo la denominacin 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 abarcaran 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. Tamao de un equipo (nmero de componentes) 3. Comunicacin entre los componentes 4. Distintas polticas a seguir 5. Espacio fsico de trabajo

Figura 7. Efectividad de comunicacin entre miembros del equipo (Fernandez Enrich, 2003)

Utilizacin Mtodos giles

19

Crystal Clear descripto en (Cockburn, 2001; Cockburn, 2004), es la metodologa ms ligera de este conjunto, y esta dirigida a la comunicacin de equipos pequeos que desarrollan software cuya criticidad no es elevada. Tiene asociadas siete caractersticas, traducidas de (Marcos, 2009): 1. Liberacin frecuente de funcionalidad. La propiedad ms importante de cualquier proyecto es hacer entregas, cada pocos meses, de cdigo testeado y funcionando a usuarios reales. Algunas de las ventajas son: Los sponsors reciben comentarios crticos 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 indecisin Los equipos depuran su desarrollo y el proceso de implementacin. 2. Mejora reflexiva. Un equipo de desarrollo puede revertir su suerte de falla catastrfica a xito, si se renen y analizan si su trabajo esta funcionando o no, discutir que puede funcionar mejor y luego hacer los cambios en la prxima iteracin, en otras palabras, reflexionar y mejorar. 3. Comunicacin osmtica. La informacin fluye en el entorno de trabajo, por lo tanto los miembros del equipo adquieren informacin relevante por smosis. Esto es una consecuencia de estar todos sentados en el mismo espacio de trabajo.

Utilizacin Mtodos giles

20

Entonces, cuando un miembro hace una pregunta, los otros pueden contestar o no, contribuyendo a la discusin 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 daando 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 algn progreso, y segundo, se refiere a la direccin que el proyecto esta tomando. 6. Fcil 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 mnimo una reunin de dos horas, una vez por semana con el experto del negocio, y tener posibilidad de comunicarse telefnicamente cuando sea necesario. 7. Entorno tcnico con pruebas automatizadas, administracin de la configuracin e integracin continua. Debe haber integracin 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):

Utilizacin Mtodos giles Executive Sponsor (Patrocinador Ejecutivo) Project Manager (Jefe de Proyecto) Domain Expert (Experto en el Dominio) Usage Expert (Experto de uso) Designer-Programmer (Programador Diseador) Designer (UI Diseador) Tester (Realizador de Pruebas) Technical (Programador Tcnico) Estrategias Ni las estrategias ni las tcnicas 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 estn ms 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.

21

. 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 ms "cuerpo" al esqueleto inicial.

Utilizacin Mtodos giles Todas describen una forma de tomar ventaja del desarrollo incremental para establecer valor desde el principio. Tcnicas

22

Igual que con las estrategias, hay una lista de tcnicas propuestas por Crystal Clear, de las cuales se pueden ir tomando las ms convenientes segn el momento en que se encuentra el proceso de desarrollo del proyecto (Morales, 2007). Reuniones diarias. Acompaan el seguimiento y mantienen el foco en el prximo paso a seguir, y tambin permiten la discusin productiva de lneas a seguir. Reuniones de reflexin. Las reuniones de reflexin peridicas son fundamentales para que los miembros del equipo se expresen abiertamente, para revisar el trabajo hecho y evaluar qu cosas dan resultado y cules no o de empezar a trabajar. Programacin side-by-side. Consiste en dos personas sentadas lo suficientemente cerca como para ver la pantalla del otro fcilmente, pero cada una trabajando en su propia tarea, es una alternativa menos intensiva que la programacin de a pares. Todo esto permite ir armando una metodologa de trabajo que se adecue al equipo, el proyecto y los tiempos que se manejen. En Resumen la gua de trabajo que presenta Crystal Clear es altamente recomendable para equipos pequeos. Da flexibilidad y prioriza la parte humana, apuntando a lograr eficiencia, habitabilidad y confianza en los miembros del equipo. Presta especial importancia a la ubicacin fsica del grupo, donde la comunicacin cumple el rol principal. La entrega frecuente de cdigo confiable y funcionando mantiene el foco y evita distracciones. El equipo es el que elige qu tcnicas aplicar segn lo que consideren apropiado en cada proyecto.

Utilizacin Mtodos giles 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 implementacin de referencia, fue el Singapore Project; DeLuca haba sido contratado para salvar un sistema muy complicado para el cual el contratista anterior haba producido, luego de dos aos, 3500 pginas de documentacin y ninguna lnea de cdigo. Naturalmente, el proyecto basado en FDD fue

23

todo un xito, y permiti fundar el mtodo en un caso real de misin crtica (Reynoso, 2004). En 2002, Palmer y Felsing publicaron un nuevo libro desarrollando esta metodologa. FDD se basa en un proceso iterativo con iteraciones cortas que producen un software funcional que el cliente y la direccin de la empresa pueden ver y monitorizar. Las iteraciones se deciden en base a features o funcionalidades, que son pequeas 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. Disear por Rasgo 5. Construir por Rasgo Los ltimos dos se hacen en cada iteracin. Este proceso iterativo soporta desarrollo gil con adaptaciones rpidas a cambios de ltimo momento y requerimientos del negocio. Cada proceso se divide en tareas y se da un criterio de comprobacin.

Utilizacin Mtodos 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 especficamente el tema de la recoleccin y gestin de los requerimientos. Los expertos del dominio presentan un walkthrough2 donde los miembros del equipo y el jefe de arquitectos son introducidos a una descripcin 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 pequeos 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. Simultneamente, el modelo global del sistema es construido.

Tutorial Ensayo Descripcin de un proceso paso a paso

Utilizacin Mtodos giles Construir una Lista de los Rasgos Los walkthroughs, modelos de objeto y documentacin de requerimientos proporcionan la base para construir una amplia lista de rasgos. En dicha lista, el equipo de

25

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 jerrquicamente para poder estructurar el trabajo de desarrollo; se realiza la priorizacin de los mismos basndose en la satisfaccin al cliente, las prioridades sugeridas por FDD son: A (debe tener), B (sera 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 creacin 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 ms importantes para los conjuntos de rasgos. Diseo por Rasgos y Construccin por Rasgos Se selecciona un pequeo 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 diseo y construccin son procedimientos iterativos durante los cuales son producidos los rasgos seleccionados. Una iteracin puede tomar de unos pocos das un mximo de dos semanas. Puede haber varios equipos diseando y construyendo concurrentemente su propio set de rasgos. Este proceso iterativo incluye inspeccin de diseo, codificacin, pruebas unitarias, integracin e inspeccin de cdigo. Luego de una iteracin satisfactoria, los rasgos completos son promovidos al proyecto principal mientras la

Utilizacin Mtodos giles iteracin de diseo y construccin comienza con un nuevo grupo de rasgos tomados del set. La figura 10 detalla como se desarrollan las iteraciones 4 y 5.

26

Figura 10. Diseo y Construccin en FDD (Abrahamsson et al., 2002). Roles y Responsabilidades El FDD clasifica sus roles en las siguientes tres categoras (Calabria, 2003): 1. Key roles: Project manager. Es el lder 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 diseo global del sistema y de la ejecucin de todas las etapas del diseo. Tambin tiene la ltima palabra sobre las decisiones del diseo 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. Adems, este rol

Utilizacin Mtodos 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 anlisis de los requerimientos y el diseo del proyecto. El Chief Programmer es el responsable de guiar a pequeos equipos en el anlisis, diseo y desarrollo de nuevas funcionalidades. Adems, selecciona las funcionalidades a desarrollar de la lista de funcionalidades de la prxima iteracin en la ltima fase del FDD, identifica las clases y el Class Owner que se necesita en el equipo para la iteracin. Con la ayuda de otros Chief Programmers resuelve problemas tcnicos y de recursos, y reporta el progreso del equipo durante la semana. Class owner. Trabaja bajo la gua del Chief Programmer en las tareas de diseo, codificacin, testing y documentacin. l es responsable del desarrollo de las clases que se le asignaron como propias. Para cada iteracin los Class Owner participan en la decisin de que clase ser incluida en la lista de funcionalidades de la prxima iteracin. 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:

Utilizacin Mtodos giles

28

Realese manager. Controla el avance del proceso mediante la revisin de los reportes del Chief Programmer y realiza pequeas reuniones con l. Adems, 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 especfico lenguaje de programacin o tecnologa. Este rol es particularmente importante cuando el equipo trabaja con una nueva tecnologa. Build engineer. Es la persona responsable de preparar, mantener y correr el proceso de construccin, incluidas las tareas de mantenimiento de las versiones y la publicacin de la documentacin. Toolsmith. Es un rol para la construccin de herramientas especficas para el desarrollo, conversin de datos y testeo. Adems, puede trabajar en la preparacin 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 recin 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 informacin existente requerida por el nuevo sistema y participa en el lanzamiento de los nuevos productos.

Utilizacin Mtodos giles Techical writer. Se encarga de preparar la documentacin para los usuarios, quienes pueden formar parte o no del equipo del proyecto.

29

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 rene con los Chief Programmers para que stos reporten como es el avance de las tareas. En esta reunin, que tiene una duracin 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 estn situados los dems 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 desempeo del mismo.

Utilizacin Mtodos giles Prcticas. FDD consiste de un conjunto de mejores prcticas y los desarrolladores del mtodo destacan que a pesar de que las prcticas seleccionadas no son nuevas, la mezcla especfica de estos ingredientes hace que los cinco procesos de FDD sean nicos para cada caso. Palmer y Felsing (2002) sostienen que las prcticas disponibles deben ser utilizadas para obtener el mayor beneficio del mtodo y no que una sola prctica domine todo el proceso. FDD consiste en las siguientes prcticas: 1. Modelo de Objetos del Dominio. Exploracin y explicacin del dominio del problema a resolver. Su resultado es un framework donde se agregan los rasgos del sistema. La tcnica que recomiendan los autores es modelar en colores, en la figura 12 se puede observar un ejemplo de un caso real.

30

Figura 12. Ejemplo de modelo de Dominio. 2. Desarrollo por rasgos. Desarrollo y seguimiento del progreso a travs de una lista de funciones descompuestas por funcionalidad y valoracin del cliente. Es importante restringir la lista a las funcionalidades que el cliente pueda entender, por eso se

Utilizacin Mtodos giles denomina a esta lista funciones valoradas por el cliente o simplemente rasgos. 3. Propietario individual de la clase (cdigo). 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 pequeos grupos dinmicos, bajo la supervisin de un Chief

31

Programmer. Los propietarios de las clases trabajan todos juntos y comparten sus ideas, los Chief Programmers tambin 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 deteccin de defectos. Las inspecciones tienen dos beneficios adicionales: transferencia de conocimiento y cumplimiento de los estndares. 6. Construir regularmente. Se refiere a asegurarse que siempre hay una versin del sistema disponible para mostrar. Las construcciones regulares son la base donde se agregan los nuevos rasgos al sistema. 7. Administracin de la configuracin. Permite la identificacin y seguimiento del historial de las ltimas versiones de cada archivo fuente terminado. Provee un seguimiento histrico de todos los artefactos que contienen la informacin del proyecto. 8. Reportar el progreso. El progreso es reportado basndose en trabajo terminado a todos los niveles de la organizacin que sea necesario. Los reportes deben ser frecuentes,

Utilizacin Mtodos 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 prctica para cumplir con FDD, sin embargo se le permite adaptarlas segn 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 diseo y construccin. Nada dice sobre la captura de requerimientos, el diseo de las interfaces ni la implementacin. Con respecto al tamao de los proyectos, es muy efectivo en proyectos grandes con una lgica de negocio compleja. Es apropiado para desarrollar sistemas crticos como as tambin para actualizar cdigo existente y hacer segundas versiones. Un rasgo llamativo de FDD es que no exige la presencia del cliente como otros mtodos giles. Dynamic Systems Development Method (DSDM) El DSDM (Dynamic Systems Development Method) empez en Gran Bretaa en 1994 como un consorcio de compaas del Reino Unido que queran construir sobre RAD (Rapid Applications Development) Desarrollo Rpido de Aplicaciones y desarrollo iterativo. Habiendo empezado con 17 fundadores ahora tiene ms de mil miembros y ha crecido fuera de sus races britnicas. Siendo desarrollado por un consorcio, tiene un sabor diferente a muchos de los otros mtodos giles. Tiene una organizacin de tiempo completo que lo apoya con manuales, cursos de entrenamiento, programas de certificacin y dems (DSDM Consortium y Stapleton, 2003). El Consorcio, tomando las mejores prcticas que se conocan en la industria y la experiencia trada por sus fundadores, liber la primera versin de DSDM a principios de 1995. A partir de ese momento el mtodo fue bien acogido por la industria, que empez a utilizarlo y a capacitar a su personal en las prcticas y valores de DSDM.

Utilizacin Mtodos giles Debido a este xito, el Consorcio comision al Presidente del Comit Tcnico, Jennifer

33

Stapleton (1997), la creacin de un libro que explorara la realidad de implementar el mtodo (Schenone, 2004). La estructura del mtodo 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 propsitos del negocio es el criterio esencial para la aceptacin de los entregables. 5. El desarrollo iterativo e incremental es necesario para converger hacia una correcta solucin del negocio. 6. Todos los cambios durante el desarrollo son reversibles. 7. Los requerimientos estn especificados a un alto nivel. 8. El testing es integrado a travs del ciclo de vida. 9. Un enfoque colaborativo y cooperativo entre todos los interesados es esencial. El Proceso DSDM define cinco fases en la construccin de un sistema como se puede observar en la figura 13. Las mismas son: a) estudio de factibilidad, b) estudio del negocio, c) iteracin del modelo funcional, d) iteracin del diseo y e) construccin, implantacin. 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 iteracin tiene que finalizar dentro del timebox. El tiempo permitido para cada iteracin esta planeado de antemano, junto con los resultados que la

Utilizacin Mtodos giles

34

iteracin garantiza producir. En DSDM, un la duracin tpica de un timebox es de unos pocos das a unas pocas semanas.

Figura 13. Diagrama de procesos de DSDM (Stapleton, 1997) A continuacin se desarrollan las fases del proceso, traducidas de (Abrahamsson et al., 2002): 1. Estudio de factibilidad. El estudio de factibilidad es una pequea fase que propone DSDM para determinar si la metodologa se ajusta al proyecto en cuestin. 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 caractersticas 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 tecnologa no son bien conocidas y no permiten decidir la factibilidad del proyecto. Este estudio de factibilidad no debe llevar ms que unas pocas semanas.

Utilizacin Mtodos giles 2. Estudio del negocio. En esta fase se analizan las caractersticas del negocio y de la tecnologa. Se recomienda realizar pequeos workshops3 donde un nmero suficiente de clientes expertos se renen y son capaces de considerar todos los aspectos

35

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 Definicin del rea de Negocio. Descripciones de alto nivel de los procesos de negocio son plasmadas en este documento, en la forma ms apropiada, como pueden ser diagramas entidad-relacin, modelo de objetos de negocio, etc. Otras dos salidas son producidas en esta fase, la Definicin de la Arquitectura del sistema, y un bosquejo del Plan de Prototipo. La definicin de la arquitectura es el primer boceto, por lo que puede ser modificada durante el curso del proyecto. El plan de prototipo debera establecer una estrategia para la creacin de los prototipos en las prximas etapas y un plan para la gestin de la configuracin. 3. Iteracin del modelo funcional. Es la primera fase iterativa e incremental. En cada iteracin, se planea el contenido y el enfoque de la misma, se ejecuta la iteracin 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 anlisis. 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

Talleres de trabajo.

Utilizacin Mtodos giles

36

cdigo del prototipo y los modelos de anlisis. El testeo es tambin una parte esencial de esta fase. Otros cuatro documentos son realizados en esta fase, en distintos momentos de la iteracin. Un lista de las funciones priorizadas que sern entregadas al final de la iteracin, un documento de revisin de la funcionalidad de los prototipos, donde se plasman comentarios de los usuarios sobre el prototipo actual y que sirve como entrada para prximas iteraciones. Se listan los requerimientos no funcionales sobre todo para ser tratados en la siguiente fase. El anlisis de riesgos, para seguir el desarrollo es un documento muy importante en al fase de iteracin del modelo funcional, ya que a partir prxima fase (iteracin del diseo y construccin) en adelante, los problemas que se encuentren sern ms difciles de abordar. 4. Iteracin del diseo y construccin. Es en esta fase donde se crea principalmente el sistema. La salida es un Sistema Testado que cumpla al menos con el mnimo de los requisitos acordados. El diseo y la construccin son iterativos, el diseo y los prototipos funcionales son revisados por los usuarios, y el desarrollo se basa en los comentarios de los usuarios. 5. Implantacin. En esta fase el sistema se transfiere del ambiente de desarrollo al ambiente de produccin. Se entrenan los usuarios en el uso del sistema. Si el nmero de usuarios es muy grande y la implantacin puede ser hecha gradualmente, se pueden hacer iteraciones. Aparte del sistema entregado, como salida de esta fase tambin se incluye un Manual de Usuario y un Informe de Revisin del proyecto. Este ltimo resume los resultados del proyecto y basndose en estos

Utilizacin Mtodos giles resultados se estable el curso del desarrollo. DSDM define cuatro posibles cursos de desarrollo. Si el sistema cumple con todos los requerimientos, no

37

hay ms 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 crtica fue omitida, el proceso puede iniciarse otra vez desde la fase de iteracin del modelo funcional en adelante. Por ltimo, si algunas cuestiones tcnicas no pueden abordarse por falta de tiempo, pueden hacerse en este punto iterando nuevamente, comenzando desde la fase de iteracin del diseo y construccin. Roles y Responsabilidades. DSDM define 15 roles para usuarios y desarrolladores (Stapleton, 1997). Los ms relevantes son descriptos a continuacin, traducidos de (Abrahamsson et al., 2002): Desarrolladores y Desarrolladores Senior Son los nicos roles de desarrollo. La categora de senior se basa en la experiencia en las tareas que competen al desarrollador. Esta categora tambin indica un nivel de liderazgo en el grupo. Estos dos roles cubren todo el staff de desarrollo, ya sean analistas, diseadores, programadores o testers. Coordinador Tcnico Este define la arquitectura del sistema y es responsable de la calidad tcnica del proyecto. Tambin es responsable del control tcnico del proyecto, como el uso del software para gestin de la configuracin. 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 informacin sobre el

Utilizacin Mtodos giles progreso del proyecto al resto de los usuarios. Esto asegura el feedback necesario para el

38

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 percepcin 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 direccin correcta desde el punto de vista de esos requerimientos. Sponsor Ejecutivo Es la persona de la organizacin del usuario que tiene la responsabilidad y autoridad financiera. Tiene la ltima palabra en la toma de decisiones. Adaptabilidad Para resolver la cuestin 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 aplicacin computacionalmente compleja? Es la aplicacin potencialmente grande? Si lo es, puede ser particionada en componentes funcionales ms pequeos? Est el proyecto realmente acotado en el tiempo?

Utilizacin Mtodos giles Son los requerimientos flexibles y slo especificados a un alto nivel? Las mismas refieren a las caractersticas que se deben cumplir en los proyectos para poder utilizar el enfoque RAD de construccin. Se observa que aquellos proyectos que califiquen afirmativamente de acuerdo a dichas preguntas tendrn las siguientes caractersticas 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.

39

2. Particionables en componentes de funcionalidad ms pequeos si la aplicacin es de gran tamao. 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 anlisis sobre su aplicabilidad a un espectro bien definido de proyectos de software. Sin embargo, la metodologa no tiene ninguna prescripcin respecto a las tcnicas a ser usadas en el proyecto, ni siquiera impone el desarrollo bajo un paradigma especfico, funciona tanto para el modelo de orientacin a objetos como para el modelo estructurado. Algo que s sugiere el mtodo es la generacin de un conjunto mnimo de modelos necesarios para la sana progresin de la entrega del software y facilidad en el mantenimiento. Estos modelos esenciales debern ser definidos antes que comience el desarrollo, y debern ser revisados en las sucesivas iteraciones para validad su contenido. Se ha elaborado en particular la combinacin de DSDM con XP y se ha llamado a esta mixtura EnterpriseXP, trmino acuado 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 sera conveniente aprender de esa experiencia.

Utilizacin Mtodos giles Tambin hay documentos conjuntos de DSDM y Rational, con participacin de Jennifer Stapleton, que demuestran la compatibilidad del modelo DSDM con RUP, a pesar de sus fuertes diferencias terminolgicas (Reynoso, 2004). Lean Development (LD) y Lean Software Development (LSD)

40

Lean Development fue iniciado por Bob Charette y se inspira en el xito del proceso industrial Lean Manufacturing, bien conocido en la produccin automotriz y en manufactura desde la dcada de 1980. Este proceso tiene como precepto la eliminacin de residuos a travs de la mejora constante, haciendo que el producto fluya a instancias del cliente para hacerlo lo ms perfecto posible. Los procesos a la manera americana corran con sus mquinas al 100% de capacidad y mantenan inventarios gigantescos de productos y suministros; Toyota, en contra de la intuicin, resultaba ms eficiente manteniendo suministros en planta para un solo da, y produciendo slo lo necesario para cubrir las rdenes pendientes. Esto es lo que se llama Just in Time Production. Con JIT se evita adems 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 relacin participativa con el empleado y el trato que le brinda la compaa, as como una especificacin de principios, disciplinas y mtodos iterativos, adaptativos, auto-organizativos e interdependientes en un patrn de ciclos de corta duracin que tiene algo ms que un aire de familia con el patrn de procesos de los Mtodos 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 mtodo, no hay mucha bibliografa escrita por l en la actualidad, por lo que se van a desarrollar los principios de Lean segn lo

Utilizacin Mtodos giles describen Tom y Mary Poppendieck (2003, 2006) en su libros, tomado de la traduccin realizada en (De Seta, 2009). Eliminar el Desperdicio Brindar un liderazgo tcnico y de mercado. La organizacin puede ser exitosa si produce productos innovadores y tecnolgicamente avanzados, pero es importante comprender lo que valoran los clientes y conocer la tecnologa que se est usando.

41

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 estn enfocados en crear valor. Escribir menos cdigo. Mientras ms cdigo se tenga, ms pruebas se van a necesitar, por lo que se necesitar ms 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 produccin. Esto genera cdigo extra, el cual tuvo que seguirse, compilarse y testearse, el mismo incrementa la complejidad y es un posible punto de fallo. 2. La documentacin. Consume recursos, demoras, se pierde y se vuelve obsoleta. Si se utiliza, que sea solo la necesaria. 3. Asignar una misma persona a mltiples 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 ms interrupciones que beneficios. 4. Las Esperas

Utilizacin Mtodos 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 definicin de requerimientos, en el armado de la excesiva documentacin, en la codificacin, en revisin y aprobacin, 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 diseadores, de aqu a los desarrolladores y luego al testeo, en cada pasaje es probable que se pierda algo, ya que un porcentaje de conocimiento tcito 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 versin en produccin. Crear Conocimiento Crear equipos de diseo y construccin. El lder del equipo de desarrollo tiene que escuchar a los miembros y hacerles preguntas inteligentes que los incite a buscar respuestas y volver lo ms 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 estn mejorando continuamente en lo que trabajan, deben saber que no son y no deben ser perfectas, y que siempre tienen algn rea que pueden mejorar. Ensear mtodos de resolucin de problemas. Los equipos de desarrollo deberan comportarse como pequeos centros de investigacin, estableciendo hiptesis y realizando varios experimentos rpidos para verificar su validez.

Utilizacin Mtodos giles Construir con Calidad Cdigo Prueba y Error usando Test Driven Development. Escribir especificaciones ejecutables en lugar de requerimientos.

43

Automatizar. Automatizar las pruebas, la construccin, 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 duplicacin. Cada vez que aparezca la oportunidad, realizar la refactorizacin del cdigo, de las pruebas y de la documentacin 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 da a da, lo ms importante es mantener la direccin correcta. Romper con las dependencias. Los componentes deben estar lo ms desacoplados posibles para que puedan implementarse en cualquier orden. Mantener opciones. Desarrollar mltiples soluciones para todas las decisiones crticas 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 organizacin en su totalidad. Entregar un producto completo. Los equipos necesitan tener buenos lderes, y tambin buenos ingenieros, vendedores, especialistas de marketing, secretarias, etc. Todos juntos pueden entregar un gran producto final a los clientes.

Utilizacin Mtodos giles Entregar Rpido.

44

Trabajar en bloques pequeos. Reducir el tamao del proyecto, acortar los ciclos de entrega, estabilizar el ambiente de trabajo, repetir lo bueno y erradicar las prcticas que crean obstculos. Limitar el trabajo a la capacidad. Limitar la cola de tareas al mnimo (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 utilizacin. Agregar tareas pequeas 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 lderes de equipo. Darles a los lderes de equipo entrenamiento, guas y espacio libre para implementar el pensamiento Lean en su ambiente. Mover la responsabilidad y la toma de decisiones al nivel ms bajo posible. Dejar que las personas piensen y decidan por su cuenta, ellos saben mejor que nadie cmo implementar algoritmos difciles y aplicar tecnologas de ltima generacin. Fomentar orgullo por el trabajo. Fomentar la pasin y la participacin del equipo hacia lo que hacen y cmo lo hacen. La aplicacin 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 aplicacin puede ser difcil en algunas compaas, ya que requiere un cambio importante en la cultura y en los hbitos organizacionales. Pero las mejoras que se pueden

Utilizacin Mtodos giles lograr son importantsimas, no solo en el producto final sino tambin en su evolucin, en la participacin, compromiso y satisfaccin de las personas involucradas. Herramientas A continuacin 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 aplicacin del Lean Manufacturing, que

45

permite tener una visin 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 aadido y sin valor aadido) necesarias en trminos de flujo del material fsico y flujo de informacin para entregar un producto al cliente. Esta herramienta de lpiz 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 estratgica y operativa que permite englobar la situacin 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 perfeccin en las cadenas de valor (Optimizacin de Procesos operativos, s.f.). Kanban. La palabra kanban proviene del japons y parte de las palabras kan que significa visual y ban que significa tarjeta o tablero. Es un sistema para gestionar procesos, basndose en tcnicas como just-in-time (JIT), inventado por Taichi Ohno en Toyota (hace 50 aos). Los principios que promueve son: Calidad perfecta. Todo lo que se hace, debe de intentar hacerse bien, no rpido, ya que cuesta ms tiempo hacer algo rpido y tener que arreglarlo despus, que hacerlo bien desde el principio.

Utilizacin Mtodos giles Minimizacin del desperdicio. Hacer lo justo y necesario (y hacerlo bien, como se

46

deca antes) y no entretenerse en otras tareas secundarias o no necesarias (principio YAGNI). Mejora continua. Ir mejorando continuamente los desarrollos, segn 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 segn las necesidades puntuales. Construccin y mantenimiento de una relacin a largo plazo con los proveedores. En el desarrollo del software, el sistema kanban se puede resumir como la visualizacin 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 seccin inicial, en las reuniones peridicas con el dueo de producto (o el cliente) se priorizan las ms importantes, y se encolan en las siguientes zonas. Adems, las secciones que se pueden incluir en el tablero, adems de diseo, desarrollo y pruebas, son las de paso a produccin, con lo que, se tendran todas las tareas en un seguimiento exhaustivo, desde que se piensan que deben de hacerse, hasta el punto en que se ha llevado a produccin. Como se puede ver en la figura 14, cada seccin vertical, puede anidarse en conjuntos, de modo que la tarea de desarrollo, por ejemplo, pueda descomponerse en otras ms 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

Utilizacin Mtodos giles

47

pruebas y subida a produccin, o incluso entre departamentos, tomando un ltimo grupo para puesta en produccin o incluso un primer grupo para la toma de propuestas y priorizacin de tareas. Lo ms corriente es que exista un grupo inicial, el dueo 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 identificacin rpida 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. Adems de esto, las tarjetas de kanban suelen tener bastante ms informacin, ya que el mtodo consiste en tener todo visual, para saber de forma rpida la carga total de trabajo, ya sea de los grupos, como del departamento, etc. Es importante destacar que las tarjetas deben de tener la estimacin de tiempo que tiene asignada la tarea, as como se pueden anotar las fechas de entrada en cada cuadrante, para tener informacin, al trmino de la tarea, de si ha sido una buena estimacin, 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 mtodo se basa en tener a los trabajadores con un flujo de trabajo constante, las tareas ms 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.

Utilizacin Mtodos giles

48

El sistema de kanban tiene ciertas ventajas con relacin a otras metodologas, ya que permite no solo llevar el seguimiento de un proyecto de forma individual, sino tambin 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 Jimnez, 2009). Extreme Programming (XP) A mediados de la dcada de 1980, Kent Beck y Ward Cunningham trabajaban en un grupo de investigacin de Tektronix; all idearon las tarjetas CRC y sentaron las bases de lo que despus seran los patrones de diseo y XP. Los patrones y XP no necesitan presentacin, pero las tarjetas CRC tal vez s. Se trata de simples tarjetas de papel para fichado, de 4x6 pulgadas; CRC denota Clase-Responsabilidad-Colaboracin, y es una tcnica que reemplaza a los diagramas en la representacin de modelos. En las tarjetas se escriben las Responsabilidades, una descripcin de alto nivel del propsito de una clase y las dependencias primarias. En su economa sintctica y en su abstraccin, prefiguran a lo que ms tarde seran las tarjetas de historias de XP. En la dcada siguiente, Beck fue empleado por Chrysler para colaborar en el sistema de liquidacin de sueldos en Smalltalk que se conoci como el proyecto C3 (Chrysler Comprehensive Compensation). Ms tarde se unieron al proyecto Ron Jeffries y Martin Fowler, ulterior lder de Cutter Consortium4. Previsiblemente, terminaron desarrollando C3 en una especie de proto-XP. La primera fase del C3 fue muy exitosa y comenz a principios de 1997. El proyecto continu desde entonces y despus se encontr con dificultades, lo que result en la cancelacin del desarrollo en 1999 (Reynoso, 2004).

Es una firma de consultora IT compuesta por un grupo de mas de 150 expertos reconocidos internacionalmente, que se han unido para ofrecer investigacin, consultora y formacin a sus clientes

Utilizacin Mtodos giles

49

En la gestacin de C3 se encuentra no slo la raz de XP, sino el ncleo 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 publicacin de su libro (Beck, 1999) y posteriormente (Beck y Andrs, 2004). Inclusive Addison-Wesley ha creado una serie de libros denominada The XP Series. Fue la misma gente del proyecto C3 la que produjo tambin 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 prctica en un proyecto.

Figura 15. Gestacin 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 prctica que de su experiencia saba que trabajaba bien. Entonces, Beck decidi girar todas las perillas al mximo para ver que ocurra. As fue como dio inicio a XP. (Schenone, 2004). 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.

Utilizacin Mtodos giles

50

Figura 16. Evolucin de los largos ciclos de desarrollo en cascada (a) a ciclos iterativos ms cortos (b) y a la mezcla que hace XP (Acebal y Cueva, 2002) Valores. La programacin extrema, lejos de ser un proceso incontrolado, es una metodologa muy disciplinada y que se apoya en cinco valores fundamentales (Berrueta, 2006 ; Calero Sols, 2003): 1. Comunicacin. Se hace nfasis en que la comunicacin, 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 das. Trabajan todos juntos desde los requerimientos hasta la codificacin. Entre todos deben crear la mejor solucin 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 tcnica del equipo ni construir una aplicacin que resuelva ms problemas que los del cliente. La sencillez y la comunicacin se complementan, cuanto mas simple es el sistema menos tienes que comunicar de l.

Utilizacin Mtodos giles 3. Retroalimentacin. No se puede dirigir adecuadamente un proceso si no se dispone de retroalimentacin permanente sobre su progreso. Puede provenir del cliente,

51

de los programadores, de herramientas automticas, etc. La retroalimentacin acta junto con la sencillez y la comunicacin, cuanto mayor retroalimentacin ms fcil es la comunicacin. Cuanto mas simple un sistema mas fcil de probar. 4. Valenta. 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 direccin respeta el derecho a aceptar responsabilidad y recibir autoridad sobre el trabajo realizado. (Wells, 2009). Estos valores dan origen a cinco principios bsicos: conseguir retroalimentacin rpida, 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 travs de las prcticas de la programacin extrema. Las Doce Prcticas de XP La principal suposicin que se realiza en XP es la posibilidad de disminuir la mtica curva exponencial del costo del cambio a lo largo del proyecto, lo suficiente para que el diseo evolutivo funcione. XP apuesta por un crecimiento lento del costo del cambio y con un comportamiento asinttico. Esto se consigue gracias a las tecnologas disponibles para

Utilizacin Mtodos giles

52

ayudar en el desarrollo de software y a la aplicacin disciplinada de las prcticas (Letelier y Penads, s.f.). Las doce prcticas de la programacin extrema tienen su origen en prcticas bien conocidas en la ingeniera del software y en el sentido comn, y por tanto, no pueden resultar extraas. Sin embargo, lo que caracteriza a este conjunto es la cohesin de todos los elementos, y que cada prctica ha sido llevada al extremo (Berrueta, 2006).

Figura 17. El costo de un cambio. A continuacin se desarrollan las doce prcticas segn (Beck, 1999), tomadas de (Abrahamsson et al., 2002; Letelier y Penads, s.f.; Programacin en pares, 2005; Reynoso, 2004). El Juego de la Planificacin. Es un espacio frecuente de comunicacin entre el cliente y los programadores. El equipo tcnico realiza una estimacin del esfuerzo requerido para la implementacin de las historias de usuario y los clientes deciden sobre el mbito y tiempo de las entregas y de cada iteracin. Esta prctica 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

Utilizacin Mtodos giles acuerdo con el valor que aporta para el negocio. Los programadores estiman el esfuerzo asociado a cada historia de usuario. Se ordenan las historias de usuario segn prioridad y esfuerzo, y se define el contenido de la entrega y/o iteracin, apostando por enfrentar lo de ms valor y riesgo cuanto antes. Este juego se realiza durante la planificacin de la entrega, en la planificacin de cada iteracin y cuando sea necesario reconducir el proyecto. Entregas Pequeas y Frecuentes. Se trata de publicar una nueva versin operativa del sistema en cuanto sea posible, aunque obviamente no cuenten con toda la funcionalidad pretendida para el sistema pero si que aporten valor para el negocio. Una entrega no debera tardar ms 3 meses. Metfora. El sistema es definido a travs de una metfora o un conjunto de metforas, una historia compartida por clientes, managers y programadores que orienta todo el sistema describiendo como funciona. Una metfora es una historia compartida que describe cmo debera funcionar el sistema. Consiste en elegir un conjunto de nombres que acten como

53

vocabulario para hablar sobre el dominio del problema, ayudando a la nomenclatura de clases y mtodos del sistema. Diseo Simple. Se debe disear la solucin ms simple que pueda funcionar y ser implementada en un momento determinado del proyecto. La complejidad innecesaria y el cdigo extra debe ser removido inmediatamente. Kent Beck dice que en cualquier momento el diseo adecuado para el software es aquel que: supera con xito todas las pruebas, no tiene lgica duplicada, refleja claramente la intencin de implementacin de los programadores y tiene el menor nmero posible de clases y mtodos. Esta es la prctica donde se impone el minimalismo de

Utilizacin Mtodos giles

54

YAGNI5: no implementar nada que no se necesite ahora; o bien, nunca implementar algo que vaya a necesitarse ms adelante; minimizar diagramas y documentos. Prueba Continua. La produccin de cdigo est dirigida por las pruebas unitarias. Las pruebas unitarias son establecidas antes de escribir el cdigo y son ejecutadas constantemente ante cada modificacin del sistema. Esto es test-driven development (TDD). Los clientes escriben las pruebas funcionales para cada historia de usuario que deba validarse. Hay dos clases de prueba: la prueba unitaria, que verifica una sola clase, o un pequeo conjunto de clases; la prueba de aceptacin verifica todo el sistema, o una gran parte. En este contexto de desarrollo evolutivo y de nfasis en pruebas constantes, la automatizacin para apoyar esta actividad es crucial. Refactorizacin Continua. (Refactoring). Es una actividad constante de reestructuracin del cdigo con el objetivo de remover duplicacin de cdigo, mejorar su legibilidad, simplificarlo y hacerlo ms flexible para facilitar los posteriores cambios. Se mejora la estructura interna del cdigo sin alterar su comportamiento externo. Se lo ha parafraseado diciendo: Si funciona bien, arrglelo de todos modos. Programacin de a Pares (Pair Programming). Todo el cdigo est escrito por pares de programadores. Dos personas escriben cdigo en una computadora, turnndose en el uso del mouse y el teclado. El que no est escribiendo, piensa desde un punto de vista ms estratgico y realiza lo que podra llamarse revisin de cdigo en tiempo real. Siempre que sea posible, cada persona relativamente experimentada debe tener como pareja a una persona relativamente inexperta. La persona inexperta utilizar el teclado, para que el conocimiento de la persona experimentada tenga que fluir a travs del
5

En ingls 'You Ain't Gonna Need It, No vas a necesitarlo.

Utilizacin Mtodos giles

55

novato hacia la computadora. No se busca que el gur dicte al novato; al contrario, el que el inexperto tenga el teclado le permite mantenerse dentro del crculo de trabajo. Cuando esta manera de trabajo no proporciona suficiente ancho de banda, el experto pedir el teclado, y le mostrar el procedimiento en vez de enserselo a un ritmo menor. Los roles pueden cambiarse varias veces al da. Los estudios demuestran que, tras aprender habilidades personales dos programadores son ms que doblemente productivos que uno slo para una tarea determinada. Las principales ventajas de introducir este estilo de programacin son: 1. Muchos errores son detectados conforme son introducidos en el cdigo. Se realizan inspecciones de cdigo continuas. 2. La tasa de errores del producto final es ms baja. 3. Los diseos son mejores y el tamao del cdigo menor, hay una continua discusin de ideas de los programadores. 4. Los problemas de programacin se resuelven ms rpido. 5. Se posibilita la transferencia de conocimientos de programacin entre los miembros del equipo. 6. Varias personas entienden las diferentes partes sistema. 7. Los programadores conversan mejorando as el flujo de informacin y la dinmica del equipo. Dichos beneficios se consiguen despus de varios meses de practicar la programacin en parejas. El objetivo ideal sera que cada integrante del equipo trabaje al menos una vez con cada uno de los dems integrantes y con cada componente de software, de forma que el conocimiento de la aplicacin completa lo posea el equipo entero y no unos pocos miembros.

Utilizacin Mtodos giles Propiedad Colectiva del Cdigo. Cualquiera puede cambiar cdigo en cualquier parte del sistema en cualquier momento. En el transcurso de una refactorizacin, o mientras se corrige un defecto, algn

56

programador va a tener que modificar lneas de cdigo escritas por otro programador. Antes de modificar el cdigo deber hacerse la correspondiente prueba unitaria. Esta prctica motiva a todos a contribuir con nuevas ideas en todos los segmentos del sistema, evitando a la vez que algn programador sea imprescindible para realizar cambios en alguna porcin de cdigo. Para eso se hacen las pruebas automticas. Integracin Continua. Cada pieza de cdigo es integrada en el sistema una vez que est lista. As, el sistema puede llegar a ser integrado y construido varias veces en un mismo da. Hay una computadora (solamente) dedicada a este propsito. Para poder hacerlo, es imprescindible que el proceso de integracin est automatizado y pueda verificarse mediante pruebas. Todas las pruebas son ejecutadas y tienen que ser aprobadas para que el nuevo cdigo sea incorporado definitivamente. La integracin continua a menudo reduce la fragmentacin de los esfuerzos de los desarrolladores por falta de comunicacin sobre lo que puede ser reutilizado o compartido. Ritmo Sostenible. Antes se llamaba a esta prctica Semana de 40 horas. Se debe trabajar un mximo de 40 horas por semana. No se trabajan horas extras en dos semanas seguidas. Si esto ocurre, probablemente est ocurriendo un problema que debe corregirse. Dado que el desarrollo de software se considera un ejercicio creativo, se estima que hay que estar fresco y descansado para hacerlo eficientemente; con ello se motiva a los participantes, se evita la rotacin del personal y se mejora la calidad del producto. El trabajo extra desmotiva al equipo y los programadores cansados se equivocan ms.

Utilizacin Mtodos giles

57

Los proyectos que requieren trabajo extra para intentar cumplir con los plazos suelen al final ser entregados con retraso. En lugar de esto se puede realizar el juego de la planificacin para cambiar el mbito del proyecto o la fecha de entrega. Cliente en el Lugar de Desarrollo. Incluir un cliente real en el equipo, disponible de forma full-time para responder preguntas. ste es uno de los principales factores de xito del proyecto XP. El cliente conduce constantemente el trabajo hacia lo que aportar mayor valor de negocio y los programadores pueden resolver de manera inmediata cualquier duda asociada. La comunicacin oral es ms efectiva que la escrita ya que esta ltima toma mucho tiempo en generarse y puede tener ms riesgo de ser mal interpretada. Estndares de Codificacin. Los programadores escriben todo el cdigo de acuerdo con reglas que enfatizan la comunicacin a travs del mismo, con lo cual es indispensable que se sigan ciertos estndares de programacin (del equipo, de la organizacin u otros estndares reconocidos para los lenguajes de programacin utilizados). Los estndares de programacin mantienen el cdigo legible para los miembros del equipo, facilitando los cambios. El mayor beneficio de las prcticas se consigue con su aplicacin conjunta y equilibrada puesto que se apoyan unas en otras. Esto se puede observar en la figura ilustra en la Figura 18, donde una lnea entre dos prcticas significa que las dos prcticas se refuerzan entre s. La mayora de las prcticas propuestas por XP no son novedosas sino que en alguna forma ya haban sido propuestas en ingeniera del software e incluso demostrado su valor en la prctica El mrito de XP es integrarlas de una forma efectiva y complementarlas con otras ideas desde la perspectiva del negocio, los valores humanos y el trabajo en equipo. Estas prcticas se agrupan en cuatro clases como muestra la figura 19.

Utilizacin Mtodos giles

58

Figura 18. Las practicas se refuerzan entre si (Letelier y Penads, s.f.). Las Historias de Usuario Entre los artefactos que se utilizan en XP vale la pena mencionar las tarjetas de historias de usuarios (User Stories). Son la tcnica utilizada en XP para especificar los requisitos del software. Se trata de tarjetas de papel en las cuales el cliente describe brevemente las caractersticas que el sistema debe poseer, sean requisitos funcionales o no funcionales. El tratamiento de las historias de usuario es muy dinmico y flexible, en cualquier momento historias de usuario pueden romperse, reemplazarse por otras ms especficas o generales, aadirse nuevas o ser modificadas. Cada historia de usuario es lo suficientemente comprensible y delimitada para que los programadores puedan implementarla en unas semanas. Se usan para estimar prioridades, alcance y tiempo de realizacin; en caso de discrepancia, gana la estimacin ms optimista (Letelier y Penads, s.f.).

Utilizacin Mtodos giles

59

Figura 19. Clasificacin de las prcticas de XP (Reynoso, 2004). El Ciclo de Vida de XP El ciclo de vida ideal de XP consiste de seis fases: Exploracin, Planificacin de la Entrega (Release), Iteraciones, Produccin, Mantenimiento y Muerte del Proyecto. En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe presionar al programador a realizar ms trabajo que el estimado, ya que se perder calidad en el software o no se cumplirn los plazos. De la misma forma el cliente tiene la obligacin de manejar el mbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteracin. A continuacin se detallan las fases que se ilustran en la figura 20, segn fueron descriptas en (Beck, 1999), tomadas de (Abrahamsson et al., 2002; Letelier y Penads, s.f.): Fase de Exploracin En esta fase, los clientes escriben las historias de usuario que son de inters para la primera entrega del producto. Cada historia de usuario describe un rasgo que ser incluido en el programa. Al mismo tiempo el equipo de desarrollo se familiariza con las herramientas, tecnologas y prcticas que se utilizarn en el proyecto. Se prueba la tecnologa y se exploran

Utilizacin Mtodos giles las posibilidades de la arquitectura del sistema construyendo un prototipo. La fase de

60

exploracin toma de pocas semanas a pocos meses, dependiendo del tamao y la experiencia que tengan los programadores con la tecnologa.

Figura 20. Ciclo de vida de XP (Abrahamsson et al., 2002). Planificacin de la Entrega (Release) Se establece el orden de prioridad de las historias de usuario y se acuerdan los contenidos de la primera entrega que se va a hacer. Los programadores estiman el esfuerzo para cada historia y se acuerda el cronograma con el cliente. Una entrega debera obtenerse en no ms de tres meses. Esta fase dura unos pocos das. Las estimaciones de esfuerzo asociado a la implementacin de las historias la establecen los programadores utilizando como medida el punto. Un punto, equivale a una semana ideal de programacin. Las historias generalmente valen de 1 a 3 puntos. Por otra parte, el equipo de desarrollo mantiene un registro de la velocidad de desarrollo, establecida en puntos por iteracin, basndose principalmente en la suma de puntos correspondientes a las historias de usuario que fueron terminadas en la ltima iteracin. La planificacin se puede realizar basndose en el tiempo o el alcance. La velocidad del proyecto es utilizada para establecer cuntas historias se pueden

Utilizacin Mtodos giles implementar antes de una fecha determinada o cunto tiempo tomar implementar un

61

conjunto de historias. Al planificar por tiempo, se multiplica el nmero de iteraciones por la velocidad del proyecto, determinndose cuntos puntos se pueden completar. Al planificar segn alcance del sistema, se divide la suma de puntos de las historias de usuario seleccionadas entre la velocidad del proyecto, obteniendo el nmero de iteraciones necesarias para su implementacin. Iteraciones Esta fase incluye varias iteraciones sobre el sistema antes de ser entregado. El Plan de Entrega est compuesto por iteraciones que van de una a cuatro semanas. En la primera iteracin se establece una arquitectura del sistema que pueda ser utilizada durante el resto del proyecto. Esto se logra escogiendo las historias que fuercen la creacin de esta arquitectura, sin embargo, esto no siempre es posible ya que es el cliente quien decide qu historias se implementarn en cada iteracin (para maximizar el valor de negocio). El test funcional escrito por el cliente es corrido al final de cada iteracin. Al final de la ltima iteracin el sistema estar listo para entrar en produccin. Los elementos que deben tomarse en cuenta durante la elaboracin del Plan de la Iteracin son: historias de usuario no abordadas, velocidad del proyecto, pruebas de aceptacin no superadas en la iteracin anterior y tareas no terminadas en la iteracin anterior. Todo el trabajo de la iteracin es expresado en tareas de programacin, cada una de ellas es asignada a un programador como responsable, pero llevadas a cabo por parejas de programadores. Produccin La fase de produccin requiere de pruebas adicionales y revisiones de rendimiento antes de que el sistema sea trasladado al entorno del cliente. Al mismo tiempo, se deben tomar decisiones sobre la inclusin de nuevas caractersticas a la versin actual, debido a

Utilizacin Mtodos giles cambios durante esta fase. Puede ser necesario bajar el tiempo que toma cada iteracin, de tres semanas a solo una. Las ideas que han sido propuestas y las sugerencias son documentadas para su posterior implementacin, por ejemplo, durante la fase de mantenimiento. Mantenimiento Mientras la primera versin se encuentra en produccin, el proyecto XP debe mantener el sistema en funcionamiento al mismo tiempo que desarrolla nuevas iteraciones.

62

Para realizar esto se requiere de tareas de soporte para el cliente. De esta forma, la velocidad de desarrollo puede bajar despus de la puesta del sistema en produccin. La fase de mantenimiento puede requerir nuevo personal dentro del equipo y cambios en su estructura. Muerte del Proyecto Esta fase se da cuando el cliente no tiene ms historias para ser incluidas en el sistema. Esto requiere que se satisfagan las necesidades del cliente en otros aspectos como rendimiento y confiabilidad del sistema. Se genera la documentacin final del sistema y no se realizan ms cambios en la arquitectura. La muerte del proyecto tambin ocurre cuando el sistema no genera los beneficios esperados por el cliente o cuando no hay presupuesto para mantenerlo. Roles y Responsabilidades Beck (1999) define diferentes roles en Xp, de acuerdo a las tareas durante el proceso de desarrollo y sus prcticas, tomados de (Abrahamsson et al., 2002; Letelier y Penads, s.f.): Programador El programador escribe las pruebas unitarias y produce el cdigo del sistema y debe mantenerlo tan sencillo y definido como sea posible. Es fundamental para asegurar el xito de un proyecto la adecuada comunicacin y coordinacin entre los programadores y otros miembros del equipo.

Utilizacin Mtodos giles Cliente El cliente escribe las historias de usuario y las pruebas funcionales para validar su implementacin. Adems, asigna la prioridad a las historias de usuario y decide cules se implementan en cada iteracin centrndose en aportar mayor valor al negocio. El cliente es slo uno dentro del proyecto pero puede corresponder a un interlocutor que est representando a varias personas que se vern afectadas por el sistema. Encargado de Pruebas (Tester) El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas. Encargado de Seguimiento (Tracker)

63

El encargado de seguimiento proporciona realimentacin al equipo en el proceso XP. Su responsabilidad es verificar el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, comunicando los resultados para mejorar futuras estimaciones. Tambin realiza el seguimiento del progreso de cada iteracin y evala si los objetivos son alcanzables con las restricciones de tiempo y recursos presentes. Determina cundo es necesario realizar algn cambio para lograr los objetivos de cada iteracin. Entrenador (Coach) Es responsable del proceso global. Es necesario que conozca a fondo el proceso XP para proveer guas a los miembros del equipo de forma que se apliquen las prcticas XP y se siga el proceso correctamente. Consultor Es un miembro externo del equipo con un conocimiento especfico en algn tema necesario para el proyecto. Gua al equipo para resolver un problema especfico.

Utilizacin Mtodos giles Manager (Big boss) Es quien toma las decisiones. Es el vnculo entre clientes y programadores, ayuda a

64

que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinacin. Si bien XP es una de las metodologas giles de ms renombre en la actualidad, se diferencia de las dems metodologas que forman este grupo en un aspecto en particular: el alto nivel de disciplina de las personas que participan en el proyecto. El mismo Beck (1999) sugiere que XP debe ser adoptado gradualmente: Si usted quiere probar con XP, por Dios no intente digerirlo todo de una vez. Tome el peor problema en su proceso actual y trate de resolverlo con XP. Scrum La mayor parte de la informacin sobre Scrum detallada a continuacin fue extrada y adaptada de (Albaladejo et al., 2009). En los casos que se utilizaron otras fuentes, estas tienen su correspondiente referencia. El concepto de Scrum tiene su origen en un estudio de 1986 sobre los nuevos procesos de desarrollo utilizados en productos exitosos en Japn y los Estados Unidos (cmaras de fotos de Canon, fotocopiadoras de Xerox, automviles de Honda, ordenadores de HP y otros). Los equipos que desarrollaron estos productos partan de requisitos muy generales, as como novedosos, y deban salir al mercado en mucho menos del tiempo del que se tard en lanzar productos anteriores. Estos equipos seguan patrones de ejecucin de proyecto muy similares. En este estudio se comparaba la forma de trabajo de estos equipos altamente productivos y multidisciplinares con la colaboracin entre los jugadores de rugby y su formacin de Scrum (figura 21) donde el equipo entero acta como un solo hombre para intentar llegar al otro lado del campo, pasando el baln de uno a otro. The New Product

Utilizacin Mtodos giles Developement Game, por Hirotaka Takeuchi (Hitotsubashi University) y Ikujiro Nonaka. Harvard Business Review, Enero-Febrero de 1986.

65

Figura 21. Formacin de Scrum. En 1993 se realiz el primer Scrum para desarrollo de software. Jeff Sutherland, John Scumniotales y Jeff McKenna concibieron, ejecutaron y documentaron el primer Scrum para desarrollo gil de software, utilizando el estudio de gestin de equipos de Takeuchi y Nonaka como base. En 1995 Ken Schwaber formaliz el proceso para la industria de desarrollo de software y ha publicado varios libros describiendo esta metodologa (Schwaber y Beedle, 2002; Schwaber, 2004). Desde ese entonces miles de proyectos en todo el mundo han utilizado Scrum para el desarrollo de productos, tanto en empresas pequeas con tan slo 5 personas desarrollando un producto, como en multinacionales. En la actualidad, Scrum se est utilizando en diferentes tipos de negocio y, especialmente, en el desarrollo de software.

Utilizacin Mtodos giles La Scrum Alliance es la organizacin sin nimo de lucro que se encarga de difundir Scrum en este mbito. Qu es Scrum Scrum es un proceso en el que se aplican de manera regular un conjunto de mejores prcticas para trabajar en equipo y obtener el mejor resultado posible de un proyecto. Estas prcticas se apoyan unas a otras y su seleccin tiene origen en un estudio de la manera de trabajar de equipos altamente productivos. En Scrum se realizan entregas parciales y regulares del resultado final del proyecto, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum est especialmente indicado para proyectos en entornos complejos, donde se necesita obtener

66

resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovacin, la competitividad y la productividad son fundamentales. Scrum tambin se utiliza para resolver situaciones en que no se est entregando al cliente lo que necesita, cuando las entregas se alargan demasiado, los costos se disparan o la calidad no es aceptable, cuando se necesita capacidad de reaccin ante la competencia, cuando la moral de los equipos es baja y la rotacin alta, cuando es necesario identificar y solucionar ineficiencias sistemticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto. Las metodologas tradicionales ya mencionaban las prcticas y conceptos utilizados en Scrum, llegando a utilizarlos en mayor o menor medida y prometiendo tambin un mejor resultado en los proyectos. Pero una cosa es reconocer que estas prcticas son buenas y otra muy diferente es actuar en consecuencia, es decir, utilizar todas estas prcticas situndolas en el centro del proceso.

Utilizacin Mtodos giles Desarrollo Iterativo e Incremental

67

El desarrollo iterativo e incremental ya exista antes. La diferencia es que en Scrum la planificacin del proyecto hace explcitos los objetivos del cliente y los prioriza en funcin del ROI (Return of Investment), es decir, balanceando el valor aportado al cliente respecto a su coste de desarrollo, y minimizando el trabajo en curso (Work In Progress) necesario para obtener un resultado. En las metodologas tradicionales el cliente tena que esperar a tener todo el valor de un proyecto el ltimo da de la ltima fase, habiendo acumulando todos los retardos de todas las fases, en cambio con Scrum el cliente puede dirigir de manera sistemtica y regular (cada iteracin) los resultados que va obteniendo del proyecto. De esta manera (y siguiendo la ley de Pareto en que el 20% del esfuerzo proporciona el 80% del valor), el cliente puede empezar antes a recuperar su inversin (y/o autofinanciarse) comenzando a utilizar un producto al que slo le faltan caractersticas poco relevantes, puede sacar al mercado un producto antes que su competidor, puede ir adaptndolo mejor a las necesidades de los clientes y hacer frente a urgencias o nuevas peticiones. Orientacin a Personas La orientacin a personas ya se practicaba antes, slo que se basaba en aspectos relacionados con la ejecucin de cada persona y condicionados a la subjetividad del evaluador. En Scrum, en cambio, dado que el equipo es multidisciplinar (incluye a todas las personas necesarias para llevar a cabo el proyecto) el planteamiento es de potenciacin del equipo (team empowerment), de darle responsabilidad y autoridad para que decida cmo funcionar de la manera ms eficiente posible, mejore su entorno de trabajo y pueda mostrar resultados de manera regular, as como permitirle aportar innovacin al producto que est desarrollando, cosa que facilita la motivacin y realizacin personal de cada uno de sus miembros.

Utilizacin Mtodos giles Planificacin con Tareas La planificacin con tareas, tiempo y personas ya se haca antes, slo que en las metodologas tradicionales las tareas, las asignaciones y los tiempos las decida un jefe de proyecto. Sin embargo, en Scrum la planificacin de proyecto se hace orientada a objetivos

68

del cliente (y no a tareas) y la realiza el equipo utilizando tcnicas muy rpidas de estimacin (por ejemplo planning poker). Asimismo, la planificacin de iteracin tambin la hace el equipo, quien identifica y estima de manera conjunta las tareas a realizar y se las autoasigna. De esta manera, las estimaciones son mucho ms fiables por que se realizan en base a las experiencias e informacin de todos los miembros del equipo y dado que las han proporcionado ellos se convierten en compromiso. Control del Progreso del Proyecto El control del progreso del proyecto orientado a tareas ya se haca antes, con el jefe de proyecto preguntando a cada persona el estado en que se encuentran sus tareas. Sin embargo, en Scrum el equipo se compromete y reporta diariamente su avance y problemas respecto al resto de miembros del equipo, con lo que la sinergia, la transferencia de informacin, de experiencias y de soluciones es mucho ms alta. En Scrum, en lugar de un responsable del equipo/proyecto hay un facilitador que garantiza la colaboracin entre todos los participantes. Gestin de Cambios La gestin de cambios ya exista antes, era un control frreo para impedir que el proyecto se moviese tanto en alcance, como en tiempo como recursos. En cambio, el planteamiento que se hace en Scrum, es el de aceptar que los cambios son naturales y permitirlos en el inicio de cada iteracin (ya que todava no se ha desarrollado nada respecto a futuros objetivos), una vez se ha demostrado al cliente los resultados obtenidos en la iteracin anterior, para darle ms flexibilidad en la adaptacin del producto a sus necesidades

Utilizacin Mtodos giles (siguiendo unas reglas de alcance variable que permiten que tanto el cliente como el proveedor ganen). Retrospectivas

69

Las retrospectivas y los anlisis post mortem (para mejorar los proceso de trabajo) ya se hacan antes, slo que normalmente al final de un proyecto o de una gran fase. Sin embargo, en Scrum las retrospectivas se hacen al final de cada iteracin, de manera que el equipo pueda aprender y sea ms productivo dentro del mismo proyecto. Timeboxing El timeboxing era una herramienta conocida anteriormente. La diferencia ahora es el uso de timeboxing para todas las actividades de Scrum, de manera que facilite el enfoque en resultados y la toma de decisiones. El enfoque de Scrum exige utilizar estas prcticas de manera regular y frecuente para as proporcionar flexibilidad, productividad, innovacin y calidad, teniendo como base la colaboracin entre las personas que participan. En el pensamiento gil prima la colaboracin y transparencia con el cliente y entre el equipo, para as reducir riesgos, cubrir al mximo posible las expectativas del cliente, mejorar de manera continua los procesos, ganar en creatividad y disfrutar ms en la realizacin del trabajo. Requisitos para Poder Utilizar Scrum Aplicar estas prcticas de forma sistemtica en el da a da de los proyectos puede no ser fcil (e incluso puede no ser idneo), bien por que la cultura de la empresa no est alineada (no se trata de una cultura colaborativa) o bien por qu se desconocen las tcnicas sobre cmo aplicarlos. Los siguientes puntos son de especial importancia para la implantacin de una gestin gil de proyectos como Scrum:

Utilizacin Mtodos giles Cultura de Empresa

70

La cultura de la empresa proveedora del proyecto debe estar alineada con la filosofa de una gestin gil de proyectos como Scrum, debe fomentar: a) El trabajo en equipo y la colaboracin entre todas las personas implicadas en un proyecto; b) Equipos autogestionados a los que se ha delegado la responsabilidad y autoridad para hacer su trabajo, en contraposicin a la direccin y control de personas que ejercera un jefe de proyecto tradicional, en lugar del jefe de proyecto existe la figura del Facilitador (Scrum Master); c)La creatividad del equipo; d) La transparencia y la mejora continua, tanto del contexto de la organizacin y del proyecto y como de las herramientas del equipo. Scrum sistematiza la identificacin de obstculos que pueden impedir el correcto progreso del proyecto. Los problemas previamente existentes en la organizacin (procesos, personas, herramientas, etc.) y que atentan contra la productividad se harn ms evidentes cuando se aplique Scrum y ser necesario ir solucionndolos. Compromiso del Cliente Scrum exige del cliente una alta implicacin y una dedicacin regular: 1. El cliente tiene la responsabilidad de dirigir los resultados del producto o proyecto: El cliente debe disponer de una visin de alto nivel del producto o proyecto y tener reflejadas sus expectativas en forma de lista de requisitos priorizada donde ha indicado el valor que le aportar cada uno. A partir de los costes de desarrollo que le proporcione el equipo, priorizar los requisitos en funcin del Retorno de la Inversin (ROI) ms rpido. El cliente re planifica el proyecto en cada iteracin para maximizar este ROI de manera continua.

Utilizacin Mtodos giles 2. Al tratarse de un proyecto que va entregando resultados en iteraciones

71

regulares, el cliente debe colaborar participando en el inicio de cada iteracin (reunin de planificacin) y en el fin de cada iteracin (demostracin), y debe estar disponible durante la ejecucin de cada iteracin para resolver dudas. Compromiso de la Direccin La Direccin debe estar comprometida y apoyar el uso de Scrum: Se harn muy evidentes los obstculos ya existentes y por venir que impiden el correcto desarrollo de los proyectos (a nivel de expectativas del cliente, productividad, calidad, etc.), sean organizativos, tcnicos, procesos, relaciones entre personas/departamentos, habilidades de los equipos, etc. Ser necesario tomar decisiones, realizar cambios organizativos, alinear a personas y proporcionar recursos para hacer la transicin. Gestores y equipos debern desaprender formas de trabajar y de relacionarse a las que estaban habituados y aprender nuevas dinmicas. Un proyecto ya no consistir en que cada Departamento/rea/Unidad realice su parte del trabajo y se la pase al siguiente. Ser necesario formar equipos autogestionados y multidisciplinares capaces de conseguir un objetivo por ellos mismos. Habr gestores que tendrn que cambiar sus roles para ser Facilitadores o Clientes, en una jerarqua de equipos haciendo Scrum de Scrums. Se tendr que gestionar aquellas conductas personales que no permiten que otras personas puedan aportar ideas sobre el qu y el cmo de un proyecto, que defienden a toda costa su parcela de responsabilidad, que les cuesta mucho cederla al equipo y.dejar de controlarlo, que no son capaces de delegar tareas o de colaborar con otras personas en la resolucin de problemas.

Utilizacin Mtodos giles Compromiso del Equipo Scrum se basa en el compromiso conjunto y la colaboracin entre los miembros del

72

equipo. La transparencia entre todos es fundamental para poder inspeccionar la situacin real del proyecto y as poder hacer las mejores adaptaciones que permitan conseguir el objetivo comn. Por ello, ser difcil trabajar utilizando Scrum para las personas que: 1. No confan en los dems, no permiten que otras personas puedan aportar ideas sobre el qu y el cmo, no son capaces de colaborar en la resolucin de problemas ni de delegar tareas. 2. No son transparentes respecto a su trabajo personal, sea por que defienden a toda costa su parcela de responsabilidad o por inseguridad para comunicarse o colaborar, cosa que no permite que sean ayudados. 3. Su modo de relacin se basa en la generacin de conflicto o bien evitan entrar en conflictos sanos en que ambas partes ganen (ganar/ganar), con lo que los problemas realmente no se resuelven sino que crean conversaciones veladas, de manera que estas personas no acaban de adquirir un compromiso real con el equipo. 4. Priorizan su ego, sus intereses personales, de carrera o de departamento, por encima de los intereses del equipo. 5. No son capaces de cambiar sus hbitos y salir de su zona de confort, tienen miedo al cambio, prefieren que se les diga qu tienen que hacer o quieren decir a los dems qu tienen que hacer. 6. Quieren seguir siendo los hroes que solucionan los proyectos y/o las personas de las que depende la empresa.

Utilizacin Mtodos giles Relacin entre Proveedor y Cliente La relacin entre el cliente y el proveedor del proyecto debe estar basada en el

73

principio de ganar ganar. En lugar de estar ligados por un contrato frreo de alcance, tiempo y coste, las dos partes asumen que habr cambios para que cliente pueda obtener lo que realmente necesita, no lo que est escrito en un documento inicial o seguir un plan inicial que vaya perdiendo su sentido. La relacin contractual se aproxima a un contrato de un equipo por meses, donde el cliente dirige mes a mes los resultados que el proyecto debe ir proporcionando. Debe existir transparencia en la ejecucin del proyecto para facilitar esta relacin. Esta transparencia la facilita de manera regular el propio proceso de Scrum, especialmente en la actividad de demostracin de los requisitos completados al final de cada iteracin. Facilidad para realizar Cambios en el Proyecto Para poder utilizar Scrum se debe poder ir incorporando requisitos de manera incremental en el producto del proyecto y realizar cambios de forma controlada sin un coste prohibitivo para el cliente. Para ello es necesario: 1. Disponer de tcnicas y herramientas que faciliten el crecimiento incremental y la introduccin de cambios. 2. Mantener la simplicidad y calidad interna del producto que se est creando. Para cubrir los requisitos actuales del cliente no hay que realizar ms esfuerzo del que sea necesario y, a la vez, se debe vigilar no hacer nada en contra de futuros requisitos. Dado que los requisitos se desarrollan priorizados por su valor, es ms improbable que ocurran cambios sustanciales en los primeros requisitos desarrollados, cuando se construye la base del producto. Se fomenta que los cambios que suelen aparecen cuando el proyecto ya est avanzado se realicen sobre requisitos que no son tan importantes.

Utilizacin Mtodos giles

74

La arquitectura emerge conforme se va necesitando, iteracin a iteracin, con lo que se asegura que todo lo que se disea se utiliza y se prueba. Roles y Responsabilidades Aunque suene a broma, los roles se dividen en dos: los cerdos y los pollos. Y la mejor manera de entender la diferencia entre unos y otros es un chiste, tomado de (SCRUM: metodologa gil para tus proyectos, 2008): Un cerdo y un pollo van caminando por la calle. El pollo le dice al cerdo: -Oye, por qu no abrimos un restaurante? El cerdo se vuelve y le responde: -Buena idea, cmo quieres que lo llamemos? El pollo se lo piensa y propone: -Por qu no lo llamamos Huevos con jamn. -No cuentes conmigo -responde el cerdo-. En ese caso, vos slo estaras implicado, mientras que yo estara realmente comprometido. Siguiendo esta lgica, el papel de los cerdos, que son los que estn realmente comprometidos, porque son los que contribuyen con su jamn al proyecto, lo desempean: 1. El cliente (Product owner), que representa la voz del cliente y aporta la visin de negocio. 2. El facilitador (ScrumMaster), que tiene como principal papel el de dejar el camino libre de obstculos e impedimentos para que el resto del equipo consiga el objetivo del sprint. 3. El equipo (Team), que tiene la responsabilidad de entregar el producto. El papel de los pollos, que no son actores esenciales pero s estn implicados y deben ser tenidos en cuenta, lo juegan: 1. Los usuarios del producto o aplicacin.

Utilizacin Mtodos giles 2. Los clientes y vendedores (Stakeholders). 3. Los gestores y directivos (Managers). Cliente (Product Owner).

75

Las responsabilidades del Cliente (que puede ser interno o externo a la organizacin) son: 1. Ser el representante de todas las personas interesadas en los resultados del proyecto internas o externas a la organizacin, promotores del proyecto y usuarios finales (idealmente tambin debera ser un usuario clave o consumidores finales del producto) y actuar como interlocutor nico ante el equipo, con autoridad para tomar decisiones. 2. Definir los objetivos del producto o proyecto. 3. Dirigir los resultados del proyecto y maximizar su ROI (Return Of Investment). Es el propietario de la planificacin del proyecto: crea y mantiene la lista priorizada con los requisitos necesarios para cubrir los objetivos del producto o proyecto, conoce el valor que aportar cada requisito y calcula el ROI a partir del coste de cada requisito que le proporciona el equipo. Reparte los objetivos/requisitos en iteraciones y establece un calendario de entregas. Antes de iniciar cada iteracin re planifica el proyecto en funcin de los requisitos que aportan ms valor en ese momento, de los requisitos completados en la iteracin anterior y del contexto del proyecto en ese momento (demandas del mercado, movimientos de la competencia, etc.). 4. Participar en la reunin de planificacin de iteracin, proponiendo los requisitos ms prioritarios a desarrollar, respondiendo a las dudas del equipo y detallando los requisitos que el equipo se comprometer a hacer.

Utilizacin Mtodos giles

76

5. Estar disponible durante el curso de la iteracin para responder a las preguntas que puedan aparecer. 6. No cambiar los requisitos que se estn desarrollando en una iteracin, una vez est iniciada. 7. Participar en la reunin de demostracin de la iteracin, revisando los requisitos completados. Facilitador (Scrum Master) Lidera al equipo llevando a cabo las siguientes responsabilidades: 1. Velar por que todos los participantes del proyecto sigan las reglas y proceso de Scrum, encajndolas en la cultura de la organizacin, y guiar la colaboracin intraequipo y con el cliente de manera que las sinergias sean mximas. Esto implica: a) Asegurar que la lista de requisitos priorizada est preparada antes de la siguiente iteracin; b) Facilitar las reuniones de Scrum (planificacin de la iteracin, reuniones diarias de sincronizacin del equipo, demostracin, retrospectiva), de manera que sean productivas y consigan sus objetivos; c) Ensear al equipo a autogestionarse. No da respuestas, si no que gua al equipo con preguntas para que descubra por s mismo una solucin. 2. Quitar los impedimentos que el equipo tiene en su camino para conseguir el objetivo de cada iteracin (proporcionar un resultado til al cliente de la manera ms efectiva) y poder finalizar el proyecto con xito. Estos obstculos se identifican de manera sistemtica en las reuniones diarias de sincronizacin del equipo y en las reuniones de retrospectiva. 3. Proteger y aislar al equipo de interrupciones externas durante la ejecucin de la iteracin (introduccin de nuevos requisitos, "secuestro" no previsto de un miembro del equipo, etc.). De esta manera, el equipo puede mantener su

Utilizacin Mtodos giles productividad y el compromiso que adquiri sobre los requisitos que completara en la iteracin, notar, sin embargo, que el equipo debe reservar

77

tiempo para colaborar con al cliente en la preparacin de la lista de requisitos para la prxima iteracin. Equipo (Team) Grupo de personas que de manera conjunta desarrollan el producto del proyecto. Tienen un objetivo comn, comparten la responsabilidad del trabajo que realizan (as como de su calidad) en cada iteracin y en el proyecto. El tamao del equipo es de 7 2 personas. Por debajo de 5 personas cualquier imprevisto o interrupcin sobre un miembro del equipo compromete seriamente el compromiso que han adquirido y, por tanto, el resultado que se va a entregar al cliente al finalizar la iteracin. Por encima de 9 personas, la comunicacin y colaboracin entre todos los miembros se hace ms difcil y se forma subgrupos. De cualquier manera, se puede hacer Scrum con 3 personas y se ha utilizado en proyectos con 250 personas en varios equipos. Cuando es necesario que ms de un equipo trabaje de manera gil en un mismo proyecto, existen diferentes tcnicas que permiten esta colaboracin, desde el Scrum de Scrums hasta equipos de integracin que dedican parte de su tiempo a trabajar con los equipos de desarrollo, siempre completando incrementos de producto de manera regular. Es un equipo autoorganizado, que comparte informacin y cuyos miembros confan entre ellos. Realiza de manera conjunta las siguientes actividades: 1. Seleccionar los requisitos que se compromete a completar en una iteracin, de forma que estn preparados para ser entregados al cliente. 2. Estimar la complejidad de cada requisito en la lista de requisitos priorizada del producto o proyecto.

Utilizacin Mtodos giles

78

3. En la reunin de planificacin de la iteracin decide cmo va a realizar su trabajo: Seleccionar los requisitos que pueden completar en cada iteracin, realizando al cliente las preguntas necesarias. Identificar todas las tareas necesarias para completar cada requisito. Estimar el esfuerzo necesario para realizar cada tarea. Cada miembro del equipo se auto asigna a las tareas. 4. Durante la iteracin, trabajar de manera conjunta para conseguir los objetivos de la iteracin. Cada especialista lidera el trabajo en su rea y el resto colaboran si es necesario para poder completar un requisito. 5. Al finalizar la iteracin: Demostrar al cliente los requisitos completados en cada iteracin. Hacer una retrospectiva la final de cada iteracin para mejorar de forma continua su manera de trabajar. El equipo es multidisciplinar. Los miembros del equipo tienen las habilidades necesarias para poder identificar y ejecutar todas las tareas que permiten proporcionar al cliente los requisitos comprometidos en la iteracin. Usualmente consiste en: Analistas Diseadores Encargados de Calidad (QA) Desarrolladores Documentadores Otras habilidades necesarias para realizar el trabajo Muchas organizaciones suelen tener un grupo de personas especializadas en distintos temas, como ser usabilidad, administradores de bases de datos, expertos en seguridad y

Utilizacin Mtodos giles arquitectos de sistemas. Cuando se necesita la participacin de alguno de ellos, deberan pasar a formar parte del equipo. Es decir, no son parte de un grupo externo de expertos que

79

dan consejos, sino que se convierten en miembros del equipo para aquellas iteraciones en las que es necesario construir una arquitectura, infraestructura o trabajar en la base de datos. Pueden estar trabajando o guiando, monitoreando a los miembros del equipo que hacen el trabajo. La diferencia fundamental es que no son ms pollos. Se comprometen al comienzo de la iteracin junto al resto del equipo, y siguen con ellos hasta el fin de la iteracin. Por lo tanto se convierten en cerdos por un perodo corto de tiempo. Tienen que depender lo mnimo de personas externas al equipo, de manera que el compromiso que adquieren en cada iteracin no se ponga en peligro. Se crea una sinergia que permite que el resultado sea ms rico al nutrirse de las diferentes experiencias, conocimientos y habilidades de todos. Colaboracin creativa. Los miembros del equipo deben dedicarse al proyecto a tiempo completo para evitar daar su productividad por cambios de tareas en diferentes proyectos, para evitar interrupciones externas y as poder mantener el compromiso que adquieren en cada iteracin. Todos los miembros del equipo trabajan en la misma localizacin fsica, para poder maximizar la comunicacin entre ellos mediante conversaciones cara a cara, diagramas en pizarras blancas, etc. De esta manera se minimizan otros canales de comunicacin menos eficientes, que hacen que las tareas se transformen en un pasa pelota o que hacen perder el tiempo en el establecimiento de la comunicacin (como cuando se llama repetidas veces por telfono cuando la persona no est en su puesto). El equipo debe ser estable durante el proyecto, sus miembros deben cambiar lo mnimo posible, para poder aprovechar el esfuerzo que les ha costado construir sus relaciones interpersonales, engranarse y establecer su organizacin del trabajo.

Utilizacin Mtodos giles Caractersticas de Scrum Desarrollo Iterativo e Incremental En un desarrollo iterativo e incremental el proyecto se planifica en diversos bloques

80

temporales (en el caso de Scrum de un mes natural o hasta de dos semanas, si as se necesita) llamados iteraciones. Las iteraciones se pueden entender como mini proyectos: en todas las iteraciones se repite un proceso de trabajo similar (de ah el nombre iterativo) para proporcionar un resultado completo sobre producto final, de manera que el cliente pueda obtener los beneficios del proyecto de forma incremental. Para ello, cada requisito se debe completar en una nica iteracin: el equipo debe realizar todas las tareas necesarias para completarlo (incluyendo pruebas y documentacin) y que est preparado para ser entregado al cliente con el mnimo esfuerzo necesario. De esta manera no se deja para el final del proyecto ninguna actividad arriesgada relacionada con la entrega de requisitos. En cada iteracin el equipo evoluciona el producto (hace una entrega incremental) a partir de los resultados completados en las iteraciones anteriores, aadiendo nuevos objetivos/requisitos o mejorando los que ya fueron completados. Un aspecto fundamental para guiar el desarrollo iterativo e incremental es la priorizacin de los objetivos/requisitos en funcin del valor que aportan al cliente. Beneficios. Se puede gestionar las expectativas del cliente (requisitos desarrollados, velocidad de desarrollo, calidad) de manera regular, puede tomar decisiones en cada iteracin. Esto es especialmente interesante cuando: 1. El cliente no sabe exactamente qu es lo que necesita, lo va sabiendo conforme va viendo cuales son los resultados del proyecto. 2. El cliente necesita hacer cambios a corto plazo (nuevos requisitos o a cambios en los ya realizados) por:

Utilizacin Mtodos giles

81

Cambios en las condiciones del mercado (por un cambio de necesidades, por un nuevo producto que ha lanzado la competencia, urgencias). La reaccin y aceptacin del mercado respecto al uso de los primeros resultados del proyecto. Cualquier cambio en el entorno (recursos, etc.), que pueda incluso finalizar el proyecto manteniendo como mnimo los resultados alcanzados hasta ese momento. 3. El equipo necesita saber si lo que ha entendido es lo que el cliente espera. El cliente puede comenzar el proyecto con requisitos de alto nivel, quizs no del todo completos, de manera que se vayan refinando en sucesivas iteraciones. Slo es necesario conocer con ms detalle los requisitos de las primeras iteraciones, los que ms valor aportan. No es necesario realizar una recoleccin completa y detallada de todos los requisitos antes de empezar el desarrollo del proyecto. El cliente puede obtener resultados importantes y usables ya desde las primeras iteraciones. Se puede gestionar de manera natural los cambios que van apareciendo durante el proyecto. La finalizacin de cada iteracin es el lugar natural donde el cliente puede proporcionar su feedback tras examinar el resultado obtenido. Con esta informacin ya es posible planificar los cambios necesarios para alinearse con las expectativas del cliente desde las primeras iteraciones, de manera que al finalizar el proyecto el cliente obtenga los objetivos esperados. El cliente como mximo puede perder los recursos dedicados a una iteracin, no los de todo el proyecto. La finalizacin de cada iteracin es el lugar natural donde el equipo puede decidir cmo mejorar su proceso de trabajo, en funcin de la experiencia obtenida. Con esta

Utilizacin Mtodos giles

82

informacin ya es posible planificar los cambios necesarios para aumentar la productividad y calidad desde las primeras iteraciones. Permite conocer el progreso real del proyecto desde las primeras iteraciones y extrapolar si su finalizacin es viable en la fecha prevista. El cliente puede decidir re priorizar los requisitos del proyecto, aadir nuevos equipos, cancelarlo, etc. Permite mitigar desde el inicio los riesgos del proyecto. Desde la primera iteracin el equipo tiene que gestionar los problemas que pueden aparecer en una entrega del proyecto. Al hacer patentes estos riesgos, es posible iniciar su mitigacin de manera anticipada. Permite gestionar la complejidad del proyecto: a) En una iteracin slo se trabaja en los requisitos que aportan ms valor en ese momento; b) Se puede dividir la complejidad para que cada parte sea resuelta en diferentes iteraciones. Dado que cada iteracin debe dar como resultado requisitos terminados, se minimiza el nmero de errores que se producen en el desarrollo y se aumentar la calidad. Restricciones. La disponibilidad del cliente debe ser alta durante todo el proyecto dado que participa de manera continua: 1. En el inicio de una iteracin, el cliente ha de detallar (o haber detallado previamente) los requisitos que se van a desarrollar. 2. En la finalizacin de cada iteracin, el cliente ha de revisar los requisitos desarrollados. La relacin con el cliente ha de estar basada en los principios de colaboracin y ganar/ganar ms que tratarse de una relacin contractual en la cual cada parte nicamente defiende su beneficio a corto plazo. Cada iteracin debe dar como resultado requisitos terminados, de manera que el resultado sea realmente til para el cliente y no deje tareas pendientes para futuras iteraciones o para la finalizacin del proyecto.

Utilizacin Mtodos giles

83

Cada iteracin ha de aportar un valor al cliente, entregar unos resultados cerrados que sean susceptibles de ser utilizados por l. Es necesario disponer de tcnicas y herramientas que permitan hacer cambios fcilmente en el producto, de manera que pueda crecer en cada iteracin de manera incremental sin hacer un gran esfuerzo adicional, manteniendo su complejidad minimizada y su calidad. Recomendaciones. Utilizar iteraciones cortas de 2 a 4 semanas incrementa la productividad del proyecto, dado que el equipo trabaja de forma ms eficiente cuando tiene objetivos a corto plazo. Asimismo, con iteraciones cortas la precisin de las estimaciones aumenta. El tamao depende de: 1. Los condicionantes del proyecto. 2. La necesidad de tener feedback ms o menos rpido. 3. Que no se degrade la relacin trabajo til / gestin operativa (por ejemplo reuniones, actividades necesarias que no producen valor directo, etc.). Utilizar iteraciones regulares, de manera que todas sean un timebox de la misma duracin: 1. El equipo aprende a calcular la velocidad de desarrollo, la cantidad de trabajo que puede hacer en una iteracin (sin tener que hacer extrapolaciones si las iteraciones no fuesen regulares). 2. El cliente puede proyectar cuantas iteraciones se necesitan para tener cada entrega, en funcin de la velocidad de desarrollo del equipo (el trabajo que pudo completar en iteraciones anteriores del mismo tamao), y tomar decisiones al respecto. 3. Permite gestionar y sincronizar de manera sencilla las necesidades del proyecto con respecto a las de otros proyectos (integracin con el trabajo

Utilizacin Mtodos giles

84

realizado por otros equipos, compartir personas que son difciles de asignar a un nico equipo). 4. Las iteraciones coincidiendo con meses naturales permiten sincronizar el trabajo del equipo con el de otros departamentos y con el resto de la organizacin (por ejemplo, la organizacin puede tener medidas de resultados y objetivos a nivel trimestral o cuatrimestral). Timeboxing La tcnica del timebox consiste en fijar el tiempo mximo para conseguir unos objetivos, tomar una decisin o realizar unas tareas, y hacer lo mejor que podamos en ese intervalo. De esta manera, en lugar de ponerse a trabajar en algo hasta que est hecho, de antemano se acuerda que slo se dedica un tiempo limitado. La conciencia de esta limitacin temporal favorece la priorizacin de objetivos/tareas y fuerza la toma de decisiones. Algunos ejemplos son: 1. Limitar el tiempo a dedicar en la bsqueda de informacin para elaborar un artculo. 2. Todas las actividades de Scrum: la reunin de planificacin de la iteracin (Sprint planning), la ejecucin de la iteracin (Sprint), la reunin diaria de sincronizacin del equipo (Scrum daily meeting), la demostracin de los requisitos completados (Sprint Demostration) y la Retrospectiva (Sprint Retrospective). Beneficios: 1. Productividad y efectividad. Se prioriza los objetivos o tareas ms importantes a realizar.

Utilizacin Mtodos giles Timebox da soporte al lema lo perfecto es enemigo de lo bueno. Dado que existe una tendencia a ocupar todo el tiempo disponible para conseguir un

85

objetivo, sean 2 das o una semana con un timebox las personas trabajan ms enfocadas y de manera ms eficiente, al existir una fecha lmite a corto plazo para entregar un resultado. Similarmente, el timebox ayuda a eliminar los procesos, tareas y adornos no necesarios. Aumenta la creatividad y fuerza a tomar decisiones para que las cosas estn hechas al final del timebox. Evita dejar las cosas para el final. 2. Aprendizaje. Timebox ayuda a aprender cunto tiempo es necesario para hacer una tarea. La finalizacin del timebox es el momento ideal para obtener feedback del trabajo realizado (como por ejemplo en la demostracin de los requisitos completados en una iteracin): los objetivos conseguidos son suficientes, se cumplen las expectativas, o bien es necesario un nuevo timebox para profundizar ms o conseguir nuevos objetivos?. Recomendaciones: 1. Objetivos claros y realizables. Los objetivos y resultados entregables deben estar claros para que al final del timebox se pueda demostrar que se ha conseguido el resultado esperado. Slo se deben escoger objetivos que se puedan completar en el timebox. Alternativamente, el tiempo elegido de timeboxing debe ser suficiente para poder conseguir estos objetivos; antes de iniciar el timebox, se debe planear las tareas a realizar para poder conseguir los objetivos esperados y estimar su coste temporal (por ejemplo en la reunin de planificacin de la iteracin). Las herramientas con que realizar las tareas deben ser conocidas. 2. Tiempo y recursos fijos, objetivos variables.

Utilizacin Mtodos giles El tiempo y los recursos (por ejemplo, las personas dedicadas) son fijos, mientras que los objetivos son reducibles. En caso de no estar llegando a lograr todos los objetivos, se reduce su nmero de manera que los objetivos

86

que s se consiga al final del timebox mantengan una calidad determinada y se pueda demostrar que se han completado. Como complemento a este planteamiento, es importante que los objetivos estn priorizados por el valor que aportan, de manera que queden sin completar los menos importantes. 3. Sin interrupciones. Para poder lograr los objetivos acordados, mientras se est trabajando en el timebox se debe impedir las interrupciones externas, de manera que se mantenga la concentracin y la productividad (una de las tareas del Scrum Master dentro de la ejecucin de una iteracin). En caso de que las interrupciones externas (o entrada de nuevos objetivos) sean habituales, el timebox puede ser suficientemente pequeo como para permitir que estas interrupciones puedan esperar a la finalizacin del timebox para ser atendidas (o iniciar su desarrollo). 4. Equipo de tamao suficiente. El tamao del equipo debe ser suficiente para reducir el impacto de imprevistos (como una peticin externa no alineada con los objetivos del timebox, o la enfermedad repentina de un miembro del equipo) de manera que no se comprometan seriamente los objetivos del timebox. El Proceso En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de un mes natural y hasta de dos semanas, si as se necesita). Cada iteracin tiene que

Utilizacin Mtodos giles

87

proporcionar un resultado completo, un incremento de producto final que sea susceptible de ser entregado con el mnimo esfuerzo al cliente cuando lo solicite.

Figura 22. El Proceso de Scrum. (Albaladejo et al., 2009) El proceso parte de la lista de objetivos/requisitos priorizada del producto, que acta como plan del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan respecto a su coste y quedan repartidos en iteraciones y entregas. De manera regular el cliente puede maximizar la utilidad de lo que se desarrolla y el retorno de inversin mediante la replanificacin de objetivos que realiza al inicio de cada iteracin. Las actividades que se llevan a cabo en Scrum son las siguientes: Planificacin de la Iteracin (Sprint Planning) La planificacin de las tareas a realizar en la iteracin se divide en dos partes: 1. Primera parte de la reunin. Se realiza en un timebox de cmo mximo 4 horas:

Utilizacin Mtodos giles

88

El cliente presenta al equipo la lista de requisitos priorizada del producto o proyecto, pone nombre a la meta de la iteracin (de manera que ayude a tomar decisiones durante su ejecucin) y propone los requisitos ms prioritarios a desarrollar en ella. El equipo examina la lista, pregunta al cliente las dudas que le surgen, aade ms condiciones de completitud y selecciona los requisitos ms prioritarios que se compromete a completar en la iteracin, de manera que puedan ser entregados si el cliente lo solicita. 2. Segunda parte de la reunin. Se realiza en un timebox de cmo mximo 4 horas. El equipo planifica la iteracin, dado que ha adquirido un compromiso, es el responsable de organizar su trabajo y es quien mejor conoce cmo realizarlo. Define las tareas necesarias para poder completar cada requisito, creando la lista de tareas de la iteracin. Realiza una estimacin conjunta del esfuerzo necesario para realizar cada tarea. Cada miembro del equipo se auto asigna a las tareas que puede realizar. La estimacin la lleva a cabo el equipo. La estimacin no la realiza el cliente (Product Owner), por que no es l quien se va a ensuciar las manos y luchar por cumplir con fechas. Todo el equipo realiza la estimacin para: a) Reforzar el compromiso de todo el equipo respecto a las fechas que dan al cliente; b) Reforzar el compromiso de cada miembro del equipo respecto al resto; c) Hacer que todo el mundo se sienta odo. La estimacin se puede realizar utilizando alguna de las siguientes unidades: 1. Das ideales: los das necesarios para que el equipo pueda completar un objetivo, sin considerar interrupciones. Para pasar a das reales hay que aplicar

Utilizacin Mtodos giles un factor de correccin que puede ir del 60 % al 70 % de dedicacin real al proyecto. Asimismo, habr que tener en cuenta un margen para imprevistos como bajas por enfermedad, etc. 2. Puntos de historia de usuario: la complejidad que tiene cada historia de usuario. Un equipo en un proyecto determinado es capaz de completar un nmero semi-regular de puntos de historia cada iteracin (velocidad). Planning Poker .Es una tcnica de estimacin usada en conjuncin con Wideband Delphi, para lograr consensuar estimaciones de tamao de los requisitos de un proyecto de

89

una manera rpida y gil. Es una prctica gil, que resulta til para conducir las reuniones en las que el equipo estima el esfuerzo y la duracin de tareas. Para evitar en estos casos las discusiones dilatadas que no terminan de dar conclusiones concretas, James Grening ide este juego de planificacin como ayuda para conducir la reunin. El Planning Poker es muy sencillo, se presentan los requisitos a estimar uno por uno haciendo una descripcin de los mismos. Luego se procede a discutir aquellos detalles ms relevantes o que no hayan quedado claros. Tras este perodo de discusin cada una de las personas implicadas en el proceso de estimacin elije de su mazo de cartas (que estn numeradas segn la serie de Fibonacci) la carta que representa su estimacin del trabajo que implica implementar el requisito que se est discutiendo.

Figura 23. Las cartas de Planning Poker

Utilizacin Mtodos giles

90

Las estimaciones son privadas hasta que todo el mundo cuenta con una estimacin. En ese momento, todas las estimaciones se hacen pblicas (esto es as para evitar que las estimaciones de unas personas sesguen las de otras). Si la dispersin entre las estimaciones se vuelve al discutir el requisito y se vuelve a realizar el proceso de estimacin. Generalmente la dispersin en las estimaciones es sntoma de que la informacin que maneja parte de los involucrados en el proceso de estimacin no es completa o exacta. La segunda ronda de discusin permite aclarar aquellos puntos oscuros, diferencias de criterio y develar informacin que pueda no ser obvia sobre el requisito, de tal manera que en la siguiente ronda de estimacin, la dispersin de las estimaciones ser mucho menor y se podr llegar fcilmente a un consenso. De esta manera es fcil estimar los requisitos de una manera democrtica, gil y rpida y que lleva a estimaciones respaldadas por todos los involucrados y basadas en consensos, en definitiva estimaciones que todo el mundo puede asumir como suyas y que todo el mundo respetar. Uno de los problemas que tiene el Planning Poker es que requiere que todos los implicados en la estimacin se encuentren en una misma sala. Esto no siempre es posible cuando los equipos de desarrollo estn distribuidos geogrficamente. La unidad de estimacin: el da ideal. Los nmeros que se muestran en las cartas pueden representar distintas unidades. Uno de los enfoques ms utilizados es el de "da ideal de trabajo". Esto es, la unidad representa un da ideal y perfecto de trabajo, sin interrupciones, interferencias o distracciones de ningn tipo. Dicho de otra manera: "si estuviera yo solo encerrado en una habitacin, con alimento ilimitado y trabajando 6 horas perfectas, inspirado y totalmente concentrado, cunto tardara en desarrollar la funcionalidad X de forma completa y con calidad productiva?".

Utilizacin Mtodos giles Por ejemplo, la carta "5" representa que quien estim podra completar la funcionalidad estimada en 5 das "ideales" de trabajo. El desarrollo de Planning Poker fue extrado de (Planificacin de Poker, s.f.). Lista de objetivos / requisitos priorizada (Product Backlog) La lista de objetivos/requisitos priorizada representa la visin y expectativas del cliente respecto a los

91

objetivos y entregas del producto o proyecto. El cliente es el responsable de crear y gestionar la lista (con la ayuda del Facilitador y del equipo, quien proporciona el coste estimado de completar cada requisito). Dado que refleja las expectativas del cliente, esta lista permite involucrarlo en la direccin de los resultados del producto o proyecto. Contiene los objetivos/requisitos de alto nivel del producto o proyecto. Para cada requisito se indica el valor que aporta al cliente y el coste estimado de completarlo. La lista est priorizada balanceando el valor que cada requisito aporta al negocio frente al coste estimado que tiene su desarrollo, es decir, basndose en el Retorno de la Inversin (ROI).

Figura 24. La lista de requisitos priorizada (Product Backlog). En la lista se indican las posibles iteraciones y las entregas esperadas por el cliente (los puntos en los cuales desea que se le entreguen los objetivos/requisitos completados hasta ese momento), en funcin de la velocidad de desarrollo del (los) equipo(s) que trabajar(n) en

Utilizacin Mtodos giles el proyecto. Es conveniente que el contenido de cada iteracin tenga una coherencia, de manera que se reduzca el esfuerzo de completar todos sus objetivos.

92

La lista tambin tiene que considerar los riesgos del proyecto e incluir los requisitos o tareas necesarios para mitigarlos. Antes de iniciar la primera iteracin, el cliente debe tener definida la meta del producto o proyecto y la lista de requisitos creada. No es necesario que la lista sea completa ni que todos los requisitos estn detallados al mismo nivel. Basta con que estn identificados y con suficiente detalle los requisitos ms prioritarios con los que el equipo empezar a trabajar. Los requisitos de iteraciones futuras pueden ser mucho ms amplios y generales. La incertidumbre y complejidad propia de un proyecto hacen conveniente no detallar todos los requisitos hasta que su desarrollo est prximo. De esta manera, el esfuerzo de recoger, detallar y desarrollar el resto de requisitos (menos prioritarios) est repartido en el perodo de ejecucin del proyecto. En el caso del desarrollo de un producto, la lista va evolucionando durante toda la vida del producto (los requisitos "emergen"). En el caso de un proyecto, conforme ste avance irn apareciendo los requisitos menos prioritarios que falten. Esto produce varias ventajas: 1. Se evita caer en parlisis de anlisis al inicio del proyecto, de manera que se puede iniciar antes el desarrollo y el cliente puede empezar a obtener resultados tiles. 2. Se evita analizar en detalle requisitos no prioritarios que podran cambiar durante el transcurso del proyecto, dado que el cliente conocer mejor cul ha de ser el resultado a conseguir, o bien por que podran ser reemplazados por otros.

Utilizacin Mtodos giles 3. Puede llegar a un punto del proyecto en que no valga la pena analizar ni desarrollar los requisitos restantes, dado el poco retorno de inversin (ROI) que tienen.

93

Definicin de completado. El cliente y el equipo tienen que acordar la "definicin de completado de los objetivos / requisitos en el proyecto: Debe incluir lo necesario para considerar de manera clara que el cliente obtendr lo que necesita segn sus criterios de entregables y de calidad (producto probado, documentacin, refactorizacin para conseguir calidad interna/mantenibilidad, etc.). A esta definicin de completado hay que aadir las condiciones de completitud de cada objetivo / requisito. Debe asegurar que el producto est preparado para ser entregado al cliente al finalizar cada iteracin, que no hay tareas pendientes que puedan impedir utilizar los resultados del proyecto lo antes posible. De este modo, el cliente podr tomar decisiones correctas cuando al final de cada iteracin el equipo le haga una demostracin de los requisitos completados: cambiar las prioridades en funcin de la velocidad de desarrollo, solicitar una entrega del producto desarrollado hasta ese momento, etc. Iteracin de entrega. Cuando el cliente solicita una entrega de los objetivos/requisitos completados hasta ese momento, el equipo puede necesitar aadir una iteracin de entrega, ms corta que las iteraciones habituales, donde realizar alguna tarea que no ha sido necesaria o posible hasta el momento de la entrega final y acabar de corregir defectos detectados en la ltima demostracin. Uso de la lista: Para medir la velocidad de desarrollo del equipo y extrapolar la fecha de las entregas, es conveniente seguir las siguientes recomendaciones: a) Los requisitos deben tener

Utilizacin Mtodos giles un esfuerzo semejante para ser completados; b) La estimacin de un requisito no debe ser superior a 10 das (si las iteraciones son de 20 das laborables). Cada requisito tiene asociado un factor de complejidad, que permite ajustar su coste

94

estimado en funcin de la incertidumbre de la complejidad de su desarrollo en el momento de introducirlo en la lista. Este factor de coste se ir ajustando conforme las iteraciones avancen y el equipo conozca mejor el producto o proyecto, su contexto y su velocidad de desarrollo con las herramientas y tecnologas que utiliza. Si un requisito depende de otro, se coloca en algn punto por debajo del que depende. Si un requisito no se finaliza en una iteracin, se le vuelve a poner en alguna de las siguientes iteraciones, indicando el coste pendiente de desarrollo. El origen permite saber quin podra participar en la definicin de un objetivo / requisito y sera conveniente que estuviese presente en el momento de su demostracin. El progreso del proyecto y su velocidad con respecto a requisitos completados se muestra en un grfico de trabajo pendiente (Burndown chart). Lista de tareas de la iteracin (Sprint Backlog). Lista de tareas que el equipo elabora como plan para completar los objetivos/requisitos seleccionados para la iteracin y que se compromete a demostrar al cliente al finalizar la iteracin, en forma de incremento de producto preparado para ser entregado. Esta lista permite ver las tareas donde el equipo est teniendo problemas y no avanza, con lo que le permite tomar decisiones al respecto. Para cada uno de los objetivos/requisitos se muestran sus tareas, el esfuerzo pendiente para finalizarlas y la auto asignacin que han hecho los miembros del equipo. Uso de la lista: Los objetivos/requisitos estn ordenados por orden de prioridad para el cliente. Por ello, signos de falta de foco, problemas o impedimentos seran que se estn

Utilizacin Mtodos giles completando objetivos que no son los primeros de la lista, as como tener demasiados objetivos / requisitos en progreso simultneamente.

95

Figura 25. La lista de tareas de la iteracin (Sprint Backlog). Si una tarea depende de otra, se coloca en algn punto por debajo de la que depende. Las tareas deben estar identificadas de manera que tengan un coste semejante para ser completadas, entre 4 y 16 horas. Este tamao permitir: 1. Que las tareas sean suficientemente pequeas como para poder detectar progreso o estancamiento de manera diaria. 2. Que las tareas no sean muy pequeas, que sean suficientemente relevantes, no generen ruido ni micro gestin. 3. Medir la velocidad de desarrollo del equipo y extrapolar si es posible finalizarlas dentro de la iteracin. El progreso de la iteracin y su velocidad con respecto a tareas u horas pendientes se muestra mediante un grfico de trabajo pendiente (Burndown chart).

Utilizacin Mtodos giles

96

Grficos de trabajo pendiente (Burndown charts). Un grfico de trabajo pendiente a lo largo del tiempo muestra la velocidad a la que se est completando los objetivos/requisitos. Permite extrapolar si el equipo podr completar el trabajo en el tiempo estimado. Se pueden utilizan los siguientes grficos de esfuerzo pendiente: 1. Das pendientes para completar los requisitos del producto o proyecto (product burndown chart), realizado a partir de la lista de requisitos priorizada (Product Backlog). 2. Horas pendientes para completar las tareas de la iteracin (sprint burndown chart), realizado a partir de la lista de tareas de la iteracin (Iteration Backlog). Este tipo de grfico permite realizar diversas simulaciones: ver cmo se aplazan las fechas de entrega si se le aaden requisitos, ver cmo se avanzan si se le quitan requisitos o se aade otro equipo, etc.

Figura 26. Product burndown chart

Utilizacin Mtodos giles

97

Figura 27. Sprint burndown chart El tabln de tareas (Scrum Taskboard). La lista de objetivos a completar en la iteracin tambin se puede gestionar mediante un tabln de tareas. Al lado de cada objetivo se ponen las tareas necesarias para completarlo, en forma de post-its, y se van moviendo hacia la derecha para cambiarlas de estado (pendiente de iniciar, en progreso, completada). Para cada miembro del equipo se puede utilizar adhesivos de colores ms pequeos sobre cada tarea, de manera que se pueda ver en qu tareas est trabajando cada cual. El equipo elabora esta lista de tareas en la segunda parte de la reunin de planificacin de la iteracin. La lista va evolucionando (nuevas tareas, cambios, estado, esfuerzo pendiente) a medida que la iteracin avanza, especialmente durante la reunin diaria de sincronizacin. Este tabln o cuadro de mandos acta como radiador de informacin tanto para el equipo como para cualquier otra persona relacionada con el proyecto. Por ello tambin se suele poner: el objetivo de la iteracin, la hora de la reunin diaria de sincronizacin del equipo (Scrum daily meeting), una leyenda con los nombres y colores de los miembros del equipo, los grficos de trabajo pendiente (Burndown charts), las tareas sorpresa todava "no planeadas", la lista de impedimentos (con la persona asignada para su resolucin), la lista de

Utilizacin Mtodos giles

98

objetivos/requisitos priorizada (Product Backlog), un calendario con los hitos ms relevantes, etc.

Figura 28. El tabln de tareas (Scrum Taskboard) Ejecucin de la Iteracin (Sprint) En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones de un mes natural y hasta de dos semanas). Cada iteracin tiene que proporcionar un resultado completo, un incremento de producto que sea susceptible de ser entregado con el mnimo esfuerzo cuando el cliente (Product Owner) lo solicite. Cada da el equipo realiza una reunin de sincronizacin, donde cada miembro inspecciona el trabajo de los otros para poder hacer las adaptaciones necesarias, comunica cuales son los impedimentos con que se encuentra, actualiza el estado de la lista de tareas de la iteracin (Sprint Backlog) y los grficos de trabajo pendiente (Burndown charts). El Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir con su compromiso y de que no se merme su productividad. Elimina los obstculos que el equipo no puede resolver por s mismo y protege al equipo de interrupciones externas que puedan afectar su compromiso o su productividad. Recomendaciones. Para poder completar el mximo de requisitos en la iteracin, se debe minimizar el nmero de objetivos/requisitos en que el equipo trabaja simultneamente (WIP, Work In Progress), completando primero los que den ms valor al cliente. Esta forma

Utilizacin Mtodos giles de trabajar, que se ve facilitada por la propia estructura de la lista de tareas de la iteracin, permite tener ms capacidad de reaccin frente a cambios o situaciones inesperadas. Restricciones. No se puede cambiar los objetivos/requisitos de la iteracin en curso. En la reunin de planificacin de la iteracin el equipo adquiri el compromiso de completar en la iteracin unos requisitos concretos, bas su plan y organizacin en ellos.

99

Cambiar los objetivos/requisitos de la iteracin dificulta la concentracin del equipo, baja su moral y su compromiso. El hecho de no poder cambiar los objetivos/requisitos de la iteracin una vez iniciada facilita que el cliente cumpla con su responsabilidad de conocer qu es lo ms prioritario a desarrollar, antes de iniciar la iteracin. Notar que Scrum minimiza esta necesidad ya que, por un lado, los objetivos/requisitos que se estn desarrollando eran los ms prioritarios justo antes de iniciar la iteracin y, por otro lado, las iteraciones en Scrum son suficientemente cortas (2 o 4 semanas) como para que la probabilidad de cambios una vez iniciada la iteracin sea mnima. Terminacin anormal de la iteracin. Slo en situaciones muy excepcionales el cliente o el equipo pueden solicitar una terminacin anormal de la iteracin. Esto puede suceder si, por ejemplo, el contexto del proyecto ha cambiado enormemente y no es posible esperar al final de la iteracin para aplicar cambios, o si el equipo encuentra que es imposible cumplir con el compromiso adquirido. En ese caso, se dar por finalizada la iteracin y se dar inicio a otra mediante una reunin de planificacin de la iteracin. Reunin diaria de sincronizacin del equipo (Scrum daily meeting). El objetivo de esta reunin es facilitar la transferencia de informacin y la colaboracin entre los miembros del equipo para aumentar su productividad. Cada miembro del equipo inspecciona el trabajo que el resto est realizando (dependencias entre tareas, progreso hacia el objetivo de la iteracin, obstculos que pueden

Utilizacin Mtodos giles

100

impedir este objetivo) para al finalizar la reunin poder hacer las adaptaciones necesarias que permitan cumplir con el compromiso conjunto que el equipo adquiri para la iteracin (en la reunin de planificacin de la iteracin). Cada miembro del equipo debe responder las siguientes preguntas en un timebox de cmo mximo 15 minutos: 1. Qu he hecho desde la ltima reunin de sincronizacin? Pude hacer todo lo que tena planeado? Cul fue el problema? 2. Qu voy a hacer a partir de este momento? 3. Qu impedimentos tengo o voy a tener para cumplir mis compromisos en esta iteracin y en el proyecto? Como apoyo a la reunin, el equipo cuenta con la lista de tareas de la iteracin, donde se actualiza el estado y el esfuerzo pendiente para cada tarea, as como con el grfico de horas pendientes en la iteracin. Beneficios. Aumentar la productividad en el proyecto y potencia el compromiso de equipo, dado que cada miembro pone de manifiesto delante del resto: 1. Las tareas que pueden afectar a otros miembros del equipo, por que impactan en su trabajo o por que hay dependencias (especialmente si existe un retraso). 2. Los impedimentos con que se encuentra. El resto de miembros del equipo pueden ofrecer ayuda a otros en la realizacin de tareas o para resolver problemas que ya tuvieron anteriormente. El Facilitador (Scrum Master) se encargar de solucionar los impedimentos que el equipo no puede solucionar por s solo o que le quitan tiempo para cumplir con su compromiso fundamental de desarrollo de requisitos.

Utilizacin Mtodos giles

101

3. Las tareas no planeadas que est realizando que el equipo no conoce y puede que no estn alineadas con el compromiso del equipo, aunque l crea que lo que est haciendo es lo mejor que se puede hacer. 4. Cuales son sus necesidades. Cada miembro entiende las necesidades de los otros miembros del equipo respecto a su trabajo, de manera que pueden colaborar y adaptar sus trabajos para que den el mximo valor y no realizar tareas que no proporcionan ningn beneficio al resto del equipo. 5. Cual es su ritmo de trabajo. Se hace visible si de manera continua un miembro del equipo est realizando tareas por debajo del rendimiento esperado. Se evita que una persona seale con el dedo a otra, dado que la reunin de sincronizacin pone a todos los miembros del equipo en la misma situacin de tener que explicar en qu tareas estn trabajando. 6. Cuales son los criterios que est utilizando para realizar sus tareas, de manera que estn alineados con los objetivos comunes del equipo. 7. Fomentar el aprendizaje de los miembros del equipo, ya que pueden ver cmo trabajan los otros segn sus especialidades y experiencias. 8. Conocer el estado de la iteracin, ver si es posible completar los requisitos a que se comprometi el equipo, en vista de las desviaciones y de las tareas pendientes. Restricciones. La reunin diaria de estado y sincronizacin del equipo no es para resolver problemas, los problemas se resuelven despus de la reunin. No a todos los miembros del equipo les interesan todos los detalles de cada tema. En la reunin los miembros del equipo programan reuniones entre ellos donde colaborar sincronizando tareas, ayudando a resolver problemas, etc.

Utilizacin Mtodos giles

102

El equipo debe contar con unos criterios consensuados sobre el proceso de ejecucin de las de tareas. El proceso de ejecucin de las tareas debe estar consensuado para evitar que cada reunin sea una exposicin de discrepancias entre los miembros del equipo. Recomendaciones. Realizar la reunin diaria de sincronizacin de pie, para que los miembros del equipo no se relajen ni se extiendan en ms detalles de los necesarios. Realizar las reuniones de colaboracin entre miembros del equipo justo despus de la de sincronizacin. Demostracin de Requisitos Completados (Sprint Demonstration) El ltimo da de la iteracin se realiza la reunin de revisin de la iteracin. Tiene dos partes, una de ellas es la Demostracin. Se trata de una reunin informal donde el equipo presenta al cliente los requisitos completados en la iteracin, en forma de incremento de producto preparado para ser entregado con el mnimo esfuerzo, haciendo un recorrido por ellos lo ms real y cercano posible al objetivo que se pretende cubrir. En funcin de los resultados mostrados y de los cambios que haya habido en el contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya desde la primera iteracin, re planificando el proyecto. Se realiza en un timebox de cmo mximo 4 horas. Beneficios. El cliente puede ver de manera objetiva cmo han sido desarrollados los requisitos que proporcion, ver si se cumplen sus expectativas, entender ms qu es lo que necesita y tomar mejores decisiones respecto al proyecto. El equipo puede ver si realmente entendi cules eran los requisitos que solicit el cliente y ver en qu puntos hay que mejorar la comunicacin entre ambos. El equipo se siente ms satisfecho cuando puede ir mostrando los resultados que va obteniendo. No est meses trabajando sin poder exhibir su obra.

Utilizacin Mtodos giles

103

Restricciones. Slo se pueden mostrar los requisitos completados, para que el cliente no se haga falsas expectativas y pueda tomar decisiones correctas y objetivas en funcin de la velocidad de desarrollo y el resultado realmente completado. Un requisito no completado quedar como un requisito ms a re planificar. Replanificacin del proyecto. En las reuniones de planificacin de entregas y/o durante el transcurso de una iteracin, el cliente va trabajando en la lista de objetivos/requisitos priorizada del producto o proyecto, aadiendo requisitos, modificndolos, eliminndolos, re priorizndolos, cambiando el contenido de iteraciones y definiendo un calendario de entregas que se ajuste mejor a sus nuevas necesidades. Los cambios en la lista de requisitos pueden ser debidos a: 1. Modificaciones que el cliente solicita tras la demostracin que el equipo realiza al final de cada iteracin sobre los resultados obtenidos, ahora que el cliente entiende mejor el producto o proyecto. 2. Cambios en el contexto del proyecto (sacar al mercado un producto antes que su competidor, hacer frente a urgencias o nuevas peticiones de clientes, etc). 3. Nuevos requisitos o tareas como resultado de nuevos riesgos en el proyecto. Para realizar esta tarea, el cliente colabora con el equipo: 1. Para cada nuevo objetivo/requisito conjuntamente se hace una identificacin inicial de sus condiciones de completitud (que se detallarn en la reunin de planificacin de la iteracin). 2. El cliente obtiene del equipo la re-estimacin de costes de desarrollo para completar los objetivos/requisitos siguientes. El equipo ajusta el factor de complejidad, el coste para completar los requisitos y su velocidad de desarrollo en funcin de la experiencia adquirida hasta ese momento en el proyecto.

Utilizacin Mtodos giles

104

3. El cliente re-prioriza la lista de objetivos/requisitos en funcin de estas nuevas estimaciones. Hay que notar que el equipo sigue trabajando con los objetivos/requisitos de la iteracin en curso, (que de hecho eran los ms prioritarios al iniciar la iteracin). No es posible cambiar los requisitos que se desarrollan durante la iteracin. En la reunin de planificacin de la iteracin el cliente presentar la nueva lista de requisitos para que sea desarrollada. Beneficios. El cliente puede tomar decisiones con tiempo respecto al progreso del proyecto y posibles desviaciones: 1. Re planificar el proyecto para obtener un nuevo calendario de entregas que cumpla con sus necesidades actuales. 2. Incorporar nuevos recursos. 3. Cancelar el proyecto con los requisitos completados hasta el momento plenamente operativos, si el beneficio pendiente de obtener es menor que el coste de desarrollo. El plan de proyecto se actualiza con la velocidad de desarrollo del equipo, se evitan sorpresas de ltima hora. Retrospectiva (Sprint Retrospective) Esta reunin se realiza despus de la reunin de demostracin al cliente de los objetivos conseguidos en la iteracin, para poder incorporar su feedback y cumplimiento de expectativas como parte de los temas a tratar en la reunin de retrospectiva. Con el objetivo de mejorar de manera continua su productividad, el equipo analiza cmo ha sido su manera de trabajar durante la iteracin: 1. Qu cosas han funcionado bien. 2. Cuales hay que mejorar.

Utilizacin Mtodos giles 3. Qu cosas quiere probar hacer en la siguiente iteracin. 4. Qu ha aprendido.

105

5. Cuales son los problemas que podran impedirle progresar adecuadamente. El Facilitador se encargar de ir eliminando los obstculos identificados que el propio equipo no pueda resolver por s mismo. Se realiza en un timebox de cmo mximo 3 horas. Beneficios. Incrementa la productividad en el proyecto y el aprendizaje del equipo de manera sistemtica, iteracin a iteracin, con resultados a corto plazo. Aumenta la motivacin del equipo dado que participa en la mejora de proceso, se siente escuchado, toma decisiones consensuadas (y ms sostenibles) para ir eliminando lo que le molesta y le impide que sea ms productivo. Restricciones. Es necesario que el Equipo y el Facilitador dispongan de autoridad, mecanismos y recursos para ir mejorando su forma de trabajar y el contexto del proyecto. Es frustrante encontrar sistemticamente los mismos obstculos y no poder solucionarlos.

Utilizacin Mtodos giles LAS ENCUESTAS Introduccin

106

La modalidad que se utiliz para relevar los datos fue enviar encuestas por mail. Las mismas consistieron en un cuestionario de preguntas abiertas resumidas en siete tems: 1. Metodologa utilizada en el lugar de trabajo. 2. Tiempo de experiencia en el uso de mtodos giles. 3. Practicas utilizadas. 4. Reaccin de los clientes. 5. Certificaciones de calidad. 6. Casos de xito. 7. Rol del encuestado en los proyectos. Se eligi la metodologa de preguntas abiertas, ya que pese a ser mas dificultoso el anlisis de los resultados, las respuestas son mucho mas ricas y permiten a los encuestados expresar su opinin y explayarse con libertad sobre los temas tratados. Para realizar esta tarea se debieron conseguir las direcciones de correo de personas que trabajaran en alguna empresa de desarrollo de software que implemente mtodos giles. Se utilizaron varias estrategias para tratar de contactar a los encuestados, las mismas se detallan en los prrafos siguientes. Se busco en internet empresas que mencionen en sus pginas Web el uso de estas metodologas. Una vez encontradas, se enviaron mails a las direcciones de contacto que figuraban en la pgina solicitando permiso para enviar la encuesta. Este primer intento no tuvo mucho xito, muy pocos respondieron. Un motivo puede ser que quien abre el correo de contacto de la pgina Web de la empresa, no es siempre la persona indicada para decidir si se puede responder o no una encuesta sobre la forma de trabajo de la empresa y descarte la misma.

Utilizacin Mtodos giles

107

El segundo intento, que tuvo mas xito que el anterior, fue buscar paginas Web de la Argentina, que se relacionen con las metodologas giles. De esta forma, la autora se suscribi al grupo giles-argentina, perteneciente a la Comunidad Latinoamericana de Metodologas giles, y envi un mail a lista de usuarios solicitndoles autorizacin para enviarles la encuesta. Se obtuvieron de esta forma algunas respuestas mas, pero an eran muy pocas. El tercer paso fue buscar en las paginas Web de eventos, como las Jornadas Latinoamericanas giles 2008 y giles 2009, presentaciones realizadas por expositores de empresas del pas, y luego de obtener sus nombres, tratar de conseguir sus direcciones de correo ya sea desde el documento de la presentacin, ya que muchos la firman, o en la Web. En los casos en que se pudo conseguir una direccin de contacto, se envo un primer correo comentando de qu se trataba el proyecto y solicitando permiso para enviar la encuesta. Este fue el mtodo por el cual se consiguieron la mayor cantidad de respuestas. Otra forma que se utiliz para contactar, fue enviar un mail a quienes escriban a la lista giles-argentina, solicitando permiso para enviarles la encuesta, tambin fue un mtodo efectivo, la mayora respondi al ser un mail personalizado, y no enviado masivamente a la lista. Tambin se contactaron algunos docentes, quienes a criterio de la autora por estar relacionados con el tema, podran proporcionar algn contacto o responder ellos mismos la encuesta. Se obtuvieron algunos contactos de esta forma. Resultados Obtenidos Se enviaron 44 mails comentando el proyecto y solicitando permiso para enviar la encuesta. De stos, 35 respondieron que se les enve la encuesta, 2 ofrecieron otros contactos y 7 no respondieron.

Utilizacin Mtodos giles Se enviaron las 35 encuestas, 7 no respondieron. A continuacin se detallan las 28 encuestas respondidas. Las Respuestas

108

Como se coment antes, por ser preguntas abiertas, muchas de las respuestas son ricas en contenido, por lo que se decidi transcribirlas textualmente, respetando la redaccin de los encuestados, incluso los trminos utilizados en ingls, generalmente referenciados a las prcticas de los distintos mtodos giles. Cabe mencionar que las prcticas aludidas fueron desarrolladas en el presente trabajo cuando se explic la metodologa a la que pertenecen. Pregunta 1 Cul o cules de las metodologas giles se utilizan donde usted trabaja? 1. Usamos principalmente Scrum y XP, aunque tambin nos apoyamos en un universo mayor, que es Lean. En el denominado Lean Thinking, cuyo origen se podra rastrear en Toyota, hace ya medio siglo, se estipulan una serie de principios fundamentales sobre los cuales consideramos que se apoya el movimiento Agile. De Lean usamos tcnicas muy concretas como Value Stream Mapping o Kanban, y principios un poco menos especficos: Pull vs Push, Continuous flow, Waste elimination y fundamentalmente la mejora continua. Me gustara aclarar que no aplicamos metodologa en el sentido de un set fijo de pasos o cosas para realizar en cada proyecto. Vemos a Agile como un marco de trabajo muy til, pero que siempre requiere de una adaptacin al contexto de cada proyecto. Con esto quiero decir que nunca realizamos exactamente los mismos pasos de la misma manera, sino que para cada situacin es necesario entender el contexto y ajustar el modo en que ser encarada. Lo que s se tiene es un punto de partida o un marco genrico dentro del cual ajustamos las variables especficas. Siendo ms concreto: siempre

Utilizacin Mtodos giles

109

trabajamos con entregas frecuentes, pero no siempre las frecuencias de entrega son las mismas. Siempre trabajamos integrando al cliente al proyecto, no siempre lo tenemos en nuestra oficina. Siempre tenemos retrospectivas, no siempre son al fin de una iteracin. Es ms, no siempre tenemos iteraciones, a veces un enfoque de flujo continuo (ver Kanban) nos sirve mucho ms. 2. Tomamos prcticas en general pero la que mas seguimos es SCRUM. 3. Usamos algunas de las prcticas recomendadas por Scrum y varias de las de XP, en ninguno de los dos casos, en forma completa. 4. Usamos SCRUM como metodologa de Gestin y nos basamos en Extreme Programming (XP) para aplicar al desarrollo. 5. No utilizamos ninguna metodologa gil en particular sino que tenemos una combinacin propia. 6. SCRUM. 7. Usamos una metodologa basada en Scrum. Toma prcticas de esta, pero no es Scrum "by the book"6. Tambin usamos algunas prcticas de XP. 8. SCRUM. 9. Scrum + XP. 10. Utilizamos Scrum, no como metodologa, sino como framework de trabajo. 11. Dentro del Framework Scrum se utilizan varias metodologas segn el proyecto. TDD, Continuos Integration, Pair Programming. En base al inspect and adapt cada team agile es libre de adoptar y probar metodologas nuevas. 12. Scrum.

Seguir el modelo al pie de la letra, como fue propuesto por el autor.

Utilizacin Mtodos giles 13. Scrum. Actualmente trabajo en Mercado Libre desde febrero de este ao,

110

estamos implementando Scrum desde hace 4 meses. Anteriormente trabaje en otra empresa donde empez mi experiencia con este marco de trabajo. 14. Scrum. 15. Scrum. 16. Scrum. Planeamos usar XP. 17. Actualmente, estamos aplicando Scrum en uno de nuestros equipos, y una adaptacin entre Scrum y Kanban. 18. Para gestin de proyectos utilizamos Scrum, y en alguna implementacin para proyectos de soporte estamos usando Kanban. Adems, para mejorar la calidad utilizamos varias prcticas de XP y seguimos los principios de Lean Software Development. 19. Scrum, XP, Crystal Clear. 20. Scrum. 21. No es una metodologa estndar, sino una adaptacin hecha en particular para el contexto propio de la empresa. Si tuviera que decir que se parece ms sera a SCRUM, pero tambin tenemos muchas prcticas de agile que exceden SCRUM como integracin continua, TDD, etc. 22. SCRUM. 23. SCRUM. 24. Scrum y muchas prcticas de XP. 25. Estamos usando Scrum. 26. Scrum y Extreme Programming.

Utilizacin Mtodos giles 27. Utilizamos un approach propio de acuerdo a cada proyecto basado en el

111

concepto de metodologas giles. No usamos ningn framework en particular (como Scrum). 28. Scrum, RUP. Anlisis de las respuestas. Con los resultados obtenidos se ha elaborado el siguiente grfico. Para aquellos que respondieron utilizar ms de una metodologa, se sumo uno en cada una de las mencionadas. Se puede observar: 1. el 58% utiliza Scrum o alguna de sus prcticas. 2. el 27% utiliza XP o alguna de sus prcticas. 3. el 7% utiliza Lean o alguna de sus prcticas. 4. el 4% utiliza una metodologa gil propia. 5. el 2% utiliza Crystal Clear o alguna de sus prcticas. 6. el 2% restante utiliza RUP.

2% 2% 7% Scrum 4% XP Lean Crystal Clear Rup Mtodo agil propio 27% 58%

Figura 29. Distribucin en el uso de los mtodos giles. Cabe mencionar, que 13 de los 28 encuestados utilizan Scrum como nico framework de trabajo, el resto utiliza las prcticas que mas le interesan de cada mtodo.

Utilizacin Mtodos giles

112

30 25 20 15 10 5 0
Metodo de trabajo Solo Scrum; 13 Practicas de distintos metodos; 15

Figura 30. Comparacin entre el uso de Scrum como nico framework de trabajo y la combinacin de distintas prcticas giles. Pregunta 2 Cuanto tiempo de experiencia tienen aplicando esta metodologa? 1. Remarcando la diferenciacin de la palabra metodologa, venimos trabajando con Agile hace ms de 6 aos. Soy CSM (Certified Scrum Master) desde hace 3 aos. Nuestra empresa es ms joven que 6 aos, pero hemos pasado por otras compaas y trabajbamos de este modo (antes, trabaj varios aos con RUP (Rational Unified Process), y por supuesto, aos y aos de nadar contra la cascada). Con mi socio trabajamos juntos en la creacin de la Software Factory de Teletech en Argentina, y fuimos parte del grupo que impuls la adopcin de Agile (concretamente Scrum) dentro de la Factory, y finalmente de la corporacin. Durante los aos en Teletech pudimos evaluar la efectividad de esta filosofa de trabajo en las trincheras, con muchos equipos de trabajo y cientos de proyectos. La Factory se inici con un grupo de 16 personas (entre las que estbamos nosotros) y creci hasta tener un total de ms de 170 empleados. Actualmente cubre todas las necesidades de software de la corporacin (ms de 60.000 empleados en ms de 16 pases). Todo el software se construye de modo Agile. 2. Algunas prcticas se han trabajado desde el ao 2005 aproximadamente.

Utilizacin Mtodos giles 3. Dos o tres aos. 4. Estamos aplicando mtodos giles desde 2006. Y contamos con varios certificados CSM. 5. 6 aos. 6. 2.5 aos. 7. Casi 3 aos. El primer proyecto con esta metodologa empez a fines del 2006. 8. Ms de 5 aos, aunque la experiencia vara entre algunos miembros. 9. 5 aos. 10. La empresa tiene aproximadamente 2 aos, y desde su inicio la idea es establecer el proceso basado en metodologas giles, el mismo se va desarrollando de forma incremental, con lo cual tambin es incremental la implementacin de metodologas giles en la empresa. 11. Ms de 3 aos. 12. 1 ao y medio aproximadamente. 13. 3 Aos. Empec en el 2006 para un proyecto de Microsoft USA. 14. 7 meses. 15. 2 aos. 16. En el equipo, 5 meses (yo tengo ms tiempo).

113

17. En lo personal, tengo ms de un ao y medio de experiencia en metodologas giles. En la empresa, el equipo con mayor experiencia tiene aproximadamente 6 meses. 18. Nuestra experiencia es mayor a 3 aos. 19. 4 aos. 20. 4-5 aos.

Utilizacin Mtodos giles

114

21. Dado que tenemos definido un proceso de mejora continua la forma de trabajo est en constante evolucin. La empresa trabaja con mtodos giles en general desde hace ms de 3 aos. 22. Un ao. 23. 2/3 aos. 24. 2 aos. Fuimos incorporando prcticas de XP con el correr del tiempo. 25. Hace casi dos aos que estamos usndola. En este momento la usamos en proyectos que, aproximadamente, ocupan el 45% de los personas. 26. 3 aos. 27. Desde prcticamente siempre (al menos ms de 3 aos seguro que es el tiempo que hace que estoy yo). 28. Scrum 3 aos, RUP 4. Anlisis de las respuestas. La experiencia en el uso de los mtodos giles entre los encuestados se puede observar en el siguiente grfico:
14 12 10 8 6 4 2 0
Menos de 2 aos Entre 2 y 4 anos Entre 4 y 6 aos

13 7 7 1
Mas de 6 aos

Figura 31. Aos de experiencia en la aplicacin de mtodos giles Se observa lo siguiente: 1. 7 de los 28 encuestados (25%), menos de 2 aos usando mtodos giles. 2. 13 de los 28 encuestados (46%), entre 2 y 4 aos.

Utilizacin Mtodos giles 3. 7 de los 28 encuestados (25%), entre 4 y 6 aos. 4. 1 de los 28 encuestados (4%), mas de 6 aos. Se dividi por cada una de las categoras anteriores, quienes usan solo Scrum y quienes aplican distintas prcticas, y se obtuvo el siguiente grfico.
Practicas de distintos metodos Solo Scrum

115

14 12
4

10 8 6 4 2 0
1 Menos de 2 aos Entre 2 y 4 anos Entre 4 y 6 aos 6 9 4 1 Mas de 6 aos 3

Figura 32. Aos de experiencia en la aplicacin de mtodos giles y mtodos utilizados Se observa lo siguiente: 1. De los 7 que tienen menos de 2 aos de experiencia, 1 (14%) usa varias prcticas y 6 (86%) solo Scrum. 2. De los 13 que tienen entre 2 y 4 aos de experiencia, 9 (69%) aplican varias prcticas y 4 (31%) solo Scrum. 3. De los 7 que tienen entre 4 y 6 aos de experiencia, 4 (57%) aplican varias prcticas y 3 (43%) solo Scrum. 4. El encuestado con ms de 6 aos de experiencia utiliza una combinacin de varias prcticas.

Utilizacin Mtodos giles

116

Pregunta 3 Que tcnicas propuestas por la metodologa aplican, todas o solo algunas? Si aplican solo algunas, cuales? Porque no utilizan todas? 1. Como te deca en una pregunta anterior, no nos atamos a aplicar todas o algunas de las tcnicas. Usamos las que consideramos tiles para cada situacin o proyecto. Las tcnicas son eso, herramientas. A veces viene bien una pala, a veces precisas un hacha. Algunos proyectos los vemos ms apropiados para usar Scrum puro, esto es, usando todas las ceremonias que Scrum prescribe, y los roles que Scrum prescribe. En otros proyectos, donde se requiere un dinamismo an mayor o bien no es posible planificar una iteracin por adelantado (por ejemplo, un proyecto de mantenimiento) usamos Kanban, y lo suplementamos con tcnicas de Scrum y de XP. En lneas generales, donde ms ajustamos es en el marco de proceso de Management del proyecto. Ah elegimos y ajustamos el modo de trabajo que mejor se ajuste a la realidad de nuestro cliente. En cuanto a lo puramente tcnico, sin embargo, hay muchas herramientas que propone XP que consideramos indispensables: TDD, Refactoring, Integracin Continua, comunicacin diaria, planes honestos. Agile, en cuanto a lo puramente tcnico, requiere mucha disciplina y prolijidad. Como los cambios no son rechazados, sino ms bien al contrario, el cdigo del producto que se construye tiene que estar muy claro y limpio, para poder adaptarlo fcilmente. Es necesario usar patrones y tcnicas de codificacin que faciliten la evolucin de la arquitectura, para no tener que definirla toda upfront. Es necesario trabajar con unit tests, para poder verificar que los cambios no afectan otras reas del producto, etc.

Utilizacin Mtodos giles

117

En este sentido, consideramos de crucial importancia la automatizacin de los tests, no slo a nivel unitario, sino tambin a nivel de integracin. Para esto usamos, tan frecuentemente como sea posible, la herramienta Fitnesse. La disciplina es fundamental, pero irnicamente, esa misma disciplina es lo que da libertad (para hacer cambios, experimentar, fallar rpido y recuperarse an ms rpido). 2. Solo algunas. Lista de requerimientos constante (si entra un requerimiento nuevo sale uno de los que estaba), iteraciones cortas, reuniones quincenales, programacin de a pares, entregas frecuentes, dibujos de requerimientos a mano luego digitalizados por escaneo o fotografa y subido a un wiki, participacin de los clientes en el diseo de los requerimientos. 3. En cuanto a Scrum, aplicamos Stand-up meetings, iteration planning, iteration backlog, retrospectivas. En cuanto a XP, aplicamos la mayora. Nos cuesta lograr que el cliente este a nuestra disposicin y pair programming lo utilizamos en algunas etapas. En los equipos distribuidos realizamos las reuniones diarias mediante Skype. 4. Si bien estas son las metodologas elegidas sobre las que nos basamos, no hacemos una aplicacin pura de ellas, sino que en cada proyecto de software hacemos una customizacin de las metodologas y prcticas giles a aplicar en funcin de la taxonoma del proyecto. 5. Como te deca, usamos una combinacin particular de tcnicas. No creo que en seguir ninguna a rajatablas en todo proyecto. Hay proyectos con diferentes tamaos y caractersticas. En mi opinin es muy difcil que una misma tcnica calce en todos. 6. Se aplican todas, con algunas customizaciones exigidas por Intel.

Utilizacin Mtodos giles 7. Trabajamos en sprints de entre 2 y 4 semanas (dependiendo de las

118

caractersticas del proyecto), tenemos reuniones de planificacin al empezar el sprint, daily meetings y reuniones de demo al terminar. Testing unitario, integracin continua en algunos proyectos en los cuales es factible (algunos trabajamos en el entorno del cliente, por lo tanto no podemos disponer de la infraestructura necesaria), revisiones de cdigo, captura de requerimientos por medio de user stories, planning poker para estimar. Por mencionar algunas. Como te deca, algunas no son aplicables por el cliente. Otras no las aplicamos ahora pero estamos en camino (TDD y pair programming, por ejemplo). 8. Aplicamos algunas. Unit Testing, Continuous Integration, Test Driven Development. 9. Todas. Ejemplos: Scrum: iteraciones cortas, reuniones diarias, reuniones de planning/demo/retrospectivas, etc. XP: TDD, refactoring, Continuous integration, pair programming, etc. 10. Utilizamos algunas tcnicas y/o prcticas, como mencione anteriormente usamos Scrum como framework de trabajo y no como metodologa. Segn el tipo de proyecto, el tipo de cliente que esta del otro lado y otros factores se decide que prcticas utilizar dentro de las propuestas por la metodologa (ac tambin tomamos algunas prcticas de otras metodologas giles Xp, Crystal Clear).Esto se realiza al iniciar el proyecto, y luego se puede ir ajustando durante el desarrollo del mismo. 11. Dado que Agile es no PRESCRIPTIVO, uno de los fundamentos es justamente adaptarse en vez de predecir. Esto hace que un grupo Agile defina libremente lo que usa, y lo desarrolle. As se toman algunas prcticas de XP, de Crystal

Utilizacin Mtodos giles

119

Clear o Scrum mismo (me refiero a Scrum stand ups meetings y retrospectivas por ejemplo). 12. Respecto a Scrum, hacemos sprint planning, daily meetings, demos, retrospectivas, creo que todas. Estimamos usando story point y es el equipo entero quien estima. Las decisiones son guiadas por consenso. 13. Depende el proyecto, estamos tratando de que todos los proyectos cumplan con los prcticas propuestas por Scrum pero algunos por motivos particulares no han podido incorporarlas (los cuales tampoco utilizan Scrum). En Mercado Libre somos 250 personas dedicadas a desarrollar proyectos de software, el 70% de los mismos utiliza Scrum con todas las prcticas. Te cuento que esta es una experiencia muy buena, ya que nunca vi una empresa grande que haga un mismo producto y todos usando Scrum. Independientemente de esto creo que tambin es importante cun bien se aplica la prctica y no si se aplica o no, es decir, en la mayora de los proyectos se usa Scrum con todas sus prcticas, ahora, si me pregunts si todos las aplican bien te puedo contestar que no. Este no es un tema menor y la transformacin hacia la buena aplicacin no es de la noche a la maana. Pens que seguramente donde apliques o migres a Scrum seguramente ya la empresa vena trabajando de una manera, por lo tanto y por denominacin comn, el ser humano tiende a rechazar los cambios. Por esto el proceso de transformacin es muy importante, como as tambin el couching, soporte y comprensin de los equipos de trabajo. 14. Estamos con dos proyectos pilotos en Capital Federal. En Proyecto 1: Todas, algunas todava no nos salen como deberan. Pero estamos aprendiendo.

Utilizacin Mtodos giles

120

En Proyecto 2: Todas las de Scrum y otras cuestiones tcnicas tales como Integracin Continua. 15. Todas las de Scrum. 16. Scrum: todas; XP: solo Pair Programming. El equipo est incorporando prcticas y herramientas al ritmo de una por mes. No hemos llegado an a las prcticas de XP. Esperamos hacerlo en los prximos meses. 17. Aplicamos Scrum y prcticamente todas sus reuniones. Le reunin de sprint planning meeting no siempre puede ser organizada. Pero nuestra Daily standup meeting, y por sobre todo las reuniones de retrospectivas son absolutamente impostergables. La naturaleza de algunos de los proyectos (de corto plazo), hace que algunas veces no se justifique organizar algunas reuniones, que pueden ser resueltas en el transcurso de otras, o muy rpidamente por algn otro medio. 18. De Scrum todas, de XP algunas. En el caso de kanban es un marco de gestin muy poco restrictivo que sigue una serie de principios que aplicamos para la mejora continua. Vamos tomando de a una para mejorar poco a poco, y no siempre todas aplican a nuestros proyectos. 19. Scrum se aplica al 100%, XP solo algunas prcticas como Pair Programming, Continuos Integration, Refactoring, etc, Crystal Clear solo algunas prcticas. No se usan todas las prcticas porque algunas se ha visto que no aplican a la realidad de los proyectos, y otras por dificultades en cuanto a su adopcin. 20. Algunas, la mayora. Daily Standup Meeting, Sprints, Planning Meeting, Retrospectives, Demos. No hacemos planning poker por polticas que exigen el uso de un estimador especfico. No utilizamos Story Points pues las estimaciones deben ser presentadas en horas.

Utilizacin Mtodos giles

121

21. Intentamos aplicar todo lo que hemos definido. Estamos certificados ISO y eso nos obliga a cumplir con las cosas que estn definidas en el proceso. Entre las prcticas definidas por nuestro proceso estn: Desarrollo iterativo e incremental con iteraciones semanales. Reuniones de planificacin semanales con el cliente. Reuniones de revisin semanales con el cliente. Reuniones de retrospectiva del equipo (sin un plazo fijo estipulado por el proceso sino que la periodicidad la determina cada equipo). Integracin contnua. TDD, cuando la lgica de la aplicacin lo amerita. Prueba unitaria automatizada. Utilizacin de estndares de codificacin. Diseo incremental. 22. Sprint Product Backlog, Sprint Planning, Sprint Demo, Planning Poker, Retrospective, ScrumBoard. En los proyectos chicos no aplicamos el Daily meeting porque solo tiene sentido para comunicacin en proyectos grandes. 23. Tratamos de seguir la metodologa "by the book" aplicando todas las tcnicas que propone. Se dice que SCRUM es simple, funciona, y es difcil. Tratamos de cumplir con todas las aplicaciones, pero a veces cuesta mantenerlas, especialmente cuando el cliente no se adapta completamente a la metodologa y tenemos presupuesto y tiempo acotados para terminar el proyecto. 24. De Scrum aplicamos todo el framework para el proceso. De XP aplicamos: continuos integration, design improvements, small releases, coding standards, collective code ownership, simple design, sustainable pace, pair programming (no siempre), unit testing.

Utilizacin Mtodos giles

122

Muchas prcticas de Management de XP son muy similares a las prcticas de Scrum. Otras que no aplicamos (ej. TDD) es porque intentamos ir mejorando y aplicando prcticas nuevas para nosotros de a poco. La idea es ir aplicando con el tiempo todas las prcticas que consideremos nos agregan valor. 25. Usamos la mayora pero hicimos una adaptacin para que sea compatible con nuestro sistema de gestin de la calidad, que es compatible a su vez con CMMI y con ISO. Para los proyectos que no usan este mtodo tenemos un modelo ms clsico basado en el ciclo de vida en 'V' y un mtodo para hacer mantenimiento de software. Ambos compatibles tambin con el sistema de gestin de la calidad. 26. Scrum todo. Algunas prcticas de XP, sobre todo integracin continua y test driven development. Algunas prcticas de XP no se ajustan muy bien a nuestra realidad o no nos resultaron eficientes (como pair programming). 27. De acuerdo al proyecto, pero siempre focalizamos en el entregable, en ser incremental al final de cada iteracin y en utilizar lo que da valor de acuerdo a la situacin. Toda metodologa cubre un gran espectro de proyectos y lo bueno es usar solamente lo que se necesita ya que si se usa una metodologa al 100% es muy probable que se estn haciendo cosas que no agreguen valor a lo que se quiere entregar (en nuestro caso working software). 28. En Scrum Todas, casi siempre, depende el proyecto. En RUP solo las necesarias. Anlisis de las respuestas. Por ser las preguntas abiertas, cada participante respondi de manera diferente. Algunos se limitaron a decir que aplicaban todas las prcticas o solo algunas de un mtodo, otros mencionaron las prcticas que utilizan. Muchos hicieron

Utilizacin Mtodos giles

123

comentarios con respecto al uso de las mismas. De todas estas respuestas se hizo el siguiente anlisis: 1. El 50% de los encuestados respondi que utiliza las tcnicas o prcticas propuestas por los distintos mtodos que mejor se adaptan al proyecto o al cliente en cuestin. No siempre aplican las mismas. 2. El 53% (15) utiliza todas las prcticas propuestas por Scrum. 3. Las prcticas de Scrum mencionadas fueron: Reuniones diarias de pie (Stand up daily meetings) (6). Planificacin de la iteracin (Sprint planning) (6). Retrospectivas (Sprint Retrospective) (6). Demostracin al cliente (Sprint Demostration) (4). Lista de tareas de la iteracin (Sprint Backlog) (2) Sprint (2). Poker planning (2). Tabln de tareas (Scrum Blackboard) (1). 4. Las prcticas de XP mencionadas fueron: Integracin continua (Continuos Integration) (9). Programacin de a pares (Pair Programming) (7). Programacin dirigida por pruebas (TDD) (6). Test unitario automatizado (5). Refactorizacin continua. (Refactoring) (3). Estndares de codificacin (Coding standards) (2). Historias de usuario (User Stories) (2). Propiedad colectiva de cdigo (Collective code ownership) (1). Diseo simple (Simple design) (1).

Utilizacin Mtodos giles Ritmo sostenible (Sustainable pace) (1).

124

5. El 11% (3) de los encuestados mencionaron utilizar prcticas de Crystal Clear. 6. El 7% (2) utiliza Kankan combinado con otras tcnicas de Scrum o XP. 7. Por ltimo tambin se mencionaron prcticas que son comunes a la mayora de los mtodos giles: Entregas frecuentes. Participacin del cliente. Iteraciones cortas. Diseo incremental. Pregunta 4 Con respecto a los clientes: Usan esta metodologa para todos sus clientes? Para los que no las usan, que mtodos aplican? Como reaccionan los clientes, se comprometen con el proyecto? 1. Con todos nuestros clientes trabajamos en forma Agile. Con algunos de una manera, con otros de otra. Pero en todos los casos nos basamos en los principios del Manifesto Agile para guiar la colaboracin. En una gran mayora de casos, la reaccin es de un gran entusiasmo y compromiso. Les resulta muy atractivo estar mucho ms involucrados y entender de primera mano las realidades y dificultades del desarrollo de SU proyecto. En algunos casos, cuando las personas involucradas del lado del cliente no estn verdaderamente interesadas en el proyecto (pensar en una gran corporacin, donde la cultura no vincula el xito de un proyecto con el xito de la persona), pueden llegar a verlo como un problema. Agile no resuelve los inconvenientes mgicamente, pero los resalta muy rpido. Si las personas

Utilizacin Mtodos giles

125

tienen algn tipo de inters en mantener cosas en la sombra, un desarrollo gil va en contra de esos intereses. 2. Utilizamos los mtodos mencionados con todos nuestros clientes y en general se comprometen con el proyecto. 3. Si, usamos los mtodos mencionados con todos los clientes, aunque variamos las prcticas de acuerdo al tamao del proyecto, tiempos disponibles, etc. En general los clientes aprecian la alta visibilidad sobre el avance del proyecto. 4. Contamos con clientes de todas las industrias y verticales de negocio, el grado de compromiso varia de proyecto a proyecto y depende muchas variables. 5. S se comprometen, aunque no creo que tengan consciencia qu tipo de metodologa usamos. 6. Lo aplicamos a todos nuestros clientes. La parte del involucramiento de stakeholders es formal a travs de la firma de documentos como el plan de proyectos y los requerimientos. 7. Si bien soportamos proyectos con metodologas tradicionales, actualmente todos los proyectos trabajan con esta metodologa. En caso de no aplicarla para algn cliente tenemos definida una metodologa de tipo waterfall. La reaccin depende muchsimo del tipo de cliente, prioridad del proyecto y tipo de proyecto. En algunos hay alta compromiso, participando en las daily meetings, etc. En otros, por ah no estn en la daily pero seguro estn en la planificacin y demo. Tambin se los compromete en el soporte para la definicin de requerimientos.

Utilizacin Mtodos giles 8. Utilizamos estos mtodos solo para los clientes que son compatibles con la

126

metodologa. Para los que no, generalmente exponemos un cronograma macro, y llevamos el proyecto internamente con integraciones. Los clientes reaccionan con variedad, algunos estn ms interesados en la metodologa que otros. Muchas veces tratamos de ensearle al cliente sobre las metodologas. 9. Usamos estos mtodos para todos los clientes, y siempre se comprometen con el proyecto. 10. No la usamos para todos, segn el tipo de cliente decidimos que metodologa usar, en nuestro caso tenemos proyectos tipo software factory en los que se hace muy difcil aplicar un metodologa propia, en este caso generalmente terminamos adaptndonos a la metodologa de trabajo del cliente. En el caso de proyectos de tipo llave en mano se utilizamos Scrum, hemos tenido un proyecto en el que el cliente estaba muy presente, (daily meeting todos los das) y realmente se involucro dentro del proyecto actuando de product owner. Y tambin tuvimos casos donde el cliente no estuvo demasiado presente en el cual se aplic Scrum y actuando de product owner una persona de la empresa, la cual realiz los requerimientos. 11. No la usamos para todos, inspect and adapt. Los clientes que logran hacer iteraciones y entienden el valor de la agilidad, no lo abandonan nunca. Sin embargo hay organizaciones que no pueden lograrlo. 12. Hace poco que estoy en la empresa, tengo entendido que no se usan mtodos giles para todos los clientes, pues la empresa hace otras cosas adems de desarrollo de software, no se que usan para esos clientes.

Utilizacin Mtodos giles

127

En el proyecto que trabajo los clientes estn bastante comprometidos, porque quieren implementar en poco tiempo. Generalmente nos responden preguntas en el da. 13. Al ser una empresa que produce un producto, tenemos al cliente dentro de la empresa. Esto lo comento porque es una particularidad, no somos una consultora de sistemas, somos una empresa de producto con un rea de sistemas. El "Product Owner" como define Scrum para el que representa los intereses del negocio y conoce del mismo, no necesariamente es una sola persona. Lo que pas, es que cuando empezamos a implementar esta metodologa obtuvimos un poco mas de compromiso por la aprobacin formal del producto. 14. No las usamos para todos, estamos haciendo una prueba piloto con dos proyectos. Para el resto usamos Watherfalls, siguiendo una metodologa que se fue definiendo internamente. Las reacciones de los clientes fueron: En Proyecto 1: Depende del usuario, los ms descredos a partir del 4to sprint (tenemos Sprint de 4 semanas) confiaron (tomando en cuenta que tengo usuarios muy "golpeados" por fracasos en TI). En Proyecto 2: El rol de Product Owner lo asumi un analista funcional, interactuando con los usuarios, por lo tanto no sintieron el esfuerzo extra de compromiso, pero s estn viendo los beneficios de entregas ms rpidas con muy buena calidad. 15. Solamente usamos mtodos giles para proyectos donde el equipo no sea mayor a 6 personas y los clientes se comprometen con el proyecto. Para otros proyectos usamos el ciclo de vida CMMi.

Utilizacin Mtodos giles

128

16. Usamos los mtodos giles con todos los clientes. Se comprometen mucho, se entusiasman y participan. 17. Utilizamos esta metodologa para desarrollos, el 100% de las veces provenientes de nuestros clientes internos (Business, y otras areas comerciales). La experiencia demostr que en primera instancia, nuestros clientes se muestran expectantes, son conscientes de los problemas de comunicacin u organizacin que se ven en los equipos, pero esperan un cambio. Al cabo de poco tiempo, cuando los resultados son evidentes, se muestran muy proactivos y comprometidos con la iniciativa. En algunos casos, y en algunos equipos, an se esta trabajando sin ninguna metodologa en particular. Por lo general esto provoca muchos desentendidos y cierta desorganizacin. Paulatinamente, estamos intentando modificar esta conducta proveniente de la cultura organizacional, para promover prcticas giles. 18. De las puertas para adentro lo usamos para todos. Nos cuesta mucho firmar contratos que se ajusten 100% a la metodologa, porque siempre nos exigen fixed price. Los clientes se sorprenden con la mejora en la forma de trabajo y se van motivando y metiendo en el da a da del proyecto, hasta que se sienten parte del equipo. 19. No para todos, para la mayora s, pero no el 100%. Para los que no aplicamos agile usamos RUP. En los casos en que se usan metodologas giles, los clientes tienen un alto nivel de compromiso.

Utilizacin Mtodos giles

129

20. No las usamos para todos, para los que no, usamos PMI. Solo algunos clientes se comprometen con los proyectos. 21. Si las usamos para todos y se comprometen con el proyecto. 22. Intentamos hacerlo en todo proyecto gestionado por nosotros. Cuando el proyecto es gestionado por el cliente, nos adaptamos a su metodologa. La reaccin ha sido siempre buena y con resultados positivos. 23. Las usamos para todos los clientes. El nivel de compromiso depende del cliente. Los clientes con los que tenemos mayor confianza entienden el proceso de entregas incrementales y participan activamente del proyecto, dando feedback por cada entrega y priorizando el backlog. Otros clientes no se involucran tanto y esperan ver el juego terminado. 24. Intentamos usar metodologas giles siempre que podemos, pero a veces los clientes tienen una cultura que no lo permite. Para estos usamos un enfoque mas waterfall con requerimientos bien definidos de antemano (en general esto solo lo aceptamos para proyectos muy chicos, de no ms de 1 mes de 1 o 2 personas). Con los que las usamos, la mayora si se compromete, aunque hay algunos a quienes les cuesta el cambio cultural que trabajar con metodologas giles implica. 25. Nuestros clientes, en la mayora de los casos, son tcnicos de reas como desarrollo de producto, hardware y tambin software. De todos modos hay reacciones de todo tipo desde exigir su uso hasta no participar. No veo, al menos hasta ahora, una diferencia en cunto a compromiso. Por el momento parece ms una moda.

Utilizacin Mtodos giles

130

26. No las usamos para todos, tenemos otra versin de nuestra metodologa, a la que llamamos "tradicional", que en general se aplica a los proyectos del tipo "paquete cerrado". Es algo basado en RUP. Con respecto al compromiso, hay de todo. En general muchos clientes son empresas de software que ya conocen Scrum, y entonces no tenemos el problema de la adopcin. En otros casos hay algo de resistencia. El nivel de involucramiento vara... no es parejo. 27. Tenemos clientes internos solamente, no somos una consultora y s, estn muy comprometidos con todos los proyectos. 28. No, usamos la del cliente, si el cliente lo permite usamos en general Scrum o la que consideremos la mejor para ese cliente. Con respecto al compromiso depende, quin sea la cara del cliente y que tan grande es el cliente. Anlisis de las respuestas. Con respecto al uso de mtodos giles con los clientes, los encuestados respondieron: 1. 43% (12) utilizan mtodos giles con todos sus clientes. 2. 36% (10) utilizan estos mtodos con los clientes que se pueden adaptar a los mismos. 3. 14% (4) utilizan mtodos giles con la mayora de sus clientes. 4. 7% (2) no especificaron con que clientes los usan. Esto mismo se puede observar en el grfico que sigue:

Utilizacin Mtodos giles

131

Todos Los que son compatibles con agile

12

10

La mayoria

No especifica

10

12

14

Figura 33. Utilizacin de los mtodos giles con los clientes. Con respecto al grado de compromiso demostrado por los clientes para con los proyectos, los encuestados respondieron: 1. 39% (11) La mayor parte de las veces los clientes se comprometen con el proyecto. 2. 32% (9) Solo algunas veces los clientes se muestran comprometidos con el proyecto. 3. 25% (7) Los clientes siempre muestran alto grado de compromiso con el proyecto. 4. 4% (1) Se compromete a los clientes con el proyecto a travs de documentos. A continuacin observamos el grfico con la informacin antes detallada.

4%

25% 32% Siempre La mayoria de las veces Algunas veces A traves de documentos 39%

Figura 34. Compromiso de los clientes con los proyectos.

Utilizacin Mtodos giles

132

Los encuestados que no aplican mtodos giles para todos sus clientes (14), utilizan las siguientes alternativas para el resto: Metodologa en cascada (Waterfalls) adaptada a la empresa (3). La metodologa del cliente (3). RUP / RUP adaptado a la empresa (2). No aclara que utiliza para el resto de los clientes (2). Ningn mtodo definido (1). PMI (1). Cronograma macro, con integraciones internas (1). Ciclo de vida de CMMi (1). Pregunta 5 Cuntas personas forman los grupos de trabajo? Son muchos grupos? Estn todos en el mismo lugar? 1. Intentamos mantener equipos de hasta 7 integrantes. En caso de que el proyecto lo requiera, el modo de escalar no es agrandando el equipo, sino particionando el trabajo de modo que pueda ser manejado por dos o ms equipos. La sincronizacin de esos equipos es todo un tema, pero hay bastante experiencia sobre eso (Scrum de Scrums, etc.). Nuestra empresa actual es pequea, tenemos poco ms de 6 meses de vida. Tenemos un total de 10 desarrolladores, todos en el mismo lugar. Como contraste, en Teletech, manejbamos entre mi socio y yo 60 personas. Y si bien los equipos de desarrollo s estaban todos juntos, cada proyecto inclua gente de otros lugares, sobre todo de USA y Europa. El desarrollo Agile remoto es posible, pero requiere un buen manejo de las comunicaciones y de las culturas de los interlocutores. Definitivamente es ms productivo si se tiene a toda la gente junta, pero si eso no es posible, de todos

Utilizacin Mtodos giles modos se pueden lograr muchsimas mejoras sobre otros modos de trabajo ms burocrticos o prescriptivos.

133

2. El grupo es de 13 personas. Es un solo grupo con 3 lugares fsicos : Lugar A 10 personas, Lugar B - 2 personas, Lugar C - 1 persona. 3. Entre dos y tres personas. Un grupo por proyecto, en uno de los casos, es un equipo totalmente distribuido. 4. Los grupos se pueden formar desde 2 personas a 20 personas, en funcin de las caractersticas y dimensin de cada proyecto. La empresa cuenta con una plantilla de 170 profesionales, de los cuales 120 son desarrolladores, con lo cual tenemos muchos grupos de trabajo de diferente tamao y en distintas locaciones, ya que la empresa cuenta con oficinas en LA PLATA, NEUQUEN, CAPITAL FEDERAL Y CHILE. Muchos de nuestros proyectos se componen de equipos distribuidos, por ejemplo: Lider de Proyect y Analistas Funcionales en CAPITAL FEDERAL, Desarrolladores en LA PLATA, y grupo de Quality Assurance en NEUQUEN. 5. Entre 3 y 4 personas por grupo. No estamos distribuidos, somos pocos y trabajamos juntos. 6. Hasta 14 personas por grupo. El site esta dividido en 3 grandes reas y somos un total de 110 personas, todas en el mismo site. Y la conformacin de los grupos varia entre 3 y 14 personas siendo el nmero de integrantes mas frecuente entre 5 y 7. 7. Es variado. Hay desde equipos con 1 o 2 personas, hasta algunos de ms de 20 subdivididos por funcionalidad para un mismo cliente. Estamos repartidos entre Bs. As. y Baha Blanca. Tendemos a que la mayor parte de los proyectos tengan toda la gente en la misma ubicacin, aunque hay algunos que tienen

Utilizacin Mtodos giles

134

por ejemplo el tester en Baha y el resto en Bs. As o el analista en Bs. As. y el resto en Baha. 8. Un promedio de 3 personas y no ms de 9. Por proyecto hay uno o dos grupos y siempre estn en el mismo lugar. Desde el punto de vista de Lagash son muchos grupos y estn en distintos lugares. 9. Depende mucho el proyecto. Alrededor de 5 +-2 personas es lo normal. Usualmente trabajamos en forma distribuida en varios lugares. Al menos el cliente casi siempre est en otra oficina u otra ciudad o pas. 10. En general en los proyectos que manejamos nosotros, los equipos no son de ms de dos o tres personas, ms una persona que oficia de Scrum master, la cual no est incluida directamente en el equipo debido a que no desarrolla, sino que es la encargada de administrar el proyecto. Generalmente es un solo grupo que se encuentra en el mismo lugar fsico dado que son proyectos chicos. Hemos tenido un caso en el que el cliente era el Product Owner y no estaba en el mismo lugar fsico y se solucion haciendo las daily meeting a travs de conferencias. 11. Los grupos son de 4 a 8 personas. Son muchos grupos. Particularmente trabajo en ambientes dispersos (coordino grupos de todo el mundo) usando Scrum of Scrums. Creamos "virtual war rooms" para mejorar la comunicacin y reducir distancias. 12. En el proyecto el equipo es de 6 personas. Somos 2 equipos de desarrollo, estamos en el mismo lugar. 13. Depende, tenemos 44 proyectos los cuales varan entre 14 a 3 personas. Si estamos todos en el mismo lugar fsico depende del proyecto, la mayora si, y

Utilizacin Mtodos giles otros los tenemos entre San Luis y Buenos Aires y por ltimo algunos no necesariamente se sientan juntos.

135

14. En Proyecto 1: es un solo grupo, 7 personas (elenco estable: funcional, lder tcnico, 3 programadores, product owner, scrum master, todos en un mismo lugar fsico). Analista Tester, capacitacin, Mejora de Procesos entran y salen del equipo cuando es necesario. En Proyecto 2: 7 personas, divididas en 2 grupos, en distintas oficinas, nos reunimos para las reuniones de planificacin, revisin y retrospectiva. Adems hay reuniones de avance y revisin durante la construccin. 15. Son 6 personas por grupo, son 3 grupos trabajando en el mismo lugar. 16. Inicialmente 5, ahora 4, un solo grupo. 17. Los equipos varan entre 5 y 9 personas (sin contar al Product Owner, por supuesto). Fsicamente los equipos se encuentran en la misma oficina, lo cual facilita muchas reuniones entre ellos. Hay aproximadamente 9 equipos, de los cuales el 40% est incursionando en distintas practicas giles. 18. Depende de los proyectos, de 2 a 8 en general por grupo. La cantidad y si estamos en un mismo lugar depende de la cantidad de clientes. 19. Entre 4 y 12 personas por grupo, dependiendo del proyecto. Son muchos grupos, distribuidos en distintos edificios, y en distintas provincias en el pas. 20. Hay equipos de 3 y hasta 15 personas. Son muchos grupos. No estn todos en un mismo lugar, algunos son distribuidos geogrficamente. 21. Es variable, pero en general no ms de 8 personas por grupo. Tenemos varios equipos, en general tenemos entre 6 y 8 proyectos en paralelo, todos con gente en la misma oficina aunque puede que algunos miembros estn en las oficinas del cliente. El cliente siempre es remoto.

Utilizacin Mtodos giles

136

22. 1 a 4 personas por grupo. Somos una empresa chica, por lo que tenemos pocos grupos y todos en el mismo lugar. 23. Entre 3 y 12 personas por grupo. Dependiendo del tamao del juego. Cada equipo tiene un slo proyecto a cargo y los integrantes de cada equipo estn ubicados en el mismo espacio fsico (desarrolladores, artistas, animador, diseador grfico, diseador de juego). Hay un equipo aparte que realiza el QA para todos los juegos. 24. Trabajamos con equipos de 2 a 4 personas. Son 2 grupos ubicados en el mismo lugar. 25. Hay varios grupos (ms de 10) y tenemos de 2 personas a unas 20. En algunos casos estamos trabajando con equipos de proyecto de otros pases haciendo las reuniones diarias por video conferencia con muy buenos resultados. 26. En general los equipos son de unas 7 personas. Hay ms chicos y un poco ms grandes tambin. Tenemos unos 10 proyectos con mtodos giles ahora, en los centros de Buenos Aires, Paran y Baha Blanca. En algunos casos hay gente de distintas oficinas en el mismo equipo. 27. Se trata de no tener a ms de 10 personas por grupo de trabajo (pero cada proyecto puede tener ms de un grupo de trabajo). El ideal en mi experiencia es 6/7. Somos muchos grupos, tenemos en India, EEUU, Londres, Australia, Buenos Aires, Polonia, etc. 28. Entre 3 a 14 personas. Son muchos grupos. En general los grupos de trabajo estn en un mismo lugar, aunque un miembro puede llegar a estar fuera. Anlisis de las respuestas. Con respecto a la cantidad de integrantes que tiene cada grupo de trabajo, las respuestas fueron muy variadas, dependiendo de tamao de la empresa y

Utilizacin Mtodos giles sobre todo del tamao del proyecto. Se hizo una categorizacin por la cantidad mxima de integrantes que podran tener los equipos, y se obtuvieron los siguientes resultados: 1. Tiene equipos de hasta 4 integrantes el 21% (6) de los encuestados. 2. Tiene equipos de hasta 8 integrantes el 32% (9) de los encuestados. 3. Tiene equipos de hasta 12 integrantes el 18% (5) de los encuestados. 4. Tiene equipos de hasta 16 integrantes el 18% (5) de los encuestados. 5. Tiene equipos de hasta 20 integrantes el 11% (3) de los encuestados. Esto mismo se puede apreciar en el siguiente grfico:

137

10 8 6 4
6 9 5 5 3

2 0
hasta 4 por grupo hasta 8 por grupo

hasta 12 por grupo

hasta 16 por grupo

hasta 20 por grupo

Figura 35. Cantidad de integrantes por equipo de trabajo. Con respecto a la cantidad de grupos, algunos orientaron la respuesta a la cantidad de grupos por proyecto, y otros a la cantidad de grupos que trabajan en la empresa y algunos no aclararon ninguna de las dos anteriores. Se obtuvieron los siguientes resultados: 1. Son muchos grupos, porque son muchas personas en la empresa (10). 2. No queda claro cuantos grupos trabajan por proyecto ni en la empresa (8). 3. Trabaja un grupo por proyecto (5). 4. Trabaja uno o dos grupos por proyecto (2). 5. Son dos grupos en la empresa (2). 6. Son tres grupos en la empresa (1).

Utilizacin Mtodos giles Con respecto a la distribucin de los miembros de los equipos (figura 36), respondieron: 1. 54% (15) Trabajan todos en un mismo lugar fsico. 2. 46% (13) Algunos miembros estn distribuidos geogrficamente.

138

Combinando las dos respuestas anteriores podemos ver la distribucin geogrfica de los miembros de los equipos segn la cantidad de integrantes de los mismos:

46%

54%

Fisicamente en el mismo lugar Equipo distribuido geograficamente

Figura 36. Distribucin geogrfica de los equipos de trabajo. De los 6 que tienen equipos de hasta 4 miembros, 5 trabajan fsicamente en el mismo lugar y uno lo hace en forma distribuida. De los 9 que tienen equipos de hasta 8 miembros, 5 trabajan fsicamente en el mismo lugar y 4 lo hacen en forma distribuida. De los 5 que tienen equipos de hasta 12 miembros, 3 trabajan fsicamente en el mismo lugar y 2 los hacen en forma distribuida. De los 5 que tienen equipos de hasta 16 miembros, 2 trabajan fsicamente en el mismo lugar y 3 lo hacen en forma distribuida. Los 3 que tienen equipos de hasta 20 miembros trabajan en forma distribuida.

Utilizacin Mtodos giles

139

10 9 8 7 6 5 4 3 2 1 0
hasta 4 por grupo hasta 8 por grupo hasta 12 por hasta 16 por grupo grupo hasta 20 por grupo 1 4 2 5 2 3 5 Fisicamente en el mismo lugar Equipo distribuido geograficamente

Figura 37. Distribucin geogrfica de los equipos de trabajo segn la cantidad de miembros. Pregunta 6 Tienen alguna certificacin de calidad (ISO o CMMI), o piensan certificar alguna de ellas con metodologas giles? 1. Pensamos certificar en CMMI en un futuro prximo. En Teletech logramos certificar CMMI nivel 2, y en otra empresa en que trabaj, se certific en ISO. 2. No. Por el momento no. 3. No por el momento. 4. CMMI Nivel 2. 5. No tenemos y, por ahora, no est en nuestros planes. 6. Se obtuvo el CMMI ML2 hace un ao usando SCRUM y durante el prximo. mes de noviembre vamos por CMMI ML3. 7. ISO desde el 2008. Re certificamos este ao y vamos en camino para el ao que viene nuevamente re certificar. 8. ISO 9001. La certificacin es sobre metodologas giles. 9. No. 10. Hace un ao certificamos ISO 9000:2009 y se estableci Scrum como framework de desarrollo para la misma.

Utilizacin Mtodos giles

140

11. No, como CTO de la compaa entiendo que hay un conflicto filosfico que no se puede resolver. No podes ser gil y ser predecir sin adaptar, es decir, si la agilidad te dice, inspecciona y adptate, y CMM(i) te dice luego que seas repetitivo sers definido existe un conflicto que no se puede resolver. Particularmente soy asesor del SEI para CMM y Scrum Master, y luego de muchos aos de experiencia s que no podes ser blanco y negro a la vez. 12. Yo soy Scrum Master Certificado. 13. Actualmente estamos certificados en SOX e ISO 9001. En la empresa anterior ayude en el proceso de certificacin de CMMI nivel 3, no estuve en el proceso de evaluacin porque ya me haba ido 4 meses antes. 14. No. 15. ISO. 16. No. 17. No por el momento. 18. No. 19. Se tiene CMMI Nivel 2, y se va a certificar ISO 9001:2008 el prximo ao. 20. No por el momento. 21. Somos ISO y est implementada basada en Agile. 22. Estamos en proceso de certificacin ISO 9001, en Febrero obtendremos dicha certificacin. 23. Estamos certificados con la norma ISO 9001, usando SCRUM. 24. No. Tenemos como plan a futuro certificar ISO con metodologas giles. 25. Cuando hicimos la evaluacin CMMI (nivel 5) en 2007 recin empezbamos a usar SCRUM. Hace poco certificamos ISO 9001:2008 e incluimos los proyectos SCRUM.

Utilizacin Mtodos giles

141

Tenemos muy buenos resultados. Pero tambin los hemos tenido con los otros mtodos. En nuestro caso creemos que la clave es el sistema de gestin y el paquete completo de gestin de los proyectos. En realidad lo que nos propusimos fue introducir mtodos giles sin alterar los resultados que habamos obtenido. 26. CMMI Nivel 3. Ya certificamos presentando proyectos "giles" (entre comillas porque un agilista puro dira que esos proyectos no son giles). Tambin certificamos ISO 9000 el ao pasado, pero no lo vamos a revalidar. 27. No, eso agregara pasos innecesarios para nuestros entregables. 28. ISO. Tenemos SCMs certificados. Anlisis de las respuestas. Con respecto a las certificaciones de calidad ISO y CMMi los encuestados respondieron: 1. El 43% (12) No tienen, ni piensan tramitar ninguna de las dos certificaciones. 2. El 57% (16) Tienen alguna certificacin o tienen pensado realizarla en un futuro prximo.

43% 57%

Ninguna certificacion ISO o CMMI o ambas

Figura 38. Certificaciones de calidad. Los que tienen certificaciones se distribuyen de la siguiente manera (aquellos que tienen ms de una, fueron considerados en ambas): 1. 6 de los encuestados tienen o piensan certificar prximamente CMMi.

Utilizacin Mtodos giles 2. 13 de los encuestados tienen o piensan certificar con las normas ISO.

142

32%

ISO CMMi 68%

Figura 39. Certificaciones de calidad ISO CMMi Pregunta 7 Podra mencionar casos de xito? Que tipo de proyectos son? 1. En estos 6 meses hicimos varios proyectos interesantes, logrando clientes satisfechos. Entre ellos cabe destacar: Un sistema de automatizacin para estudios estadsticos de una empresa de investigacin de mercados. Se trata de una capa de abstraccin que les permite a los usuarios, a travs de una interfaz de usuario del tipo Wizard, procesar su informacin en la herramienta estadstica SPSS de un modo mucho ms natural para el negocio, mucho ms rpido y menos proclive a errores. En este caso, se baj el tiempo de procesamiento de un estudio tpico de 3 das a 15 minutos. Un sistema de gestin de conflictos para una empresa proveedora de Salud de California, Estados Unidos: se trata de una aplicacin Web que interacta con un paquete de software (una especie de ERP de healthcare) y permite manejar los conflictos entre la empresa y sus proveedores, manejando el workflow de procesamiento de los reclamos, las impresiones de cartas y notificaciones, y el manejo de tiempos para cumplir con las regulaciones estatales. Con este software la compaa logro tener un tracking mucho ms

Utilizacin Mtodos giles

143

preciso de sus tiempos, y reducir costos por multas de muchos miles de dlares. Un Portal de noticias, para un grupo periodstico independiente con base en San Pedro, provincia de Buenos Aires. El portal tiene una fuerte carga poltica, y permite ver noticias de toda la provincia, de una seccin electoral o de un municipio en particular. Contiene tambin un ndice de los funcionarios de la provincia, de los medios de la provincia; y un gran nmero de funcionalidades. Un sistema de notificacin en tiempo real del estado de una central telefnica IP (Asterisk). Es un widget que muestra en tiempo real el estado de las colas de llamado, de los agentes, y de diferentes alarmas que pueden ser configuradas. Es para un call center en Estados Unidos, y tiene la complejidad de un entorno tecnolgico completamente heterogneo: Linux + Asterisk en el servidor, y Windows XP en las mquinas clientes. Hay varias cosas ms, pero supongo que con esta muestra alcanza para mostrar un abanico de industrias y tipos de proyecto bastante diversos, que muestran que es posible trabajar de este modo para situaciones muy diferentes. 2. No, por razones de confidencialidad. 3. En general desarrollamos software a medida de las necesidades del cliente con buenos resultados. 4. Los casos de xito son muchos y se pueden ver en la pgina Web de la empresa http://www.snoopconsulting.com/snoop_es/Prensa/Casos-de-Exito/. Se mencionan algunos: TENARIS - Aseguramiento de calidad de desarrollos y optimizacin de bases de datos. Tenaris Siderca es la marca utilizada en Argentina por Siderca

Utilizacin Mtodos giles

144

S.A.I.C., una compaa de Tenaris. Es el proveedor lder de tubos de acero sin costura y servicios para la industria energtica local y principal exportador de productos de valor agregado. Cuando este proyecto comenz, en diciembre de 2004, el mayor requerimiento de Tenaris consista en mejorar la performance de las bases de datos productivas y capacitar a los desarrolladores Oracle para poder aumentar su productividad. Para lograrlo, Snoop implement mtricas que permitieron identificar los procesos ms pesados en las bases productivas. Plante recomendaciones para obtener una mejor performance y luego realiz informes de resultados para cada proceso afectado a esta gestin. Paralelamente, Snoop dict cursos de PL/SQL avanzado y de buenas prcticas de programacin a los desarrolladores de Tenaris. Actualmente seguimos trabajando con Tenaris y formamos parte del Team SQA. Proyecto: Nexos Cliente: Nextel. Nextel buscaba desarrollar un nuevo CRM que reemplace a Vantive y se adapte mejor a sus necesidades; considerando que llevaban ya varios aos de customizaciones sobre Vantive. As nace Nexus. Nexus es parte de un plan estratgico de Nextel con el que busca mejorar la atencin de sus clientes. Abarca desde adecuar los procesos de negocio y hacer ms fluidas las interacciones entre las reas, hasta reducir los tiempos de procesamiento de solicitudes en Back-Office. Este desafo cumpli con el primer gran hito establecido por la direccin, a mediados de septiembre de 2005; con una alta calidad de software acompaada con una bajsima tasa de incidentes registrados una vez en puesto en produccin. 5. Implementacin del sistema de atencin al pblico en el nmero de emergencias mdicas de la ciudad de Crdoba (136).

Utilizacin Mtodos giles 6. No te puedo dar esa informacin, pero tenemos un buen ratio de customer satifaction survey.

145

7. Estos son algunos casos de xito sobre los que se puede leer mas en la pgina Web de la empresa, http://www.huddle.com.ar/sp-clients.html: Grupo Santillana: Grupo Editorial internacional. Pertenecen al grupo marcas de primera lnea como Santillana, Alfaguara, Aguilar, Manderley entre otras. Anlisis, Diseo e Implementacin de la Intranet del Grupo Santillana utilizando Tecnologas Microsoft Office SharePoint 2007. La intranet posibilito la integracin de diferentes integrantes del Grupo, permiti la colaboracin entre ellos y unific la imagen corporativa. Se desarrollo el rea de Recursos Humanos desde donde se administran las noticias y comunicaciones corporativas. Se implementaron medios de comunicacin a diferentes niveles, permitiendo publicar en la Home las noticias ms importantes. Cmara Argentina de la Construccin: Institucin que tiene el objetivo de propender al desarrollo armnico de la industria de la construccin en Argentina. Implementacin del Web site, implementacin del Portal de Socios, implementacin de Intranet, todo esto usando Windows SharePoint Services 3.0. 8. Proyectos en Asociart ART, Disco. Son proyectos para desarrollo de software a largo plazo. 9. No puedo dar nombres de clientes. Puedo nombrar un caso de xito de coaching en Francia durante 6 meses, donde ayudamos a introducir metodologas giles en un equipo de ms de 20 personas distribuido en 2 pases y 3 ciudades distintas.

Utilizacin Mtodos giles

146

10. No hemos tenido proyectos que se hayan realizado con estas metodologas que se puedan mencionar como un caso de xito. Hubo un proyecto que se cay por falta de presupuesto, pero creo que la metodologa ayud mucho a su desarrollo. 11. Muchos, sin embargo una organizacin sana aprende de los errores, no de los casos de xito. Los errores ms comunes en la implementacin gil es no disponer de un buen Product Owner. Hemos tenido proyectos largos, cortos, chicos y grandes, con diferentes tecnologas. Agile sirve para todo. 12. Creo que este proyecto, cuando termine, ser un caso de xito. Se trata de una aplicacin Web, tipo content management, para un banco. Empezamos con un equipo sin experiencia en la tecnologa que usamos y hoy somos referentes dentro de la empresa a nivel tcnico y de metodologa. La verdad que todos hemos crecido y aprendido mucho en solo 1 mes y medio de proyecto. 13. Por lo general los proyectos donde observe mejores resultados es en los proyectos de "Mantenimiento" donde combinamos Scrum con Lean (Kanban) 14. Los proyectos donde estamos usando Scrum son chicos, aplicaciones de no ms de tres meses de desarrollo. En Proyecto 1: Es muy complejo para m responder por escrito esto, pero despus del 4to sprint estamos implementando el 1er entregable de 3. Teniendo en cuenta que el equipo completo se debi capacitar en Scrum, tecnologa (framework, herramientas y software de la empresa) y el negocio. En Proyecto 2: Es un proyecto con varias aplicaciones chicas, implementamos la primera en tiempo y forma, con la segunda aplicacin el

Utilizacin Mtodos giles

147

avance est siendo el estimado. Notamos un incremento en el compromiso, la motivacin y el aprendizaje en equipo. No s si es posible aplicarlo a todos los proyectos, los proyectos grandes no entiendo cmo se pueden manejar con Scrum, pero tampoco con metodologas tradicionales, no tuve buenas experiencias... la nica forma que a m se me ocurre es dividindolo en proyectos ms pequeos, pero no s si es una limitacin ma o de las metodologas. Esto mejor que te responda alguien con experiencia en proyectos grandes. Luego est el tema cultural, que no todos quieren transitar el cambio. 15. Price Surfer, http://www.psurfer.net/, es una solucin tecnolgica cuyo objetivo es centralizar toda la informacin de hoteles y otras opciones de alojamiento en un solo sistema, brindando al usuario una interfaz grfica amigable, capaz de comparar automticamente varias opciones en una sola consulta, permitiendo reservar un itinerario con distintos destinos. 16. El proyecto actual durar entre 3 y 4 meses (estamos en el 3er mes). Se est usando, se empez a usar luego de un mes de desarrollo, incorporando nueva tecnologa (CakePHP). La dinmica del equipo ha mejorado mucho, los usuarios estn muy conformes y vienen a las reuniones. 17. No, por razones de confidencialidad. 18. Nuestra primera implementacin fue sumamente exitosa, demostrando resultados no solamente a nuestra rea comercial, sino tambin aportando al estmulo de todos los integrantes de los equipos. 19. Se mencionan algunos casos de xito que se pueden ver con mas detalle en la pagina Web de la empresa, http://www.cubika.com/casos-de-exito.html :

Utilizacin Mtodos giles El diario Buenos Aires Herald buscaba una solucin que le permitiera gestionar los contenidos de su diario en Internet. Cubika implement el Dynamic Content Server, una solucin que gestiona los diferentes procesos

148

implicados en el manejo de la informacin interna y de aquella que se pone a disposicin de la comunidad. SMG Seguros, la compaa de seguros de Swiss Medical Group, eligi a Cubika para la implementacin de su extranet de productores. Esta solucin a ser implementada por SMG Seguros, le permitir mejorar la comunicacin con sus Productores, conocer estrechamente sus necesidades y ganar en prestaciones y calidad de servicio. 20. Son proyectos en .NET/SSIS/Java. Por temas de confidencialidad no puedo dar mucho detalle de los proyectos, mis disculpas en este punto. 21. Trabajamos para que todos nuestros proyectos sean casos de xito y salvo contadas excepciones siempre lo son. Los tipos de proyecto tienen que ver con implementacin de soluciones con tecnologa muy innovadora, trabajamos de forma muy cercana a Microsoft utilizando productos nuevos desde que estn en versiones alfa y beta. 22. Por temas de confidencialidad no puedo dar nombre de clientes, pero en general los resultados fueron muy positivos. 23. En octubre sali publicado LEGO Star Wars: The quest for R2D2 en http://starwars.lego.com. Este proyecto fue realizado para nuestro cliente LEGO, con quienes tenemos un alto grado de confianza. Este juego lo consideramos un caso parcial de xito. Por un lado, el cliente se involucr personalmente en el proyecto (a distancia), aprobando cada sprint release y repriorizando los features. Pero no fue un caso puramente gil, debido a que

Utilizacin Mtodos giles

149

tenamos un deadline fijo y un presupuesto final pre-acordado. Es muy difcil lograr un contrato realmente gil con los clientes, especialmente en proyectos cortos (promedio 3 meses). 24. www.adjug.com, www.dirawomen.org (no est todava abierto al publico), www.tranxgo.com/concursofacebook (ya no est online) Son aplicaciones Web. 25. Hay proyectos para software de servidores de comunicaciones, para software embebido en cable mdems y otros dispositivos, para seguridad pblica, etc. 26. Se mencionan algunos casos de xito extrados de la pagina Web de la empresa, http://www.hexacta.com/content/clients/caseStudies.html: eSidif : Dentro de sus mltiples funciones, el Ministerio de Economa, a travs de la Unidad de Informtica de la Secretara de Hacienda tiene el objetivo de planificar, integrar y administrar la plataforma informtica y de comunicaciones, el mantenimiento de sistemas, la capacitacin, el apoyo a usuarios y la asesora informtica para las unidades organizacionales vinculadas al Sistema de Administracin Financiera. Hexacta fue seleccionada para la construccin de los mdulos base de la Arquitectura: seguridad, simulacin de escenarios de formulacin presupuestaria, administracin de procesos batch, componentes para cliente Web, etc. SAFJP - Control de cuentas de capitalizacin individual : La Superintendencia de AFJPs es el ente estatal que regula el funcionamiento de las Administradoras de Fondos de Jubilaciones y Pensiones (AFJPs). La problemtica consista en crear un sistema que permita fiscalizar de forma automtica la correcta y oportuna imputacin de los aportes en las cuentas de capitalizacin individual de los afiliados.

Utilizacin Mtodos giles

150

27. El 100% de los proyectos que yo manejo son sistemas de alta disponibilidad online para que la gente realice compras (en todo el mundo). 28. VDH- desarrollo dos aos - 13 personas es un "scrum-but" tendiendo a Scrum 100%. La administracin y gerencia de la empresa es un Scrum but, pero funciona muy muy bien. Proyectos de desarrollo, varios ms... la lista es larga. Anlisis de las respuestas. Por razones de confidencialidad 8 de los encuestados no respondieron este punto. Con respecto a los casos de xito mencionados, se puede observar que son proyectos de todo tipo y tamao, no se puede realizar una clasificacin de los mismos ya que son todos diferentes. Lo que se puede observar es que los mtodos giles se pueden aplicar a todo tipo de proyectos, desde un sitio Web hasta sistemas de compras de alta disponibilidad online, juegos para PC, sistemas de registracin financiera, dispositivos de seguridad, portales de diarios online, sistemas estadsticos, etc., con las mas variadas tecnologas e involucrando distinta cantidad de personas. Los Participantes Para respetar la confidencialidad de los participantes, se les solicito explcitamente permiso para mencionarlos a ellos y a la empresa o institucin por la cual respondieron. Por este motivo no se mencionan todos los nombres de las empresas y personas contactadas, pero se puede decir que son todas de la Repblica Argentina, varias multinacionales con sede en el pas y dos instituciones educativas. A continuacin se detallan, en orden alfabtico, las empresas e instituciones participantes que autorizaron su mencin. El rol de cada participante es el que describi como parte de la encuesta. 10 Pines (http://www.10pines.com/) 10Pines es una compaa Latino Americana de desarrollo de software, especializada en la creacin de soluciones de alta calidad utilizando tecnologa de punta.

Utilizacin Mtodos giles Encuestado: Emilio Gutter. Rol: Varios dependiendo el proyecto: ScrumMaster, coach, Arquitecto, Lider, Desarrollador, etc. Agile Ways Consulting Group (http://www.awcg.com.ar/)

151

En Agile Ways Consulting Group (AWCG) nos dedicamos a la implementacin de procesos giles en empresas que comprenden que vivimos en un mundo gil. AWCG ofrece: Implementaciones Scrum en cualquier entorno gil, Entrenamiento Agile, Hands-on coaching en Lean development, Agile Project Management, Software outsourcing aplicando agile software development. Encuestado: Fabio Grigorjev. Rol: generalmente Scrum Master. Consorcio SIU (http://www.siu.edu.ar/) El SIU es un Consorcio de Universidades que desarrolla soluciones informticas y brinda servicios para el Sistema Universitario Nacional y distintos organismos de gobierno. Su objetivo es contribuir a mejorar la gestin de las instituciones, permitindoles contar con informacin segura, ntegra y disponible, optimizar sus recursos y lograr que el software sea aprovechado en toda su potencialidad. Encuestado: Ariel Zoia. Rol: Jefe de Desarrollo del proyecto SIU-Mapuche / Pampa perteneciente al Consorcio SIU. Cubika (http://www.cubika.com/inicio.html) Proveemos soluciones de negocios basadas en tecnologas Java (J2EE), SOA (Arquitectura Orientada a Servicios), .NET, y Adobe Flex, orientadas a incrementar la eficiencia de los procesos y operaciones de nuestros clientes, en distintas reas de negocio. Encuestado: Marcelo Schenone.

Utilizacin Mtodos giles Rol: Gerente de la PMO. Epidata Consulting (http://www.epidataconsulting.com/)

152

Epidata Consulting es la primera empresa especializada en Arquitectura de software de Amrica Latina y es lder del sector en Argentina. En Epidata Consulting ofrecemos servicios de Consultora, Capacitacin y Mentoring, brindando soluciones integrales de sistemas corporativos, en funcin de las necesidades de cada cliente. Encuestado:Valerio Adrin Anacleto. Rol: Soy director de la Empresa. Facultad de Ciencias Exactas y Naturales. Universidad Nacional de Buenos Aires (http://exactas.uba.ar/) Encuestado: Juan Gabardini. Rol: Scrum Master. Get Sense (http://www.getsense.com.ar/) Somos una empresa Argentina de Desarrollo de Software, apostamos a generar una relacin de socios con nuestros clientes formando equipos de trabajo en entornos de plena colaboracin. Brindamos servicios de Integracin y Desarrollo de Software que agregan valor a su Negocio. Encuestado: Pablo Francavilla. Rol: ScrumMaster. Hexacta (http://www.hexacta.com/content/home.action) Somos lderes en consultora IT, desarrollo de software, testing y diseo de interfaces de usuarios en Amrica Latina. Contamos con ms de 10 aos de experiencia en proyectos de outsourcing para compaas estadounidenses y europeas; ofrecemos servicios de calidad mundial mediante la utilizacin de metodologas giles o tradicionales, llevados a cabo por los mejores talentos de la regin.

Utilizacin Mtodos giles Encuestado: Santiago Ceria. Rol: Soy socio de la empresa y gestiono las cuentas de clientes. Intel (http://www.intel.com/index.htm#/es_LA_06)

153

Intel est superando los lmites de la innovacin para que nuestro trabajo haga que las vidas de las personas sean ms emocionantes, satisfactorias y controlables. Nuestro trabajo nunca se termina. Nunca dejamos de buscar los avances prximos en tecnologa, educacin, cultura, fabricacin y responsabilidad social. Y nunca dejamos de esforzarnos por ofrecer soluciones con el mayor beneficio para todos. Encuestado: Daniel Battisteli. Rol: Yo soy ingeniero de procesos, pertenezco al rea de Calidad de Intel Kinetica Solutions (http://www.kinetica-solutions.com/) Kinetica provee soluciones de software de alta calidad llevando a cabo el desarrollo en Argentina. Nuestros servicios incluyen la tercerizacin de servicios de desarrollo y la construccin de soluciones a medida en modo offshore.. Encuestado: Rubn Altman . Rol: Depende el proyecto. En general organizamos los grupos con "desarrolladores" y cada quien cumple diferentes roles durante el proyecto. Lagash Systems (http://www.lagash.com/) Lagash es una empresa de tecnologa dedicada a la consultora de sistemas. Con ms de 7 aos de experiencia, nos especializamos en productos y tecnologas Microsoft. En Lagash ideamos y desarrollamos soluciones de negocio basadas en software, que abarcan desde piezas especficas hasta arquitecturas corporativas, pasando por sistemas de integracin y aplicaciones para trabajo colaborativo, entre otras. Encuestado: Diego Gonzalez. Rol: Soy CTO de la empresa, y mi rol est un poco lejos de los proyectos.

Utilizacin Mtodos giles Mercado Libre (http://www.mercadolibre.com.ar/) MercadoLibre es una compaa pblica de tecnologa que ofrece soluciones de comercio electrnico para comprar, vender y pagar de todo a travs de Internet.

154

Ofrece a su comunidad de usuarios dos servicios principales: MercadoLibre.com, la mayor plataforma de compras y ventas por Internet de Amrica Latina y MercadoPago.com, la mayor plataforma de pagos por Internet de origen latinoamericano. Encuestado: Fernando Waisman. Rol: Fui Scrum Master y Miembro de un equipo, ahora soy Facilitador o Couch Motorola Argentina (http://www.motorola.com/staticfiles/Business/Corporate/AR-ES/aboutmotorola/about-motorola-argentina-home.html ) Motorola es una empresa lder en comunicaciones globales, impulsada por la pasin de inventar y un compromiso incesante para generar avances en la forma en que el mundo se conecta. Encuestado: Alvaro Ruiz de Mendarrosqueta. Rol: En mi caso tengo un rol doble, por un lado soy el director del centro y por el otro dirijo una de las gerencias de operaciones, las mismas hacen desarrollo de software y se dividen por el tipo de negocio al que atiende. Nemo Group (http://www.nemogroup.net/) Nacimos en Argentina y desde hace 13 aos crecemos en el mundo. Somos lderes en brindar soluciones de comunicacin y tecnologa -con expertise en el desarrollo de proyectos a distancia- mediante la modalidad de outsourcing. Encuestado: Jos Plano. Rol: Gerente de proyecto / CTO de Nemo.

Utilizacin Mtodos giles Snoop Consulting (http://www.snoopconsulting.com/snoop_es/) Somos la compaa con ms experiencia en desarrollos e implementaciones de

155

soluciones sofisticadas que mejoran la productividad del negocio y aseguran la inversin en tecnologa. Encuestado: Damin Roln. Rol: Gerente de Proyectos. Summa Solutions (http://summasolutions.net/default-esp.aspx) Summa Solutions brinda soluciones integrales de desarrollo de software, ofreciendo servicios de punta a punta, incluyendo diagnstico, consultora, desarrollo, prueba, implementacin y soporte. Encuestado: Aldo Bressam . Rol: Usualmente soy el Scrum Master, o el facilitador del proyecto. En esta etapa embrionaria de nuestra empresa, me resulta indispensable el clonarme y trabajar en varios proyectos simultneamente. A medida que progresemos, mi objetivo es formar equipos motivados y empoderados, que requieran muy baja supervisin (aunque un constante mentoring). Temperies IT (http://www.temperies.com.ar/) Temperies es una empresa multidisciplinaria especializada en diversas reas de Tecnologa de Informacin. Nuestra gente conforma un grupo comprometido con nuestros clientes a quienes ofrecemos calidad de servicio respaldado por profesionales altamente capacitados y con mas de 15 aos de experiencia en el sector. Encuestado: Esteban Roasio. Rol: Desarrollador.

Utilizacin Mtodos giles Three Melons (http://www.threemelons.com/)

156

Three Melons es una empresa que desarrolla juegos online y juegos para iPhone con un componente social, con modelos de negocio free-to-play, diseados para publicidad y entretenimiento. Encuestado: Pauline Morrison. Rol: Soy Scrum Master. YellowSpot ( http://yellowspot.com.ar/) YellowSpot es una empresa joven, fundada por un grupo de profesionales del desarrollo de software. Nuestro principal objetivo es generar relaciones de largo plazo con nuestros clientes, ofreciendo soluciones de software de alta calidad y a costos accesibles. Estamos convencidos de que las soluciones de software pueden hacerse bien, en el tiempo pactado y de acuerdo a la realidad de cada negocio. Encuestado: Marcelo Belnicoff. Rol: Depende del proyecto. A veces Coach, a veces Producto Owner y a veces Scrum master. Otros encuestados: Carlos Peix. Rol: En algunos proyectos, Scrum master, en otros, arquitecto. Dan Rozenfarb. Rol: Gerente de Sistemas. Fernando Claverino. Rol: Mi rol es el de potenciar a las personas y al equipo de distintas maneras. Usando Scrum como framework de trabajo, tratando de aplicar su esencia, fomentando que el equipo sea auto organizado y que las personas mejoren como profesionales. A nivel de prcticas de desarrollo estoy impulsando tcnicas como unit testing, tdd, integracin contnua, automatizacin (en todo sentido). Muchas de estas cosas ya las hemos adoptado. Otras seguimos trabajando para reforzarlas. Queremos impulsar tambin el deployment continuo, estamos trabajando en esto ltimo.

Utilizacin Mtodos giles

157

Leopoldo Simini. Rol: Cumplo el rol de Scrum Coach. Coordino los equipos y organizo los Scrum de Scrums, En algunos casos, oficio de Poduct Owner. Martin Alaimo. Rol: ScrumMaster/Coach.

Utilizacin Mtodos giles CONCLUSIONES

158

El presente trabajo ha llevado a la autora a investigar y conocer con profundidad las metodologas giles desarrolladas, de las cuales no tena mucho conocimiento y solo las haba visto brevemente mencionadas en alguna de las asignaturas de Ingeniera de Software. El contacto con las personas que se dedican a desarrollar utilizando estos mtodos ha enriquecido de gran manera los conocimientos adquiridos en la investigacin terica y ha permitido elaborar las siguientes conclusiones generales: 1. La tendencia de los resultados de las encuestas marca que Scrum sera el mtodo gil ms utilizado en las empresas del pas, seguido por las prcticas de XP y algunos de los principios de Lean Thinking. Scrum es seguido como nico framework de trabajo por casi la mitad de las empresas encuestadas, algunos by the book y otros adaptndolo a sus necesidades o desarrollando un mtodo propio basado en esta metodologa. 2. En lnea con los resultados obtenidos, aplicar una sola metodologa, con todos los pasos que esta propone no parecera ser lo ms adecuado para todos los proyectos. En muchos casos se utilizan tcnicas de varias metodologas, y se van adaptando segn el proyecto, incluso varios de los que aplican Scrum completo, tambin realizan prcticas de XP, o combinan Kanban con Scrum. Se podra decir que se toman del conjunto de los mtodos giles y de los principios del Manifesto Agile, aquellas prcticas que ms se adaptan a las necesidades del cliente o ms valor le generan a la empresa y/o al proyecto que se esta llevando a cabo. 3. La experiencia en Mtodos giles parece remontarse a no ms de seis aos. Pueden verse como relativamente nuevos comparados con las metodologas

Utilizacin Mtodos giles

159

tradicionales, y quienes se han pasado a estos mtodos se muestran conformes con los resultados obtenidos, con lo que podramos inferir que son una buena eleccin al momento de decidir una forma de trabajo. Un aspecto que se puede observar, es que los que se inician en Mtodos giles eligen Scrum, y a medida que van adquiriendo experiencia van incorporando prcticas de otros mtodos, esto tambin dara una pauta de cmo empezar en caso de querer implementarlos. 4. Con respecto a los clientes parece ser una decisin de la empresa utilizar Agile con todos o solo con los que cumplan con el perfil adecuado. Se ha detectado que algunos los utilizan para todos sus clientes, mientras otros solo para quienes consideran que se pueden adaptar a esta forma de trabajo. Analizando los resultados se podra derivar que los clientes que se adapten a Agile se comprometeran mas con los proyectos y se sentiran mas involucrados en los mismos. 5. El tamao de los grupos de trabajo depende mucho del tamao de los proyectos y de las empresas. Lo que se puede deducir es que es posible trabajar con mtodos giles, desde pequeos grupos todos en un mismo lugar, hasta en grupos distribuidos en todo el pas o incluso alrededor del mundo. 6. Con respecto a las certificaciones de calidad se han recabado opiniones muy variadas, desde aquellos que piensan que no se puede certificar ISO o CMMI con mtodos giles porque va en contra de su naturaleza, hasta quienes han obtenido estas certificaciones o esta en sus planes hacerlo. En trminos generales se puede concluir que sera posible certificar la calidad de los procesos con mtodos giles pero adaptndolos a las exigencias de las

Utilizacin Mtodos giles mencionadas certificaciones y agregando pasos que no seran del todo necesarios para cumplir con los principios bsicos del desarrollo gil.

160

7. Segn surge de los casos de xito presentados, los mtodos giles aplicaran para cualquier tipo de proyecto. Se puede observar que los hay de diferentes temticas, con realidades de negocio muy diferentes y para objetivos diversos. Podramos decir, que contrariamente a lo que muchos suponen, los mtodos giles seran factibles de utilizar para el desarrollo de cualquier tipo de producto, en cualquier rea de negocio, de la misma forma que se utiliza cualquiera de las otras metodologas conocidas como tradicionales.

Utilizacin Mtodos giles REFERENCIAS

161

Abrahamsson, P., Salo, O., Ronkainen, J., Warsta, J.(2002) Agile software development methods. Review and analysis. Espoo 2002. VTT Publications 478. University of Oulu. Disponible en: http://www.pss-europe.com/P478.pdf Acebal F.C., Cueva L. J. (Marzo,2002). eXtreme Programming (XP): un nuevo mtodo de desarrollo de software. Articulo de la edicin digital de la revista Novtica. Disponible en: http://www.ati.es/novatica/2002/156/156-8.pdf Albaladejo, X., Daz, J.R., Iglesias, J., Quesada Allue, X., Perez, M., Salvar i Alabart, J., Veliz Bernaola, G., (2009) Como gestionar proyectos con Scrum. Sitio Web ProyectosAgiles.org. Disponible en: http://www.proyectosagiles.org/ Armour, G. (2004) The Laws of Software Process: A New Model for the Production and Management of Software. Auerbach/CRC Press. Disponible en: http://ingenieriasoftware.wikispaces.com/agiles+o+Poco+pesadas Ambler, S.W.,(2002) Agile Modeling: Effective Practices for Extreme Programming and the Unified Process. Wiley Computer Publishing. Ambler, S.W., (2005) The Agile Unified Process (AUP). Disponible en: http://www.ambysoft.com/unifiedprocess/agileUP.html Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R., Mellor, S., Schwaber, K., Sutherland, J. and Thomas, D. (2001).Manifesto for Agile Software Development. Disponible en: http://agilemanifesto.org/ Beck, K.. (1999) Extreme Programming Explained. Embrace Change, Addison Wesley Professional. The XP Series.
Beck, K., Andres, C. (2004) Extreme Programming Explained: Embrace Change. Second Edition. Addison Wesley Professional. The XP Series. Berrueta, D. (Enero, 2006). Programacin extrema y software libre. Disponible en: http://www.asturlinux.org/archivos/jornadas2006/ponencias/ProgExtrema_Berrueta/p onencia-sl-y-xp.pdf

Calabria, L., (2003) Metodologa FDD. Facultad de Ingeniera. Universidad ORT Uruguay. Disponible en: http://athenea.ort.edu.uy/publicaciones/ingsoft/investigacion/ayudantias/metodologia_ FDD.pdf

Utilizacin Mtodos giles

162

Calero Sols, M.(2003). Una explicacin de la programacin extrema (XP). V Encuentro usuarios xBase 2003 Madrid. Disponible en: www.avemundi.com/archivos/XP.doc Cans, J., Letelier, P., Penads, M.C. (s.f.) Mtodologas giles en el Desarrollo de Software. DSIC. Universidad Politcnica de Valencia. Disponible en: http://www.willydev.net/descargas/prev/TodoAgil.pdf Coad, P., Lefebrve, E., De Luca, J., (1999) Java Modeling in Color with UML Prentice Hall. Coad, P., (2000) Feature-Driven Development and Extreme Programming, Coad Letter, Issue 70. Cockburn, A. (1997) Surviving Object Oriented Projects, Addison Wesley Professional. Agile Software Development Series. Cockburn, A. (2001) Agile Software Development. Addison Wesley Professional. Agile Software Development Series.
Cockburn, A.(2003) The Crystal Methods or How to make a methodology fit. Agile Development Conference. Disponible en: http://agile2003.agilealliance.org/schedule/tutorials.html

Cockburn, A. (2004) Crystal Clear: A Human-Powered Methodology for Small Teams. Addison Wesley Professional. Agile Software Development Series. Colusso R., (s.f) Una introduccin a las metodologas giles de desarrollo de software. Desarrollo gil de software. Disponible en: http://knol.google.com/k/desarrollo-gil-desoftware# De Seta, L. (Febrero 2009) Los 7 principios del desarrollo Lean. Sitio Web Dos Ideas. Disponible en: http://www.dosideas.com/metodologias/410-los-7-principios-deldesarrollo-lean.html DSDM Consortium, Stapleton, J. (2003) DSDM: Business Focused Development. Segunda Edicin. Addison Wesley. Fernndez Enrich, M. (Febrero, 2003) Crystal Methodologies. Laboratorio de Sistemas de Informacin. Facultad de Informtica. Universidad Politcnica de Valencia. Disponible en: www.dsic.upv.es/asignaturas/facultad/lsi/trabajos/282002.ppt

Utilizacin Mtodos giles

163

Fernandez Gonzalez, J., (Junio, 2006) Que son eso de las metodologas giles. Sistemas Decisionales, algo mas que Business Intelligence, blog personal. Disponible en: http://sistemasdecisionales.blogspot.com/2006/06/que-son-eso-de-las-metodologasgiles.html Highsmith, J. (2000) Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, Dorset House Publishing CO. Jeffries, R., Anderson, A., Hendrickson, C. (2000) Extreme Programming Installed. Addison Wesley Professional. The XP Series. Letelier, P., Penads, M.C. (s.f.) Mtodologas giles para el desarrollo de software: eXtreme Programming (XP). Laboratorio de Sistemas de Informacin. Departamento de Sistemas Informticos y Computacin. Facultad de Informtica. Universidad Politcnica de Valencia. Disponible en: www.willydev.net/descargas/masyxp.pdf Marcos, C., (2009) Apuntes de ctedra Mtodos giles. Facultad de Ingeniera. Universidad Nacional del Centro de la Provincia de Buenos Aires. Disponible en: https://sites.google.com/a/alumnos.exa.unicen.edu.ar/metagiles/Home/apuntes Molpeceres, A., (2003) Procesos de desarrollo: RUP, XP Y FDD. Documentacin de javaHispano. Disponible en: http://www.willydev.net/descargas/Articulos/General/cualxpfddrup.PDF Morales, A., (Febrero, 2007) Crystal Clear, una forma de trabajo. Ideas 3p. El blog tcnico de Tercer Planeta. Disponible en: http://blog.tercerplaneta.com/2007/02/ms-all-delas-capacidades-tcnicas-que.html Optimizacin de Procesos operativos Lean Manufacturing, (s.f.) Sitio Web de Ambor Consulting. Disponible en: http://anbor.com/download/pdf/white01.pdf Palmer, S., Felsing, J. (2002) A Practical Guide to Feature-Driven Development. PrenticeHall. Coad Series. Planificacin De Poker. (s.f.) Wiki del sitio Web Dos Ideas. Disponible en : http://www.dosideas.com/wiki/Planificacion_De_Poker Poppendieck M., Poppendieck T. (2003) Lean Software Development: An Agile Toolkit for Software Development Managers.Addison Wesley Professional. Agile Software Development Series.

Utilizacin Mtodos giles Poppendieck M., Poppendieck T. (2006) Implementing Lean Software Development From Concept to Cash Addison Wesley Professional. Signature Series. Programacin en Pares.(Marzo,2005) Wiki del sitio Web ProgramacionExtrema.org Disponible en: http://www.programacionextrema.org/cgi-bin/wiki.pl?ProgramacionEnPares

164

Reynoso, C. (Abril, 2004) Mtodos Heterodoxos en Desarrollo de Software. Universidad de Buenos Aires. Disponible en: http://carlosreynoso.com.ar/archivos/arquitectura/Metodos-Agiles.PDF Rodrguez Gonzlez, P. (Septiembre, 2008) Estudio de la aplicacin de Metodologas giles para la evolucin de productos software. Tesis de Master. Master en tecnologas de la informacin. Facultad de Informtica. Universidad Politcnica de Madrid. Disponible en: http://oa.upm.es/1939/ Rubio Jimenez, M.A. (Junio 2009). Kanban: el mtodo Toyota aplicado al software. Disponible en: http://bosqueviejo.net/2009/06/22/kanban-el-metodo-toyota-aplicadoal-software/ SCRUM: metodologa gil para tus proyectos (Abril, 2008). Blog de Pyme Crunch. Disponible en: http://pymecrunch.com/scrum-metodologia-agil-para-tus-proyectos Schenone, M. H., (2004). Diseo de una metodologa gil de Desarrollo de Software. Tesis de Grado en Ingeniera en Informtica. Facultad de Ingeniera. Universidad de Buenos Aires. Disponible en: http://www.fi.uba.ar/materias/7500/schenonetesisdegradoingenieriainformatica.pdf
Schwaber, K., Beedle, M., (2002) Agile software development with Scrum. Prentice-Hall. Schwaber, K. (2004) Agile Project Management with Scrum. Microsoft Press, Redmond, WA.

Stapleton, J. (1997) Dynamic systems development method The method in practice. Addison Wesley. Wells, D.,(2009) The Values of Extreme Programming. Sitio Web Extreme Programming. Disponible en: http://www.extremeprogramming.org/values.html