caso de estudio sobre apropiación de scrum en...

Caso de estudio sobre apropiación de SCRUM en empresas que han adoptado CMMI*

Silvia Isabel Lozano Argel, Raquel Anaya

Departamento de Informática y Sistemas, Universidad EAFIT. Avda. Las Vegas 7 Sur-50.

Medellín, Colombia. {slozanoa,ranaya}@eafit.edu.co

Resumen. Este artículo proporciona los resultados del estudio cualitativo que permitió observar la transferencia de conocimiento y adopción de Scrum en empresas de desarrollo de software que han realizado ciclos de mejora utilizan-do referentes de calidad como CMMI o TSP/PSP. El estudio se realizó en dos etapas: En la primera etapa se utilizó la metodología Grounded Theory lo cual permitió observar e identificar los principales retos y dudas que enfrentaron es-tas compañías durante la fase de acompañamiento presencial y virtual (4 meses) en la segunda etapa, se diseñó y llevó a cabo una encuesta en los 3 meses si-guientes, que permitió complementar los hallazgos de la primera fase. Los re-sultados indican que los principales retos se encuentran alrededor de tres cate-gorías principales: los valores establecidos en el manifiesto ágil, los elementos de Scrum y las prácticas complementarias a Scrum. El estudio también propor-ciona algunas recomendaciones y lecciones aprendidas que pueden ayudar a las organizaciones durante el proceso de adopción.

Palabras claves: Practicas ágiles, CMMI, Scrum, adopción, retos, lecciones aprendidas, Grounded Theory.

1 Introducción

La productividad y la competitividad que demanda actualmente el mercado a las or-ganizaciones de software, les generan grandes retos de tipo técnico, organizacional y de gestión. Estos retos son una de las causas por la que los procesos de desarrollo de software deben también estar en constante evolución y adopción de nuevas prácticas.

Tradicionalmente, las organizaciones de software han venido abordando dichos re-tos desde la perspectiva de la mejora en los procesos organizacionales, que se reali-zan a través de proyectos de mejora que toman como referentes modelos de calidad

* ® Capability Maturity Model, CMM and CMMI are registered in the U.S. Patent and Trademark Office

Proceedings of the XVII Ibero-American Conference on Software Engineering (CIBSE2014)

April, 23-25, Pucón, Chile Universidad de La Frontera, Temuco, Chile. 350

internacionales como CMMI[3], o modelos de calidad latinoamericanos como Mo-prosoft (México) [20], MPS.BR (Brasil) [22]. Estos programas de mejora suponen una considerable inversión en dinero, tiempo y recursos para las empresas y la mayor-ía de estas empresas no están preparadas para asumir solas estas iniciativas de mejora de proceso [4].

En el contexto latinoamericano, se han desarrollado proyectos con el apoyo de aso-ciaciones y entidades que reconocen la importancia de las TIC como un renglón competitivo de la economía, tales como Competisoft [14] y RELAIS [15]. En Colom-bia se pueden destacar, las tres fases del proyecto para la adopción del modelo CMMI en Pymes del sector software y servicios conexos que fueron impulsados por Colcien-cias, SENA, PROEXPORT desde el año 2005 y cuya última fase (2008-2010) pre-sentó un ejercicio de articulación Universidad-Empresa-Estado [5].

Durante los últimos años, los enfoques ágiles han empezado a tener más fuerza como una nueva alternativa para desarrollar software y así mejorar la baja tasa de proyectos exitosos alcanzados con prácticas orientadas a planes [6].

En este nuevo contexto aparece un programa de apoyo software promovido por Ruta N1 cuyo objetivo fue apoyar la transferencia de conocimiento y adopción del marco de trabajo ágil Scrum en un grupo de empresas de desarrollo de software de Medellín [8], que fue el marco en el cual se realizó este estudio. En la figura 1 se muestran las tres fases de este programa.

Fig. 1. Tomado de: Requisitos de postulación Programa para la transferencia de Scrum – Ruta N (Fuente: [8]).

