Scrum y Peopleware: elementos clave para la gestión en la construcción de software

Abstract

[...]it is evidenced that the adoption of Peopleware techniques in the management of motivation and knowledge in Scrum, it influences favorably. Los datos de las sumatorias totales de las dos variables analizadas para los cuatro equipos y adopciones presentados en la Tabla 1, revelan la complejidad que significa hacer software, porque cada integrante de un equipo de trabajo tiene conocimientos, aptitudes, actitudes y motivaciones diferentes; y al interactuar con otras personas muestran que no existe linealidad, un patrón o una regla que se pueda identificar en el desempeño diferente a lo evidente, es decir, el equipo 2 es el de mayor desempeño, el equipo 4 es el de menor desempeño y una medida de tendencia central, no proporciona información global del desempeño de los equipos. 3.4.Ventajas y desventajas de la propuesta basada en Scrum y Peopleware El análisis de los efectos a los cambios en la propuesta, se realizó desde la variable "elemento metodológico", a través de los indicadores: etapa, rol, herramienta, lineamiento, técnica y desempeño. Scrum practice mitigation of global software development coordination challenges: A distinctive advantage? Using Scrum in Global Software Development : A Systematic Literature Review.

Headnote

Resumen: Este trabajo presenta cómo se validó una propuesta de trabajo adaptativa basada en Scrum y Peopleware, el estudio fue cuantitativo y descriptivopropositivo. La población incluyó a las empresas de la Industria de Software del suroccidente colombiano. Se logró consolidar, junto con los directores de proyecto de las compañías, una propuesta para gestionar la construcción de software en relación con la motivación, conocimiento y trabajo en equipo. Los aportes de los colaboradores fueron la inclusión de la sensibilización y socialización del conocimiento para el equipo. En los aspectos a mejorar, se destacan el empoderamiento, motivación personal y el fortalecimiento de la comunicación grupal. Se recomienda omitir de la propuesta que se validó, elementos que sobrecarguen la adopción inicial de la forma de trabajo planteada. Finalmente, se evidenció que la adopción de técnicas de Peopleware en la gestión de la motivación y conocimiento en Scrum, logra una incidencia de favorabilidad.

Palabras-clave: Desarrollo de Software Ágil; Gestión del Desarrollo de Software; Peopleware; Scrum.

Abstract: This work presents how an adaptive work proposal based on Scrum and Peopleware is validated, the study was quantitative and descriptive-propositive. The population included companies from the Software Industry of southwestern Colombia. It was possible to consolidate together with the project managers of the companies, a proposal to manage the construction of software in relation to motivation, knowledge and teamwork. The contributions of the collaborators were the inclusion of awareness and socialization of knowledge for the team. In the aspects to be improved, empowerment, personal motivation and the strengthening of group communication stand out. It is recommended to omit from the proposal that is validated, elements that overload the initial adoption of the form of work proposed. Finally, it is evidenced that the adoption of Peopleware techniques in the management of motivation and knowledge in Scrum, it influences favorably.

Keywords: Agile Software Development; Peopleware; Scrum; Software Development Management.

1.Introducción

La Construcción de Software hace referencia a un proceso conformado por pasos ordenados para solucionar un problema u obtener un producto, específicamente un producto software, que se utilizará para resolver un problema planteado en cualquier área. Este proceso puede convertirse en algo complejo, ya que depende de diferentes características y alcance. En este sentido, contar con una metodología para la elaboración de programas, entendida ya sea como el conjunto de técnicas, procedimientos, métodos, herramientas y soporte documentado para el diseño y desarrollo, o como lo plantea Rojas Izaquita (2011), un camino definido que debe guiar el proceso de software y que cuenta con: a) las etapas y actividades, b) los roles de las personas que interactúan, c) los artefactos o entregables, d) las herramientas que soporten el proceso; y e) los lineamientos que posibiliten la toma de decisiones. Si la forma de trabajo resulta ser ágil, es decir se fundamenta en los 12 principios descritos en el Manifiesto por el Desarrollo Ágil de Software (Beck et al., 2011), el trabajo de fabricar software desafía a quienes lo hacen porque se requiere cambiar las condiciones de trabajo.

