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ón

Las Metodologías Ágiles emergen como una alternativa a las metodologías

tradicionales de desarrollo de software. Se aplican en muchos de los proyectos en

donde el entorno del sistema es muy cambiante, y con necesidades de reducir

drásticamente los tiempos de desarrollo aun manteniendo una alta calidad en el

producto.

Por eso, estas metodologías se han ido difundiendo en el mercado y están siendo

adoptadas por variadas organizaciones de desarrollo de software. ¿Cuál es el grado de

implementación de las metodologías ágiles en Argentina? ¿Cuáles de todas ellas son

las más utilizadas? ¿Se pueden adoptar en forma integral, es decir con todas las

prá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 preguntas

que se tratan de contestar en este trabajo.

Se expone en primer lugar un estudio sobre el estado del arte en el uso de

metodologías ágiles, a través de consultas realizadas en empresas, argentinas e

internacionales, con diferentes características y tamaños. El objetivo de este estudio es

indagar a través de consultas, acerca de los principales problemas de adaptación que

las empresas encuentran al implementar total o parcialmente estas metodologías. A

partir de los resultados del mismo, se formulan una serie de propuestas tendientes a

mitigar los problemas evidenciados. Dado que unos de los factores de importancia

para 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 el

contexto de una materia de grado de la carrera Ingeniería en Sistemas de la

Universidad Caece Sede Mar del Plata.

2 Estudio de la implementación de las Metodologías Ágiles en

Argentina

La industria del software ha tenido un crecimiento significativo en los últimos años en

Argentina dando muestras de un fuerte dinamismo. Según datos obtenidos del Boletín

Estadístico Tecnológico del Ministerio de Ciencia, Tecnología e Innovación

Productiva de la República Argentina [19] existen aproximadamente 1000 empresas

formales de Software y Servicios Informáticos (SSI), y durante el año 2008 dicho

sector empresarial registró ventas cercanas a los USD 2000 millones, un 22,4% más

que en 2007, y los puestos de trabajo ya superan los 50000. A su vez dicha industria

es reconocida en el mundo por su calidad teniendo en cuenta que en el ranking de

certificaciones del SEI (Software Engineering Institute)[5] Argentina se encuentra en

el puesto número 12.

Por otro lado, es importante mencionar que los organismos dedicados a fijar pautas

de calidad a aplicar para el desarrollo de software, también tienen en cuenta las

Metodologías Ágiles. La nueva versión de CMMI 1.3(Capability Madurity Model

Integration), propuesta por el Software Engineering Institute, contempla mejoras

para las organizaciones que trabajen bajo ambientes ágiles, a fin de asegurar una

correcta 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 de

difundir 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 de

metodologías ágiles

Considerando que en Argentina existen empresas con importante trayectoria y

profesionales con gran experiencia, los autores creen que estarían dadas las

condiciones 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 su

problemática en el mercado de desarrollo de software en Argentina. Este relevamiento

no fue realizado con fines estadísticos, sino como una fuente de obtención de

información. Para la materialización de este relevamiento se elaboró una lista de

cuestiones destinadas a adquirir datos sobre la implementación de métodos ágiles en

la ingeniería del software.

Considerando el objetivo mencionado anteriormente, se optó por realizar preguntas

abiertas, ya que las mismas permiten a los consultados explayarse en las respuestas.

Dicho relevamiento se enfocó desde tres perspectivas: a) empresas de desarrollo de

software, b) especialistas en calidad de software, c) empresas que tercerizan el

desarrollo de software.

Teniendo en cuenta los criterios básicos propuestos por Alistair Cockburn en los

Métodos Crystal [13] para la definición de la metodología a utilizar y los principios

del 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 seleccionadas

armando un conjunto heterogéneo que abarca la diversidad del mercado de desarrollo

de software. Este conjunto está formado por micro empresas, software factories

nacionales y empresas multinacionales con centros de desarrollo o filiales instaladas

en 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 mercado

internacional, y con rubros variados (telefonía, sistemas bancarios o comerciales,

empresas de servicios IT, entre otras). Además, se consultaron profesionales asesores

en normas y/o modelos de calidad para empresas de desarrollo de software. Por un

acuerdo de confidencialidad, no se revelan identidades de las empresas o

profesionales consultados.