El objetivo de este artículo es mostrar los resultados del estudio realizado en el marco del programa liderado por Ruta N. Las empresas que fueron seleccionadas en el programa de Ruta N, fueron a la vez empresas que anteriormente se habían benefi-ciado de programas de mejora para adopción de CMMI y por lo tanto surge la conno-tación especial del estudio en el contexto de empresas que ya han adoptado modelos de madurez como CMMI.

La organización de este artículo se conforma de la siguiente manera: la sección 2 presenta el marco conceptual usado en este estudio. En la sección 3, una visión gene-ral de los trabajos relacionados con la mejora de procesos y la adopción de prácticas

1 http://www.rutanmedellin.org



ágiles en empresas de desarrollo de software es presentada. En la sección 4 se descri-be el diseño de la investigación, el método de investigación cualitativa utilizada y como aplica a la ingeniería del software, la recolección y el análisis de datos. En la sección 5 se presentan los hallazgos y una discusión sobre los mismos. El artículo concluye en la sección 6 presentando también los trabajos futuros.

2 Marco conceptual

Según la propuesta de Hanakawa [10], la complejidad del proceso software se ve influenciado durante el progreso de un proyecto debido a los procesos adicionales necesarios para desarrollar las solicitudes repentinas o urgentes del cliente. La suma total de estos procesos adicionales es una manera de calcular la complejidad de un proceso software. Y este valor de complejidad permite que los gerentes puedan deci-dir cuándo hacer el “refactoring” de un proceso, adicionando u omitiendo actividades en su plan de proyecto [10], esto significa que más que seguir una metodología rígida, el proceso de software debe ser flexible o adaptable a las condiciones del contexto.

El proceso software no es completamente creativo, pues tiene algunas partes que pueden ser descritas con detalle y algunos procedimientos han sido impuestos pre-viamente, por otro lado tampoco es un proceso de ingeniería “pura”, porque aún no usa totalmente la ciencia experimental para apoyar sus decisiones, dependen demasia-do de mucha gente, el diseño y la producción no están claramente diferenciados, y los presupuestos, calendarios y la calidad no pueden ser planificados de forma suficien-temente confiable [11]. Se podría afirmar que esta doble naturaleza del proceso soft-ware como arte y ciencia podría influenciar la selección del conjunto de prácticas para el proceso y que sea necesario que se componga de prácticas ágiles que permitan la adaptación a los cambios, así como de prácticas robustas que permitan definir planes a largo plazo y lidiar con la complejidad de grandes equipos.

Boehm y Turner en [12] sugieren una marcada diferencia entre enfoques orientados a planes y enfoques ágiles y plantean 5 dimensiones críticas que pueden ser usadas para describir una organización o un proyecto en términos de sus características que luego permitirá definir si tendrá más éxito con prácticas disciplinadas o ágiles. La propuesta en [12] es balancear agilidad y disciplina, logrando que la disciplina cree memorias bien organizadas, manejo de la historia y experiencia de la organización que luego la agilidad usará para ajustarse y adaptarse a los cambios.

Al conocer en profundidad las prácticas ágiles, se percibe que para una adopción exitosa de las mismas es preciso hablar también de disciplina en el proceso, pues se necesita disciplina con aspectos de desempeño del equipo como la planeación y se-guimiento constante, retroalimentación continua, interacción permanente con el clien-te, prácticas de prueba, integración y liberaciones continuas y manejo de la propiedad colectiva, así como con el seguimiento de los valores del manifiesto ágil [6], [13].



3 Trabajos relacionados

Los estudios empíricos han venido utilizándose para dar evidencia de los resultados de programas de mejora [23,24,25]. Estos estudios son útiles porque permiten recopi-lar los retos que enfrentan las organizaciones cuando realizan una mejora de procesos y factores de éxito que inciden en el éxito de estos programas [16], [25].

Desde la perspectiva del enfoque ágil, existen estudios que muestran la adopción de Scrum [16], [23], [25], XP [2] y estudios secundarios que realizan una recopilación de experiencias de adopción de enfoques ágiles [7].