Dentro de las formas ágiles de desarrollar software, Scrum se está convirtiendo en la preferida por la comunidad de ingenieros de software (VersionOne.com, 2018) porque puede intervenir de manera adaptativa problemas complejos, a la vez que entrega productos con máximo valor posible de manera productiva y creativa. Además, se enfoca en agregar beneficio a los procesos de negocio de los clientes mediante la verificación continua, adaptación e innovación (Schwaber & Sutherland, 2017). En Scrum, el equipo de trabajo es fundamental para culminar con éxito cada proyecto, en este sentido en DeMarco & Lister (2013) se plantea cómo realizar la gestión de la complejidad de la labor en conjunto cuando se construye software, estableciendo estrategias para lograr equipos efectivos y eficientes (Kärpänoja, Mikkonen, Lehtonen, & Virtanen, 2016).

Las empresas de la Industria de Software, en cuanto a su operación o funcionamiento, han venido avanzando en los diferentes factores que intervienen al momento de construir software, aspecto relevante para determinar el éxito o fracaso de los proyectos. Chaos report es un informe que publica el Stadish Group, sobre el estado de la industria de desarrollo de software. Según este reporte, de 50 000 proyectos analizados en el mundo, para el 2017, un 33% finalizan con éxito, un 48% fueron catalogados como cuestionables, y un 19% fracasaron (Johnson, 2018). En el informe, se puede apreciar que, de 2013 a 2017, hubo una variación de 2 puntos porcentuales tendientes a la mejora, sin embargo, los proyectos que fracasan se mantienen.

En Colombia, la industria de software viene creciendo en tiempos cortos y ha logrado acumular experiencia, conocimiento y capacidades para la producción y prestación de servicios informáticos en diferentes sectores. Según el indicador de competitividad, citado por el Ministerio de Comercio, Industria y Turismo (Procolombia.co, 2016), entre el 2003 y el 2014 el mercado de software y TI en Colombia ha crecido cinco veces su tamaño; y cuenta con una infraestructura instalada capaz de soportar operaciones de talla mundial, este hecho manifiesta la necesidad de trabajar en el sector con métodos que den respuesta oportuna y de calidad a las exigencias de los clientes. En Tigre & Marques (2009), se precisa cómo las micro y pequeñas empresas dominan el sector económico de fabricación de software; un ejemplo concreto de esta tendencia se encuentra en el suroccidente colombiano que desde 2012 cuenta con más de 21 empresas, convirtiéndose en una fuente generadora de empleos directos (Hernández, Martínez, Argote, & Coral, 2015). Toda esta situación descrita manifiesta la necesidad de intervenir el sector con propuestas que permitan a las empresas modificar sus formas de trabajo para ser más competitivos en este mercado global de aplicaciones.

Otros autores, ya han indagado acerca del problema objeto de estudio, en Hernández et al. (2015), por ejemplo, se planteó de forma teórica una propuesta basada en Scrum para las empresas de la Industria de Software en una ciudad colombiana en particular. Este estudio, se construyó a partir de las características fundamentales de la forma de trabajo de las empresas, sin embargo, no se validó, ni tampoco se hizo un proceso de adopción por parte de las compañías colaboradoras. En Waardenburg & Vliet (2013) se reconocen problemas de comunicación, de definición del done y de manejo del cambio al implementar Scrum en empresas con un ambiente complejo de trabajo, donde se combinan métodos tradicionales con las ágiles, pero no se plantean soluciones que incluyan técnicas de Peopleware como si se formula en este trabajo.