Luego, a partir de las respuestas obtenidas, se realizaron nuevas consultas

particulares con el objeto profundizar en algunas de las cuestiones planteadas.

2.2 Resultados del estudio

A continuación se presenta el resultado del relevamiento realizado como parte de este

trabajo.

Uno de los primeros datos que surge de los resultados obtenidos es que la totalidad

de 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 de

métodos ágiles en sus procesos. Esta característica fue detectada tanto en empresas de

desarrollo como en empresas que tercerizan el desarrollo de sus aplicaciones.

Además, no se observa en ninguno de los consultados resistencia al uso de estas

metodologías, aún en aquellos que todavía no las han utilizado.

De los consultados que utilizan estas metodologías, el 85% refiere haber usado

Scrum, aunque no en forma completa sino adaptando las técnicas que consideran más

apropiadas a las necesidades del proyecto de referencia, a la certificación de calidad

de la empresa y a las idiosincrasias respectivas de los grupos involucrados. El 50% de

los proyectos a los que hacen referencia han tenido una duración de entre 4 y 12

meses, y un 20% a proyectos que tienen una duración de entre 1 y 2 años. Algunas

otras prácticas ágiles utilizadas son XP y Test Driven Development[15].

En cuanto al involucramiento del cliente en el proceso de desarrollo; todos los

consultados que han utilizado Scrum, coinciden en que es la práctica más difícil de

conseguir. 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 el

16,5% restante lo tienen entre sus objetivos pendientes.

Otro dato de consideración se refiere a las certificaciones de calidad, encontrando

que el 71% de los consultados refieren estar certificado en ISO 9001, mientras que el

29% no cuentan con certificación alguna. Dentro de las empresas certificadas en ISO

una también lo está en CMMI ML3 y otra en CMMI ML5.

No hay demasiadas coincidencias en cuanto a los resultados obtenidos con la

aplicación de métodos ágiles. Considerando el tiempo de desarrollo, algunos opinan

que fue óptimo mientras que otros no encuentran mejoría en este aspecto respecto del

uso de metodologías tradicionales. Muchos coinciden que las prácticas de gestión de

proyectos de Scrum ayudan a que esta variable esté bajo control.

Una importante apreciación en la cual coincidieron los consultados se refiere a una

drástica diminución del esfuerzo de mantenimiento, sobre todo en el tiempo más

cercano a la implantación. Según el criterio y experiencia de los autores esto se

debería al fuerte involucramiento del usuario de la aplicación en el proceso de

construcción de la misma. El mismo conlleva a la adaptación progresiva de la

aplicación a las expectativas del usuario a lo largo del desarrollo. De la misma manera

se realizan los cambios o correcciones necesarios en el mismo periodo de desarrollo

en lugar de hacerlo en modo post-implantación.

En cuanto a la calidad del producto, el 50% de los consultados encuentran una

mejoría en el aspecto atribuible a las iteraciones, mientras que el otro 50% considera

los productos de calidad aceptable pero sin percibir cambios significativos debidos a

la adopción de metodologías ágiles.

A partir de los resultados obtenidos en respuesta a los cuestionarios, se hicieron

algunas consultas particulares con aquellos profesionales que implementaban

metodologías ágiles en grandes empresas. De estas consultas surgen las siguientes

problemáticas, Scrum establece que se debe considerar a todos los desarrolladores

como "un solo equipo" y que cualquier miembro del equipo pueda realizar cualquier

tarea; no obstante, según los datos obtenidos, esto resulta difícil de implementar. Un

aspecto clave para llevarlo a cabo es el tipo de proyecto y las características del

mismo. Si el proyecto contara con una arquitectura compleja, resultaría difícil que un

analista 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ía

lograrse es que expertos en diseño y codificación puedan intercambiar algunas de sus

tareas.

Adicionalmente se observó, que si bien las prácticas ágiles se realizan, el problema

radica en cómo se las implementa. Como ejemplos de unas incorrectas

implementaciones 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 dichas

metodologías. Se evidenció casos de empresas en las cuales los responsables de

implementar el modelo ágil estaban en contra del mismo. A su vez, si dichas

empresas tenían certificados de calidad como CMMI e ISO, al momento de definir

como implementar el modelo ágil, simplemente le cambiaban el nombre a sus