Algunos de estos trabajos hacen uso de la metodología Grounded Theory [17], [19]; si bien este trabajo se hace sobre un número limitado de organizaciones, su foco principal es la trayectoria previa en mejora de procesos que han tenido las organiza-ciones.

Glasser y Strauss fueron los primeros en describir la metodología Grounded Theo-ry (GT) en 1967. El objetivo de GT es desarrollar una teoría desde los datos en vez de obtener datos para probar una teoría o hipótesis [1].

Se seleccionó GT como método de investigación por diferentes razones: Primero, las prácticas y métodos ágiles se centran en las personas y sus interacciones y GT, es una metodología de investigación cualitativa rigurosa usada para investigar fenóme-nos como sentimientos, comportamientos y emociones, los cuales son difíciles de estudiar a través de métodos cuantitativos [1]. Segundo, GT es indicado para áreas de investigación las cuales no han sido exploradas en gran detalle antes, y la literatura de investigación sobre la adopción de prácticas agiles en empresas colombianas es esca-sa.

4 Método y contexto de la investigación

En esta sección, se presentan los pasos seguidos para realizar el estudio: la caracteri-zación de las empresas participantes, el diseño del estudio, la recolección de datos y el análisis de los datos recolectados.

4.1 Caracterización de empresas participantes

Se realizaron observaciones de las sesiones de entrenamiento y coaching sobre Scrum dentro del programa de Ruta N, en las cuales participaron alrededor de 45 miembros de 8 empresas de desarrollo de software y servicios conexos en Medellín. La figura 2 muestra el perfil de las empresas participantes.

El tamaño de las organizaciones varía de 49 a 278 empleados, un 38% de las em-

presas son pequeñas (menos de 51 empleados), 38% son grandes (más de 200 em-pleados) y un 25% son mediana empresa (entre 51 y 200 empleados).



Fig. 2. Perfil de las empresas participantes en el estudio

La mitad de las empresas participantes (50%) está dentro del rango de 11 a 15 años de constitución, lo cual muestra una alta experiencia adquirida en el desarrollo de soft-ware.

El nivel de madurez CMMI presente en las empresas es de un 25% en nivel 5 y un 13% en nivel 4, las demás empresas (62%) no tienen valoraciones oficiales del SEI [9] pero participaron en programas de adopción de prácticas de este modelo en años anteriores.

La mayoría de las empresas venían trabajando un esquema de roles tradicional y los equipos de trabajo Scrum fueron conformados por personas con diferentes roles: gerentes de proyectos, líderes de calidad, líderes de procesos, desarrolladores, analis-tas de calidad, diseñadores y arquitectos.

4.2 Diseño del estudio

El objetivo de este estudio es analizar el proceso de apropiación de prácticas ágiles específicamente Scrum en empresas de desarrollo de software o servicios relaciona-dos, con el propósito de caracterizar los retos, logros y lecciones aprendidas, con respecto al uso de prácticas ágiles y su relación con las prácticas orientadas a planes (CMMI) ya adoptadas, desde el punto de vista de los investigadores, patrocinadores, consultores y miembros de los equipos de los proyectos bajo observación en el con-texto de las empresas participantes en el programa piloto de transferencia del conoci-miento y apropiación de la metodología ágil Scrum.

El tipo de estudio usado en la investigación fue un estudio experimental cualitativo primario in vivo basado en la observación directa usando la técnica de Grounded Theory y apoyado por la técnica de encuesta [21].



La encuesta estuvo conformada por un total de 15 preguntas divididas en 3 seccio-nes: Información general del encuestado y el proyecto, Adopción actual de Scrum y prácticas complementarias y la sección de Percepciones generales.

Las preguntas de investigación fueron las siguientes:

• P1. ¿Cuáles son los retos durante la apropiación de prácticas ágiles (Scrum) en empresas de desarrollo de software que han adoptado CMMI?

• P2. ¿Los retos identificados y caracterizados durante la apropiación de las prácticas ágiles son similares a los retos encontrados en la literatura?

• P3. ¿Cuáles fueron las prácticas ágiles adoptadas por los diferentes equipos de trabajo en las empresas? ¿Cuál es el nivel de adopción de las prácticas?