Trabajos de revisión teórica acerca del tema en cuestión, también fueron consultados. En Stavru (2014), por ejemplo, se realiza un estudio documental acerca de la rigurosidad e integridad de trabajos documentales sobre el uso de métodos ágiles en la fabricación de software, como resultado se consideró únicamente a uno de los nueve estudios revisados, como trabajo científico y se dan recomendaciones para mejorar la calidad de este tipo de investigaciones. Factores desafiantes en el uso de Scrum en el ámbito del Desarrollo de Software Global fueron encontrados en Hossain, Babar & Paik (2009), particularmente aspectos que tienen que ver con la comunicación interna en los equipos y procesos de colaboración y coordinación; se plantean también algunas causas y consecuencias de dichos elementos, pero no se proponen soluciones al respecto desde las técnicas de Peopleware. La búsqueda sistemática en artículos hecha por Silveira y Silva (2015) mostraron aspectos investigativos como tipo de estudio, tipo de validación trabajada, métodos ágiles analizados y criterios para las metodologías a la medida detalladas. Las validaciones que se aplicaron en los textos examinados fueron cuestionarios y juicio de expertos; en este trabajo se anima a los interesados a formular propuestas de métodos ágiles a la medida basadas en la revisión de literatura hecha, mas no en un estudio de caso como se realiza en este artículo.

En cuanto a Scrum, se encontraron trabajos investigativos orientados a describir la experiencia de haber utilizado este método en la construcción de un producto software (Bannerman, Hossain, & Jeffery, 2012; May, Morales, Marrufo & Martín, 2013); estos estudios permitieron identificar aciertos y dificultades en la aplicación de los principios definidos en Scrum cuando se elabora software. En Martinez, Ramon & Bertone (2012), Colla (2012) y Vlaanderen, Brinkkemper, Jansen & Jaspers (2011) se analizan, por una parte, las consecuencias que tiene aplicar los principios de Scrum en casos reales, por otra se evalúan resultados de aplicar el modelo de mejora Competisoft junto con Scrum en un proyecto concreto. Si bien todas estas publicaciones profundizan en métodos para desarrollar software, no proponen alguna forma de adoptar Scrum, ni tampoco indagan cómo elementos de Peopleware pueden incluirse en él, para consolidar una nueva forma de trabajo para las empresas de un contexto dado.

Como pudo leerse anteriormente, los antecedentes consultados lograron mostrar una brecha investigativa en lo referente a la inclusión de técnicas de Peopleware. En este orden de ideas, el presente trabajo plantea como propósito principal validar la propuesta basada en Scrum (Hernández et al., 2015) y con base en los resultados, incluir técnicas de Peopleware.

Este artículo comienza con la descripción de la metodología, que explica la forma de llevar a cabo la investigación. Posteriormente, se muestran los resultados obtenidos y se hace una discusión acerca de algunas consideraciones y reflexiones frente a los hallazgos y finalmente se presentan las conclusiones.

2.Metodología

Para establecer el nivel de aplicabilidad que tiene la metodología propuesta en Hernández et al. (2015), se utilizó como método el proceso de investigación de estudios de caso en Ingeniería de Software (Runeson, Höst, Rainer, & Regnell, 2012) con las etapas: diseño, preparación, recolección, análisis y reporte. En la fase de diseño, se definió el propósito de la investigación y se planeó el estudio de caso. Las preguntas formuladas fueron: ¿Cuáles son las percepciones de los líderes de proyecto en relación con la propuesta basada en Scrum? ¿Qué elementos se pueden mejorar, incluir u omitir de la propuesta basada en Scrum? ¿Qué técnicas de Peopleware se pueden alinear con la propuesta basada en Scrum? ¿Cómo poner en marcha la propuesta basada en Scrum y Peopleware? ¿Cuáles son las ventajas y desventajas de la propuesta basada en Scrum y Peopleware? En la fase de preparación, se establecieron las técnicas para recopilar y analizar datos, se elaboraron los instrumentos y se los validó mediante juicio de experto. En la fase de recolección, a los directores de proyecto de las empresas de la Industria de Software en el suroccidente colombiano, se les socializó la propuesta y posteriormente, se aplicó una encuesta y se trabajó una entrevista semiestructurada con el objeto de corroborar y profundizar la información recolectada en la encuesta. En la fase de análisis, se utilizó: estadística descriptiva y análisis documental. Como resultado, se obtuvo una matriz con los aspectos a incluir, mejorar y omitir en la propuesta objeto de validación.

