Análisis de la implementación de prácticas ágiles en Argentina

Análisis de la implementación de prácticas ágiles en Argentina M. Alvarez, F. Escobar, A. Nardin, E. Ricci Aparicio, G. Bioul Universidad CAECE, Sede Mar del Plata, Olavarría. 2464, Mar del Plata, Argentina { malvarez, fescobar, anardin, ericciaparicio, gbioul }@ucaecemdp.edu.ar Resumen. Este trabajo analiza el grado de implementación de las metodologías modernas de ingeniería de software en el ámbito profesional y educativo Argentino. A través de consultas, encuestas y en base a la experiencia de los autores, se acertaron conclusiones alentadoras acerca de la adopción de prácticas ágiles, que en muchos casos integran los nuevos conceptos en forma parcial o híbrida. Las Metodologías Ágiles son uno de los más populares enfoques para el desarrollo de software en estos días. Parte del reto de aplicar nuevas metodologías está basado en la educación. En el presente trabajo se exponen los resultados de consultas en empresas nacionales argentinas y multinacionales para identificar problemas y proponer soluciones. También se comenta una experiencia realizada en el ámbito universitario que pretende definir un método para la enseñanza de la “agilidad”. Keywords: Metodologías Ágiles, Ingeniería de Software, Scrum, Sprint.1 IntroducciónLas Metodologías Ágiles emergen como una alternativa a las metodologíastradicionales de desarrollo de software. Se aplican en muchos de los proyectos endonde el entorno del sistema es muy cambiante, y con necesidades de reducirdrásticamente los tiempos de desarrollo aun manteniendo una alta calidad en elproducto. Por eso, estas metodologías se han ido difundiendo en el mercado y están siendoadoptadas por variadas organizaciones de desarrollo de software. ¿Cuál es el grado deimplementación de las metodologías ágiles en Argentina? ¿Cuáles de todas ellas sonlas más utilizadas? ¿Se pueden adoptar en forma integral, es decir con todas lasprácticas propuestas? ¿Se pueden certificar normas o modelos de calidad siendo„ágil‟? ¿Cuál es el futuro de estas metodologías? Son estas algunas de las preguntasque se tratan de contestar en este trabajo. Se expone en primer lugar un estudio sobre el estado del arte en el uso demetodologías ágiles, a través de consultas realizadas en empresas, argentinas einternacionales, con diferentes características y tamaños. El objetivo de este estudio esindagar a través de consultas, acerca de los principales problemas de adaptación quelas empresas encuentran al implementar total o parcialmente estas metodologías. A

partir de los resultados del mismo, se formulan una serie de propuestas tendientes amitigar los problemas evidenciados. Dado que unos de los factores de importanciapara la implementación de estas metodologías es contar con recursos experimentados,se comenta una experiencia áulica de aplicación de Metodologías Ágiles en elcontexto de una materia de grado de la carrera Ingeniería en Sistemas de laUniversidad Caece Sede Mar del Plata.2 Estudio de la implementación de las Metodologías Ágiles enArgentinaLa industria del software ha tenido un crecimiento significativo en los últimos años enArgentina dando muestras de un fuerte dinamismo. Según datos obtenidos del BoletínEstadístico Tecnológico del Ministerio de Ciencia, Tecnología e InnovaciónProductiva de la República Argentina [19] existen aproximadamente 1000 empresasformales de Software y Servicios Informáticos (SSI), y durante el año 2008 dichosector empresarial registró ventas cercanas a los USD 2000 millones, un 22,4% másque en 2007, y los puestos de trabajo ya superan los 50000. A su vez dicha industriaes reconocida en el mundo por su calidad teniendo en cuenta que en el ranking decertificaciones del SEI (Software Engineering Institute)[5] Argentina se encuentra enel puesto número 12. Por otro lado, es importante mencionar que los organismos dedicados a fijar pautasde calidad a aplicar para el desarrollo de software, también tienen en cuenta lasMetodologías Ágiles. La nueva versión de CMMI 1.3(Capability Madurity ModelIntegration), propuesta por el Software Engineering Institute, contempla mejoraspara las organizaciones que trabajen bajo ambientes ágiles, a fin de asegurar unacorrecta interpretación de sus prácticas [10]. El Project Management Institute (PMI)incluye entre sus comunidades a la comunidad de Prácticas Ágiles con el objetivo dedifundir y compartir conocimiento entre seguidores del PMI y de las metodologíaságiles.2.1 Elaboración del estudio de indagación acerca de la implementación demetodologías ágilesConsiderando que en Argentina existen empresas con importante trayectoria yprofesionales con gran experiencia, los autores creen que estarían dadas lascondiciones para el incremento de la utilización de metodologías ágiles. Por tal motivo se consideró realizar un estudio para indagar a través de consultas(relevamiento) acerca del grado de implementación de las metodologías ágiles y suproblemática en el mercado de desarrollo de software en Argentina. Este relevamientono fue realizado con fines estadísticos, sino como una fuente de obtención deinformación. Para la materialización de este relevamiento se elaboró una lista decuestiones destinadas a adquirir datos sobre la implementación de métodos ágiles enla ingeniería del software. Considerando el objetivo mencionado anteriormente, se optó por realizar preguntasabiertas, ya que las mismas permiten a los consultados explayarse en las respuestas.