procesos para que “sonaran a ágil”, implementando de este modo los procesos con la

filosofía tradicional pero con otros nombres, y no aprovechando las ventajas que

ofrecen 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 un

verdadero proceso ágil, corroboran lo expuesto por Pete Mc Breen [16] quien afirma

que mucha gente proclama que sus procesos son ágiles, pero sucede que en el día a

día de los proyectos nada ha cambiado. Mc Breen expone una lista de diez síntomas

que indicarían que un proceso que dice ser ágil en realidad no lo es. Varias de las

consideraciones de esa lista se corresponden con los puntos planteados anteriormente.

Otro problema que se evidenció entre los consultados, es la dificultad para realizar

la 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 sus

prioridades a lo largo del proyecto. En algunos casos han optado por utilizar un

presupuesto en horas basado en los requerimientos que son identificados en primera

instancia, 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 un

estudio realizado en una tesis de fin de carrera dirigida por los autores [11]. Dicho

estudio 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 resultados

obtenidos refuerzan las conclusiones expresadas en este trabajo.

2.3 Problemas en la implementación detectados a partir del estudio

Las metodologías ágiles surgen como una necesidad a la hora de satisfacer los

cambiantes requerimientos de desarrollo de los sistemas actuales, pero manteniendo la

calidad del producto resultante. Por eso han sido adoptadas por distintas

organizaciones de desarrollo de software.

Sin embargo, persisten algunos problemas que a criterio de los autores dificultan

todaví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 su

principio IV “La gente del negocio y los desarrolladores deben trabajar juntos a lo

largo del proyecto”. Esto implica que esta práctica es fundamental y no puede ser

omitida. 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 reconocimiento

de la importancia de las especificaciones de requerimientos.

Tampoco se cree que sea una causa para este problema la falta de capacidad para

realizar una correcta especificación, ya que los usuarios son cada vez más expertos y

formales al expresar sus necesidades. Actualmente, tienen una mayor experiencia en

la utilización de herramientas informáticas, por lo cual la tarea de abstracción de sus

necesidades en una especificación de requerimientos es realizada prácticamente sin

mayores dificultades.

Un ejemplo claro de esto, es que en los últimos 2 años los autores han participado

en 34 proyectos de desarrollo de software utilizando metodologías tradicionales con 8

clientes diferentes. En el 41% de esos proyectos se han recibido diferentes tipos de

artefactos construidos directamente por los usuarios como parte de la definición de

sus 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 casos

fueron entregados por iniciativa propia del usuario al momento de iniciarse el

relevamiento 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 uno

de los principios del Manifiesto Ágil [3]: “Desarrollar software que funciona más que

conseguir una buena documentación”. Al entender de los autores, habría que

diferenciar la construcción de modelos con el mero fin de documentar el producto

generado, de la elaboración de modelos como proceso de diseño de soluciones. Es

decir, 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 que

en el mismo se puedan intercambiar tareas, no se descarta la existencia de una

diversidad de perfiles dentro de los integrantes, de modo tal que la asignación de

tareas en un sprint estaría regida por el conocimiento y experticia de cada uno. Si

dicho equipo es capaz de asumir el compromiso de los requisitos en cada iteración y

si 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 pueden

evolucionar hacia los métodos ágiles para integrarse en un equipo ágil, debiendo

aprender y adaptarse a los cambios requeridos para ello.

4. Propuestas de Mejoras en la Aplicación de Metodologías Ágiles

Como resultado del relevamiento, se detectó que Scrum es la metodología ágil

mayormente utilizada; sus actividades de gestión corresponden a las prácticas

recomendadas por CMMI. A partir de dicha consideración, los autores decidieron

trabajar en definir una serie de recomendaciones para la implementación de esta

metodología agregando ciertas actividades tendientes a la solución de los problemas

detectados en dicho relevamiento.

En lo que respecta a planificación y seguimiento de proyectos si las actividades

definidas por esta metodología son llevadas a cabo de manera correcta, se estarían

cumpliendo las prácticas recomendadas para la gestión de proyectos.

Como una manera de completar esta metodología los autores recomiendan reforzar

las actividades de ingeniería. A continuación se describen las diferentes

recomendaciones organizadas según el ciclo de vida y elementos de Scrum.

Product backlog. No olvidar definir y priorizar no sólo los requerimientos que