• P4. ¿Cuáles son los principales beneficios y lecciones aprendidas percibidas por los profesionales de las empresas participantes del estudio?

4.3 Recolección de datos

Durante el periodo de observación el investigador, que no pertenecía a ninguna de las empresas participantes, recolectó datos de las siguientes fuentes:

• Observación en sitio que permitió generar el registro de las acciones de los equi-pos de trabajo durante el acompañamiento (coaching) presencial de los consultores.

• Observación en sitio durante la fase de acompañamiento remoto. Se realizaron en promedio dos visitas a las empresas durante esta fase. El acompañamiento remoto se planeó con los consultores.

• Se revisaron artefactos generados por los equipos de trabajo durante el proceso de apropiación de las prácticas ágiles. (Product backlog, sprint, gráficas de progreso, estimaciones, conclusiones de retrospectivas, etc)

• Se realizó una encuesta a través de un cuestionario y fue distribuida después del periodo de acompañamiento con las empresas. La encuesta complementó los hallazgos de las sesiones y ayudó a obtener una mejor idea de las opiniones de los participantes sobre la adopción de Scrum en sus empresas.

4.4 Análisis de datos

Siguiendo el enfoque GT, se usó codificación abierta para analizar las transcripciones de las sesiones en detalle [17]. Las transcripciones contenían información de las dudas y retos de las empresas, así como de algunos aportes relevantes del consultor.

Se inicia cotejando los puntos claves de cada transcripción de las sesiones [17]. Se asigna entonces un código a cada punto clave. Un código es una frase que resume el punto clave en 2 o 3 palabras. Los códigos que surgen en cada sesión fueron constan-temente comparados contra los códigos de la misma sesión, o de otras sesiones y ob-servaciones. Esto se conoce como método de comparación constante [1,17]. Final-mente se repite el método de comparación constante sobre los conceptos para produ-cir un tercer nivel de abstracción llamado Categorías.



La figura 3.A muestra como la categoría Colaboración con cliente emerge de los conceptos y 3.B muestra los niveles de abstracción de datos usando GT.

Fig. 3. A: Como emerge la categoría Colaboración con cliente desde los conceptos subyacentes. B: Niveles de abstracción en Grounded Theory.

El resultado de este análisis son las categorías de los retos en la adopción de Scrum en empresas que anteriormente han adoptado prácticas del modelo CMMI. Dado que los códigos, conceptos y categorías emergen directamente de los datos, los cuales a la vez son recolectados del mundo real, la teoría resultante está fundamentada dentro del contexto de los datos [17]. En la siguiente sección presentamos las categor-ías de la teoría fundamentada resultante.

5 Resultados empíricos

5.1 Retos identificados durante el período de observación (Respuesta a P1)

Uno de los hallazgos claves que se encontraron al realizar este estudio es que los dife-rentes retos y dudas generadas durante el proceso de apropiación de Scrum se organi-zan alrededor de 3 temas principales: los valores establecidos en el manifiesto ágil, los elementos de Scrum y las prácticas complementarias a Scrum. Estas categorías “core” junto con los conceptos más relevantes se presentan en la figura 4.



Fig. 4. Categorías “core” y conceptos relevantes asociados a los retos en la adopción de Scrum

Retos alrededor de las prácticas complementarias a Scrum. El mayor número de dudas que expusieron los participantes se relacionan con la inte-gración de Scrum con otras prácticas que la complementan en ingeniería, entre ellas: refactoring, pruebas automatizadas, pruebas unitarias y de integración, integración continua, reuso de componentes, XP, trabajo en pares, TDD y DSDM

Algunos participantes perciben que la práctica de refactoring consume mucho tiempo y que la práctica de programación en pares es difícil de implantar pues no se conocen datos reales sobre la mejora de la productividad o calidad relacionada con su uso.

Dentro de las dudas iniciales que expusieron las empresas se encuentran aquellas relacionadas con la conexión entre las historias de usuario y otras prácticas ya conso-lidadas dentro del proceso de requisitos como casos de uso y prototipos.