Dicho relevamiento se enfocó desde tres perspectivas: a) empresas de desarrollo desoftware, b) especialistas en calidad de software, c) empresas que tercerizan eldesarrollo de software. Teniendo en cuenta los criterios básicos propuestos por Alistair Cockburn en losMétodos Crystal [13] para la definición de la metodología a utilizar y los principiosdel Manifiesto Ágil [3], entre las cuestiones incluidas en el relevamiento se destacan:  tiempo de experiencia en el uso de métodos ágiles,  tiempo de duración promedio de los proyectos, prácticas utilizadas, y  compromiso de los clientes, certificaciones de calidad y casos de éxito.Las empresas consultadas para deliberar en estas cuestiones fueron seleccionadasarmando un conjunto heterogéneo que abarca la diversidad del mercado de desarrollode software. Este conjunto está formado por micro empresas, software factoriesnacionales y empresas multinacionales con centros de desarrollo o filiales instaladasen Argentina trabajando para mercados tales como América del Sur y del Norte,Comunidad Europea y China, con 3 hasta 30 años de presencia en el mercadointernacional, y con rubros variados (telefonía, sistemas bancarios o comerciales,empresas de servicios IT, entre otras). Además, se consultaron profesionales asesoresen normas y/o modelos de calidad para empresas de desarrollo de software. Por unacuerdo de confidencialidad, no se revelan identidades de las empresas oprofesionales consultados. Luego, a partir de las respuestas obtenidas, se realizaron nuevas consultasparticulares con el objeto profundizar en algunas de las cuestiones planteadas.2.2 Resultados del estudioA continuación se presenta el resultado del relevamiento realizado como parte de estetrabajo. Uno de los primeros datos que surge de los resultados obtenidos es que la totalidadde los consultados conocen estas metodologías. Si bien no todos las aplican aún,ninguno de los consultados mostró oposición o resistencia en la utilización demétodos ágiles en sus procesos. Esta característica fue detectada tanto en empresas dedesarrollo como en empresas que tercerizan el desarrollo de sus aplicaciones. Además, no se observa en ninguno de los consultados resistencia al uso de estasmetodologías, aún en aquellos que todavía no las han utilizado. De los consultados que utilizan estas metodologías, el 85% refiere haber usadoScrum, aunque no en forma completa sino adaptando las técnicas que consideran másapropiadas a las necesidades del proyecto de referencia, a la certificación de calidadde la empresa y a las idiosincrasias respectivas de los grupos involucrados. El 50% delos proyectos a los que hacen referencia han tenido una duración de entre 4 y 12meses, y un 20% a proyectos que tienen una duración de entre 1 y 2 años. Algunasotras prácticas ágiles utilizadas son XP y Test Driven Development[15]. En cuanto al involucramiento del cliente en el proceso de desarrollo; todos losconsultados que han utilizado Scrum, coinciden en que es la práctica más difícil deconseguir. El 16,5% de las empresas lo lograron, el 67% de los consultados responde