tengan que ver con el comportamiento funcional del producto a construir, sino

tambié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 sprint

también se deberán incluir los requerimientos no funcionales que deberán

implementarse. Esto es importante ya que la incorporación de un requerimiento no

funcional podría implicar actividades adicionales dentro del sprint

.

Sprint Planning. Durante el sprint planning es conveniente generar un espacio para

el análisis de lecciones aprendidas. Es decir, considerar las acciones que hayan sido

recomendadas en las retrospectivas de sprints anteriores. En caso de que se trate del

primer sprint se podrían incluso considerar lecciones aprendidas de proyectos

anteriores en los que hayan participado los integrantes del equipo. Dicha cuestión

debería surgir naturalmente en equipos ágiles maduros, es decir con experiencia en

este tipo de proyectos. No obstante, se recomienda que el Scrum Master incluya de

manera obligatoria esta actividad dentro de la agenda.

Considerar, en la planificación, las actividades de modelado a realizar durante el

sprint y quienes serían los responsables de su elaboración.

Utilizar herramientas para el soporte de la planificación, desarrollo y control de

avance de las actividades. Existen múltiples herramientas, incluso algunas de uso

libre, que dan soporte a todas las actividades propuestas por estas metodologías.

Además proveen mecanismos que facilitan la comunicación entre los integrantes del

equipo dejando registro de dichas comunicaciones.

Sprint. En lo que respecta a actividades de ingeniería, como se ha dicho

anteriormente, construir modelos que faciliten el desarrollo no significa un

incumplimiento del manifiesto ágil. Por tal motivo, los autores consideran que si sólo

se realizan actividades de codificación sería una mala implementación de la

metodologí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 que

no pueden construirse en forma aislada con una visión independiente por

requerimiento. Por lo contario, se necesita una visión global de todo el conjunto de

requerimientos a implementarse en el sprint como, por ejemplo, el diseño de la

arquitectura y el modelo de datos.

En particular en lo que respecta a diseño, en el primer sprint sería conveniente

realizar un diagrama de arquitectura y un análisis de alternativas de solución

eficientes según los requerimientos no funcionales. Este modelo podría ser revisado

en cada sprint en caso de que se considere necesario o que aparecieran nuevos

requerimientos que afecten la arquitectura. En cuanto al modelo de datos debería

definirse de manera incremental a medida que se definan los diferentes

requerimientos 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 integrante

del equipo la necesidad de este modelado como forma de simplificación de la

codificación. Esto permitirá realizar un diseño previo a la codificación de los

requerimientos del sprint y contar con una base para las sucesivas iteraciones.

Respecto del seguimiento y control, son suficientes una correcta implementación

de los daily meetings, el uso de burndown charts y el boardtask. De todos modos, se

recomienda el uso de herramientas ya que las mismas dejarían registro suficiente para

las mediciones de desempeño y rendimiento.

Sprint Retrospective. Las retrospectivas deberían tener como principal objetivo la

obtención de lecciones aprendidas y la definición de acciones correctivas y

preventivas para las iteraciones subsiguientes del proyecto.

Las recomendaciones antes descriptas están dirigidas a la solución de algunos de los

problemas detectados para la implementación de metodologías ágiles, pero no

solucionan los problemas relacionados con la gestión de equipos y la falta de

formación superior en temas ágiles.

Enfocados en esta problemática se presenta, en la siguiente sección, una

experiencia en el marco de una materia de la carrera de Ingeniería en Sistemas.

5. Experiencia en la Enseñanza

Como se ha expresado en secciones anteriores, la falta de formación de los recursos

humanos en este tipo de metodologías es uno de los problemas coyunturales a

solucionar para su correcta implementación.

En este sentido, los autores consideran necesario que las universidades incluyan en

sus planes de estudio formación sobre metodologías ágiles. Esta formación no debería

realizarse sólo desde el punto de vista teórico ya que en estas metodologías son claves

aspectos que tienen carácter de dinámicos, como son la comunicación, y la capacidad

de autogestión del equipo. Por lo tanto, es fundamental realizar experiencias prácticas

que 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 la

carrera Ingeniería en Sistemas (Universidad CAECE), los autores consideraron

oportuno 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 producto

que sirviera como herramienta para la gestión de proyectos ágiles. Es decir, se