El mayor dolor que tienen las empresas que ya tienen implantadas practicas orien-tadas a planes como CMMI o PSP/TSP y que han realizado valoraciones para este modelo, es perder la trazabilidad entre los artefactos generados durante el proceso de desarrollo; este temor es generado quizá porque el valor ágil de “software funcionan-do por encima de la documentación”, se entiende como una eliminación de productos de trabajo del proceso de desarrollo.

Retos alrededor de los elementos de Scrum. Entre los conceptos más relevantes generados durante el análisis se encuentran: Rol de equipo: este concepto emergió en el periodo de observación relacionado al “multitasking” (varias tareas a la vez); luego al realizar la encuesta se evidencia que el único reto en común entre las dos partes del estudio es la conformación de los equipos; cuando una empresa CMMI decide implantar Scrum, es necesaria una reor-ganización de sus equipos de desarrollo especializados a equipos multifuncionales.



Fig. 5. Retos alrededor de los elementos de Scrum

Los datos mostraron que las organizaciones presentan retos en la definición del Rol de Scrum Master debido a que no se tienen claras cuáles son las expectativas sobre el mismo y no se conoce la diferencia con el rol actual de gerente de proyecto, cabe resaltar que ha surgido un nuevo rol como resultado de la mezcla entre estos dos car-gos que trata de balancear sus responsabilidades.

Artefactos Scrum: Se generaron varias dudas alrededor del product backlog ¿cómo se construye y quién y cómo lo debe priorizar? Algunas empresas de desarrollo asu-men la responsabilidad de crear y gestionar este artefacto, sin embargo es el Product Owner quien por definición de Scrum debe tener esa tarea. Para los proyectos en man-tenimiento es difícil tener un Product backlog priorizado y actualizado por las altas tasas de cambio y priorización de los requerimientos en soporte y mantenimiento; también cabe resaltar el hecho de que en empresas del gobierno el tema de los acuer-dos de niveles de servicio guía la priorización de los incidentes y requisitos.

Retos alrededor de los valores ágiles. La figura 6 resume los conceptos y categorías alrededor de los valores ágiles [18].

Negociar con el cliente e influenciarlo: Se percibe dificultad en lograr que el clien-te entienda y se adapte a las prácticas ágiles, se resalta la falta de conocimiento del framework por parte del cliente y poca claridad en el cliente de que el uso de Scrum depende del contexto del proyecto. Otro reto son los esquemas de contratación tradi-cionales que algunos clientes desean mantener (costo, tiempo y alcance fijos).

Cambio de cultura y actitud: Unas de las principales dificultades para la adopción de prácticas como Scrum es el lento cambio en la cultura organizacional. Ha sido difícil la interacción directa y continua del usuario con el equipo de trabajo. Sin em-bargo, es importante resaltar que cuando se encuestó de manera individual a las per-sonas, se percibió que no es un reto para ellas adoptarse a los cambios que se hagan en la organización (64%).

Releases: Se percibe dificultad en la gestión de entregas frecuentes al cliente y la definición del alcance de cada sprint

Manejo de Soporte y Mantenimiento: Se identifica una necesidad de definir guías de trabajo que orienten a los equipos a reconocer las más efectivas prácticas ágiles



para la gestión del soporte y mantenimiento, teniendo en cuenta los cambios de prio-ridad que se presenta como uno de los principales retos.

Fig. 6. Retos asociados a Valores del Manifiesto Ágil.

5.2 Retos y beneficios identificados posterior a la observación

Información general de empresas y encuestados. El número de profesionales que respondieron la encuesta fue de 41. Las personas que respondieron trabajaban en varios cargos o roles dentro de las organizaciones bajo estudio. Los principales roles organizacionales de los encuestados fueron el de des-arrollador (n=16) y gerentes de proyectos (n=9). La Tabla 1 presenta los cargos y roles de los encuestados en las empresas.

En cuanto a los años de experiencia en el desarrollo de software, los participantes que respondieron tienen un promedio de 8.79 años de experiencia (La desviación estándar fue de 5.24; lo mínimo fue de 1 año y el máximo fue 25 años de experien-cia).

