See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/338019691

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

software

Conference Paper · April 2019

CITATIONS READS

2 2,115

3 authors:

Giovanni Hernandez Alvaro Alexander Martinez Navarro

Universidad Mariana Universidad Mariana
21 PUBLICATIONS   34 CITATIONS    14 PUBLICATIONS   48 CITATIONS   

SEE PROFILE SEE PROFILE

Robinson Andres Jimenez Toledo

Universidad Mariana
9 PUBLICATIONS   21 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Strengthening Competencies for Building Software, Through a Community of Practice View project

System engineer profile View project

All content following this page was uploaded by Giovanni Hernandez on 07 January 2020.

The user has requested enhancement of the downloaded file.

Revista Ibérica de Sistemas e Tecnologias de Informação Recebido/Submission: 29/11/2018
Iberian Journal of Information Systems and Technologies Aceitação/Acceptance: 15/01/2019

Scrum y Peopleware: elementos clave para la gestión

en la construcción de software

Giovanni Hernández1, Álvaro Martínez2, Robinson Jiménez3, Franklin Jiménez4

gihernandez@umariana.edu.co, amartinez@umariana.edu.co, amartinez@umariana.edu.co,

fjimenez@umariana.edu.co

1,2,3,4
Universidad Mariana, 520002, San Juan de Pasto, Colombia.
Pages:265–277

Resumen: Este trabajo presenta cómo se validó una propuesta de trabajo

adaptativa basada en Scrum y Peopleware, el estudio fue cuantitativo y descriptivo-
propositivo. 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.

Scrum and Peopleware: key elements for software development

management

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.

RISTI, N.º E19, 04/2019 265

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

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

266 RISTI, N.º E19, 04/2019

RISTI - Revista Ibérica de Sistemas e Tecnologias de Informação

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

RISTI, N.º E19, 04/2019 267

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

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.

268 RISTI, N.º E19, 04/2019

RISTI - Revista Ibérica de Sistemas e Tecnologias de Informação

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

RISTI, N.º E19, 04/2019 269

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

Figura 1 – Adopciones de la propuesta para la gestión de la construcción de software basada en

Scrum y Peopleware.

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.

270 RISTI, N.º E19, 04/2019

RISTI - Revista Ibérica de Sistemas e Tecnologias de Informação

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.

Equipo Horas trabajadas Historias de usuario implementadas Horas/Historia

1 172 31 5.55
2 81 20 4.05
3 131 27 4.86
4 154 12 12.84

Tabla 1 – Desempeños totales de los equipos en las cuatro adopciones

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.

RISTI, N.º E19, 04/2019 271

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

Figura 2 – Desempeño de los equipos colaboradores.

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.

Indicador Elemento Valoración de la propuesta validada

Juicio Valor
Indicador 1 Elemento 1
Elemento 2
…
Elemento m
Indicador 2
…
Indicador n

Tabla 2 – Asignación del juicio de valor

272 RISTI, N.º E19, 04/2019

RISTI - Revista Ibérica de Sistemas e Tecnologias de Informação

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.

Valor Total del Indicador Porcentaje del Valor Total del Indicador
Indicador
– Vti - %Vti
Indicador 1 Vti 1 %Vti 1
Indicador 2  Vti 2 %Vti 2
…  … …
Indicador n  Vti n %Vti n

Tabla 3 – Valoración del factor

Donde,

y 

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.

Indicador Porcentaje del Valor Total del Indicador - %Vti Juicio de Incidencia

Indicador 1 %Vti 1 (Favorable / Desfavorable)

Indicador 2 %Vti 2 (Favorable / Desfavorable)

… …

Tabla 4 – Matriz de favorabilidad

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.

RISTI, N.º E19, 04/2019 273

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

Valoración de la propuesta validada

Indicador Elemento
Juicio Valor
Etapa Sprint planning meeting A 4
Daily meeting A 4
Sprint review MA 5
Retrospectiva NANB 3
Rol Product Owner NANB 3
Scrum Master NANB 3
Development Team A 4
Herramienta Kunagi MA 5
Niko Agile A 4
Tomato Timer NANB 3
Lineamiento Burndown Chart NANB 3
Reporte de complejidad A 4
Técnica Kanban A 4
Pomodoro A 4
Niko Niko A 4
Mob programming A 4
Coding Dojo A 4
Desempeño Historias de usuario NANB 3
Tiempo NANB 3

Tabla 5 – Asignación del juicio de valor

Valor Total del Indicador Porcentaje del Valor Total del Indicador
Indicador
– Vti - %Vti

Etapa 16 80%

Herramienta 12 80%

Técnica 20 80%

Lineamiento 7 70%

Rol 10 66%

Desempeño 6 60%

Tabla 6 – Valoración del factor

274 RISTI, N.º E19, 04/2019

RISTI - Revista Ibérica de Sistemas e Tecnologias de Informação

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.

Porcentaje del Valor Total del

Indicador Juicio de Incidencia
Indicador - %Vti
Etapa 80% Favorable
Rol 66% Favorable
Herramienta 80% Favorable
Lineamiento 70% Favorable
Técnica 80% Favorable
Desempeño 60% Favorable

Tabla 7 – Matriz de favorabilidad

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.

RISTI, N.º E19, 04/2019 275

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

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.

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.

276 RISTI, N.º E19, 04/2019

RISTI - Revista Ibérica de Sistemas e Tecnologias de Informação

Procolombia.co. (2016). Software y Servicios de TI - Invierta en Colombia. Bogotá.

Recuperado de http://inviertaencolombia.com.co/sectores/servicios/software-y-
servicios-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.1016/j.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-12th-
annual-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

RISTI, N.º E19, 04/2019 277

 © 2019. This work is published under
https://creativecommons.org/licenses/by-nc-nd/4.0/(the
“License”). Notwithstanding the ProQuest Terms and
Conditions, you may use this content in accordance with the
terms of the License.

View publication stats