construirí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 único

equipo 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 el

cual se realizó la experiencia.

Considerando la importancia que tienen para estas metodologías las relaciones

humanas y la sinergia y dinámica de los equipos de trabajo, se destaca que estos

alumnos ya se conocían en el ámbito universitario pero sólo dos de ellos habían

trabajado juntos previamente. Durante las primeras tres semanas profundizaron sus

conocimientos teóricos en metodologías ágiles y definieron las herramientas que

utilizarían durante el proyecto.

Dado que el trabajo se realizaría a lo largo de un cuatrimestre en el marco de una

materia de cuatro horas semanales, se acordó con los alumnos una dedicación

adicional aunque obviamente menor a lo que sería en un ambiente profesional. El

objetivo de la materia no era construir un producto con las mismas características que

las que tendrían en nueve semanas de trabajo en un ambiente profesional, sino que los

alumnos aprendieran la dinámica de un grupo ágil y fueran capaces de comparar la

forma 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 de

los sprints. Se debían realizar tres sprints de tres semanas de duración cada uno. El

grupo se asignó los roles y definió quien sería el Scrum Master. Los docentes

cumplieron el rol del cliente, fijando requerimientos, prioridades y evaluando el

producto.

En cada encuentro, el grupo realizaba el daily-meeting correspondiente, en el cual

comentaban las tareas realizadas y las próximas a hacer. Para el seguimiento del

proyecto utilizaron una planilla de cálculo donde incluían el product backlog, el sprint

backlog y las horas estimadas y reales de cada requisito.

Al final de cada sprint, el grupo realizaba la correspondiente demostración del

producto. En dicha reunión los docentes, en el rol de usuarios, evaluaban la

funcionalidad final desarrollada, surgiendo ajustes al producto presentado.

A continuación, los alumnos realizaban la retrospectiva, en la cual el Scrum

Master tenía un rol preponderante. Si bien el grupo fue capaz de identificar fortalezas

y debilidades, los docentes dieron un feedback de cómo habían trabajado de acuerdo a

la metodología, para que el grupo pudiera ajustar lo necesario en el siguiente sprint.

Luego de la retrospectiva, el grupo estimaba los requerimientos del product

backlog para establecer cuáles serían incluidos en el siguiente sprint. Como

herramienta para la estimación utilizaron juicio de expertos.

Cabe destacar que fueron diferentes los resultados obtenidos en los sprints, y

quedó 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 los

docentes, fueron producto de la inexperiencia de los alumnos en este tipo de

metodologías. Pueden citarse como ejemplos una subestimación de los requisitos a

incluir, la minimización de la importancia de la comunicación del equipo durante el

sprint más allá de las reuniones de los días de cursada y una pobre retrospectiva

realizada en la que jugaron un papel más de observadores que de partícipes. Podría

decirse que este sprint fracasó porque al finalizar el mismo, los alumnos no tenían un

producto para presentar. Sólo habían construido un prototipo pues estaban

implementadas las interfaces de usuario con cierta funcionalidad pero se habían

obviado múltiples validaciones que en un producto con un mínimo de robustez y

confiabilidad se deberían realizar.

Para el segundo sprint (habiendo comprendido los errores cometidos durante el

primero) el equipo planificó terminar todos los requisitos tomados durante el primero

y agregar un único requisito. Como lecciones aprendidas, realizaron cambios en

cuanto a la forma de trabajo y comunicación del equipo, asumiendo uno de los

miembros 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. Cabe

destacar 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 ser

considerados cambios de alcance) los cuales fueron tomados con naturalidad e

implementados sin mayores problemas durante el sprint.

Para el tercer sprint se seleccionaron nuevos requerimientos los cuales hacían que

la aplicación terminara siendo una buena herramienta para soporte de gestión de

metodologías ágiles pero dejaron afuera ciertos requisitos de reporting ya que el

equipo consideró que no podría llegar a completarlos. Cabe destacar que los docentes

consideraban que el product backlog definido inicialmente era mayor al que podría

ser efectivamente construido durante la cursada de la materia. La dinámica del equipo

fue muy buena, trabajando con eficiencia durante todo el desarrollo del sprint. Los

requisitos fueron concluidos en tiempo y forma.

En resumen, durante el desarrollo del proyecto, los alumnos se encontraron con los