Adopción actual de Scrum y prácticas complementarias. (Respuesta a P3) Se resalta que dentro de las practicas con mayor nivel de adopción percibido están: la práctica de Reunión de Planeación (83,33%), seguido por la práctica de Entrega In-cremental (72,22%) y luego las técnicas: Iteraciones (66,6%) y TaskBoard (66,6%) que tienen igualmente un nivel de adopción alto percibido comparadas con otras técnicas.

Otro aspecto a resaltar son las practicas Scrum que tienen un bajo nivel de adop-ción percibido por los participantes, entre ellas: TimeBoxing (33,3%), las asociadas a



métricas como el BurnDown Chart (30,56%) y el uso del listado de impedimentos (27,78%).

Cargo o rol2 Porcentaje

Desarrollador 40% Gerente de proyectos 20% Arquitectos 17% Analistas de calidad o testers 8,8% Otros roles 22,2%

Tabla 1. Cargos y roles de participantes en la encuesta

Dentro de las prácticas que se perciben como no usadas están la Definición de Listo (25%) y la estimación por puntos (16,67%).

Las técnicas de Backlog grooming 22,2%, PlanningPoker y Estimación relativa ambas con un 19,44% no eran conocidas por las personas encuestadas. La figura 7, muestra las prácticas asociadas a Scrum y el nivel de adopción percibido por los parti-cipantes dentro de sus empresas.

Fig. 7. Nivel de adopción percibido en prácticas asociadas a Scrum.

Se realizaron preguntas para dar luz sobre el nivel de adopción percibido para las prácticas complementarias a Scrum. Se resalta que las prácticas complementarias con un nivel alto de adopción percibido son las siguientes: Control de versiones (77,78%), Interacción directa con el cliente (61,11%) e Integración continúa de código (47,22%).

Según los resultados del estudio, se encuentra también que las prácticas comple-mentarias con menor nivel de adopción percibido son las siguientes: XP (Programa-ción Extrema). Esta práctica no está siendo utilizada por un 36,11% de los encuesta-dos. TDD (Desarrollo guiado por pruebas), esta práctica no está siendo utilizada, por 25% de los encuestados. Programación en pares. Esta práctica no está siendo utiliza-

2 Dado que la misma persona podía estar con diferentes roles, los encuestados pudieron selec-

cionar múltiples opciones.



da, por un 22,22% de los encuestados. Asimismo esta práctica obtuvo el mayor por-centaje para la categoría No requerida, un 5,56%.

Cabe resaltar que a pesar de que algunas investigaciones muestran que la combina-ción de Scrum y XP, incluyendo prácticas como TDD y Pair Programming, resulta en equipos ágiles más efectivos [2]; se puede observar que en las empresas involucradas en el estudio, son estas las prácticas ágiles de ingeniería menos usadas.

Este resultado coincide con los conceptos y categorías identificados a través de GT en la primera parte del estudio, donde se identificaron como retos dentro de la cate-goría de prácticas complementarias los conceptos de TDD, Pair Programming y XP.

Beneficios percibidos por la implantación de Scrum. (Respuesta a P4) Los participantes perciben un aumento en la transparencia y confianza entre el equipo y el cliente y una reducción del sobreesfuerzo y la micro administración de los equi-pos. También se percibe un aumento en la agilidad para resolver problemas logrando mejorar la calidad del producto. Se percibe una planeación más participativa y una gestión de proyectos más simple y más humana donde el trabajo en equipo se valora más y el crecimiento y conocimien-to de las personas se incrementa de manera exponencial. Se perciben equipos más motivados y sincronizados con mayor orientación al logro.

5.3 Limitaciones

Aunque se usaron métodos de investigación bien establecidos, se examinaron hallaz-gos de investigaciones previas y se tenía familiaridad con la cultura organizacional de los participantes, una de las amenazas a la validez, relacionada con la credibilidad, es que los participantes del estudio no fueron seleccionados de manera aleatoria. Tam-bién es importante advertir que la autora del estudio tiene poco tiempo usando el método Grounded Theory, por tanto la calidad de la investigación puede estar in-fluenciada por sus habilidades y experiencia.