Para ajustar la propuesta estudiada, se tomó como fuente primaria de información, la matriz construida y los referentes teóricos de Peopleware, a partir de ellos, se realizó un análisis documental y se efectuaron transformaciones a la propuesta original. Paso seguido, se puso en funcionamiento la propuesta basada en Scrum y Peopleware, formulando un solo proyecto común, posibilitando la comparación de desempeño. Finalmente, en la fase de reporte de resultados, se sintetizaron y presentaron los hallazgos, a través de formas de visualización que propiciaron una mayor comprensión.

La razón fundamental para realizar el estudio de caso fue proponer un método a la medida basado en Scrum y técnicas de Peopleware para las empresas de la industria de software del suroccidente colombiano, que se basa en la propuesta teórica de Hernández et al. (2015). Para seleccionar las empresas que participaron en el estudio de caso, se realizó una invitación abierta, de las cuales decidieron colaborar ocho. Las unidades de análisis fueron los elementos metodológicos (fase, rol, artefacto, herramienta y lineamiento), y la relevancia que pueden tener estos elementos, al ser adoptados por los directores de proyecto de las empresas, en relación con la mejora, inclusión u omisión. Para el aseguramiento de la calidad, validación y confiabilidad de los instrumentos utilizados, se empleó la técnica juicio de expertos y antes de ser aplicados, se efectuó una prueba piloto.

3.Resultados

3.1. Validación de la propuesta basada en Scrum

Las percepciones sobre la aplicabilidad de la propuesta a validar (Hernández et al., 2015) se establecieron en colaboración con expertos en el tema, en particular fueron ocho directores de proyecto de las empresas SITI Solutions, X-net Computación, HashitoApps, Grama Group SAS, SAP en línea, Grupo Sinergia LTDA, Technosmart y Acarolabs SAS. La evaluación se realizó a la luz de los siguientes indicadores: mejora, inclusión y omisión de elementos de la propuesta de trabajo original basada en Scrum. Por mejora, se entiende aquellos elementos metodológicos (fase, rol, artefacto, herramienta y lineamiento) que son susceptibles de cambio o pueden progresar a partir de la condición o estado en el que se encuentran; inclusión se entiende como la introducción de un aspecto a los elementos metodológicos dentro de sus límites; y omisión, hace referencia a la eliminación de elementos del método que no agregan valor a la construcción de software.

Las repuestas de los colaboradores, en su mayoría (66,7%), sugirieron la inclusión de dos elementos, el primero hace referencia a estrategias que permitan el desarrollo del teletrabajo, haciendo uso de lineamientos y herramientas para propiciarlo; el segundo tiene que ver con habilidades de arquitecto de software como complemento al rol del product owner. En cuanto a los aspectos a mejorar, se encontraron: la sensibilización al equipo mediante un proceso de adaptación y capacitación para las empresas en las que se vaya a implementar la forma de trabajo y capacitarlo en el uso de buenas prácticas en la construcción de software; también, buscar estrategias para motivar de forma permanente a los integrantes del equipo. Además, los expertos consultados profundizan en establecer formas de potencializarlo desde lo personal y sugieren recolectar datos sobre los resultados de la implementación de la propuesta de trabajo basada en Scrum para conocer cuál ha sido el efecto o impacto que está generando en las empresas. Finalmente, como aspecto a omitir los participantes enfatizan en no hacer uso de herramientas software de cualquier tipo durante la etapa de aprendizaje e implantación de la propuesta de Hernández et al. (2015), con el fin de evitar sobrecarga en el contenido de la misma.