siguientes 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 una

propuesta 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 de

capacitación. Resulta muy útil que los docentes transmitan los conceptos teóricos y

luego que los alumnos continúen con el aprendizaje validando en las clases siguientes

el avance y los conceptos adquiridos. Para ello, podrían realizarse pequeños talleres

de no más de una hora cada uno, para trabajar los principales puntos de estas

metodologías, tales como estimación de los requisitos que entrarán en un sprint, cómo

realizar un daily meeting, técnicas para llevar adelante las retrospectivas, diferencias

entre retrospectiva y demostración. Esto permitirá que los alumnos comiencen el

proyecto 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 o

más y que cada uno no se extienda más allá de tres semanas. Esto permitirá, (i) a los

docentes, validar la aplicación de la metodología y (ii) a los alumnos corregir los

errores 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ía

ser inferior a las diez horas, incluidas las de clase. De este modo es posible mostrar

avances 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, se

recomienda que se fijen pautas tales como: días de trabajo pre-establecidos y daily

meetings, 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 sea

conocido por los alumnos. Esto facilitará la definición del producto minimizando la

intervención de la cátedra dentro del equipo.

Teniendo en cuenta los problemas observados y los resultados obtenidos los

autores consideran fructuosas las actividades expuestas. Permiten a los alumnos

aprender desde la práctica los principios de las metodologías ágiles. Tarea que es

imposible hacer con los mismos beneficios sólo desde la teoría. El concepto

fundamental se basa en las personas y la dinámica de los equipos de trabajo. Para

respetar este concepto la técnica “on the job training” se impone.

6. Conclusiones

El uso de las Metodologías Ágiles está en expansión. Esto se debe a las ventajas que

presentan estas metodologías para un mundo cambiante y dinámico como el actual.

Como resultado del relevamiento realizado, se han detectado ciertos problemas que

aún dificultan la correcta implementación de estas metodologías. Sin embargo los

mismos pueden ser resueltos con la incorporación de pautas para actividades de

ingeniería derivadas de las metodologías tradicionales que permitan acelerar la

codificación y sirvan como base para futuras iteraciones.

En lo que respecta al equipo de trabajo, existen diversas variables a ser tenidas en

cuenta: cultura organizacional, experiencia y experticia de los integrantes del equipo,

factores culturales, y formación hacia un determinado paradigma. El desarrollo de

habilidades “ágiles” en el ámbito universitario juega un rol importante en la

formación de futuros profesionales.

En tal sentido, se evidencia que algunos de los problemas referentes a

implementaciones incorrectas detectados en el estudio de indagación realizado,

aparecieron también en los primeros Sprint de la experiencia didáctica realizada por

los autores en la Universidad CAECE. Siendo importante destacar que a medida que

los alumnos fueron avanzando en la materia estos problemas fueron corregidos.

Esto hace suponer que una correcta formación práctica en este tipo de

metodologí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 el

de objetos, consideran que están dadas las condiciones para un cambio hacia la

agilidad, 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ía

1. 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.pdf

6. M. B. Chrissis, Konrad, and Shrum, “CMMI, Guía para la integración de procesos y la

mejora de productos”, Pearson Educación, 2009

7. Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad, Sandy Shrum, “CMMI® or

Ágile: Why Not Embrace Both!”, TECHNICAL NOTE CMU/SEI-2008-TN-003

8. Henrik Kniberg, “Scrum y XP desde las trincheras”, C4Media Inc, 2007

9. Jeff Sutherland, Carsten R. Jakobsen, Kent Johnson, “Scrum and CMMI Level 5: The

Magic Potion for Code Warriors”, Ágile2007 Conference

10. 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 2009

13. Actualmente en: http://alistair.cockburn.us/Methodology+per+project

14. Actualmente en: http://www.pmi.org/GetInvolved/Pages/Communities-of-Practice-

Ágile.aspx

15. Kent Beck, “Test Driven Development By Example”. Addison Wesley, 2003

16. Actualmente en http://www.informit.com/articles/article.aspx?p=25913&seqNum=3

17. 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.pdf

19. Mike Cohn, „Succeding with Ágile: Software Development Using Scrum‟, Addison-

Wesley, 2010

20. Actualmente en:http://alistair.cockburn.us/Ágile+contracts