haber logrado el compromiso en algunos casos o en forma parcial, mientras que el16,5% restante lo tienen entre sus objetivos pendientes. Otro dato de consideración se refiere a las certificaciones de calidad, encontrandoque el 71% de los consultados refieren estar certificado en ISO 9001, mientras que el29% no cuentan con certificación alguna. Dentro de las empresas certificadas en ISOuna también lo está en CMMI ML3 y otra en CMMI ML5. No hay demasiadas coincidencias en cuanto a los resultados obtenidos con laaplicación de métodos ágiles. Considerando el tiempo de desarrollo, algunos opinanque fue óptimo mientras que otros no encuentran mejoría en este aspecto respecto deluso de metodologías tradicionales. Muchos coinciden que las prácticas de gestión deproyectos de Scrum ayudan a que esta variable esté bajo control. Una importante apreciación en la cual coincidieron los consultados se refiere a unadrástica diminución del esfuerzo de mantenimiento, sobre todo en el tiempo máscercano a la implantación. Según el criterio y experiencia de los autores esto sedebería al fuerte involucramiento del usuario de la aplicación en el proceso deconstrucción de la misma. El mismo conlleva a la adaptación progresiva de laaplicación a las expectativas del usuario a lo largo del desarrollo. De la misma manerase realizan los cambios o correcciones necesarios en el mismo periodo de desarrolloen lugar de hacerlo en modo post-implantación. En cuanto a la calidad del producto, el 50% de los consultados encuentran unamejoría en el aspecto atribuible a las iteraciones, mientras que el otro 50% consideralos productos de calidad aceptable pero sin percibir cambios significativos debidos ala adopción de metodologías ágiles. A partir de los resultados obtenidos en respuesta a los cuestionarios, se hicieronalgunas consultas particulares con aquellos profesionales que implementabanmetodologías ágiles en grandes empresas. De estas consultas surgen las siguientesproblemáticas, Scrum establece que se debe considerar a todos los desarrolladorescomo "un solo equipo" y que cualquier miembro del equipo pueda realizar cualquiertarea; no obstante, según los datos obtenidos, esto resulta difícil de implementar. Unaspecto clave para llevarlo a cabo es el tipo de proyecto y las características delmismo. Si el proyecto contara con una arquitectura compleja, resultaría difícil que unanalista del equipo, con experiencia profesional en metodologías tradicionales,modifique alguna línea de código de otro. En estos casos, lo máximo que podríalograrse es que expertos en diseño y codificación puedan intercambiar algunas de sustareas. Adicionalmente se observó, que si bien las prácticas ágiles se realizan, el problemaradica en cómo se las implementa. Como ejemplos de unas incorrectasimplementaciones se pueden nombrar:  las retrospectivas sólo usadas como espacio de formulación de quejas o para hablar únicamente del producto, y no para analizar los resultados y extraer lecciones aprendidas para las próximas iteraciones;  las reuniones diarias no utilizadas para intercambiar información de trabajo, sino para resolver problemas y por lo tanto excediéndose demasiado;  el usuario generando documentación para los desarrolladores como definición de requerimientos, en lugar de participar activamente junto al equipo del proyecto.

Otro punto muy importante es que las empresas que implementan las metodologíaságiles deben tener a su personal convencido y dispuesto a convivir con dichasmetodologías. Se evidenció casos de empresas en las cuales los responsables deimplementar el modelo ágil estaban en contra del mismo. A su vez, si dichasempresas tenían certificados de calidad como CMMI e ISO, al momento de definircomo implementar el modelo ágil, simplemente le cambiaban el nombre a susprocesos para que “sonaran a ágil”, implementando de este modo los procesos con lafilosofía tradicional pero con otros nombres, y no aprovechando las ventajas queofrecen Scrum, XP, u otras, más allá de simples pasos para crear software. Estas últimas cuestiones, que plantean dudas respecto de la implementación de unverdadero proceso ágil, corroboran lo expuesto por Pete Mc Breen [16] quien afirmaque mucha gente proclama que sus procesos son ágiles, pero sucede que en el día adía de los proyectos nada ha cambiado. Mc Breen expone una lista de diez síntomasque indicarían que un proceso que dice ser ágil en realidad no lo es. Varias de lasconsideraciones de esa lista se corresponden con los puntos planteados anteriormente. Otro problema que se evidenció entre los consultados, es la dificultad para realizarla estimación de un proyecto en forma anticipada cuando se utiliza una metodologíaágil, debido fundamentalmente a los posibles cambios en los requerimientos y susprioridades a lo largo del proyecto. En algunos casos han optado por utilizar unpresupuesto en horas basado en los requerimientos que son identificados en primerainstancia, y luego llevar adelante el proyecto hasta que se consuma dicho presupuesto. Los resultados de esta investigación fueron cotejados con los datos obtenidos en unestudio realizado en una tesis de fin de carrera dirigida por los autores [11]. Dichoestudio abordó empresas y profesionales diferentes a los referidos en este trabajo,como también así, el método de selección y contacto. No obstante ello, los resultadosobtenidos refuerzan las conclusiones expresadas en este trabajo.2.3 Problemas en la implementación detectados a partir del estudioLas metodologías ágiles surgen como una necesidad a la hora de satisfacer loscambiantes requerimientos de desarrollo de los sistemas actuales, pero manteniendo lacalidad del producto resultante. Por eso han sido adoptadas por distintasorganizaciones de desarrollo de software. Sin embargo, persisten algunos problemas que a criterio de los autores dificultantodavía su correcta implementación:  Lograr la participación activa y comprometida del usuario formando parte del equipo de desarrollo durante todo el proyecto.  Falta de definición de pautas suficientes respecto de la ingeniería del producto.  La conformación del equipo del proyecto con recursos que puedan adaptarse a las metodologías ágiles.En cuanto a la participación de los usuarios, el Manifiesto Ágil [3] expresa en suprincipio IV “La gente del negocio y los desarrolladores deben trabajar juntos a lolargo del proyecto”. Esto implica que esta práctica es fundamental y no puede seromitida. Esta resistencia a la participación del usuario puede ser debida más a