Se debe mencionar que los hallazgos y análisis de este estudio están basados en un número limitado de participantes y no se generalizan a una población mayor. Sin embargo el uso de GT y posteriormente de la encuesta permiten reducir el sesgo del investigador y asegurar que los datos son determinados por los participantes.

6 Conclusiones y trabajos futuros

A través del estudio se identificaron los retos y dudas generadas durante el inicio del proceso de adopción de Scrum en empresas que han adoptado CMMI. Si bien el obje-tivo principal era hacer transferencia del marco de trabajo Scrum, la principal pre-ocupación de los empleados de estas empresas se orientaba más hacia retos relaciona-dos con la integración de Scrum y las practicas ya definidas en su organización, lo cual permite deducir que en las empresas con alguna trayectoria, existe un fuerte tendencia de adopción de prácticas (ágiles u orientadas a planes) más allá de un mar-co particular. Se observó además que estas empresas no están dispuestas a perder el



esfuerzo y recursos invertidos en la valoración en referentes como CMMI, si no que, por el contrario, los equipos de ingeniería de procesos, realizan la redefinición de los procesos de la organización para que las prácticas de Scrum formen parte de la defini-ción estándar de procesos de su organización.

Este trabajo también proporciona algunas recomendaciones, beneficios y lecciones aprendidas que pueden ayudar a las organizaciones a evitar obstáculos en la adopción de Scrum dentro de sus prácticas de desarrollo de software integrándolas con prácticas orientadas a planes.

Debido a que este estudio no proporciona el alcance y los recursos para levantar esta teoría a un nivel más generalizado, este puede ser un tema para trabajos futuros dado que muchas teorías específicas pueden construir la base para una teoría más general. También se puede adelantar un estudio focalizado al conjunto de empresas del programa inicial de Ruta N sobre los impactos de la adopción a largo plazo en cuanto al tema de calidad, mantenibilidad de producto y satisfacción del cliente y del equipo, con el propósito de compararlos con los impactos de prácticas orientadas a planes. Reconocimientos

Damos nuestros agradecimientos a Ruta N y a todas aquellas empresas y equipos de trabajo que permitieron acompañarlos en el proceso de adopción de Scrum dentro de sus empresas

7 Referencias bibliográficas

1. Goede, R., De Villiers, C.: The Applicability of Grounded Theory as Research Methodol-ogy in studies on the use of Methodologies in IS Practices. (2003)

2. Kniberg, H., Farhang, R.: Bootstrapping Scrum and XP under crisis: A story from the trenches. Agile 2008 Conference, pp. 436-444. Toronto (2008)

3. CMMI para Desarrollo, Versión 1.3. CMU/SEI-2010-TR-033. Software Engineering Insti-tute, Carnegie Mellon University. (2010)

4. Pino, F.J., García, F., Piattini, M.: Revisión sistemática de mejora de procesos software en micro, pequeñas y medianas empresas. REICIS, Revista Española de Innovación, Calidad e Ingeniería del Software, Vol. 2, número 001, pp. 6-23. Madrid (2006)

5. Anaya, R., Gómez. L.: Lecciones Aprendidas en el Acompañamiento Masivo para Mejora de Procesos en Empresas de Software: Un Caso Colombiano. En: Memorias XV Congreso Iberoamericano de Ingeniería de Software CIBSE. Buenos Aires (2012)

6. Escobar-Sarmiento, V., Linares-Vásquez, M.: A Model for Measuring Agility in Small and Medium Software Development Enterprises .pp. 1-10. Informatica (CLEI), 2012 XXXVIII Conferencia Latinoamericana. Medellín (2012)

7. Senapathi, M., Srinivasan, A.: Sustained Agile Usage: A Systematic Literature Review EASE '13 Proceedings of the 17th International Conference on Evaluation and Assessment in Software Engineering. pp. 119-124. ACM New York, USA (2013)