3.2. Ajustes a la propuesta basada en Scrum y alineación con Peopleware

A partir de las sugerencias hechas por los colaboradores del estudio, se realizaron ajustes a la propuesta original de trabajo. Inicialmente y con el objeto de superar la crisis generada por el cambio de método y minimizar las consecuencias de salir de la zona de confort por parte de los ingenieros de las empresas, se decidió diseñar un conjunto de cuatro adopciones incrementales, que pueden verse en la Figura 1.

En la primera adopción, se plantea incorporar el rol de product owner, quién será el encargado de recopilar las necesidades del cliente y plasmarlas a través de historias de usuario. Para apoyar esta actividad, se utiliza como herramienta de gestión Kunagi, que permite construir y compartir el product backlog. La adopción se realiza de manera iterativa e incremental (Sprint). En esta fase, se recomienda la definición de las tareas que se requieren para tomar una necesidad del product backlog y ponerla en funcionamiento a satisfacción del cliente (Done).

En una segunda adopción, se plantea incorporar el rol de Scrum master, encargado de ayudar a adoptar Scrum, liderar el equipo, propiciar la autogestión del grupo y sus integrantes, y ayudar a la resolución de conflictos. En esta etapa, se utilizó Kunagi para priorizar y seleccionar las historias de usuario del sprint, y para poder observar gráficamente el estado de las tareas, se apoyó con un tablero Kanban, que provee Kunagi.

La tercera adopción, plantea empoderar al equipo desarrollador en actividades de autogestión y multifuncionalidad. Dos técnicas de Peopleware se utilizaron en esta etapa, la primera Niko Niko, que permite a cada integrante registrar una valoración sobre el estado de ánimo, antes de iniciar una jornada de trabajo. La segunda Pomodoro, específicamente en la búsqueda de periodos de concentración. Además, como tarea del Scrum master, se recomienda fomentar la gestión disciplinada de las tareas del done en la herramienta Kunagi, y así visualizar gráficamente cuál es el estado del proyecto; esta acción, se logró mediante el burndown chart.

En la última adopción, se plantea continuar con el empoderamiento del equipo desarrollador y así consolidarlo como un grupo capaz de auto gestionarse y ser multifuncional. En esta fase, se utilizó la técnica Mob programming, que permitió al grupo trabajar sobre los aspectos complejos del proyecto. Para compartir el conocimiento y la experiencia lograda en el desarrollo de las tareas y fomentar la multifuncionalidad al interior de cada equipo, se propone incorporar la técnica Coding Dojo, que permite, a través de sesiones de trabajo donde participan el equipo de desarrollo, realizar una tarea compartida -del proyecto o una nueva temática por aprender- durante un periodo de tiempo, que al final se constituye en una red de conocimiento (K. Vlaanderen et al., 2011). Además, en esta etapa el Scrum master debe continuar fomentando la gestión disciplinada de las tareas del done en la herramienta Kunagi, y así poder visualizar de manera gráfica o en papel y en tiempo real la complejidad con la que se está trabajando.

3.3.Puesta en marcha de la propuesta basada en Scrum y Peopleware

Para la puesta en funcionamiento de la propuesta, se formuló un solo proyecto común para todos los equipos y así posibilitar la comparación del desempeño. Se conformaron cuatro equipos, dos de cinco integrantes, uno de cuatro y uno de seis. La distribución se realizó de manera libre, de esta forma se permitió a los equipos conformarse de acuerdo con los criterios o afinidades de manera autónoma. El único criterio definido fue el del tamaño no inferior a cuatro, ni mayor a nueve. Esta selección, estuvo alineada con McConnell (2006) donde se demuestra que, en equipos con más de nueve integrantes el esfuerzo se aumenta, pero el tiempo no se reduce; este hecho también es compartido y complementado en Schwaber & Sutherland (2017), al plantear que el tamaño ideal es de siete integrantes.