cuestiones organizativas y operativas de los clientes, que por falta de reconocimientode la importancia de las especificaciones de requerimientos. Tampoco se cree que sea una causa para este problema la falta de capacidad pararealizar una correcta especificación, ya que los usuarios son cada vez más expertos yformales al expresar sus necesidades. Actualmente, tienen una mayor experiencia enla utilización de herramientas informáticas, por lo cual la tarea de abstracción de susnecesidades en una especificación de requerimientos es realizada prácticamente sinmayores dificultades. Un ejemplo claro de esto, es que en los últimos 2 años los autores han participadoen 34 proyectos de desarrollo de software utilizando metodologías tradicionales con 8clientes diferentes. En el 41% de esos proyectos se han recibido diferentes tipos deartefactos construidos directamente por los usuarios como parte de la definición desus requerimientos, como pueden ser prototipos de pantallas, planillas de cálculos,diagramas de actividades y/o gráficos. Es importante destacar que en todos los casosfueron entregados por iniciativa propia del usuario al momento de iniciarse elrelevamiento y no como una actividad requerida o guiada por el equipo del proyecto. Con respecto a la ausencia de pautas de ingeniería de producto, vale recordar unode los principios del Manifiesto Ágil [3]: “Desarrollar software que funciona más queconseguir una buena documentación”. Al entender de los autores, habría quediferenciar la construcción de modelos con el mero fin de documentar el productogenerado, de la elaboración de modelos como proceso de diseño de soluciones. Esdecir, que no documentar no significaría no modelar. En lo que se refiere a la conformación del equipo de trabajo, si bien se requiere queen el mismo se puedan intercambiar tareas, no se descarta la existencia de unadiversidad de perfiles dentro de los integrantes, de modo tal que la asignación detareas en un sprint estaría regida por el conocimiento y experticia de cada uno. Sidicho equipo es capaz de asumir el compromiso de los requisitos en cada iteración ysi se trabaja en forma cooperativa, es posible cumplir con los mismos. A tal efecto,Martín Alaimo, referente de la comunidad ágil en Argentina, explica en su artículo“Roles Ágiles” [17] cómo los roles existentes en metodologías tradicionales puedenevolucionar hacia los métodos ágiles para integrarse en un equipo ágil, debiendoaprender y adaptarse a los cambios requeridos para ello.4. Propuestas de Mejoras en la Aplicación de Metodologías ÁgilesComo resultado del relevamiento, se detectó que Scrum es la metodología ágilmayormente utilizada; sus actividades de gestión corresponden a las prácticasrecomendadas por CMMI. A partir de dicha consideración, los autores decidierontrabajar en definir una serie de recomendaciones para la implementación de estametodología agregando ciertas actividades tendientes a la solución de los problemasdetectados en dicho relevamiento. En lo que respecta a planificación y seguimiento de proyectos si las actividadesdefinidas por esta metodología son llevadas a cabo de manera correcta, se estaríancumpliendo las prácticas recomendadas para la gestión de proyectos.

