Este documento analiza la implementación de prácticas ágiles en Argentina a través de encuestas a empresas. Se encontró que el 85% usa Scrum de forma parcial y la participación del cliente es difícil de lograr. También se identificaron problemas como la dificultad de estimar proyectos y falta de cambio cultural. Se concluye que las prácticas ágiles se usan parcialmente y su implementación completa enfrenta desafíos.

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

2. 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.

3. 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

4. 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.

5. 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

6. 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.

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

8. 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

9. 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

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

11. 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.

12. 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