8. Requisitos de postulación Programa para la transferencia de SCRUM – Ruta N. 2012, http://www.rutanmedellin.org/info/Paginas/invitacion_programa_piloto_Scrum.aspx.



9. CMMI. Published Appraisal Results, https://sas.cmmiinstitute.com/pars/pars.aspx/ (Visitado en 2013)

10. Hanakawa, N.: A process refactoring for software development with process complexity and activity priority lists. In: Proceedings of the Sixth International Conference on Soft-ware Process and Product Measurement. Nara (2011)

11. Ruiz-González, F.: MANTIS: Definición de un Entorno para la Gestión del Mantenimiento de Software. Tesis Doctoral. Universidad de Castilla-La Mancha, España (2003)

12. Boehm, B., Turner, R.: Observations on balancing discipline and agility. In: Proceedings of the Agile Development Conference, pp. 32-39. Salt Lake City. (2003)

13. Paulk, M.: Extreme Programming from a CMM Perspective. IEEE Software, (2001) 14. Oktaba, H., Piattini, M., García, F., Pino, F., Alquicira, C., y Ruiz, F.: Software Process

Improvement: The COMPETISOFT Project. In: IEEE Computer. Vol. 40, N.10. pp: 21-28. (2007)

15. Red Latinoamericana de la Industria del Software, http://relais.sic-learning.com/

16. Sutherland, J.: Inventing and Reinventing SCRUM in five Companies. http://cf.agilealliance.org/articles/system/article/file/888/file.pdf

17. Hoda, R., Noble, J., Marshall, S.: Self-Organizing Roles on Agile Software Development Teams. IEEE Transactions on Software Enginnering. Vol. 39, No 3 (2013)

18. Beck, K., et al.: Manifesto for Agile Software Development. 2001. http://agilemanifesto.org

19. Montoni, M. A., Rocha, A. R.: Applying Grounded Theory to Understand Software Process Improvement Implementation. 2010 Seventh International Conference on the Quality of Information and Communications Technology. IEEE. Porto (2010)

20. Oktaba, H.: MoProSoft: A Software Process Model for Small Enterprises. En: Proc. 1st Int’l Research Workshop for Process Improvement in Small Settings, special report CMU/SEI-2006-SR-001; Software Eng. Institute, pp. 93-101. (2006) www.sei.cmu.edu/pub/documents/06.reports/pdf/06sr001.pdf.

21. Travassos. G., Basili. V.: Experimental Software Engineering: an Introduction. 1st Expe-rimental Software Engineering Latin American Workshop. http://lens.cos.ufrj.br:8080/eselaw/papers/minitutorial.pdf

22. Weber, K. C., Rocha, A. R., Rouiller, A.C., Crespo, A., Alves, A., Ayala, A., Gonçalves A., Paret, B., Vargas, C., Salviano, C., Machado, C., Scalet, D., Petit, D., Araújo, E., Maldonado, J.C., Oliveira, K., Oliveira, L.C., Girão, M., Amaral, M., Campelo, R., y Ma-ciel, T.: Uma estratégia para melhoria de processo de software nas empresas brasileiras. En: Proceedings of QUATIC’2004 (5th International Conference for Quality in Informa-tion and Communications Technology) Portucalense University. Porto, Portugal (2004)

23. Overhage, S. Schlauderer, S.: Investigating the Long-Term Acceptance of Agile Metho-dologies: An Empirical Study of Developer Perceptions in Scrum Projects. 45th Hawaii In-ternational Conference on System Sciences, IEEE (2012)

24. Bustard, D., Wilkie, G., Greer, D.: The Maturation of Agile Software Development Prin-ciples and Practice: Observations on Successive Industrial Studies in 2010 and 2012. In: 20th IEEE International Conference and Workshops on Engineering of Computer Based Systems (ECBS). pp.139-146. (2013)

25. Marchenko, A., Abrahamsson, P.: Scrum in a Multiproject Environment: An Ethnographi-cally-Inspired Case Study on the Adoption Challenges. Agile 2008 Conference pp. 15-26, Toronto (2008)



caso de estudio sobre apropiación de scrum en...

Documents