Como una manera de completar esta metodología los autores recomiendan reforzarlas actividades de ingeniería. A continuación se describen las diferentesrecomendaciones organizadas según el ciclo de vida y elementos de Scrum.Product backlog. No olvidar definir y priorizar no sólo los requerimientos quetengan que ver con el comportamiento funcional del producto a construir, sinotambién requerimientos no funcionales, como pueden ser: pautas de desarrollo,restricciones arquitectónicas y de plataforma, seguridad, y otras.Sprint backlog. Cuando se seleccionan los requisitos que serán incluidos en el sprinttambién se deberán incluir los requerimientos no funcionales que deberánimplementarse. Esto es importante ya que la incorporación de un requerimiento nofuncional podría implicar actividades adicionales dentro del sprint .Sprint Planning. Durante el sprint planning es conveniente generar un espacio parael análisis de lecciones aprendidas. Es decir, considerar las acciones que hayan sidorecomendadas en las retrospectivas de sprints anteriores. En caso de que se trate delprimer sprint se podrían incluso considerar lecciones aprendidas de proyectosanteriores en los que hayan participado los integrantes del equipo. Dicha cuestióndebería surgir naturalmente en equipos ágiles maduros, es decir con experiencia eneste tipo de proyectos. No obstante, se recomienda que el Scrum Master incluya demanera obligatoria esta actividad dentro de la agenda. Considerar, en la planificación, las actividades de modelado a realizar durante elsprint y quienes serían los responsables de su elaboración. Utilizar herramientas para el soporte de la planificación, desarrollo y control deavance de las actividades. Existen múltiples herramientas, incluso algunas de usolibre, que dan soporte a todas las actividades propuestas por estas metodologías.Además proveen mecanismos que facilitan la comunicación entre los integrantes delequipo dejando registro de dichas comunicaciones.Sprint. En lo que respecta a actividades de ingeniería, como se ha dichoanteriormente, construir modelos que faciliten el desarrollo no significa unincumplimiento del manifiesto ágil. Por tal motivo, los autores consideran que si sólose realizan actividades de codificación sería una mala implementación de lametodología convirtiéndose en un ciclo de vida conocido como “code and fix” [12].En este sentido, es importante destacar que hay ciertos aspectos de la aplicación queno pueden construirse en forma aislada con una visión independiente porrequerimiento. Por lo contario, se necesita una visión global de todo el conjunto derequerimientos a implementarse en el sprint como, por ejemplo, el diseño de laarquitectura y el modelo de datos. En particular en lo que respecta a diseño, en el primer sprint sería convenienterealizar un diagrama de arquitectura y un análisis de alternativas de solucióneficientes según los requerimientos no funcionales. Este modelo podría ser revisadoen cada sprint en caso de que se considere necesario o que aparecieran nuevosrequerimientos que afecten la arquitectura. En cuanto al modelo de datos deberíadefinirse de manera incremental a medida que se definan los diferentesrequerimientos en cada sprint. Además se recomienda la elaboración de diagramas de

interacción para las funciones más complejas, quedando a criterio de cada integrantedel equipo la necesidad de este modelado como forma de simplificación de lacodificación. Esto permitirá realizar un diseño previo a la codificación de losrequerimientos del sprint y contar con una base para las sucesivas iteraciones. Respecto del seguimiento y control, son suficientes una correcta implementaciónde los daily meetings, el uso de burndown charts y el boardtask. De todos modos, serecomienda el uso de herramientas ya que las mismas dejarían registro suficiente paralas mediciones de desempeño y rendimiento.Sprint Retrospective. Las retrospectivas deberían tener como principal objetivo laobtención de lecciones aprendidas y la definición de acciones correctivas ypreventivas para las iteraciones subsiguientes del proyecto.Las recomendaciones antes descriptas están dirigidas a la solución de algunos de losproblemas detectados para la implementación de metodologías ágiles, pero nosolucionan los problemas relacionados con la gestión de equipos y la falta deformación superior en temas ágiles. Enfocados en esta problemática se presenta, en la siguiente sección, unaexperiencia en el marco de una materia de la carrera de Ingeniería en Sistemas.5. Experiencia en la EnseñanzaComo se ha expresado en secciones anteriores, la falta de formación de los recursoshumanos en este tipo de metodologías es uno de los problemas coyunturales asolucionar para su correcta implementación. En este sentido, los autores consideran necesario que las universidades incluyan ensus planes de estudio formación sobre metodologías ágiles. Esta formación no deberíarealizarse sólo desde el punto de vista teórico ya que en estas metodologías son clavesaspectos que tienen carácter de dinámicos, como son la comunicación, y la capacidadde autogestión del equipo. Por lo tanto, es fundamental realizar experiencias prácticasque les permitan a los alumnos adquirir un cabal conocimiento de las prácticas ágiles. En el marco de la materia Investigación en Ingeniería de Software de 4to año de lacarrera Ingeniería en Sistemas (Universidad CAECE), los autores consideraronoportuno que los alumnos no sólo aprendieran los principios de las metodologíaságiles sino que también los ejercitaran. Para ello, propusieron a un grupo de alumnos realizar el desarrollo de un productoque sirviera como herramienta para la gestión de proyectos ágiles. Es decir, seconstruiría un producto para ágiles, aplicando Scrum como metodología de desarrollo. Debido a que eran cinco alumnos los inscriptos en el curso, se conformó un únicoequipo de trabajo. Todos los alumnos se encontraban en el tramo final de su carrera,incluso para algunos era la única materia que cursaban durante el cuatrimestre en elcual se realizó la experiencia. Considerando la importancia que tienen para estas metodologías las relacioneshumanas y la sinergia y dinámica de los equipos de trabajo, se destaca que estosalumnos ya se conocían en el ámbito universitario pero sólo dos de ellos habíantrabajado juntos previamente. Durante las primeras tres semanas profundizaron sus