En la Tabla 1, se observa el desempeño de los cuatro grupos participantes, medido en cantidad de historias implementadas y horas trabajadas. En todas cuatro adopciones del método propuesto, la tendencia es la inversión de más tiempo en las adopciones 2 y 4, porque fue en estas fases donde se realizó la retrospectiva (Schwaber & Sutherland, 2017). El proceso de implementación de historias de usuario (Ver Fig. 2) indicó que los equipos 1 y 3 tuvieron mejor desempeño que los otros. También puede apreciarse el bajo desempeño del equipo 4 en todas las adopciones; además puede notarse que las adopciones donde se culminaron muchas más historias de usuario fueron la 1 y 2, es decir, cuando se incorpora los roles product owner y Scrum master, se utiliza Kunagi, se define el done y se trabaja con un tablero Kanban para visualizar la cantidad de trabajo en progreso.

En la Figura 2, se observa que al contrastar los dos valores de desempeño -horas trabajadas vs historias de usuario hechas- se corroboran los puntajes más bajos en el equipo 4 (color verde), que requiere mucho más tiempo para cumplir su labor; mientras que para los equipos 2 y 3 (azul y rojo respectivamente) los datos son favorables, en la medida en que requieren menos tiempo para implementar cada historia de usuario.

Los datos de las sumatorias totales de las dos variables analizadas para los cuatro equipos y adopciones presentados en la Tabla 1, revelan la complejidad que significa hacer software, porque cada integrante de un equipo de trabajo tiene conocimientos, aptitudes, actitudes y motivaciones diferentes; y al interactuar con otras personas muestran que no existe linealidad, un patrón o una regla que se pueda identificar en el desempeño diferente a lo evidente, es decir, el equipo 2 es el de mayor desempeño, el equipo 4 es el de menor desempeño y una medida de tendencia central, no proporciona información global del desempeño de los equipos.

3.4.Ventajas y desventajas de la propuesta basada en Scrum y Peopleware

El análisis de los efectos a los cambios en la propuesta, se realizó desde la variable "elemento metodológico", a través de los indicadores: etapa, rol, herramienta, lineamiento, técnica y desempeño. El proceso llevado a cabo incluyó la creación de un clasificador de incidencia, para identificar ventajas y desventajas en los cambios realizados a la propuesta.

Respecto al clasificador de incidencia, el procedimiento matemático que permitió clasificar en ventajas y desventajas los elementos metodológicos, inicia con la definición del nivel de valoración, que se sustenta en una escala Likert con los juicios de incidencia: muy bajo (MB), bajo (B), ni alto-ni bajo (NA, NB), alto (A) y muy alto (MA). A cada juicio le corresponde un valor que va desde 1 para MB hasta 5 para MA.

Posteriormente, por cada indicador, se debe establecer el juicio de valor (ver Tabla 2) de la forma como se validó y desarrolló la propuesta modificada.

Dónde n, es el total de indicadores que se han tenido en cuenta para la validación de la propuesta; y m es el número total de elementos que hacen parte del indicador.

Posteriormente, se realiza la sumatoria de los valores para cada indicador y se calcula el porcentaje que representa en relación con el máximo valor posible. Estos valores se registran en la Tabla 3.

Donde,

(ProQuest: ... denotes formula omitted.)

Una vez se finalizado el cálculo del porcentaje del valor total del indicador -%Vti - se procede a definir los rangos para establecer el juicio de incidencia de los indicadores. Las dos categorías establecidas son: favorable y desfavorable. Favorable es el indicador, que cumple con el objetivo para lo cual fue incluido. Desfavorable es el indicador, que es adverso o aún no cumple con las expectativas para las que fue incorporado.

