Embed Size (px)
Citation preview
1
UNIVERSIDAD DISTRITAL
FRANCISCO JOSÉ DE CALDAS
PROYECTO DE GRADO
ESPECIALIZACIÓN EN PROYECTOS INFORMÁTICOS
MODELO DE TRANSICIÓN DE METODOLOGÍA RUP A SCRUM EN PROYECTOS
DE DESARROLLO DE SOFTWARE
Autores:
MIREYA STELLA MÉNDEZ RAMOS
DIANA PATRICIA CASTRILLÓN ARBOLEDA
JONATHAN PRECIADO GARCIA
Director
SANDRO JAVIER BOLAÑOS CASTRO
BOGOTA 2017
2
Resumen
Las áreas de desarrollo de software de las empresas no están teniendo en cuenta impactos tales
como recursos humanos y económicos, cambio en los procesos actuales y tiempo de ejecución
del proyecto durante la implementación de metodologías ágiles, por lo cual se hace necesario
diseñar un modelo para la transición de metodologías SCRUM que permita a dichas áreas mitigar
los posibles riesgos durante el proceso de transición.
El trabajo se desarrollará por etapas, en donde inicialmente se realiza consulta y documentación
sobre metodologías por medio de métodos investigativos, entrevistas, encuestas, análisis de
metodologías tradicionales (MSF-RUP) y de metodologías ágiles (SCRUM).
Con la investigación se busca diseñar un modelo de apoyo en la transición de las metodologías
teniendo en cuenta todos los aspectos relevantes durante este proceso, con el cual sea posible
aplicar un esquema que permita integrar fácilmente los dos tipos de metodología durante la
ejecución de los diferentes proyectos de la organización.
Palabras clave
Diseño, modelo, metodología tradicional, metodología Ágil, transición, SCRUM, áreas de
desarrollo de Software, proyectos.
3
Abstract
The software development areas of companies aren't taking into account impacts as human and
economic resources, changes in current processes and project execution time during the
implementation of agile methodologies, It makes necessary to design a model for the transition of
SCRUM methodologies that allow those areas to mitigate the possible risks during the transition
process.
The work will be developed in stages, starting with the consultation and documentation on
methodologies through investigative methods, interviews, surveys, analysis of traditional
methodologies (MSF-RUP) and agile methodologies (SCRUM).
With this investigation we look for to design a model of support in the transition of
methodologies given all relevant aspects during this process, with which it is possible to apply a
scheme that allows to easily integrate the two types of methodology during the execution of the
different projects of the organization.
Keywords
Design, model, traditional methodology, agile methodology, transition, SCRUM, software
development areas, projects.
4
Agradecimientos
Dedico este proyecto de tesis a Dios, a mi familia y a la universidad. A Dios porque está conmigo
en todo momento y me fortalece para continuar, a mi familia, quienes a lo largo de mi vida han
sido mi apoyo para crecer profesionalmente y superar todos los obstáculos que se presentan en mi
camino y a la universidad por haberme permitido formarme en tan respetable institución.
Mireya Stella Méndez Ramos
Agradezco a Dios por darnos la vida y hacer posible la realización de este trabajo; por enseñarnos
lo maravilloso que es la vida, el que en todo momento esta con migo ayudándome a aprender de
mis errores, el que me acompaña y siempre me levanta. Agradezco a mis compañeros y a la
Universidad por su acogida y permitirnos el logro de esta especialización.
Diana Patricia Castrillón Arboleda
Este proyecto está dedicado a la comunidad estudiantil de la universidad distrital Francisco José
de Caldas, en especial a los docentes quienes fueron guía y nos dieron las bases para el desarrollo
del mismo. Agradezco a mis compañeras con quienes a lo largo del desarrollo del proyecto
logramos hacer un equipo y resolver bajo acuerdos y negociaciones la diferencia de opiniones
respecto a temas particulares.
Jonathan Preciado García
5
Tabla de contenidos
1 Introducción 11
2 Capítulo 1. Descripción de la investigación 12
2.1 Identificación del problema 12
2.1.1 Formulación de la pregunta de investigación 13
2.1.2 Sistematización del problema 13
2.2 Objetivos 13
2.2.1 Objetivo General 13
2.2.2 Objetivos específicos 14
2.3 Justificación 14
2.4 Hipótesis 15
2.5 Marco referencial 15
2.5.1 Marco Teórico 16
2.5.1.1 Rational Unified Process (RUP) 16
2.5.1.2 Microsoft Solutions Framework (MSF) 19
2.5.1.3 Metodología SCRUM 24
2.5.1.4 MetaProceso 29
2.5.1.5 SCRUM vs Gestión tradicional de Proyectos 30
2.5.2 Marco conceptual 33
2.6 Metodología 36
2.7 Limitaciones y alcance 37
2.8 Impacto y productos esperados 38
3 Capítulo 2. Descripción de metodología RUP y SCRUM 39
3.1 Transición de metodología RUP a SCRUM 39
3.2 Aspectos de la metodología SCRUM 42
3.3 Matriz DOFA para transición de RUP a SCRUM 45
3.4 Procesos y metodologías 51
4 Capítulo 3. Descripción de la solución 53
4.1 Principales problemas en gestión de proyectos 53
6
4.2 Beneficios de SCRUM 55
4.3 Modelo de transición de metodología RUP a SCRUM 58
5 Capítulo 4 Comprobación del modelo de transición de metodología RUP a SCRUM 68
5.1 Encuestas 68
5.1.1 Análisis de Costos. 69
5.1.2 Eficiencia 69
5.1.3 Gestión. 70
5.1.4 Procesos internos 70
5.1.5 Capacitación 71
5.1.6 Proyecto Piloto 72
5.1.7 Autonomía 72
6 Conclusiones 74
7 Bibliografía y referencias bibliográficas 76
8 ANEXOS 79
7
Tabla de Figuras
Figura 1. Dependencias entre Modelos. Recuperado de (Amo,2015) ........................................... 18
Figura 2. Ciclo de metodología SCRUM. Recuperado de http://www.martarepupilli.com.ar/ .... 26
Figura 3. Métodos agiles y SCRUM. Recuperado de http://projectmanager.soy/?cat=14 ............ 28
Figura 4. Metamodelo RUP - SCRUM como Estrategia. Adaptado de (Bolaños Castro, Medina
García, & Ferro Escobar, abril de 2016) ........................................................................................ 52
Figura 5. Modelo de transición de metodología RUP a SCRUM ¡Error! Marcador no definido.
Figura 6. Personas encuestadas por empresa ................................................................................. 68
Figura 7. Análisis de Costos con dedicación exclusiva de un experto .......................................... 69
Figura 8. SCRUM aumenta la eficiencia en el desarrollo de proyectos tecnológicos ................... 70
Figura 9. SCRUM cuenta con mecanismos y estrategias .............................................................. 70
Figura 10. SCRUM permite cumplir con los procesos de la organización ................................... 71
Figura 11. Capacitación de metodología ....................................................................................... 71
Figura 12. Proyecto Piloto ............................................................................................................. 72
Figura 13. Autonomía en SCRUM ................................................................................................ 73
8
Índice de tablas
Tabla 1 Diferencias entre Modelos SCRUM vs Gestión tradicional de Proyectos ....................... 32
Tabla 2 Diferencias entre metodología RUP y SCRUM ............................................................... 40
Tabla 3 Beneficios de SCRUM y Cómo se consiguen .................................................................. 56
9
Índice de anexos
Anexo A. Encuesta de Investigación de Transición de RUP a SCRUM. .............................................. 79
10
Tabla de Figuras de anexos
Gráfica 1. Análisis de Costos con dedicación exclusiva de un experto ......................................... 79
Gráfica 2. SCRUM aumenta la eficiencia en el desarrollo de proyectos tecnológicos ................. 80
Gráfica 3. SCRUM tiene mecanismos y estrategias ...................................................................... 80
Gráfica 4. SCRUM permite cumplir con los procesos de la organización .................................... 81
Gráfica 5. Capacitación de metodología ........................................................................................ 82
Gráfica 6. Proyecto Piloto .............................................................................................................. 82
Gráfica 7. Autonomía en SCRUM ................................................................................................. 83
11
1 Introducción
Muchas empresas hoy en día utilizan metodologías tradicionales que en la mayoría de los casos
no cumplen con las expectativas esperadas. Lo anterior conlleva a la búsqueda de mejorar el
Time to market de sus proyectos de desarrollo, mediante la implementación de nuevas
metodologías sin analizar el impacto que puede generar la transición de una metodología a otra.
La implementación de nuevas metodologías se ha convertido en un reto para las organizaciones
teniendo en cuenta que cada una de ellas tiene sus ventajas y desventajas, lo que genera altos
niveles de hostilidad al cambio por parte de los equipos de trabajo lo cual se convierte en una
falencia a la hora de realizar una transición de una metodología a otra.
Con el presente trabajo se busca que las áreas de desarrollo de Software puedan usar tanto
metodologías tradicionales como ágiles teniendo en consideración todos los puntos relevantes de
la convivencia de dos metodologías, así como la transición al marco de trabajo SCRUM, esto con
el fin de conseguir un mejor desempeño durante la ejecución de los proyectos de desarrollo.
12
PARTE I FUNDAMENTACIÓN DE LA INVESTIGACIÓN
2 Capítulo 1. Descripción de la investigación
A continuación, se detalla el estudio del problema de investigación de este proyecto.
2.1 Identificación del problema
Actualmente en las empresas se presenta una tendencia al uso de marcos de trabajo ágil como
SCRUM, lo cual causa impactos en los procesos de la compañía debido a que la implementación
de la nueva metodología es un proceso de transición evolutivo que según la madurez de la
empresa puede ser implementado en un corto periodo de tiempo o durar varios meses y en
algunos casos hasta años.
De acuerdo con lo anterior se identifica que esto lleva a la necesidad que en un periodo
determinado de tiempo la organización se vea obligada a tener simultáneamente en ejecución
proyectos de desarrollo de software que hacen uso de las dos metodologías utilizadas por la
compañía.
Con esto se busca que las empresas cuentan con información relevante para ejecutar el proceso de
transición utilizando un modelo que les permita migrar a la nueva metodología minimizar el
impacto en su operación.
13
2.1.1 Formulación de la pregunta de investigación
El planteamiento del problema nos permite identificar la siguiente pregunta de investigación:
¿Cómo realizar el proceso de transición de metodologías tradicionales a metodología SCRUM en
el desarrollo de software?
2.1.2 Sistematización del problema
¿Cómo minimizar el impacto de transición de metodologías tradicionales a metodología SCRUM
en el desarrollo de software?
2.2 Objetivos
A continuación, se describen el objetivo general y los objetivos específicos del proyecto:
2.2.1 Objetivo General
Diseñar un modelo de transición de metodología tradicional RUP a la metodología SCRUM en el
desarrollo de software, mitigando los riesgos, optimizando los tiempos de entrega y los recursos
asignados a los proyectos.
14
2.2.2 Objetivos específicos
➢ Proponer un esquema con las mejores prácticas en el desarrollo de proyectos de Software
para transición entre metodologías.
➢ Identificar los aspectos relevantes que se deben tener en cuenta en la implementación de
la metodología SCRUM cuando se tienen proyectos en ejecución en metodología
tradicional.
➢ Determinar los aportes de la metodología SCRUM dentro del ciclo de vida de los
proyectos de desarrollo de software
➢ Identificar los principales problemas en la gestión de proyectos basados en las
metodologías tradicionales.
➢ Identificar las fortalezas y debilidades entre las metodologías tradicionales y SCRUM.
➢ Conformar el modelo de transición de metodologías tradicionales a metodología SCRUM.
2.3 Justificación
Esta investigación pretende identificar si existe una relación complementaria o excluyente de las
metodologías tradicionales y SCRUM, determinando los efectos del uso de metodología SCRUM
en la optimización del Time to market de los proyectos de desarrollo de software.
La importancia de este modelo plantea describir cómo las áreas de desarrollo de software no
están teniendo en cuenta los impactos generados por el cambio en los procesos durante la
implementación de una nueva metodología. Por lo cual se hace necesario diseñar un modelo para
15
la transición a metodología SCRUM que permita a dichas áreas mitigar los posibles impactos en
cada proyecto como, por ejemplo: recursos físicos, recursos humanos, arquitectura(s),
tecnología(s) y actividades durante su ejecución.
2.4 Hipótesis
Actualmente muchas de las áreas de desarrollo están implementando el uso de metodologías
ágiles como SCRUM para sus proyectos de desarrollo de software y esto necesariamente genera
un proceso de transición de la metodología actualmente usada a la nueva metodología, lo cual
pueden generar impactos en el área y en la ejecución de los proyectos.
De acuerdo con lo anterior se plantea la siguiente hipótesis:
Un modelo de transición de metodologías tradicionales a metodología SCRUM, mitiga los
riesgos que se generan durante la implementación de una nueva metodología de desarrollo de
software, logrando un mejor aprovechamiento de los recursos asignados.
2.5 Marco referencial
El uso de metodologías en las áreas de desarrollo se enfoca en hacer más eficaz la producción y
lograr un resultado óptimo.
16
2.5.1 Marco Teórico
A continuación, se describe una reseña de los puntos más relevantes de esta investigación como
es la definición y características de las metodologías tradicionales y agiles que hacen parte del
marco teórico:
2.5.1.1 Rational Unified Process (RUP)
RUP es una metodología que tiene como objetivo ordenar y estructurar el desarrollo de software,
en la cual se tiene un conjunto de actividades necesarias para transformar los requisitos del
usuario en un sistema de Software.
Características
El RUP es un proceso basado en los modelos en Cascada y por Componentes, el cual presenta las
siguientes características: Es dirigido por los casos de uso, es centrado en la arquitectura e
iterativo, lo cual es fundamental para el proceso de desarrollo de software:
Casos de Uso: Describe un servicio que el usuario requiere del sistema, incluye la secuencia
completa de interacciones entre el usuario y el sistema.
Centrado en la arquitectura: Comprende las diferentes vistas del sistema en desarrollo, que
corresponden a los modelos del sistema: Modelos de casos de uso, de análisis, de diseño, de
17
despliegue e implementación, sirve para organizar el desarrollo, fomentar la reutilización de
componentes y hacer evolucionar el sistema, es decir, agregar más funcionalidad.
Iterativo e Incremental: Significa que la aplicación se divide en pequeños proyectos, los
cuales incorporan una parte de las especificaciones, y el desarrollo de la misma es una
iteración que va incrementando la funcionalidad del sistema de manera progresiva, de tal
forma que los requisitos y demás modelos no se desarrollan en una sola iteración sino
progresivamente, ello con la finalidad de poder garantizar entregas funcionales e iterativas y
de tal forma ir completando el sistema software paso a paso. Booch, G.; Jacobson, I. &
Rumbaugh, J.(2006),
La vida del Proceso Unificado
El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un
sistema, Cada ciclo concluye con una versión del producto para los clientes.
Cada ciclo produce una nueva versión del sistema y cada versión es un producto preparado para
su entrega. Consta de un cuerpo de código fuente incluido en componentes que puede compilarse
y ejecutarse, además de manuales y otros productos asociados.
Para llevar el ciclo de manera eficiente, los desarrolladores necesitan todas las representaciones
del producto como se muestra en la Figura 2.5.1.
18
Figura 1. Dependencias entre Modelos. Recuperado de (Amo,2015)
Modelos:
Un modelo de casos de uso: con todos los casos de uso y su relación con los usuarios.
Un modelo de análisis: Con dos propósitos, primero refinarlos casos de uso con más
detalle y segundo establecer la asignación inicial de funcionalidad del sistema a un
conjunto de objetos que proporcionan el comportamiento.
Un modelo de diseño: Define la estructura estática del sistema en la forma de subsistemas,
clases e interfaces y los casos de uso reflejados como colaboraciones.
Un modelo de implementación: Incluye componentes y la correspondencia de las clases
con los componentes.
Un modelo de despliegue define los nodos físicos y la correspondencia de los
componentes con esos nodos.
Un modelo de prueba, que describe los casos de prueba que verifican los casos de uso.
EI sistema también debe tener un modelo del dominio o modelo del negocio que describa
el contexto del negocio en el que se halla el sistema.
19
Todos estos modelos están relacionados. Juntos, representan al sistema como un todo. Los
elementos de un modelo poseen dependencias de traza hacia atrás y hacia adelante. Booch, G.;
Jacobson, I. & Rumbaugh, J.(2006),
2.5.1.2 Microsoft Solutions Framework (MSF)
MSF es una guía de desarrollo de software, es escalable pues está diseñada para poder expandirse
según la magnitud del proyecto. La metodología MSF está basada en una serie de conceptos,
directrices y prácticas de uso que aseguran los resultados y la calidad (Gattaca S. A.)
Características
Componentes que representan años de experiencia. Se encuentran en conceptos que son válidos
en los distintos modelos, procesos y disciplinas de MSF, estos principios y mentalidades son la
base de MSF.
Principios: Los principios están enfatizados hacia la entrega de una solución de calidad, en los
cuales se encuentran 9 principios fundamentales.
Fomentar las comunicaciones abiertas: su mayor objetivo es compartir niveles adecuados
de información entre los miembros del equipo y en toda la empresa.
Trabajar hacia una visión compartida: Permite agilidad y ayuda a los miembros del equipo
20
a llenar las brechas de requisitos a medida que se descubren.
Capacitar a los miembros del equipo: Los equipos aprenden a encontrar formas creativas
para tener éxito y para ayudarse mutuamente.
Establecer una clara responsabilidad y responsabilidad compartida: Cuando los miembros
del equipo tienen más responsabilidades esto conduce a una mayor calidad.
Entrega valor incremental: Primero asegúrese de que lo que se entrega tiene un valor
óptimo para las partes interesadas y segundo determine los incrementos óptimos en los
que genera valor agregado.
Manténgase ágil: tener una forma ágil de manejar el cambio ayuda a minimizar los
riesgos causados por el cambio.
Invertir en calidad: La calidad debe ser incorporado en el ciclo de vida del proyecto.
Aprende de todas las experiencias: Se debe aprovechar lo aprendido en proyectos
anteriores esto permite refinar un proceso y crear métricas de calidad.
Asociarse con clientes internos y externos: Cuando los clientes trabajan estrechamente y
de manera incremental con un equipo de entrega, la solución lograda satisface mejor sus
expectativas
Mentalidad: Está orientada en la solución particular dando una mejor comodidad que permite
maximizar el éxito al equipo de trabajo, existen alguna Mentalidades que cada miembro del
equipo debe tener en cuenta:
Fomentar un equipo de compañeros. Propone que la responsabilidad sea compartida para
una entrega exitosa de una solución.
Concéntrese en el valor del negocio. El equipo completo debe conocer lo que el cliente
21
considera valioso.
Mantenga una perspectiva de la solución: los miembros del equipo deben tener una
perspectiva amplia y no en los detalles.
Orgullo de la mano de obra: la calidad es responsabilidad de todos a lo largo del ciclo de
vida del proyecto.
Aprende continuamente: Los miembros del equipo necesitan capacitaciones constantes
que permitan adquirir nuevas habilidades.
Internalizar cualidades de servicio: Las cualidades de servicio definen las características
operativas esperadas de una solución, como el nivel de disponibilidad esperada de la
solución.
Practicar la buena ciudadanía. La buena relación entre los integrantes del equipo de
trabajo garantiza aporta al éxito del proyecto.
Cumpla con sus compromisos: El cumplimiento de una actividad por parte de un
miembro del equipo pone en peligro todo el proyecto
Modelos
El modelo del equipo de MSF entrega de soluciones y responsabilidades en siete grupos que son
interdependientes y multidisciplinarios estos roles ofrecen una perspectiva única sobre lo que se
necesita.
Este modelo se encarga de organizar las personas para que realicen el trabajo y se asegura que las
metas del proyecto se cumplan. Define los principios, los roles y las actividades involucrando al
equipo en todas las decisiones fundamentales que rodean el proyecto (Gattaca S. A).
22
Roles
Gestión de Producto: Asegurar que la solución ofrezca un valor comercial, Garantizar que
las necesidades y expectativas de los clientes están satisfechas.
Gestión de Programas: Entregar la solución dentro de las limitaciones del proyecto y
establecer los medios para satisfacer las necesidades.
Arquitectura: Diseñar una solución para cumplir los objetivos empresariales dentro de las
limitaciones del proyecto.
Desarrollo: Construir la solución a la especificación.
Experiencia de Usuario: Maximizar la usabilidad de la solución, Mejorar la disposición y
eficacia del usuario y Garantizar que las necesidades y expectativas de los usuarios estén
satisfechas.
Prueba: Aprobar la solución para la liberación sólo después de asegurarse de que todos los
aspectos de la solución cumplen o superan sus respectivos niveles de calidad definidos.
Liberación / Operaciones: Despliegue y transición a las operaciones y Garantizar que las
necesidades y expectativas de las operaciones de TI / Negocios sean satisfechas
Fases
Fase visión: Se debe tener el objetivo y limitaciones del proyecto, el análisis de los
problemas de negocios, el ámbito de la aplicación, la evaluación del riesgo y planificación
del producto.
23
Fase planificación: Se debe tener la ingeniería de requerimientos, planificación y gestión
de riesgos.
Fase desarrollo: En esta fase se codifica y se realizan las respectivas pruebas, también se
identifican y mitigan los riesgos existentes.
Fase estabilización: Se realizan pruebas beta, se crea un plan de gestión de incidencias, se
revisa la documentación final de la arquitectura y se elabora un plan de despliegue.
Fase implantación: Se libera la solución software, se crea un registro de mejoras y
sugerencias, se revisan las guías y manuales de usuario y se entrega el proyecto final
(Castrillón, 2012).
El Modelo de Gobernabilidad de MSF
Está estructurado para permitir que un equipo entregue porciones clave de una solución más
rápido de lo que sería posible si se centrará primero en las características de mayor prioridad y
movía las críticas menos importantes a las versiones posteriores. El modelo está estructurado para
ayudar a conducir a un equipo rápidamente a un consenso compartido sobre cómo entregar los
diversos aspectos de una solución. El modelo de gobernanza es un componente flexible de MSF
que se ha utilizado con éxito para mejorar el control del proyecto, minimizar el riesgo, mejorar la
calidad de la solución y aumentar la velocidad de desarrollo. Debido a que MSF es
completamente personalizable, se espera que una organización adapte el Modelo de
Gobernabilidad para que se adapte a sus procesos de negocio ya los enfoques de entrega de
soluciones existentes.
24
El ciclo de vida de MSF:
MSF se puede llevar a cabo de forma iterativa, de tal forma que, al liberar una solución, este
proceso presenta un conjunto de métodos para la gestión del proyecto, la gestión del riesgo y la
gestión de preparación para el cambio. Dentro de las cuales comprende:
Gestión de proyecto: Tiene como objetivo permitir mayor escalabilidad en proyectos pequeños,
grandes y complejos, basado en la planificación sobre las entregas cortas, la incorporación de
nuevas características sucesivamente, e identificar cambios ajustando el cronograma.
Gestión del riesgo: Se encarga de ayuda al equipo a tomar las decisiones correctas y controlar las
emergencias que puedan presentarse, por medio de un entorno estructurado para la toma de
decisiones y acciones, valorando los riesgos que puedan provocar.
Gestión de cambios: Esta disciplina tiene como objetivo lograr que el equipo sea proactivo en
lugar de reactivo, teniendo en cuenta que los cambios deben considerarse riesgos y por lo tanto se
deben registrar y hacer evidentes.
2.5.1.3 Metodología SCRUM
Características
SCRUM es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas
para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto.
25
Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de
trabajar de equipos altamente productivos.
En SCRUM se realizan entregas parciales y regulares del producto final, priorizadas por el
beneficio que aportan al receptor del proyecto. Por ello, SCRUM está especialmente indicado
para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los
requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la
flexibilidad y la productividad son fundamentales.
SCRUM también se utiliza para resolver situaciones en que no se está entregando al cliente lo
que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es
aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la moral de los
equipos es baja y la rotación alta, cuando es necesario identificar y solucionar ineficiencias
sistemáticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo
de producto.
Proceso
En SCRUM un proyecto se ejecuta en bloques temporales cortos y fijos (iteraciones) que
normalmente son de 2 semanas, aunque en algunos equipos son de 3 y hasta 4 semanas, límite
máximo de feedback y reflexión. Cada iteración tiene que proporcionar un resultado completo, un
26
incremento de producto final que sea susceptible de ser entregado con el mínimo esfuerzo al
cliente cuando lo solicite.
Figura 2. Ciclo de metodología SCRUM. Recuperado de http://www.martarepupilli.com.ar/
El proceso parte de la lista de objetivos/requisitos priorizada del producto, que actúa como plan
del proyecto. En esta lista el cliente prioriza los objetivos balanceando el valor que le aportan
respecto a su coste y quedan repartidos en iteraciones y entregas.
Las actividades que se llevan a cabo en SCRUM son las siguientes:
Planificación de la iteración: El primer día de la iteración se realiza la reunión de planificación
de la iteración. Tiene dos partes:
27
Selección de requisitos (4 horas máximo). El cliente presenta al equipo la lista de requisitos
priorizada del producto o proyecto. El equipo pregunta al cliente las dudas que surgen y
selecciona los requisitos más prioritarios que se compromete a completar en la iteración, de
manera que puedan ser entregados si el cliente lo solicita.
Planificación de la iteración (4 horas máximo). El equipo elabora la lista de tareas de la
iteración necesarias para desarrollar los requisitos a que se ha comprometido. La estimación
de esfuerzo se hace de manera conjunta y los miembros del equipo se auto asignan las tareas.
Ejecución de la iteración: Cada día el equipo realiza una reunión de sincronización (15 minutos
máximos). Cada miembro del equipo inspecciona el trabajo que el resto está realizando
(dependencias entre tareas, progreso hacia el objetivo de la iteración, obstáculos que pueden
impedir este objetivo) para poder hacer las adaptaciones necesarias que permitan cumplir con el
compromiso adquirido. En la reunión cada miembro del equipo responde a tres preguntas:
✓ ¿Qué he hecho desde la última reunión de sincronización?
✓ ¿Qué voy a hacer a partir de este momento?
✓ ¿Qué impedimentos tengo o voy a tener?
Durante la iteración el Facilitador (SCRUM Master) se encarga de que el equipo pueda cumplir
con su compromiso y de que no se merme su productividad.
✓ Elimina los obstáculos que el equipo no puede resolver por sí mismo.
✓ Protege al equipo de interrupciones externas que puedan afectar su compromiso o su
productividad.
28
Durante la iteración, el cliente junto con el equipo refina la lista de requisitos (para prepararlos
para las siguientes iteraciones) y, si es necesario, cambian o planifican los objetivos del proyecto
para maximizar la utilidad de lo que se desarrolla y el retorno de inversión.
Inspección y adaptación: El último día de la iteración se realiza la reunión de revisión de la
iteración. Tiene dos partes:
Demostración (4 horas máximo). El equipo presenta al cliente los requisitos completados en
la iteración, en forma de incremento de producto preparado para ser entregado con el mínimo
esfuerzo. En función de los resultados mostrados y de los cambios que haya habido en el
contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera objetiva, ya
desde la primera iteración, re planificando el proyecto.
Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su manera de trabajar y
cuáles son los problemas que podrían impedirle progresar adecuadamente, mejorando de
manera continua su productividad. El Facilitador se encargará de ir eliminando los obstáculos
identificados.
Ciclo de vida
Figura 3. Métodos agiles y SCRUM. Recuperado de http://projectmanager.soy/?cat=14
29
2.5.1.4 MetaProceso
El MetaProceso ha sido visto desde la perspectiva de la evolución del proceso, este enfoque
distingue entre el proceso del mundo real, que reúne las actividades necesarias para realizar un
producto de software incluyendo las personas, y el modelo de proceso que refleja el proceso del
mundo real.
Las metodologías y los procesos se ubican en una capa intermedia según la configuración del
MetaProceso. SCRUM constituyen la instancia ontológica de una metodología y RUP constituye
la instancia oncológica del proceso, sin embargo ambas son instancias lingüísticas.
El lenguaje de modelamiento busca facilitar el uso, construcción y creación en MetaProcesos, Su
vocabulario configura la posibilidad de crear nuevos conceptos basados en las categorías del
lenguaje, manteniendo la estructura y filosofía, adicional está dotado de una anotación gráfica
próxima a lenguajes como UML.
En algunos casos es conveniente relevar una u otra durante la convivencia entre los procesos y las
metodologías, es decir cuando se necesite el procedimiento para resolver el problema es clave
que salga a relucir el cómo, cuándo se necesite el quien, o el dónde o el cuándo es importante que
reluzca la metodología, se pretende explotar las ventajas de proceso y metodologías permitiendo
su modelado y su evolución, gran parte de estos proceso o modelos corren sobre las perdonas.
(Bolaños Castro, Medina García, & Ferro Escobar, abril de 2016).
30
2.5.1.5 SCRUM vs Gestión tradicional de Proyectos
Uno de los temas importantes en las metodologías tradicionales es hacer una planificación
detallada del proyecto enfocado en el alcance, costo, horarios y gestionar los demás parámetros.
En ocasiones, la gestión tradicional de proyectos puede llevar a una situación en la que, aunque el
plan haya tenido éxito, el cliente no está satisfecho.
La metodología SCRUM cree en que el conocimiento de los trabajadores de hoy en día puede
ofrecer mucho más que solo su experiencia técnica, y en qué tratar de asignar y planear en un
ambiente de constante cambio no es eficiente. En SCRUM, el enfoque principal es la entrega de
productos que satisfagan los requisitos del cliente en pequeños incrementos iterativos que sean
entregables. Para entregar la mayor cantidad de valor en el menor tiempo posible, SCRUM
promueve la priorización y el Time-Boxing en vez de la fijación del alcance, del costo y del
cronograma de un proyecto. Una característica importante de SCRUM es la auto organización, lo
cual permite a las personas que hacen el trabajo estimar y asumir la propiedad de las tareas.
En los métodos tradicionales de gestión de proyectos, la estructura de la organización es
jerárquica y la autoridad para todos los aspectos del proyecto se delega desde el nivel superior al
inferior (por ejemplo, el patrocinador, o sponsor del proyecto delega autoridad al Project
Manager, y este, a su vez, la delega a los miembros del equipo). Los métodos tradicionales de
gestión de proyectos hacen énfasis en la responsabilidad individual respecto a las
responsabilidades del proyecto, en vez de la responsabilidad propiedad colectiva. Cualquier
desviación de la autoridad delegada se considera como una señal de problemas y puede ser
31
llevada a un nivel más alto en la jerarquía de la organización. Por lo general, es el Project
Manager, quien es responsable de la finalización con éxito del proyecto, así como de la toma de
decisiones sobre diversos aspectos del proyecto, incluyendo el inicio, planificación, estimación,
ejecución, seguimiento y control y cierre.
El énfasis en SCRUM está en la auto organización y la automotivación, donde el equipo asume
una mayor responsabilidad en lograr el éxito de un proyecto. Esto también garantiza la existencia
de un sentido de compromiso del equipo y responsabilidad compartida. Esto, a su vez, da lugar a
la motivación del equipo que lleva a una optimización de su eficiencia. El Product Owner, el
SCRUM Master y el Equipo SCRUM trabajan de cerca con los Stakeholder para ajustar los
requisitos a medida que avanzan a través de los procesos de Desarrollar, esto asegura que no
haya margen para la planificación aislada en SCRUM. El conocimiento y las experiencias del
equipo sobre el desarrollo de productos se utilizan para evaluar las entradas necesarias para
planificar, calcular y ejecutar el trabajo del proyecto.
Los proyectos tradicionales hacen énfasis en una amplia planificación y en el apego al plan de
proyecto creado por el Project Manager. Por lo general, los cambios se administran mediante un
sistema formal de gestión de cambio y el valor se crea al final del proyecto cuando se entrega el
producto final.
En los proyectos SCRUM, no se realiza una extensa planificación de largo plazo antes de la
ejecución del proyecto. La planificación se realiza de manera iterativa antes de cada sprint. Esto
permite una respuesta rápida y eficaz a los cambios, lo cual se traduce en menores costos y en
última instancia, aumenta la rentabilidad y el retorno sobre la inversión.
32
En la Tabla 1, se resume muchas de las diferencias entre los modelos tradicionales de gestión de
proyectos.
Tabla 1
Diferencias entre Modelos SCRUM vs Gestión tradicional de Proyectos
33
2.5.2 Marco conceptual
A continuación, se describen los conceptos con mayor relevancia utilizados para este proyecto:
Metodología Tradicional: impone una disciplina de trabajo sobre el proceso de desarrollo del
software, con el fin de conseguir un software más eficiente. Hace énfasis en la planificación total
de todo el trabajo a realizar y comienza el ciclo de desarrollo del producto software. Se centran
especialmente en el control del proceso, mediante una rigurosa definición de roles, actividades,
artefactos, herramientas y notaciones para el modelado y documentación detallada.
Metodología Ágil: Son un conjunto de técnicas y procedimientos para la gestión de proyectos
basado en desarrollo o ejecución iterativa.
Time to market: Tiempo transcurrido desde el inicio de la idea o producto hasta la puesta en
marcha o entrega del mismo.
Proyectos de desarrollo: Son los Proyecto cuyo objetivo son la construcción u optimización de
software.
SCRUM Master: Es la persona que tiene el rol de líder o facilitador durante la ejecución de las
interacciones y es el encargado que el equipo pueda cumplir con el objetivo.
34
Iteraciones: Ciclos repetitivos definidos dentro de la ejecución de un proyecto que busca el logro
de los objetivos del proyecto. Cada iteración está asociada a un logra o entregable por parte del
equipo.
Daily: Reunión programada diariamente para la sincronización del equipo de trabajo del
proyecto.
Time-Boxing: es la fijación de breves períodos de períodos para hacer el trabajo. Si el trabajo
realizado queda incompleto al final del time-box, este se asigna a un nuevo time-box. El asignar
bloques de tiempo fijo proporciona la estructura necesaria para los proyectos SCRUM, los cuales
tienen un elemento de incertidumbre, son dinámicos por naturaleza y propensos a cambios
frecuentes.
Problemas: Los problemas generalmente son certezas bien definidas que actualmente se están
sucediendo en el proyecto, por lo que no hay necesidad de realizar una evaluación de
probabilidad como se hace con un riesgo.
Proyecto: Un proyecto es un emprendimiento colaborativo para crear nuevos productos o
servicios, o para obtener resultados como los que se definen en la declaración de la visión del
proyecto. Los proyectos por lo general se ven afectados por limitaciones de tiempo, costo,
alcance, calidad, personal y la capacidad de la organización.
Riesgo: El riesgo se define como un evento incierto o una serie de eventos que pueden afectar los
objetivos de un proyecto pudieran contribuir a su éxito o fracaso.
35
Stakeholder: es un término colectivo que incluye a clientes, usuarios y patrocinadores que
interactúan frecuentemente con el Product Owner, con el SCRUM Master y con el Equipo.
Adaptación: La adaptación sucede cuando el equipo principal de SCRUM y el (los) Stakeholder
aprende por medio de la transparencia e inspección, adaptando después lo aprendido para mejorar
el trabajo que realizan.
Colaboración: en SCRUM se refiere a que el equipo principal de SCRUM trabaja e interactúa
con los Stakeholders para crear y validar los resultados del proyecto a fin de cumplir con los
objetivos que se plantean en la visión del proyecto. La colaboración se produce cuando un equipo
trabaja en conjunto para contraponer los aportes del otro a fin de producir algo más grande.
Daily Standup Meeting: es una breve reunión diaria con un Time-box de 15 minutos. Los
miembros del equipo se reúnen para informar sobre cómo avanza el proyecto, respondiendo a las
siguientes tres preguntas:
1. ¿Qué he hecho desde la última reunión?
2. ¿Qué tengo planeado hacer antes de la siguiente reunión?
3. ¿Qué impedimentos u obstáculos (si los hubiera) estoy enfrentando en la actualidad?
36
2.6 Metodología
Con base a los objetivos planteados en el proyecto se define el desarrollo de la investigación de
tipo exploratoria, teniendo en cuenta que se busca destacar los aspectos de los riesgos y
problemáticas que se pueden presentar en las áreas de desarrollo de software de las empresas,
durante el proceso de transición de una metodología tradicional a la metodología SCRUM.
De acuerdo con el planteamiento anterior se aborda la problemática de una manera exploratoria
con la cual se realiza el entendimiento de la problemática desde diferentes puntos de vista, que
afecta de manera directa o indirecta el desarrollo del proyecto de software en las organizaciones.
Adicionalmente las actividades definidas en el plan de trabajo permiten cumplir con los objetivos
establecidos y de esta manera tener un entregable de alta calidad.
Durante la ejecución del plan de trabajo mencionado anteriormente se emplea el método de
campo, teniendo en cuenta que la investigación se basa principalmente en observación, lluvia de
ideas y entrevistas con el fin de indagar sobre los puntos más relevantes detectados por cada uno
de los perfiles o roles de un equipo de trabajo de desarrollo de software. De igual forma se toma
en cuenta los procesos definidos en las metodologías tradicionales y la metodología SCRUM.
37
2.7 Limitaciones y alcance
Las limitaciones identificadas para el normal desarrollo del proyecto de acuerdo a la naturaleza
del mismo son el no contar con la disponibilidad de todos los roles y perfiles de más de un área
de desarrollo de software que estén en proceso de transición de su metodología con las cuales se
puede realizar el proceso exploratorio y de recopilación de información.
Con el fin de mitigar la limitación anteriormente identificada se plantea dentro del proceso de
recopilación de información, involucrar a profesionales de diferentes roles y perfiles de diferentes
empresas con el objetivo de obtener una mayor muestra de información relacionada al punto de
investigación.
El presente trabajo tiene como alcance el diseño de un modelo de transición de metodologías
tradicionales a metodología SCRUM, que permita mitigar los riesgos durante el proceso de
adopción de la nueva metodología. Con dicho modelo se busca como beneficio que a las áreas de
desarrollo de software puedan tener las bases de conocimiento necesarias para reducir el impacto
generado cuando se adopta una nueva metodología.
38
2.8 Impacto y productos esperados
Con base a lo anterior, los impactos proyectados que pueden surgir cuando las áreas de desarrollo
de software hagan uso del modelo propuesto para la transición a metodología SCRUM, son la
reducción en costos, tiempo de implementación, reducción en el impacto en los proceso y fácil
adaptación del equipo de trabajo a la nueva metodología.
Como producto final del desarrollo del proyecto se obtendrá como resultado un documento que
describa un modelo para la transición a metodología SCRUM para apoyo a las áreas de desarrollo
de software en el proceso transitorio.
39
PARTE II FUNDAMENTOS DE LA TRANSICION DE METODOLOGIAS
3 Capítulo 2. Descripción de metodología RUP y SCRUM
A continuación, se detalla el estudio del problema de investigación de este proyecto.
3.1 Transición de metodología RUP a SCRUM
Como ya se ha mencionado antes, RUP es una metodología para el proceso de software
extensamente usado, pero cuando se piensa en una metodología ágil como lo es el marco de
procesos SCRUM se identifican los beneficios o desventajas que se pueden obtener.
El enfoque en RUP es establecer una serie de reglas para el desarrollo de un proyecto. Lo cual en
proyectos de mediano tamaño nos encasilla y limita en lugar de simplemente establecer orden. En
SCRUM al contrario “los principios SCRUM” tienden a ser líneas guía y “normas o reglas
fundacionales” para los desarrolladores.
Comparando ambas metodologías, el tipo de documentación de RUP enfatiza en las
comunicaciones formales con la finalidad de ser más predictivos, mientras que en SCRUM se
enfatiza en las comunicaciones informales continuas y la adaptación al cambio, con la finalidad
de ser más adaptativas.
40
La otra diferencia está relacionada con las iteraciones de desarrollo, mientras que en RUP tienden
a ser pocas y largas, en SCRUM tienden a ser muchas pero frecuentes. En la metodología
SCRUM se realizan reuniones diarias las cuales son llamadas Daily SCRUM y es donde se
sostiene una pequeña charla sobre el estado del proyecto. En particular muestran los
impedimentos para progresar que se atraviesan y que la gerencia debe resolver. También
informan lo que se ha hecho para tener una actualización diaria de dónde va el proyecto. El
marco de trabajo SCRUM se enfoca principalmente en la planeación iterativa y el seguimiento
del proceso.
Diferencias entre las metodologías RUP y SCRUM
En la Tabla 2 se describen las diferencias entre las metodologías RUP y SCRUM, permitiendo
identificar de manera general sus características generales.
Tabla 2
Diferencias entre metodología RUP y SCRUM
RUP SCRUM
Enfoque: Cada iteración debe tener definida su
planificación de tiempos.
Cada iteración implementa un
subconjunto de la funcionalidad total.
Ciclo de
desarrollo
Existe Plan formal del proyecto
asociado a múltiples iteraciones que
cubren el mismo de principio a fin
No existe un plan de principio a fin del
proyecto. El plan de la siguiente
iteración se determina al final de la
iteración previa. Cada Iteración
(Sprint) es un ciclo completado.
41
Alcance Es definido antes del comienzo del
proyecto y llamado en el documento
de Alcance. El Alcance puede
revisarse a lo largo de la vida del
proyecto, pero existe proceso que
controla las revisiones.
El alcance es definido en la Lista de
Objetivos (Project Backlog) que es
reevaluado al fin de cada iteración
(Sprint).
Artefactos Documento de Alcance, Visión, Caso
de Negocio, Lista de Riesgos, Plan
de Desarrollo, Plan de Iteraciones,
Lista de principales casos de Uso,
etc.
El Software operativo es el único
artefacto.
Tipo de
proyecto
Proyectos empresariales de largo
alcance
Proyectos con requisitos cambiantes o
implementación de mejoras rápidas
Para ejecutar un proceso de transición de RUP a SCRUM podemos proponer que el cambio se
puede dar de manera parcial o radical presentando un modelo para proyecto de desarrollo:
● Cambio parcial consta en agregar algunas características de metodología Ágil a
la metodología tradicional.
● Cambio radical, muchos jefes de proyectos o gerentes pueden resistirse al cambio
aduciendo que como todo marcha bien para que cambiar, por ello una alternativa sería
presentar un software piloto basado en metodología Agile para observar la diferencia con
el desarrollo de otro software.
42
3.2 Aspectos de la metodología SCRUM
A continuación, se describen los aspectos relevantes que se deben tener en cuenta en la
implementación de la metodología SCRUM cuando se tienen proyectos en ejecución con
metodología tradicional.
Para las empresas que tengan proyectos en ejecución con metodología RUP y decidan agregar en
su proceso SCRUM es necesario validar los siguientes aspectos:
Costos
La organización debe presupuestar los costos en la adquisición de recursos especializados
y capacitados para conformar equipos de trabajo auto organizados y funcionales definidos
en la guía SCRUM para el desarrollo y construcción de los productos.
Con relación a lo anterior, definir los periodos de contratación del recurso humano
depende de una buena planificación de los recursos y una óptima asignación de labores
durante la ejecución del proyecto permitirá reducir parte del costo.
Otro costo importante mencionar es la adquisición de las herramientas de trabajo,
tecnología e infraestructura necesarias y acordes para que el personal contratado ejecute
las labores asignadas en los proyectos.
Por lo anterior las empresas deben ejecutar una etapa de análisis de costos que involucra
43
la definición del costo de incluir SCRUM en la ejecución del proyecto, definir la
capacidad financiera con la que cuentan y definir el presupuesto requerido.
Dedicación de equipos de trabajo
De acuerdo con la planificación de tiempos de entrega, actividades y entregables
planificados de los productos al cliente, se debe definir el número de personas y equipos
de trabajo que se deben conformar para mantener el progreso y lograr el éxito del
proyecto.
El tiempo de dedicación por persona y equipos depende del estado del proyecto, el
progreso y cumplimiento de los entregables, es decir, la no existencia de eventos que
causen retrasos.
Capacitación del equipo
El equipo de trabajo en el modelo SCRUM cuentan con competencias de alto nivel,
habilidades especializadas y alto conocimiento en las áreas en las que estén enfocados
requeridas para llevar a cabo su asignación en el proyecto, así como estar en la capacidad
de ejecutar y cubrir cualquiera de los roles que se requiera durante la construcción del
producto.
Lo anterior implica realizar un proceso de recursos humanos que incluya etapas de
conformación de equipos, sensibilización de personal, capacitación de personal y
empoderamiento del equipo de trabajo.
44
Roles
La guía SCRUM propone la composición de un equipo SCRUM en el que hacen parte
roles importante como: SCRUM Master, Dueño de producto y el Equipo de desarrollo
que lo componen no más de 9 personas o mínimo 3.
La organización no cuenta con estos roles inmediatamente para asignar al proyecto en
ejecución, por lo cual debe tomar las siguientes decisión de: uno, contratar el personal
especializado que cumpla con los rol requerido lo cual implica un costo de contratación,
la ventaja sería obtener ahorro en tiempos, ya que se consigue un empalme corto de
actividades en el proyecto para ejecución de su tarea; dos, se debe poner a la tarea de
búsqueda entre su personal el individuo que cuente con las competencias requeridas para
el rol, lo cual implica tiempos de capacitación de las actividades que debe ejecutar, línea
en el tiempo de aprendizaje y experiencia y riesgos en el progreso del proyecto.
Eventos y artefactos:
Para lograr un progreso efectivo en el proyecto y evitar retrasos por causa de adicionar
tiempos para ejecutar los eventos propuestos por SCRUM, es necesario que la
organización realice un proceso de Homologación de actividades SCRUM con proceso
existentes con la metodología tradicional.
En cuanto a los artefactos de SCRUM, son herramientas que complementan el proceso de
construcción de los desarrollos porque ayudan en el control ejecución de los
requerimientos de un producto, además de ofrecer visibilidad y transparencia del progreso
del proyecto o los impedimentos que se presenten para que sea mitigado a tiempo.
Compromiso de alta gerencia
45
Para implementar la guía de trabajo SCRUM en proyectos en ejecución se requiere que la
alta gerencia apoye la inclusión de modelo en lo económico, procedimental y social, ya
que sin esto se tiene un alto riesgo que fracase.
Su participación en el seguimiento y evaluación del progreso de esta implementación le permitirá
evaluar y definir los beneficios, ventajas y desventajas que puede obtener y aplicar en su
organización.
3.3 Matriz DOFA para transición de RUP a SCRUM
Los puntos relevantes encontrados en cada componente de la matriz DOFA entre la metodología
tradicional RUP y SCRUM describen las ventajas de este proceso de transición a metodologías
ágiles.
Debilidades
Difícil aplicar en un Startup de pocos empleados:
SCRUM habla de la gestión de un solo proyecto y realizar iteraciones en torno a él. En un
startup que está naciendo o creciendo, normalmente hay varios proyectos. Es muy difícil
poner en práctica SCRUM en equipos tan reducidos, con varios proyectos a la vez.
Solución de incidentes graves:
No queda muy claro cómo resuelve SCRUM las incidencias de carácter grave que deben
46
resolverse en el momento en que se producen y no estaban contempladas en el sprint.
Falta de información inicial al cliente:
SCRUM no realiza una planificación inicial del proyecto de manera detallada y no
proporciona herramientas para realizar planificaciones largas. Sin embargo, los clientes,
antes de empezar quieren saber cuánto tiempo va a costar el proyecto y cuanto les va a
costar. ¿Cómo puede SCRUM dar respuesta al cliente?
Actualmente, la mayoría de los clientes desconfían de un proyecto si no tienen la garantía
de cuánto tiempo van a durar y cuánto va a costar. Eso implica que se van a perder
muchos clientes por falta de confianza o información.
Implicación en aspectos Financieros:
SCRUM no habla de cómo se factura el proyecto. ¿En cada iteración el cliente paga un
poco? ¿Paga todo al final? ¿Paga la mitad al inicio y la mitad al final? El problema es que
SCRUM no es capaz de decir cuánto va a durar el proyecto. Las empresas pueden
encontrarse con problemas de flujo de caja para pagar a los empleados mensualmente, y el
cliente no querrá pagar hasta no tener terminado el trabajo.
Por lo anterior, SCRUM no menciona en ningún momento el tema económico o
financiero. La gestión de proyectos debe ser conocedora de las finanzas de la empresa, no
ser totalmente ajena y realizar estimaciones de costes para mitigar los problemas
financieros que se presenten durante el proyecto.
47
Oportunidades
Clientes Satisfechos:
Los clientes pueden participar en cada una de las iteraciones y proponer soluciones. De
hecho, el proceso en su conjunto está pensado para un tipo de evaluación conjunta.
Entregables en tiempo y forma:
Se pueden ir enviando entregables al cliente mientras se van realizando las metas más
sencillas, eso permite ganar tiempo para atacar los objetivos más complejos. Se maneja el
conocimiento necesario para lograr el objetivo primario y secundario por lo cual se puede
ir controlando el proyecto y delegando roles. Por tanto, alineamiento entre el cliente y el
equipo de desarrollo.
Promueve la reutilización:
Reduce la complejidad del mantenimiento (extensibilidad y facilidad de cambios). El
diseñador piensa en términos del comportamiento de objetos y no en detalles de bajo
nivel.
Facilita la construcción de prototipos:
Se pueden identificar los resultados anticipados. Cada iteración arroja una serie de
resultados. No es necesario, por tanto, que el cliente espere hasta el final para ver el
producto. Se genera por tanto confiabilidad, integridad y Estabilidad.
Gestión sistemática de riesgos:
48
Los riesgos que pueden afectar a un proyecto son gestionados en el mismo momento de
su aparición. La intervención de los equipos de trabajo es inmediata. Se involucra desde
un principio y se da un rol a todos los Stakeholders. Los problemas se identifican con
suficiente antelación a través de las reuniones diarias y por lo tanto se pueden resolver con
rapidez.
Fortalezas
Buen ambiente laboral:
Se define como el medio ambiente, humano y físico, en el que se desarrolla el trabajo
cotidiano, que influye en la satisfacción de los trabajadores y su productividad. Uno de los
aspectos claves para generar un ambiente laboral es la comunicación en el trabajo que
logra evitar conflictos, ayuda a que fluyan las ideas y fortalece las relaciones laborales
entre compañeros. Realizar actividades como SCRUM Meetings que son reuniones
periódicas para alinear el equipo de trabajo, adaptarlo y sincronizarlo, aumentando la
efectividad y eficiencia en la consecución de un proyecto.
Otros aspectos que lo complementan son la calidad en las relaciones humanas dentro entre
el equipo de trabajo, el respeto, la manera de comunicarse unos con otros, la colaboración,
el compañerismo, todos son apoyados por el rol del SCRUM Master.
Recursos humanos motivados y contentos:
Se pretende contar con equipos de trabajo estructurados y empoderados por la
organización para gestionar su propio trabajo. Cada persona sabe lo que tiene que hacer y
49
no es necesario estar reorganizando una y otra vez las actividades de cada persona. Se
auto gestionan lo cual permite la reducción de riesgos.
Proactividad en la gestión:
SCRUM propone trabajar con un equipo de trabajo que sea auto organizado y
multifuncional. Con esto se obtiene un alto grado de autonomía de las personas en la
ejecución de sus tareas habituales. El hecho de que cualquier empleado disponga de toda
la independencia que es capaz de asumir favorece el buen clima laboral.
Buena calidad del producto final:
Las iteraciones permiten la entrega de productos con alta calidad, ya que cada incremento
de producto terminado al finalizar el Sprint cumple con el objetivo propuesto para este
evento e incluye un proceso de pruebas y control de calidad para ser entregado al dueño
de producto.
Experiencia de los recursos humanos:
Son equipos que tienen las competencias requeridas para llevar a cabo su trabajo con
habilidades especializadas y áreas en las que estén enfocados. Pueden cubrir cualquiera de
los roles que se requiera durante la construcción del producto.
Amenazas
Costos:
En proyectos pequeños, es posible que no se puedan cubrir los costos de dedicación del
50
equipo de profesionales necesarios.
Experiencia de los recursos humanos:
Se requiere conocimiento del proceso, y manejo de equipos pequeños, en empresas
grandes, se deben dividir con objetivos concretos. No es una modalidad de gestión propia
de grupos junior o que apenas estén en proceso de formación. Se requiere de la
experiencia que aportan los profesionales de los equipos, quienes por lo general acumulan
años de experiencia. En algunas ocasiones, miembros del equipo pueden saltar pasos
importantes en el proceso para llegar al objetivo final. Se requiere miembro de equipo
centrados y convencidos.
Dirección firme y definida:
La falta de dirección firme puede llevar a los proyectos a no completarse o incluso fallar.
El cliente siempre va a esperar los informes en la fecha definida o solicitar avances.
Muchas reuniones:
Se pueden presentar exceso de reuniones que pueden no presentar un resultado
tangible.
Ausencia de Personal:
Si una persona renuncia o hay algún cambio es complicado reemplazar ese rol ya que es
la persona que se lleva el conocimiento específico y puede afectar el proyecto.
Dificultad de aplicación en grandes proyectos:
51
Plantea un problema si el desarrollo está restringido por una fecha de entrega y un precio
de entrega cerrados por contrato. Depende en gran medida de la interacción del cliente,
por lo que, si el cliente no está claro, el equipo se puede conducir en la dirección
equivocada.
3.4 Procesos y metodologías
El metamodelo se centra en la definición de dos grandes estrategias; referida al proceso y
referida a la metodología.
El proceso se plantea como la articulación de un conjunto de actividades, es necesario que
los procesos establezcan nuevas formas de estrategias, mecanismos y pautas, por otro lado
la metodología aborda el proceso como uno de sus componentes, su objetivo es controlar
limitaciones, restricciones, riesgos y contraindicaciones que debilitan la estrategia.
Los procesos no deben ser, ni convertirse en guiones estáticos deben considerar todas las
posibles variables que lo afectan, usar un mismo proceso una y otra vez puede ser nocivo,
la estructuración requiere de un rol que configure los procesos de manera conveniente y
acorde a sus condiciones particulares.
Las pautas en las que está centrado el metamodelo son pro y contras de las metodologías,
los pro enfatizan en prácticas, valores principios y otros elementos que fortalecen el uso
de las metodologías, los contras enfatizan en riesgo, restricciones, límites y otros
52
elementos que debilitan el uso de las metodologías.
Está enfocado en establecer los procesos del conocimiento, estos se generan duros o
blandos. El conocimiento Duro es aquel que puede ser informatizado y expresado en
lenguajes ejecutables, en tanto el conocimiento blando reside en los individuos y
constituye las experiencias, experticias y habilidades propias de cada uno. (Bolaños
Castro, Medina García, & Ferro Escobar, abril de 2016).
Figura 4. Metamodelo RUP - SCRUM como Estrategia. Adaptado de (Bolaños Castro, Medina
García, & Ferro Escobar, abril de 2016)
53
4 Capítulo 3. Descripción de la solución
3.
4.1 Principales problemas en gestión de proyectos
Durante la investigación se encontraron varios problemas que son frecuentes en muchas
empresas, sin embargo los más relevantes son los requerimientos mal definidos, las estimaciones
erróneas, aceptación de controles de cambio sobre el desarrollo y cambio de personal durante el
proyecto.
Es común ver requerimientos mal definidos, en los casos vistos durante la investigación se
encontró que las personas que realizan los requerimientos no tienen el suficiente conocimiento y
experticia para esta gestión, se identificó que algunas personas cuentan con un alto conocimiento
sobre metodologías pero poco conocimiento del negocio y realizan solicitudes muy genéricas no
apropiadas para el negocio. Por otro lado se encontraron personas que conocía muy bien el
negocio pero no tanto las metodología a aplicar, esto también era un problema ya que no tenía la
suficiente experticia para ir más allá de la operación conocida. Sin embargo en ambos casos no se
obtenía un buen resultado pero sí se tendría un desarrollo con muchos cambios y nuevas
definiciones.
Llegar a una estimación tecnológica y que esta sea correcta es una de las metas más esperadas
por los clientes y los proveedores, durante la investigación se identificó que menos del 20% de
los proyectos cumplían con el presupuesto esperado, el 80% restante sobrepasaba el presupuesto,
estos gastos adicionales están divididos entre ampliación o cambio de la infraestructura y
54
aceptación de nuevas definiciones durante el desarrollo del proyecto.
Es común ver que a los usuarios se les ocurran nuevas cosas durante el desarrollo de los
proyectos, sin embargo se debe tener mucho cuidado de cómo se van a manejar estos cambios ya
que estos generan retrasos a tal punto que el proyecto podría no terminar, sin embargo durante el
desarrollo de proyectos se pueden encontrar con un cambio que sea indispensable y que sin este
no se obtendría el resultado esperado, estos son los cambios que se deberían aprobar cualquier
otro cambio se debe dejar para después que el proyecto termine.
.Es importante tener una buena relación entre su equipo de proyecto, esto permite que sean
colaborativos entre ellos y que tengan un buen resultado, si se está motivado es más difícil que se
retire, se identificó que si dentro del equipo de trabajo existen personas que no pueden convivir y
no son capaces de separar lo personal de lo laboral entonces es mejor tomar la decisión de
prescindir de uno de los dos, ya que una mala relación puede llevar a realizar una división entre
todo su equipo tal como dice el refrán una manzana podrida puede pudrir las otras, sin embargo si
se presenta un cambio en el equipo del proyecto es importante validar que el estado de este no
este dividido es decir uno de los puntos más críticos para realizar el cambio es después que
realizan el análisis y levantamiento ya que la mayoría de las veces las personas no escriben este
resultado detalladamente, las anotaciones son muy genéricas y pensadas en la metodología
utilizada, una persona nueva en un proyecto durante su desarrollo no tendrá las bases necesarias
para realizar un buen seguimiento y/o liderazgo del proyecto.
55
4.2 Beneficios de SCRUM
El objetivo de SCRUM es segmentar los proyectos de desarrollo de software en Iteraciones,
dividiendo los requerimientos en bloques para construir productos sencillos y funcionales o ir
creando un incremento del producto para entregar al cliente. SCRUM contribuye en el ciclo de
vida de los proyectos de desarrollo de software con los siguientes aportes:
➢ Entrega de resultados periódicamente de máximo un mes de desarrollo planificado en los
Sprint con ventajas como:
o Gestión de las expectativas del cliente.
o Resultados tangibles y anticipados (Time to market).
o Flexibilidad y adaptación a las necesidades del cliente.
o Gestión del Retorno de Inversión (ROI) en menor tiempo.
o Mitigación de los riesgos del proyecto.
➢ Calidad del producto entregado.
➢ Alineamiento de los objetivos de los proyectos entre el cliente y el equipo de desarrollo.
➢ Equipo de desarrollo motivado, creativo y comprometido.
Cómo obtener los beneficios de SCRUM
En la Tabla 3, se describen los beneficios que ofrece SCRUM en los proyectos de desarrollo de
software y de qué manera pueden obtener:
56
Tabla 3
Beneficios de SCRUM y Cómo se consiguen
Beneficios de SCRUM Cómo se consiguen
Gestión de expectativas del cliente. Lista de requisitos priorizada (Product Backlog).
El cliente establece las expectativas y el valor de los
requerimientos del proyecto y la fecha estimada en
la que esperan esté terminado.
El cliente registra en la lista de requisitos del
proyecto, en el que se relaciona la prioridad, el valor
y la fecha estimada de entrega.
El cliente verifica el cumplimiento de sus
requerimientos, toma decisiones a partir de
resultados objetivos y dirige los resultados hacia la
optimización del proyecto.
SCRUM ejecuta Sprint de máximo un mes de
trabajo para entregar productos completados o un
incremento de estos, permitiendo que el cliente
valide el cumpliendo de sus expectativas y que el
equipo de desarrollo informe el progreso de los
entregables y posteriormente tomar las decisiones
que correspondan a partir de los resultados.
Resultados tangibles y anticipados (Time to
market). Priorización de requisitos por valor y coste.
El cliente puede iniciar con la utilización de los
incrementos más importantes de un requerimiento
del proyecto antes de que esté finalizado por
completo el producto.
Al inicio de cada iteración el cliente prioriza la lista
de requisitos del proyecto en función del valor y el
costo del desarrollo con relación a los riesgos y
prioridades del proyecto.
A partir de lo anterior el cliente puede empezar
antes a recuperar su inversión utilizando un
producto al que le faltan características poco
relevantes con que puede enfrentar una urgencia del
cliente.
El proyecto se mide en función de los requisitos que
el equipo de desarrollo entregue completos en cada
Sprint.
Flexibilidad y adaptación a las necesidades del
cliente.
Revisión Planificación del proyecto al inicio de
cada Sprint.
Cuan se finaliza cada Sprint y se hace entrega del
producto completado, el cliente puede usarlo para
hacer pruebas funcionales con usuarios y reportar
los incidentes encontrados.
Los requerimientos que se completen la
funcionalidad requerida por el cliente minimiza la
probabilidad de que se produzcan grandes cambios
en el transcurso del proyecto.
Retorno de inversión (ROI) en menor tiempo. Priorización de requisitos por valor.
El objetivo de todo proyecto es que el cliente
maximice el ROI del proyecto. Cuando el beneficio
pendiente de obtener es menor que el coste de
desarrollo, el cliente puede finalizar el proyecto.
En cada Sprint el cliente dispone de unos requisitos
completados puede re planificar las prioridades de
los requerimientos del proyecto en función del valor
que le aportan a la operación.
Mitigación de riesgos del proyecto Desarrollo Iterativo y entrega incremental de
productos.
57
Al iniciar cada Sprint el equipo de trabajo del
proyecto tiene que gestionar los problemas que
pueden aparecer en cada entrega de producto
durante el proyecto. Al encontrar riesgos es posible
ejecutar un plan de mitigación de manera anticipada
para ahorrar esfuerzo y tiempo.
En una Iteración el equipo de desarrollo puede
entregar uno o varios productos completos o el
incremento de uno, ejecutando todas las tareas
necesarias para entregarlo al cliente y finalizar el
proyecto sin actividades pendientes relacionadas con
la entrega de requisitos.
Calidad del producto entregado. Comunicación diaria del equipo y Mejora
Continua.
En las reuniones diarias, el Equipo de desarrollo
sincroniza su trabajo y resuelve los problemas que
impiden conseguir el objetivo de la iteración,
permitiendo una comunicación efectiva y la
adaptación a las diferentes necesidades entre los
miembros del equipo con el fin de realizar tareas
innecesarias y evitar ineficiencias.
En cada iteración el equipo realiza una retrospectiva
para analizar su manera de trabajar e identificar los
obstáculos que le impiden avanzar y todo el equipo
de SCRUM conoce el trabajo de los demás
compañeros y el impacto que puede tener con su
actividad asignada.
Las personas trabajan más enfocadas y de manera
más eficiente cuando hay una fecha límite a corto
plazo para entregar un resultado al que se han
comprometido. La consciencia de esta limitación
temporal favorece la priorización de las tareas y
fuerza la toma de decisiones.
Utilización de los TimeBoxing que permite al
equipo de trabajo enfocarse y trabajar
eficientemente, al existir una fecha límite a corto
plazo para entregar un resultado.
Los Sprints de SCRUM son iteraciones de un mes
de trabajo de desarrollo planificado para facilitar la
sincronización de otros equipos de desarrollo con la
empresa y el cliente.
Los eventos o reuniones de SCRUM siempre tiene
definida una duración, en estos periodos de tiempo
se puede organizar, priorizar tareas y tomar
decisiones.
El equipo de desarrollo no depende de personas
externas para poder avanzar.
En SCRUM se debe contar un equipo
multidisciplinario que está formado por personas de
diferentes especialidades necesarias para llevar a
cabo el proyecto.
Para desarrollar un requisito con calidad es
conveniente contar con personas que tengan
diferentes especializaciones, experiencias y puntos
de vista. Asimismo, con iteraciones cortas la
precisión de las estimaciones aumenta.
La Planificación de la Iteración es la reunión inicial
de un Sprint donde se realiza una estimación en
conjunto con los miembros del equipo para estimar
la lista de requisitos priorizada del proyecto.
58
Las personas trabajan de manera más eficiente y con
más calidad cuando ellas mismas se
han comprometido a entregar un resultado en un
momento determinado y deciden cómo hacerlo, no
cuando se les ha asignado una tarea e indicado el
tiempo necesario para realizarla.
El compromiso del equipo es establecido por el
propio equipo, se organiza, identifica las actividades
necesarias, su esfuerzo y se auto asigna las tareas
que se compromete a realizar. En cada Planificación
de iteración el equipo selecciona los requisitos que
se compromete a desarrollar y entregar al final de la
iteración.
Alineamiento entre cliente y equipo Cliente y Trabajo en equipo
Con los resultados y esfuerzos del proyecto se
miden en forma de objetivos y requisitos entregados
al negocio. Todos los participantes en el proyecto
conocen cuál es el objetivo a conseguir.
En cada iteración el equipo y el cliente trabajan
juntos, por ejemplo en la creación de la lista
priorizada de requisitos del proyecto, durante la
reunión de planificación de la iteración y en el
análisis del resultado obtenido en la reunión de
revisión del Sprint.
Equipo motivado, creativo y comprometido Equipo auto gestionado
El equipo de trabajo se mantiene motivado cuando
pueden usar su creatividad para resolver problemas
y cuando puede organizar su trabajo.
El equipo de desarrollo es quien se compromete a
completar los requisitos seleccionados en una
iteración y quien mejor sabe cómo desarrollarlos.
Por ello es el equipo quien se auto organiza y quien
planifica cómo trabajará en la iteración.
4.3 Modelo de transición de metodología RUP a SCRUM
Anexo se encuentra el modelo de transición de la metodología RUP a SCRUM construido,
basado en el análisis de la información recopilada a lo largo de la investigación.
59
Figura 5. Modelo de transición de metodología RUP a SCRUM
El modelo de transición está definido en tres fases (Análisis, definición y ejecución) abarcando
cinco áreas (Talento humano, procesos, documentación, costos y negocio), las cuales se
consideran las principales a tener en cuenta dentro del proceso de adopción de la nueva
metodología SCRUM.
Es de aclarar que este modelo fue construido teniendo como punto de referencia el proceso RUP
pero este puede ser aplicado independientemente cual sea la metodología que esté usando la
organización si su objetivo es implementar proyectos bajo SCRUM, también se debe tener en
cuenta que el modelo está enfocado como una guía o marco de referencias para las
organizaciones que estén en proceso iniciar el uso de SCRUM en sus proyectos, si la
60
organización ya tiene consolidada la metodología SCRUM este modelo será un punto de
verificación.
A continuación se describe el modelo abordando cada una de sus fases:
o Fase de Análisis.
En esta fase se realiza el análisis preliminar de viabilidad y prerrequisitos básicos para adoptar la
metodología SCRUM.
● Análisis de costos
El análisis de costos es el punto de partida para la implementación de la metodología
SCRUM en los proyectos dado que uno de los pilares de esta metodología es contar con
dedicación exclusiva del equipo de trabajo al desarrollo de las actividades definidas en los
sprints desde el inicio del mismo, lo cual de acuerdo a las investigaciones realizadas ha
significado costos adicionales al estimado bajo la metodología RUP, en la medida que
bajo esta última los recursos pueden ser usados a demanda de acuerdo a la etapa en la cual
se encuentra el proyecto. El análisis de costos puede variar si el equipo SCRUM es
totalmente interno de la compañía, contratado con un proveedor de servicios de desarrollo
o mixto.
De acuerdo a lo anterior la compañía debe analizar si cuenta con la capacidad financiera
para la adopción de SCRUM teniendo en cuenta principalmente la relación
costo/beneficio y el retorno dela inversión
61
● Análisis de procesos
El análisis de procesos consiste en revisar a detalle los procesos actuales con los que
cuenta la organización ya sea por sus procesos de calidad internos, regulaciones de ley o
normativas externas que deba cumplir la organización.
● Análisis de proyectos a trabajar bajo SCRUM
Se debe realizar un análisis preliminar para definir los proyectos que por su naturaleza,
alcance, dependencias o presupuesto puedan ser trabajados bajo la metodología SCRUM.
o Fase de Definición
En esta fase se definen los aspectos que deben ser ejecutados, adaptados o revisados previamente
a la ejecución o inicio de un proyecto bajo la metodología SCRUM.
● Selección de procesos mínimos requeridos
Posterior al análisis del inventario total de los procesos de la organización, es requerido
seleccionar cuáles de ellos son el mínimo requerido que se debe ser adaptado a la nueva
metodología o cuales se deben seguir ejecutando para el cumplimiento con las políticas
internas y con las normativas o regulaciones externas que apliquen según la organización.
● Homologar actividades SCRUM con procesos existentes
De acuerdo a los procesos mínimos requeridos se debe realizar una revisión detallada de
las actividades definidas dentro del proceso con relación a las actividades de la
metodología SCRUM con el fin de homologarlas o definir el manejo que se le va a dar a
62
las que no estén contempladas en SCRUM.
● Conformación del equipo de trabajo
Se debe conformar el equipo de trabajo previamente a la ejecución del proyecto
definiendo los roles a desempeñar por cada uno de los integrantes dentro el equipo de
trabajo.
● Sensibilización del personal
Es conveniente realizar una sensibilización con todos los miembros de la organización
que puedan llegar a tener relación con los proyectos o el equipo de trabajo, respecto a
beneficios y cambios que puede generar la adopción de la nueva metodología, de ser
posible desde la perspectiva de cada uno de los roles de la organización.
● Capacitación del personal
Una vez conformado el equipo de trabajo, es requerido realizar un proceso de
capacitación de acuerdo a las capacidades que la organización considere requeridas o de
valor para los miembros del equipo para el desarrollo de las actividades, como pueden ser
temas relacionados con metodologías ágiles, temas técnicos, trabajo en equipo,
negociación, etc
● Empoderamiento del equipo de trabajo
Uno de los puntos más relevantes en lo correspondiente al equipo de trabajo es que se
debe otorgar todo el empoderamiento requerido para la toma de decisiones respecto al
proyecto con el fin que en la ejecución el proyecto pueda fluir al ritmo esperado sin
63
requerir de escalamientos que puedan generar bloqueo en la ejecución de las actividades.
● Evaluar documentación requerida
De acuerdo a los procesos mínimos definidos y la homologación de los mismos con las
actividades SCRUM, es requerido evaluar la documentación actual en relación a la
definida según SCRUM para cumplimento de calidad, regulaciones y/o normativas.
● Documentación interna
Hace referencia a la documentación para cumplimiento de procesos internos de la
organización.
● Documentación regulaciones y/o normativas
Hace referencia a la documentación para cumplimiento de las regulaciones, leyes o
normativas externas que apliquen de acuerdo al tipo de compañía.
● Establecer documentos mínimos requeridos
De acuerdo a los procesos mínimos definidos y la homologación de los mismos con las
actividades SCRUM es necesario evaluar la documentación mínima requerida para
cumplimento de las regulaciones y/o normativas.
● Definir cantidad y tamaño de los equipos de trabajo
Con base a los proyectos que se van a trabajar bajo la metodología SCRUM y a la
capacidad financiera con la que cuente la organización, se define la cantidad de los
equipos SCRUM que trabajaran en los diferentes proyectos y el tamaño de cada uno de
64
ellos. Se debe tener muy claro que en la mayoría de los casos la capacidad financiera es
menor a las expectativas del usuario, por lo cual este primer factor resulta siendo el
determinante en la definición del equipo de trabajo.
● Provisión del presupuesto para ejecución
Una vez definido los equipos de trabajo se debe realizar un aprovisionamiento de recursos
dentro del presupuesto de la organización o del área, con el fin de contar con los recursos
financieros requeridos y que éste factor no sea un impedimento durante la ejecución de
los proyectos.
o Fase de Ejecución
En esta fase se describen las actividades que se deberán llevar a cabo durante la ejecución de un
proyecto con la nueva metodología SCRUM
● Definir proyecto piloto
Este es uno de los puntos más importantes a tener en cuenta durante el proceso de
implantación de la nueva metodología; en este paso del modelo se debe seleccionar un
proyecto piloto con el cual se trabajará bajo la nueva metodología y el cual sirve como
base de conocimiento para identificar y aplicar los puntos de mejora identificados.
Dado que durante la ejecución de los primeros proyectos bajo la nueva metodología, la
organización y equipos de trabajo aún no tiene la suficiente madurez en el uso de
SCRUM, estos primeros proyectos deben ser de impacto medio o bajo para la
organización, con el fin que no afecten las proyecciones estratégicas y tácticas del
65
negocio y se pueda ganar experiencia con la ejecución de cada uno de los proyectos,
buscando un punto de madurez lo suficientemente alto en el uso de la metodología para
posteriormente aplicarlo a los proyectos críticos o estratégicos de la organización.
● Definir mínimo producto viable y mínimo comercializable
De acuerdo con el proyecto piloto seleccionado se debe definir el mínimo producto viable
y mínimo producto comercializable para que con base en esto definir las historias de
usuario a trabajar.
Mínimo producto viable: Entregable o paquete funcional que los diferentes usuarios
pueden usar, probar y evaluar.
Mínimo producto comercializable: Entregable probado y evaluado por los diferentes
usuarios internos de la organización y que se considera que cuenta con la calidad y
funcionalidad mínima o requerida para ser liberada a los clientes
● Definir historias de usuario priorizadas
Con base al mínimo producto viable se deben construir las historias de usuario y
priorizarlas de acuerdo a su relevancia o dependencia que genera para otras historias de
usuario, con el fin que el equipo tenga claro desde el inicio a que debe centrarse especial
atención en caso de presentarse eventualidades.
● Acordar capacidad base
Con base a la métrica usada para la estimación, la cantidad de recursos, conocimiento
66
específico, experiencia de los recursos etc. El equipo SCRUM debe acordar la capacidad
con la cual se trabajará cada Sprint. Esta capacidad base será una medida inicial
posiblemente definida subjetivamente la cual se debe refinar con la ejecución de cada
Sprint de acuerdo a las métricas que puedan definirse.
● Ejecutar un Sprint de diagnóstico
Debido a que varios aspectos de la nueva metodología son inciertos y poco explorados
por el equipo de trabajo como por ejemplo la capacidad del equipo SCRUM, es
conveniente que el primer o los primeros Sprint sean ejecutados bajo la concepción de
diagnóstico con el fin de establecer y obtener las métricas requeridas para lograr la mejora
continua.
● Optimizar
Con el objetivo de lograr una mejora de manera continua en el rendimiento,
productividad y la calidad de los productos, el equipo debe analizar cómo ha sido su
manera de trabajar durante el Sprint, identificando las razones del porque se está
consiguiendo o no los objetivos a que se comprometió el equipo.
Los principales aspectos que se deben evaluar son:
Qué cosas han funcionado bien.
Qué cosas hay que mejorar.
Qué cosas se quieren probar en el siguiente Sprint.
Qué se aprendió de la ejecución del Sprint de diagnóstico.
Cuáles son los problemas que podrían impedirle lograr los objetivos trazados.
67
● Consolidar
Con base al proceso de optimización ejecutado es conveniente consolidar las métricas, la
capacidad y el rendimiento, con el objetivo de tener una base del equipo de trabajo, el
cual será el referente de los nuevos equipos SCRUM que se quieran establecer en un
futuro.
Se debe tener muy claro que el proceso de consolidar es iterativo y debe ser alimentado
constantemente con el proceso de previo de optimizar.
68
5 Capítulo 4 Comprobación del modelo de transición de metodología RUP a SCRUM
4.
5.1 Encuestas
El objetivo de las encuestas es calcular el porcentajes el uso del marco de trabajo SCRUM en los
proyectos de desarrollos de software y poder determinar qué aspectos de los planteados en el
modelo de transición, tienen un alto grado de incertidumbre o posiblemente no son contemplados
por los encuestados a la hora de dar inicio a un proyecto bajo la metodología SCRUM, lo cual
nos confirma la necesidad de contar con un modelo que pueda optimizar y reducir el riesgo al
momento de iniciar a ejecutar proyectos bajo SCRUM.
Se realizó la encuesta a 20 empleados con profesiones de Ingenieros de Sistemas, Ingenieros
Industriales e Ingenieros en telecomunicaciones de diferentes compañías como se muestra en la
Figura 6, quienes pertenecen al área de Sistemas o Telecomunicaciones.
Figura 6. Personas encuestadas por empresa
69
El cuestionario aplicado a los diferentes roles que participan en la implementación de proyectos
de desarrollo de software generó los siguientes resultados:
5.1.1 Análisis de Costos.
El 25% de las personas encuestadas consideran que tener un experto con dedicación exclusiva
desde el inicio del proyecto es muy costoso, mientras que el 75% afirman lo contrario, ver Figura
7.
Figura 7. Análisis de Costos con dedicación exclusiva de un experto
5.1.2 Eficiencia
El 95% de las personas encuestadas consideran que las metodologías ágiles aumentan la
eficiencia en el desarrollo de proyectos tecnológicos, en cuanto al 5% restante opina lo contrario,
ver Figura 8.
70
Figura 8. SCRUM aumenta la eficiencia en el desarrollo de proyectos tecnológicos
5.1.3 Gestión.
El 85% de las personas encuestadas consideran que SCRUM tiene todos los
mecanismos y/o estrategias necesarias para el cumplimiento de las políticas
organizacionales, mientras que el 15% restante opina lo contrario, ver Figura 9.
Figura 9. SCRUM cuenta con mecanismos y estrategias
5.1.4 Procesos internos
El 60% de las personas encuestadas afirman que con el uso de SCRUM es posible dar
71
cumplimiento a todos los procesos definidos en su organización, mientras que el 40%
confirma lo contrario, ver Figura 10.
Figura 10. SCRUM permite cumplir con los procesos de la organización
5.1.5 Capacitación
El 10% de los encuestados afirman que los temas tratados y la periodicidad de la
capacitación que realiza la compañía sobre su metodología es suficiente, mientras que el
35% opina lo contrario y el 55% restante confirman que no se recibe capacitación, Ver
Figura 11.
Figura 11. Capacitación de metodología
72
5.1.6 Proyecto Piloto
El 5% de las personas encuestadas afirman que el tipo de proyecto de Alto Impacto se
considera apropiado para hacer uso por primera vez de la metodología SCRUM, el 70%
opina que eso aplica mejor en proyectos de Mediano Impacto y el 25% restante eligen el
proyecto de Bajo Impacto, ver Figura 12.
Figura 12. Proyecto Piloto
5.1.7 Autonomía
El 55% de las personas encuestadas confirman que, si alguno de ellos fuera parte del
equipo de trabajo de SCRUM, tendrían autonomía en la toma de decisiones, el 10% opina
que no tendrían autonomía y el 35% restante respondieron que algunas veces, ver Figura
13.
73
Figura 13. Autonomía en SCRUM
74
6 Conclusiones
Se identificó como mejores prácticas consolidar el equipo de trabajo minimizando al máximo los
cambios de personal dentro del equipo, mantener una buena relación entre el equipo de trabajo,
estructurar adecuadamente los requerimientos funcionales (Historias de usuario) incluyendo los
usuarios finales y tener claro desde el inicio el proyecto los mínimos productos viables y
comercializables.
La gestión de proyectos usando un modelo de desarrollo RUP puede ser un problema si en esta se
aplican métodos pesados, o si es aplicada a proyectos muy pequeños ya que por el grado de
complejidad puede ser no muy adecuado, o es posible que no se puedan cubrir los costos de
dedicación del equipo de profesionales necesarios.
Para las empresas que tengan proyectos en ejecución con metodología RUP y den inicio a
proyectos bajo SCRUM que tienen una interdependencia, es necesario validar aspectos como
costos en la adquisición de recursos especializados y herramientas de trabajo, la planificación de
la dedicación del equipo, capacitación del equipo, roles, eventos y artefactos, así como es
necesario contar con el compromiso de alta gerencia.
Con el análisis DOFA realizado en la investigación se identificaron los principales problemas o
debilidades en la ejecución de proyectos bajo el proceso RUP, así como las fortalezas y
debilidades entre los marcos de trabajo RUP y SCRUM.
Con base en los objetivos planteados podemos concluir que el modelo propuesto ofrece un marco
de referencia, el cual puede ser aplicado por las organizaciones durante la implementación de la
75
metodología SCRUM en la ejecución de los proyectos de desarrollo de software, logrando que
sean tenidos en cuenta la mayoría de los aspectos relevantes en este proceso, aportando un valor
agregado a las compañías durante la transición al uso de SCRUM.
A partir de la iniciativa de generar un modelo en la transición RUP a SCRUM, encontramos que
las compañías tienen una gran confianza en la utilización de SCRUM para proyectos de
desarrollo de Software. Sin embargo, aunque SCRUM es una metodología óptima es muy
importante que las empresas lo hagan de forma correcta, ya que por su fácil implantación y por su
agilidad en los procesos, las compañías tienden a iniciar su utilización con proyectos de alto
impacto. Se debe tener en cuenta que el equipo de trabajo aún no tiene la experticia suficiente
para llevar con éxito proyectos de gran tamaño o críticos para la organización.
Se identificó que por la facilidad en la implantación de la metodología SCRUM, las
organizaciones dejan de lado aspectos importantes que deben ser evaluados y definidos
detenidamente y previamente al inicio de los proyectos buscando que algún punto no
contemplado genere un impacto negativo o se convierta en impedimento para la ejecución exitosa
del proyecto.
Los aportes de la metodología SCRUM dentro del ciclo de vida de los proyectos que no son otra
cosa más que distintos pasos a seguir para el desarrollo de software se encuentran ventajas como
resultados tangibles, adaptación, mitigación de riesgos, productividad, calidad, gestión de
expectativas y equipo motivado, estos aportes permiten una adaptación a cualquier situación que
se pueda presentar.
76
7 Bibliografía y referencias bibliográficas
Guía SBOK™ (2016). Una guía para el cuerpo de conocimiento de SCRUM (Guía SBOK™) -
2016 Edición.
Booch, G.; Jacobson, I. & Rumbaugh, J.(2006), El Proceso Unificado de Desarrollo de Software
Edición. Addison Wesley Iberoamericana, Madrid. 2000
Bolaño Castro, S. J., Medina Garcia, V. H., & Ferro Escobar, R. (2016). MetaProceso de
Desarrollo de Software -El Grial de las Metodologías y Procesos. Bogotá: Editorial UD.
Gattaca S.A, “Presentación Metodología MSF”, Microsoft Solutions Framework [en linea],
[Fecha de consulta: 18 de Marzo de 2017] Disponible en:
http://docshare01.docshare.tips/files/5432/54320344.pdf
Microsoft, “Visión general de Microsoft Solutions Framework (MSF), Microsoft, [Fecha de
consulta: 18 de Marzo de 2017] disponible en:
https://translate.google.com.co/translate?hl=es&sl=en&u=https://msdn.microsoft.com/en-
us/library/jj161047(v%3Dvs.120).aspx&prev=search.
SCRUMstudy (2016), Una guía para el Cuerpo de Conocimiento de SCRUM (Guía SBOK™) –
3ra Edición [en línea], [Fecha de consulta: 14 de Marzo de 2017] Disponible
77
en:<http://www.SCRUMstudy.com/SBOKGuide/Download-Free-Buy-SBOK .
(Sprint), “Ejecución de la iteración (Sprint)”), proyectosagiles.org, [Fecha de consulta: 18 de
Marzo de 2017] disponible en: https://proyectosagiles.org/ejecucion-iteracion-sprint/
Project Manager Soy, CERTIFICACIÓN SCRUM MANAGER, [en línea], [Fecha de consulta:
16 de Marzo de 2017] Disponible en: http://www.projectmanager.soy
Proyectos agiles, Beneficios de SCRUM, proyectosagiles.org, [en línea], [Fecha de consulta: 10
de Octubre de 2017] Disponible en: https://proyectosagiles.org/beneficios-de-SCRUM/
Matrizfoda, Ejemplos de matriz foda, matrizfoda.com, [en línea], [Fecha de consulta: 12 de
Octubre de 2017] Disponible en: http://www.matrizfoda.com/dafo/que-es-la-matriz-
foda/fortalezas-y-debilidades/
IeBS, ¿Qué es el método SCRUM y que beneficios y ventajas va a aportar a mi negocio? (2014),
[en línea], [Fecha de consulta: 12 de Octubre de 2017] Disponible en:
http://www.iebschool.com/blog/que-es-SCRUM-beneficios-ventajas-para-negocio-agile-
SCRUM/
EDT, 6 ventajas de la metodología SCRUM para tu empresa, [en línea], [Fecha de consulta: 14
78
de Octubre de 2017] Disponible en: http://www.edt.es/6-ventajas-de-la-metodologia-SCRUM-
agile-para-tu-empresa/
AlfaTec, Los 10 beneficios de la metodología SCRUM, , [en línea], [Fecha de consulta: 14 de
Octubre de 2017] Disponible en: https://alfatecsistemas.es/los-10-beneficios-la-metodologia-
SCRUM/
79
8 ANEXOS
Anexo A. Encuesta de Investigación de Transición de RUP a SCRUM.
Objetivo del estudio es determinación el nivel de uso del marco de trabajo SCRUM en los
proyectos de desarrollos de software. La encuesta fue aplicada a los Perfiles de: PM, Coordinares
de Sistemas, Jefes de Sistemas, Consultores y Desarrollares.
A continuación se detallan las preguntas aplicadas con sus opciones de respuesta:
1. ¿Considera que tener un experto con dedicación exclusiva desde el inicio del proyecto es
más costoso?
a. Si
b. No
Resultados:
Gráfica 1. Análisis de Costos con dedicación exclusiva de un experto
2. ¿Considera que las metodologías ágiles aumentan la eficiencia en el desarrollo de
proyectos tecnológicos?
80
a. Si
b. No
Resultados:
Gráfica 2. SCRUM aumenta la eficiencia en el desarrollo de proyectos tecnológicos
3. ¿Considera que SCRUM tiene todos los mecanismos y/o estrategias necesarios para el
cumplimiento de las políticas organizacionales?
a. Si
b. No
Resultados:
Gráfica 3. SCRUM tiene mecanismos y estrategias
81
4. ¿Haciendo uso de SCRUM es posible dar cumplimiento a todos los procesos definidos en
su organización?
a. Si
b. No
Resultados:
Gráfica 4. SCRUM permite cumplir con los procesos de la organización
5. ¿Los temas tratados y la periodicidad de la capacitación que realiza la compañía sobre su
metodología es suficiente?
a. Si
b. No
c. No se recibe capacitación
Resultados:
82
Gráfica 5. Capacitación de metodología
6. ¿Qué tipo de proyecto considera apropiado para hacer uso por primera vez de la
metodología SCRUM?
a. Proyecto de Alto Impacto
b. Proyecto de Mediano Impacto
c. Proyecto de Bajo Impacto
Resultados:
Gráfica 6. Proyecto Piloto
83
7. ¿Si usted fuera parte del equipo de trabajo de SCRUM, tiene autonomía en la toma de
decisiones?
a. Si
b. No
c. Algunas Veces
Resultados:
Gráfica 7. Autonomía en SCRUM
![PROCEEDINGS OF SPIE · 7580 0I High average and peak power pulsed fiber lasers at 1030 nm, 515 nm, and 343 nm [7580-17] J. Saby, B. Cocquelin, A. Meunier, S. Pierrot, P.-J. Devilder,](https://img.pdfslide.us/doc/110x75/5f0226017e708231d402cfc7/proceedings-of-spie-7580-0i-high-average-and-peak-power-pulsed-fiber-lasers-at-1030.jpg)