conocimientos teóricos en metodologías ágiles y definieron las herramientas queutilizarían durante el proyecto. Dado que el trabajo se realizaría a lo largo de un cuatrimestre en el marco de unamateria de cuatro horas semanales, se acordó con los alumnos una dedicaciónadicional aunque obviamente menor a lo que sería en un ambiente profesional. Elobjetivo de la materia no era construir un producto con las mismas características quelas que tendrían en nueve semanas de trabajo en un ambiente profesional, sino que losalumnos aprendieran la dinámica de un grupo ágil y fueran capaces de comparar laforma de trabajo de estas metodologías respecto de las tradicionales. Una de las pocas pautas establecidas por los docentes fue la cantidad y duración delos sprints. Se debían realizar tres sprints de tres semanas de duración cada uno. Elgrupo se asignó los roles y definió quien sería el Scrum Master. Los docentescumplieron el rol del cliente, fijando requerimientos, prioridades y evaluando elproducto. En cada encuentro, el grupo realizaba el daily-meeting correspondiente, en el cualcomentaban las tareas realizadas y las próximas a hacer. Para el seguimiento delproyecto utilizaron una planilla de cálculo donde incluían el product backlog, el sprintbacklog y las horas estimadas y reales de cada requisito. Al final de cada sprint, el grupo realizaba la correspondiente demostración delproducto. En dicha reunión los docentes, en el rol de usuarios, evaluaban lafuncionalidad final desarrollada, surgiendo ajustes al producto presentado. A continuación, los alumnos realizaban la retrospectiva, en la cual el ScrumMaster tenía un rol preponderante. Si bien el grupo fue capaz de identificar fortalezasy debilidades, los docentes dieron un feedback de cómo habían trabajado de acuerdo ala metodología, para que el grupo pudiera ajustar lo necesario en el siguiente sprint. Luego de la retrospectiva, el grupo estimaba los requerimientos del productbacklog para establecer cuáles serían incluidos en el siguiente sprint. Comoherramienta para la estimación utilizaron juicio de expertos. Cabe destacar que fueron diferentes los resultados obtenidos en los sprints, yquedó en evidencia la importancia de la experiencia en estas metodologías. Durante este primer sprint se cometieron una serie de errores que, a juzgar por losdocentes, fueron producto de la inexperiencia de los alumnos en este tipo demetodologías. Pueden citarse como ejemplos una subestimación de los requisitos aincluir, la minimización de la importancia de la comunicación del equipo durante elsprint más allá de las reuniones de los días de cursada y una pobre retrospectivarealizada en la que jugaron un papel más de observadores que de partícipes. Podríadecirse que este sprint fracasó porque al finalizar el mismo, los alumnos no tenían unproducto para presentar. Sólo habían construido un prototipo pues estabanimplementadas las interfaces de usuario con cierta funcionalidad pero se habíanobviado múltiples validaciones que en un producto con un mínimo de robustez yconfiabilidad se deberían realizar. Para el segundo sprint (habiendo comprendido los errores cometidos durante elprimero) el equipo planificó terminar todos los requisitos tomados durante el primeroy agregar un único requisito. Como lecciones aprendidas, realizaron cambios encuanto a la forma de trabajo y comunicación del equipo, asumiendo uno de losmiembros el rol de tester para hacer una integración funcional del producto,reuniéndose por fuera de la materia para trabajar en un mismo lugar físico y