Finalmente, se procede a asignar el juicio de incidencia, como se presenta en la Tabla 4, para el porcentaje del valor total del indicador - %Vti.

Aplicación del clasificador. La primera actividad realizada fue, la asignación del juicio de valor para cada indicador y elemento de la propuesta como se observa en la Tabla 5.

Posteriormente, se realizó la sumatoria de los valores para cada indicador y se calculó el porcentaje que representa del máximo valor que se puede obtener para el indicador. Estos valores se pueden observar en la Tabla 6.

Se procedió luego a definir los rangos para establecer el juicio de incidencia. Un rango mayor o igual a 60% tendrá un juicio de incidencia favorable, en caso contrario será desfavorable. Finalmente, se asignó el juicio de incidencia, como se presenta en la Tabla 7.

Todos los indicadores estudiados, clasificaron en la categoría de favorabilidad. Este resultado permitió evidenciar la posibilidad de realizar aportes a la propuesta basada en Scrum (Hernández et al., 2015), desde la perspectiva de los expertos o interesados, logrando dar respuesta a los interrogantes que se plantearon desde el enfoque teórico de Peopleware, para lograr equipos productivos como también se evidencia en Kärpänoja et al. (2016) cuando se trata de procesos de entrega continua. De igual forma, de manera consiente, los líderes de proyecto colaboradores, en la propuesta validada encontraron respuesta a los problemas que involucran la complejidad de hacer software, bajo una serie de condiciones específicas como: tiempo, costo, necesidades y valor agregado.

4.Conclusiones

Uno de los aspectos de mayor preocupación, en la adopción de la propuesta creada en Hernández et al. (2015) por parte de los directores de proyecto colaboradores, fue la crisis que generó el cambio en la forma de trabajar y las consecuencias que trajo salir del estado de confort en el que se encontraban los ingenieros de las empresas al adoptarla. En ese sentido, y con el objeto de superar las dificultades mencionadas, se propuso un conjunto de adopciones incrementales para incorporar los elementos que plantea la nueva propuesta.

La propuesta basada en Scrum original, fue transformada a partir de las recomendaciones hechas por los líderes de proyecto que participaron en el estudio, específicamente, se incluyeron técnicas de Peopleware, y se omitieron contenidos y actividades que sobrecargan el trabajo en equipo.

El clasificador de incidencia creado en este trabajo, permitió establecer una manera de medición cuantitativa al momento de identificar ventajas y desventajas en la aplicación de la propuesta basada en Scrum y Peopleware.

El estudio de caso trabajado en esta investigación, se realizó con 8 de las 15 empresas invitadas, no obstante, se debe buscar mecanismos para vincular a la mayoría, porque los aportes que realicen los directores de proyecto serán relevantes hacia un futuro uso y adopción del método.

References

Referencias

Bannerman, P. L., Hossain, E., & Jeffery, R. (2012). Scrum practice mitigation of global software development coordination challenges: A distinctive advantage? Proceedings of the Annual Hawaii International Conference on System Sciences, 5309-5318. DOI: 10.1109/HICSS.2012.512

Beck, K., Beedle, M., Bennekum, A. van, Cockburn, A., Cunningham, W., Fowler, M., ... Thomas, D. (2011). Manifiesto por el Desarrollo Ágil de Software. Recuperado de http://agilemanifesto.org/iso/es/manifesto.html

Colla, P. (2012). Marco para evaluar el valor en metodología Scrum. 13th Argentine Symposium on Software Engineering, ASSE 2012, 32-46.

DeMarco, T., & Lister, T. (2013). Peopleware. Productive Projects and Teams (3rd ed.). Boston: Addison-Wesley.

Hernández, G., Martínez, Á., Argote, I., & Coral, D. (2015). Metodología adaptativa basada en Scrum : Caso empresas de la Industria de Software en San Juan de Pasto - Colombia. Revista Tecnológica ESPOL, 28(5), 211-223. Recuperado de http://www.rte.espol.edu.ec/index.php/tecnologica/article/view/435