utilizando un cuadro de fortalezas e ítems a mejorar para la retrospectiva. Cabedestacar que durante el desarrollo de este sprint los docentes, en el rol de usuario,introdujeron algunos cambios en la definición de los requisitos (aunque no pueden serconsiderados cambios de alcance) los cuales fueron tomados con naturalidad eimplementados sin mayores problemas durante el sprint. Para el tercer sprint se seleccionaron nuevos requerimientos los cuales hacían quela aplicación terminara siendo una buena herramienta para soporte de gestión demetodologías ágiles pero dejaron afuera ciertos requisitos de reporting ya que elequipo consideró que no podría llegar a completarlos. Cabe destacar que los docentesconsideraban que el product backlog definido inicialmente era mayor al que podríaser efectivamente construido durante la cursada de la materia. La dinámica del equipofue muy buena, trabajando con eficiencia durante todo el desarrollo del sprint. Losrequisitos fueron concluidos en tiempo y forma. En resumen, durante el desarrollo del proyecto, los alumnos se encontraron con lossiguientes problemas, los cuales fueron solucionados a lo largo de la experiencia:  Falta de experiencia en estas metodologías: Si bien tuvieron un período de entrenamiento teórico y capacitación previo al inicio del proyecto, en los primeros sprints la implementación de la metodología no fue la adecuada y mejoró en las sucesivas iteraciones.  Sinergia del equipo: Los integrantes mejoraron la dinámica de trabajo con el avance del proyecto, pues el conocerse más hizo que la comunicación fuera más fluida y se entendieran con mayor facilidad ante problemas.  Necesidad de trabajar en un mismo lugar físico fuera del horario de cátedra: En el inicio de cada sprint se repartían las tareas y durante la semana estaban en contacto entre ellos o se reunían en sub-grupos. Para poder avanzar y tratar de cumplir los compromisos acordados, comenzaron a reunirse en la última semana del sprint para integrar lo que cada uno había desarrollado, pues para esas tareas necesitaban estar todos en un mismo lugar físico.Como cierre de esta experiencia didáctica, los autores exponen a continuación unapropuesta para aplicar en la enseñanza de prácticas ágiles. Antes de comenzar con el ejercicio práctico, es necesario contar con un período decapacitación. Resulta muy útil que los docentes transmitan los conceptos teóricos yluego que los alumnos continúen con el aprendizaje validando en las clases siguientesel avance y los conceptos adquiridos. Para ello, podrían realizarse pequeños talleresde no más de una hora cada uno, para trabajar los principales puntos de estasmetodologías, tales como estimación de los requisitos que entrarán en un sprint, cómorealizar un daily meeting, técnicas para llevar adelante las retrospectivas, diferenciasentre retrospectiva y demostración. Esto permitirá que los alumnos comiencen elproyecto con conceptos más maduros y el ejercicio les resulte más productivo. Respecto de la cantidad y duración de los sprints; se recomienda que sean tres omás y que cada uno no se extienda más allá de tres semanas. Esto permitirá, (i) a losdocentes, validar la aplicación de la metodología y (ii) a los alumnos corregir loserrores eventuales y aplicar cambios en las siguientes iteraciones. Con relación a la dedicación semanal mínima de cada alumno, la misma no deberíaser inferior a las diez horas, incluidas las de clase. De este modo es posible mostraravances concretos en la construcción del producto y realizar las reuniones

correspondientes. En cuanto a la organización de la ejecución de las tareas, serecomienda que se fijen pautas tales como: días de trabajo pre-establecidos y dailymeetings, aun cuando el equipo no se encuentre físicamente en el mismo lugar. En cuanto al producto a construir, se sugiere que su dominio de aplicación seaconocido por los alumnos. Esto facilitará la definición del producto minimizando laintervención de la cátedra dentro del equipo. Teniendo en cuenta los problemas observados y los resultados obtenidos losautores consideran fructuosas las actividades expuestas. Permiten a los alumnosaprender desde la práctica los principios de las metodologías ágiles. Tarea que esimposible hacer con los mismos beneficios sólo desde la teoría. El conceptofundamental se basa en las personas y la dinámica de los equipos de trabajo. Pararespetar este concepto la técnica “on the job training” se impone.6. ConclusionesEl uso de las Metodologías Ágiles está en expansión. Esto se debe a las ventajas quepresentan estas metodologías para un mundo cambiante y dinámico como el actual. Como resultado del relevamiento realizado, se han detectado ciertos problemas queaún dificultan la correcta implementación de estas metodologías. Sin embargo losmismos pueden ser resueltos con la incorporación de pautas para actividades deingeniería derivadas de las metodologías tradicionales que permitan acelerar lacodificación y sirvan como base para futuras iteraciones. En lo que respecta al equipo de trabajo, existen diversas variables a ser tenidas encuenta: cultura organizacional, experiencia y experticia de los integrantes del equipo,factores culturales, y formación hacia un determinado paradigma. El desarrollo dehabilidades “ágiles” en el ámbito universitario juega un rol importante en laformación de futuros profesionales. En tal sentido, se evidencia que algunos de los problemas referentes aimplementaciones incorrectas detectados en el estudio de indagación realizado,aparecieron también en los primeros Sprint de la experiencia didáctica realizada porlos autores en la Universidad CAECE. Siendo importante destacar que a medida quelos alumnos fueron avanzando en la materia estos problemas fueron corregidos. Esto hace suponer que una correcta formación práctica en este tipo demetodologías, derivarían en una mejora en la implementación de las mismas en elámbito profesional. Así como los autores han vivido la transición del paradigma estructurado hacia elde objetos, consideran que están dadas las condiciones para un cambio hacia laagilidad, pero aplicando las lecciones aprendidas de los distintos paradigmas.Mientras antes se empiece con este reto, más rápido se verán los resultados.Bibliografía1. Kent Beck. “Extreme Programming Explained: Embrace Change”. Reading, Addison Wesley, 1999.

2. Laurie Williams, Robert R. Kessler, Ward Cunningham, Ron Jeffries, “Strengthening the Case for Pair Programming,” IEEE Software, 2000.3. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, y otros. “Ágile Manifesto”. 2001.http://ágilemanifesto.org/4. Ken Schwaber, Mike Beedle, “Ágile Software Development with Scrum”, Prentice Hall, 2001.5. Actualmente en: http://www.sei.cmu.edu/cmmi/casestudies/profiles/pdfs/upload/2010MarCMMI.pdf6. M. B. Chrissis, Konrad, and Shrum, “CMMI, Guía para la integración de procesos y la mejora de productos”, Pearson Educación, 20097. Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad, Sandy Shrum, “CMMI® or Ágile: Why Not Embrace Both!”, TECHNICAL NOTE CMU/SEI-2008-TN-0038. Henrik Kniberg, “Scrum y XP desde las trincheras”, C4Media Inc, 20079. Jeff Sutherland, Carsten R. Jakobsen, Kent Johnson, “Scrum and CMMI Level 5: The Magic Potion for Code Warriors”, Ágile2007 Conference10. Mike Phillips , Sandy Shrum, “Process Improvement for All: What to Expect from CMMI Version 1.3”, Software Engineering Institute,2010.11. Andrea N. Alende, “La utilización de las Metodologías Ágiles en las empresas de desarrollo de software de Argentina”, Universidad CAECE Sede Mar del Plata, 2010.12. Tom de Marco, “Software Engineering An idea whose time has come and gone”, IEEE Software, July August 200913. Actualmente en: http://alistair.cockburn.us/Methodology+per+project14. Actualmente en: http://www.pmi.org/GetInvolved/Pages/Communities-of-Practice- Ágile.aspx15. Kent Beck, “Test Driven Development By Example”. Addison Wesley, 200316. Actualmente en http://www.informit.com/articles/article.aspx?p=25913&seqNum=317. Actualmente en http://www.martinalaimo.com/es/2010/02/roles-ágiles/18. Actualmente en: http://www.mincyt.gov.ar/indicadores/banco_indicadores/publicaciones/bet_TIC_final.pdf19. Mike Cohn, „Succeding with Ágile: Software Development Using Scrum‟, Addison- Wesley, 201020. Actualmente en:http://alistair.cockburn.us/Ágile+contracts

Análisis de la implementación de prácticas ágiles en Argentina

by Agile Spain on Dec 20, 2011

Accessibility

Tags

Upload Details

Usage Rights

Statistics

Análisis de la implementación de prácticas ágiles en Argentina — Document Transcript