Hossain, E., Babar, M. A., & Paik, H. (2009). Using Scrum in Global Software Development : A Systematic Literature Review. Fourth IEEE International Conference on Global Software Engineering Using, 175-184. DOI: 10.1109/ ICGSE.2009.25

Johnson, J. (2018). CHAOS Report: Decision Latency Theory: It Is All About the Interval. Boston: Lulu.com, 2018.

Kärpänoja, P., Mikkonen, T., Lehtonen, T., & Virtanen, A. (2016). Exploring Peopleware in Continuous Delivery. In XP '16 Workshops. Edinburgh: ACM.

Martinez, N., Ramon, H., & Bertone, R. (2012). Aplicabilidad de Competisoft a partir de un método ágil como Scrum. Un caso práctico. XVIII Congreso Argentino de Ciencias de La Computación, 1-11. Recuperado de http://sedici.unlp.edu.ar/ bitstream/handle/10915/23722/Documento_completo.pdf?sequence=1

May, M., Morales, Y., Marrufo, J., & Martín, M. (2013). Ciencias de la Ingeniería y Tecnología. Handbook T-II. Congreso Interdisciplinario de Cuerpos Académicos. In M. Ramos & V. Aguilera (Eds.) (pp. 176-190). México: ECORFAN.

McConnell, S. (2006). Software Estimation. Demystifying the Black art (1st ed.). Washington: Microsoft Press.

Procolombia.co. (2016). Software y Servicios de TI - Invierta en Colombia. Bogotá. Recuperado de http://inviertaencolombia.com.co/sectores/servicios/software-yservicios-de-ti.html

Rojas Izaquita, M. E. (2011). Agilizando lo ágil: un framework para la desarrollo de software bajo el modelo CMMI en compañías que usan metodologías ágiles de desarrollo de software usando el modelo acelerado de implementación (AIM). Universidad Nacional de Colombia. Recuperado de http://www.bdigital.unal.edu. co/8889/

Runeson, P., Höst, M., Rainer, A., & Regnell, B. (2012). Case study research in softare engineering - Guidelines and Examples. New Jersey: JohnWiley & Sons, Inc.

Schwaber, K., & Sutherland, J. (2017). La Guía de Scrum (Vol. 1). Recuperado de http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US. pdf#zoom=100

Silveira Campanelli, A., & Silva Parreiras, F. (2015). Agile methods tailoring - A systematic literature review. The Journal of Systems & Software, 110, 85-100. DOI: 10.1016/j.jss.2015.08.035

Stavru, S. (2014). A Critical Examination of Recent Industrial Surveys on Agile Method Usage. The Journal of Systems & Software. DOI: 10.1016Zj.jss.2014.03.041

Tigre, P., & Marques, F. (2009). Aspectos eonómicos del software y consecuencias. In Desafíos y oportunidades del software en América Latina (1st ed., pp. 1-20). Bogotá: Mayol Editores S.A. Recuperado de http://repositorio.cepal.org/bitstream/ handle/11362/1990/S33826D4412009_es.pdf?sequence=1

VersionOne.com. (2018). The 12th anual state of Agile report. Atlanta - USA. Recuperado de file:///D:/Clases/Clases II 2018/Artículos/CibSE 2019/7-versionone-12thannual-state-of-agile-report.pdf

Vlaanderen, K., Brinkkemper, S., Jansen, S., & Jaspers, E. (2011). The agile requirements refinery: Applying SCRUM principles to software product management. Information and Software Technology, 53(1), 58-70. DOI: 10.1016/j.infsof.2010.08.004

Waardenburg, G. Van, & Vliet, H. Van. (2013). When agile meets the enterprise. Information and Software Technology, 55(12), 2154-2171. DOI: 10.1016/j. infsof.2013.07.012