Antonio Garea Muina TFM MasterDip

Implantación de un Servicio
en una Empresa de Desarrollo Software con

Metodología DIP
Tutores: Óscar García & Eduardo Sanjurjo Antonio Garea Muiña – 2018
“Implantación dun Servicio DevOps nunha Empresa de Desenrolo

Software con Metodoloxía DIP”
“Implementation of a DevOps Service in a Software Development
Company with DIP Methodology”
IMPLANTACIÓN DE UN SERVICIO DEVOPS
1
AUTOR: Antonio Garea Muíña - [2018]
RESUMEN
En el presente Trabajo de Fin de Máster se plantea la dirección de un proyecto de tecnologías

de la información.
Nos ponemos en el supuesto de que nuestra Organización consigue un contrato con un Cliente
de ámbito internacional, y que nos encarga la dirección integral del mismo. La singularidad de
su modelo de gestión, basado en la innovación y la flexibilidad, y los logros alcanzados, han
convertido a dicho Cliente en uno de los mayores grupos de distribución de moda.
Este documento tiene como objetivo definir la implantación de un Servicio DevOps, que
mediante el uso de un conjunto de herramientas, patrones y buenas prácticas permita que los
productos software, desarrollados por el Departamento de Sistemas de Información de Cliente,
se construyan de una manera que puedan ser liberados en entornos productivos de una forma
ágil, segura y en cualquier momento.
Para la realización nos apoyamos en la aplicación de una Metodología Mixta, que combina:
 Metodología Predictiva, PMBOK®

 Metodología Ágil, SCRUM®
SUMMARY
In the present Master's Thesis, the direction of an information technology project is presented.
We put ourselves on the assumption that our organization gets a contract with a client of
international scope, and that it entrusts us with the integral management of it. The uniqueness
of its management model, based on innovation and flexibility, and the achievements made,
became that customer in one of the largest fashion distribution groups.
This document aims to implement a DevOps service, which through the use of a set of tools,
patterns and best practices allows the software of the products by the Customer Information
Systems Department, is constructed in a way that will be serrated in productive environments in
an agile, safe and at any time.
For the realization we rely on the application of a Mixed Methodology, which combines:
 Predictive Methodology, PMBOK®
 Agile Methodology, SCRUM®
PALABRAS CLAVE
Implantación, DevOps, Metodología, Predictiva, Ágil, Mixta, Integración, PMBOK, SCRUM,

Integración Continua, Release
2
Índice
RESUMEN ...................................................................................................................................... 2
SUMMARY ..................................................................................................................................... 2
PALABRAS CLAVE........................................................................................................................... 2
1. INTRODUCCIÓN ........................................................................................................................ 7
1.1. CONTEXTUALIZACIÓN........................................................................................................ 7
1.1.1. Desarrollo tradicional de software y problemática detectada ................................... 7
1.1.2. La solución: DevOps .................................................................................................. 10
1.1.3. Metodologías Ágiles – SCRUM .................................................................................. 12
1.2. DESCRIPCIÓN DEL PROYECTO ......................................................................................... 13
1.3. OBJETIVOS ....................................................................................................................... 13
1.4. CICLO DE VIDA DEL PROYECTO........................................................................................ 13
2. PLAN PARA LA DIRECCIÓN DEL PROYECTO............................................................................ 15
2.1. GRUPO DE PROCESOS DE INICIO ..................................................................................... 15
2.1.1. Acta de Constitución ................................................................................................. 15
2.1.2. Identificar a los interesados ...................................................................................... 23
2.2. GRUPO DE PROCESOS DE PLANIFICACIÓN...................................................................... 24
2.2.1. Plan para la dirección del proyecto ........................................................................... 24
2.2.2. Gestión del Alcance ................................................................................................... 25
2.2.3. Integración de metodología SCRUM ......................................................................... 32
2.2.4. Gestión del Tiempo ................................................................................................... 32
2.2.5. Gestión de los Costos ................................................................................................ 34
2.2.6. Gestión de la Calidad ................................................................................................. 36
2.2.7. Gestión de los Recursos ............................................................................................ 38
2.2.8. Gestión de las Comunicaciones ................................................................................. 40
2.2.9. Gestión de los Riesgos ............................................................................................... 42
2.2.10. Gestión de las Adquisiciones ................................................................................... 44
2.2.11. Gestión de los Interesados ...................................................................................... 45
2.3. GRUPO DE PROCESOS DE EJECUCIÓN ............................................................................. 46
2.3.1. Agilizar aplicando metodología SCRUM .................................................................... 46
2.3.2. Dirigir y gestionar el trabajo del proyecto ................................................................ 46
2.3.3. Gestionar el conocimiento del proyecto ................................................................... 47
2.3.4. Gestionar la participación de los interesados ........................................................... 47
2.3.5. Adquirir recursos ...................................................................................................... 47
2.3.6. Desarrollar el equipo ................................................................................................ 47
2.3.7. Dirigir el equipo ........................................................................................................ 48
3
2.3.8. Gestionar las comunicaciones .................................................................................. 48

2.3.9. Efectuar las adquisiciones ........................................................................................ 48
2.3.10. Gestionar la calidad ................................................................................................ 48
2.3.11. Implementar las respuestas a los riesgos............................................................... 49
2.4. PROCESOS DE SEGUIMIENTO Y CONTROL ...................................................................... 49
2.4.1. Seguir y controlar el trabajo del proyecto ................................................................ 49
2.4.2. Realizar el control integrado de cambios .................................................................. 49
2.4.3. Gestión ágil del cambio con metodología SCRUM .................................................... 49
2.4.4. Controlar el involucramiento de los interesados ...................................................... 50
2.4.5. Controlar el cronograma ........................................................................................... 50
2.4.6. Controlar los costos ................................................................................................... 51
2.4.7. Controlar las comunicaciones ................................................................................... 51
2.4.8. Controlar los riesgos.................................................................................................. 52
2.4.9. Control de riesgos ágil con metodología SCRUM ...................................................... 52
2.4.10. Controlar la calidad ................................................................................................. 52
2.4.11. Controlar los recursos ............................................................................................. 53
2.4.12. Control ágil de los recursos con metodología SCRUM ............................................ 53
2.4.13. Validar el alcance .................................................................................................... 53
2.4.14. Controlar el alcance ................................................................................................ 54
2.4.15. Controlar el alcance mediante metodología SCRUM .............................................. 54
2.4.16. Controlar las adquisiciones ..................................................................................... 55
2.5. PROCESOS DE CIERRE ...................................................................................................... 55
2.5.1. Cerrar el proyecto ..................................................................................................... 55
3. CONCLUSIÓN........................................................................................................................... 57
4. ANEXOS ................................................................................................................................... 58
A1 – Ecosistema Cliente ......................................................................................................... 58
A1.1 – Estructura ................................................................................................................. 58
A1.2 – Jira ............................................................................................................................ 59
A1.3 – Confluence ............................................................................................................... 60
A2 – Herramientas DevOps .................................................................................................... 62
A3 – Modelo Simplificado DevOps......................................................................................... 64
A4 - Beneficios que aporta SCRUM al proceso de desarrollo .............................................. 65
A5 - Modelo SCRUM .............................................................................................................. 65
A5.1 - Roles dentro de un equipo Scrum ............................................................................ 66
A5.2 - Tareas de Scrum........................................................................................................ 66
A5.3 - Fases de Scrum ......................................................................................................... 66
4
A6 – Gestión de riesgos .......................................................................................................... 67

A6.1. – Identificación de riesgos ......................................................................................... 67
A6.2 – Análisis cualitativo.................................................................................................... 70
A6.3 – Análisis cuantitativo ................................................................................................. 73
A6.4. – Respuesta a los riesgos ........................................................................................... 76
A7- Pizarras SCRUM ................................................................................................................ 88
A8 - Tempo .............................................................................................................................. 89
A9 – Plantilla gestión del cambio ........................................................................................... 90
A10 – Modelo Checklist .......................................................................................................... 90
A11 – Encuesta de satisfacción .............................................................................................. 91
A12 – Modelo informe seguimiento ...................................................................................... 92
A13 – Detalle Gantt ................................................................................................................ 92
A13.1 – Ejecución SCRUM ................................................................................................... 92
A13.2 – Seguiento y control ................................................................................................ 92
A14 – Gráfico BurnDown ........................................................................................................ 93
A15 – Primeros resultados ..................................................................................................... 94
A16 – Lecciones aprendidas ................................................................................................... 95
A17 – Diccionario de la EDT.................................................................................................... 95
5. BIBLIOGRAFÍA Y EGRAFÍA ....................................................................................................... 97
5.1. BIBLIOGRAFÍA .................................................................................................................. 97
5.2. EGRAFÍA ........................................................................................................................... 97
5
Tabla de ilustraciones
Ilustración 1- Desarrollo tradicional [Antonio Garea] ................................................................... 7
Ilustración 2- Problemática [Antonio Garea] ................................................................................ 9
Ilustración 3 - Interrelaciones DevOps [Antonio Garea] ............................................................. 10
Ilustración 4 - Ciclo DevOps [Ref: E06] ........................................................................................ 10
Ilustración 5 - Mapa de ruta DevOps [Ref: E07] .......................................................................... 11
Ilustración 6 - Características DevOps [Antonio Garea] .............................................................. 11
Ilustración 7- Beneficios DevOps [Antonio Garea] ...................................................................... 11
Ilustración 8 - Ciclo SRUM [Antonio Garea] ................................................................................ 12
Ilustración 9 - Ciclo de Vida Proyecto [Antonio Garea] ............................................................... 14
Ilustración 10 - Organigrama alto nivel [Antonio Garea] ............................................................ 22
Ilustración 11- Flujo gestión de cambios [Antonio Garea] .......................................................... 24
Ilustración 12 - Flujo gestión de alcance [Antonio Garea] .......................................................... 25
Ilustración 13 - Criterios SMART [Antonio Garea]....................................................................... 25
Ilustración 14 - EDT I [Antonio Garea]......................................................................................... 30
Ilustración 15 - EDT II [Antonio Garea]........................................................................................ 31
Ilustración 16- EDT III [Antonio Garea] ....................................................................................... 31
Ilustración 17 - Cronograma [Antonio Garea] ............................................................................. 33
Ilustración 18 - Organigrama completo [Antonio Garea] ........................................................... 38
Ilustración 19 - Flujo de gestion de riesgos [Antonio Garea] ...................................................... 42
Ilustración 20 - Dashboard Jira [Ref: E04] ................................................................................... 60
Ilustración 21 - Dashboard Confluence [Antonio Garea] ............................................................ 61
Ilustración 22 - Espacio de proyecto en Confluence [Antonio Garea] ........................................ 62
Ilustración 23- Herramientas DevOps [E08] ................................................................................ 63
Ilustración 24- Modelo Simplificado DevOps [Antonio Garea] ................................................... 64
Ilustración 25- Modelo SCRUM [Ref: E09] .................................................................................. 65
Ilustración 26 - Pizarra SCRUM [Ref. E12] ................................................................................... 88
Ilustración 27 - Pizarra SCRUM Virtual vs Física [Ref. E04] ......................................................... 88
Ilustración 28 - Dashboard Jira [Ref. E04] ................................................................................... 89
Ilustración 29 - Tempo [Ref. E04] ................................................................................................ 89
Ilustración 30 - Plantilla gesión del cambio [Antonio Garea] ...................................................... 90
Ilustración 31 - Modelo Checklist [Antonio Garea] ..................................................................... 90
Ilustración 32 - Encuesta satisfacción [Antonio Garea] .............................................................. 91
Ilustración 33- Modelo informe seguimiento [Antonio Garea] .................................................. 92
Ilustración 34 - Diagrama gantt ejecución SCRUM [Antonio Garea] .......................................... 92
Ilustración 35- Diagrama gantt seguimiento y control [Antonio Garea]..................................... 92
Ilustración 36 - Gráfico BurnDown [Ref. E10] ............................................................................. 93
Ilustración 37- Integración contínua [Ref. E11]........................................................................... 94
6
1. INTRODUCCIÓN
En el presente Trabajo de Fin de Máster se plantea la dirección de un proyecto de tecnologías
de la información.
Nos ponemos en el supuesto de que nuestra Organización consigue un contrato con un Cliente
de ámbito internacional, y que nos encarga la dirección integral del mismo.
1.1. CONTEXTUALIZACIÓN
El desarrollo de productos software es una consecución de fases y tareas que han de realizarse
en base a un orden y tiempo determinados. Las necesidades de usuarios, clientes y sectores de
negocio se han vuelto más exigentes a lo largo del tiempo, tanto en calidad del resultado final
como en tiempo de ejecución del proyecto.
A continuación, se realizará una presentación del marco de aplicación sobre el que tiene lugar
el desarrollo de este trabajo. Para ello se presentará:
 El modelo tradicional de creación de software
 El concepto DevOps y campo de aplicación
 Las metodologías ágiles
1.1.1. Desarrollo tradicional de software y problemática detectada

En el sistema tradicional de desarrollo software identificamos claramente los siguientes
procesos que, aunque ordenados, se ejecutan de modo aislado. En consecuencia, la transición
entre los mismos se realiza de un modo ‘manual’ y gran parte de las ocasiones sin una operativa
y procedimientos claros y seguros.
Ilustración 1- Desarrollo tradicional [Antonio Garea]
Como podemos observar, y como consecuencia de los ‘gap’ originados, detectamos los
siguientes puntos de mejora:
 Tiempo: La transición entre los diferentes procesos del desarrollo de un proyecto

implica dedicar horas presupuestadas que no se reflejaran en el producto final.
 Oportunidad: El tiempo que dedicamos a estas tareas no lo invertimos en otras de más
valor para la Compañía.
7
 Talento: Estamos desperdiciando el talento de los empleados en tareas monótonas que

no representan retos (a pesar de la problemática que conllevan), llevado al extremo
podría provocar desmotivación y pérdida de compromiso.
Vemos por lo tanto que los esfuerzos realizados no tendrán retorno ni valor como tal.
1.1.1.1. Problemática general en el desarrollo de aplicaciones

Adicionalmente a lo expuesto, y tras las sucesivas reuniones de toma de requisitos con los
responsables técnicos de las diferentes áreas:
 Se identifica el ecosistema del Cliente, ver ANEXO A1 – Ecosistema Cliente.
 Se crea la siguiente clasificación de problemas a solucionar
Problemas con la gestión de código

El actual esquema de la instalación de SVN (Subversion, herramienta de control de versiones
software) hace que todos los proyectos de Departamento de Sistemas residan bajo el mismo
repositorio. Debido al alto número de desarrolladores trabajando contra la herramienta la
cantidad de 'commits' integrados se incrementa cada segundo ocasionando que:
 sea más compleja la traza de cambios y el seguimiento de las revisiones.
 sea imposible realizar 'dumps' y otras operaciones masivas sobre las máquinas debido a
la cantidad de recursos necesaria para llevarlas a cabo.
La existencia de equipos inmaduros, con el uso de SVN ocasionan cierto descontrol y malas
prácticas en la gestión de ramas, en especial los 'tags'. Esto hace difícil e ineficiente la traza de
cambios del código fuente.
Si bien es un tema que quedaría resuelto con una sesión de divulgación para corregir estos
comportamientos, no asegura que no se repliquen a futuro. Por ello se solicita que nuestro
Sistema, de forma automática, gestione la creación y archivado de 'tags'.
Por otro lado, dentro de los equipos más maduros, que trabajan de forma correcta con el
repositorio corporativo, crece la demanda de un sistema que permita trabajar de forma
distribuida (Git).
Problemas con la generación de artefactos

Se detecta que los equipos de las diferentes áreas mantienen código que cubre casos de uso
similares, esto hace que en cada nuevo proyecto se pierda tiempo 'reinventando la rueda' y que
el repositorio se llene de código sin valor. Por ello, se hace necesario un sistema que permita
disponer de librerías o módulos reutilizables entre los distintos equipos de un área funcional e
incluso llegar a tenerlos accesibles al resto del Departamento de Sistemas.
Como consecuencia del gran número de desarrollos y personas involucradas, somos alertados
del alto tráfico que se genera entre los equipos informáticos de los programadores y los
repositorios públicos de artefactos de los que hace uso su instalación local de Maven
(herramienta para la construcción de aplicaciones Java a partir del código fuente). Esto, aparte
de ser totalmente ineficiente, penaliza el rendimiento de varios procesos de la Organización en
horas de máxima actividad.
8
Problemas con la puesta en producción

El proceso de generación de artefactos software de las áreas funcionales se delega a los equipos
de desarrollo. Por lo que no existe la certeza de que lo que se instala o actualiza sea lo que
realmente aparece en los repositorios.
Del mismo modo, no se puede asegurar que las aplicaciones pasaron por todos los test y
exigencias mínimas de calidad antes de su puesta en producción.
Por otro lado, con la configuración actual de entornos previos los equipos de desarrollo se ven
obligados a esperar al pase a preproducción para probar realmente su aplicación. Esto es debido
a que, a pesar de los volcados de datos periódicos a desarrollo, no es posible replicar todo el
ecosistema que tiene el entorno de preproducción/producción. Por ello las pruebas previas a la
liberación de una versión son en muchas ocasiones incompletas.
Problemas de calidad
El proceso de validación no se encuentra industrializado, con lo que el testeo y controles de
calidad se delegan en los equipos y áreas de desarrollo. Esto conlleva dos problemas:
 Las pruebas y validaciones no son imparciales

 No hay un equipo QA (Quality Assurance), que vele por puestas en producción con unos
mínimos de calidad y rendimiento aceptables.
1.1.1.2. Problemática derivada de las nuevas exigencias de mercado

Adicionalmente identificamos toda la problemática que surge para dar respuesta a las
necesidades y exigencias del mercado para nuestro Cliente:
Ilustración 2- Problemática [Antonio Garea]
9
1.1.2. La solución: DevOps

DevOps es una metodología con la que se cambia el modo en el que se gestiona el ciclo de
desarrollo de software, a nivel tecnológico pero sobre todo a nivel cultural. Los equipos de
desarrollo y de Operaciones (o sistemas) eliminan el trabajo “en silos” y comienzan a trabajar
de una manera colaborativa y bidireccional. Entre todos cubren el ciclo completo de desarrollo
de software, garantizando procesos mucho más rápidos y seguros, entregas más fiables y
productos de calidad. Para conseguirlo, se introducen -como veremos después- nuevas
herramientas que contribuyen a la automatización de tareas repetitivas y al trabajo en equipo,
ayudando a agilizar los procesos y evitar trabajo duplicado y la introducción de nuevos errores.
DevOps establece una “intersección” entre

Desarrollo, Operaciones y Calidad, pero no se
rige por un marco estándar de prácticas, sino
que permite una interpretación mucho más
flexible en la medida en que cada organización
quiera llevarlo a la práctica, según su estructura
y circunstancias.
Ilustración 3 - Interrelaciones DevOps [Antonio

Garea]
A continuación, la representación del ciclo de desarrollo DevOps, en contraste ya deja entrever

el dinamismo frente a un modelo tradicional:
Ilustración 4 - Ciclo DevOps [Ref: E06]
10
Entrando más en detalle podemos observar el ‘road map’ de un ciclo DevOps:
Ilustración 5 - Mapa de ruta DevOps [Ref: E07]
Todo esto no sería posible sin un conjunto de herramientas debidamente integradas, en el:
 ANEXO A2 - Herramientas DevOps, desarrollamos este tema.

 ANEXO A3 - Modelo Simplificado, acercamos una aproximación al modelo que
proporcionaremos al Cliente.
Características y beneficios de implementar DevOps

A continuación, se reflejan las características y beneficios que aporta a las organizaciones la
implementación de un Servicio DevOps.
Características Beneficios
Ilustración 6 - Características DevOps [Antonio Garea]

Ilustración 7- Beneficios DevOps [Antonio
Garea]
11
DevOps tiene como objetivo maximizar la previsibilidad, eficiencia, seguridad y mantenimiento

de los procesos operativos. Es especialmente útil en el nuevo entorno de la transformación
digital y el desarrollo de productos digitales, para los que el usuario final y/o el cliente interno
de negocio demanda TTM (time-to-market), más flexibilidad, más calidad, menos coste y una
altísima frecuencia de entregas.
1.1.3. Metodologías Ágiles – SCRUM

Las metodologías ágiles (Agile), como SCRUM, se han usado típicamente para la implementación
de proyectos de desarrollo de software, esto es debido a que se trata de metodologías que son
capaces de adaptarse a las nuevas circunstancias del sector o del mercado de una manera rápida
y flexible.
Todas las metodologías que se consideran ágiles cumplen con el Manifiesto ágil, que no es más
que una serie de principios agrupados en tres valores:
1. Los individuos y su interacción: Por encima de los procesos y herramientas.

2. El software: Que funciona, frente a la documentación exhaustiva.
3. La colaboración con el cliente: Por encima del seguimiento de un plan.
Lo que se pretende con este tipo de metodologías es primar las tareas realmente importantes
frente a las que pueden ser menos importantes de cara al desarrollo del producto. Lo que mejora
en gran medida la productividad en el proceso de desarrollo.
1.1.3.1. SCRUM
Scrum es un método de trabajo ágil 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 dentro de un proyecto, minimizando así los riesgos derivados de los desarrollos muy
largos. Para esto es primordial la colaboración con el cliente, ya que es éste quien establece las
prioridades en función de sus necesidades.
Por ello, Scrum está especialmente indicado para proyectos en entornos complejos, donde se
necesitan obtener resultados de manera inmediata y donde la innovación, la competitividad, la
flexibilidad y la productividad son fundamentales.
Ilustración 8 - Ciclo SRUM [Antonio Garea]
12
BENEFICIOS QUE APORTA SCRUM
1.- Gestión de las expectativas del Cliente

2.- Reducción en tiempos de desarrollo y puesta en marcha
3.- Capacidad de adaptación
4.- Aumento de la productividad
5.- Estimación de esfuerzo continua
Para más detalle se puede consultar los recursos:
 ANEXO A4 – Beneficios que aporta SCRUM al proceso de desarrollo

 ANEXO A5 – Modelo SCRUM
1.2. DESCRIPCIÓN DEL PROYECTO

El presente proyecto se desarrolla en el seno de una Organización que reúne a más de un
centenar de sociedades vinculadas con las diferentes actividades que conforman el negocio
del diseño, la fabricación y la distribución textil.
La singularidad de su modelo de gestión, basado en la innovación y la flexibilidad, y los logros

alcanzados, han convertido a dicha empresa en uno de los mayores grupos de distribución de
moda.
El presente documento tiene como objetivo definir la implantación de un Servicio DevOps, que
mediante el uso de un conjunto de herramientas, patrones y buenas prácticas permita que los
productos software, desarrollados por el Departamento de Sistemas de Información de una
empresa, se construyan de una manera que puedan ser liberados en entornos productivos de
una forma ágil, segura y en cualquier momento.
1.3. OBJETIVOS
Los objetivos que buscamos con la realización de este proyecto:
 Mejora del TTM (time-to-market)

 Mejora de la flexibilidad
 Mejora de la calidad
 Incremento del número de despliegues
 Mejora de la rentabilidad
Para ello implantaremos un servicio DevOps y utilizaremos las metodologías tradicional

(PMBOK) y ágil (SCRUM).
1.4. CICLO DE VIDA DEL PROYECTO

El ciclo de vida de este proyecto está constituido por una única fase, que incluye los cinco
procesos: Inicio, Planificación, Ejecución, Seguimiento y Control, Cierre.
El proyecto se inicia con la firma del acta de constitución y se finaliza con la implantación DevOps
realizada, con la entrega de la documentación, con la entrega de la checklist con la validación y
con la firma del acta de cierre.
13
El proyecto deberá ser realizado en un plazo de 12 meses, con un presupuesto de 319.797,69 €.
Ilustración 9 - Ciclo de Vida Proyecto [Antonio Garea]
14
2. PLAN PARA LA DIRECCIÓN DEL PROYECTO
2.1. GRUPO DE PROCESOS DE INICIO
2.1.1. Acta de Constitución
DATOS DEL PROYECTO
PROYECTO Implantación de un Servicio DevOps en una

Empresa de Desarrollo Software
CÓDIGO DE PROYECTO PROPRD-DVPS- SW01
CÓDIGO DE CLIENTE SW01
DIRECTOR DEL PROYECTO Antonio Garea Muiña
VERSIÓN DEL ACTA 1.0.0
FECHA DE REDACCIÓN 2017/12/14
PROPÓSITO Y JUSTIFICACIÓN DEL PROYECTO
PROBLEMAS DETECTADOS:
Tras las sucesivas reuniones de toma de requisitos con los responsables técnicos de las
diferentes áreas se crea la siguiente clasificación de problemas a solucionar con la
implantación del Sistema de Entrega Continua:
 Problemas con la gestión de código
 Problemas con la generación de artefactos
 Problemas con la puesta en producción
 Problemas con los procesos
PROPÓSITO:
Definir la implantación de un Servicio DevOps, que mediante el uso de un conjunto de
herramientas, patrones y buenas prácticas permita que los productos software,
desarrollados por el Departamento de Sistemas de Información de una empresa en un
entorno real, se construyan de una manera que puedan ser liberados en entornos
productivos de una forma ágil, segura y en cualquier momento.
15
DESCRIPCIÓN DEL PROYECTO Y ENTREGABLES
El proyecto consiste en la Implantación de un Servicio DevOps en una Compañía de

Desarrollo Software. El Cliente tiene un portfolio con proyectos con tecnología heterogénea
y se debe buscar una solución que contemple toda la casuística.
Para ello la solución aportada constará.

 Un Sistema de Control de Versiones
 Un Sistema de Integración Continua
 Un Repositorio de Librerías
 Un conjunto normalizado de arquetipos
 Plugins que permitan la integración de las herramientas
 Scripts de automatización
Cada uno de los puntos anteriores debe venir acompañado de la documentación oportuna:
 Referencia documental de la herramienta y posibles alternativas (si se trata de un
producto).
 Manual de instalación/configuración
 Manual de usuario
REQUISITOS DE ALTO NIVEL
 El Servicio DevOps permitirá realizar despliegues automáticos de nuevas versiones

de las aplicaciones en un tiempo máximo de diez minutos en todos los entornos.
 El servicio DevOps permitirá realizar al menos veinte builds en paralelo
 El servicio DevOps permitirá realizar al menos cinco despliegues en paralelo.
 El Cliente aporta una lista de veinte proyectos que deben quedar integrados en el
Servicio DevOps, de forma previa al cierre del mismo.
 La plataforma DevOps debe constar de:
o Repositorio de Código
o Servidor Integración Contínua
o Servidor de Artefactos
o Servidor de análisis de código y generación de métricas
o Servidor de ejecución de despliegues
 La plataforma de Integración Contínua debe realizar los pasos:
o Obtener el código fuente desde los repositorios
o Construir la aplicación a partir del código (Build)
o Generar un nuevo tag versionado del código fuente
16
o Invocar el análisis de código y obtención de métricas

o Realizar el despliegue (o no, en función de la configuración)
o Enviar notificaciones de estado para cada actividad generada
 Crear arquetipos-maven (batch, web, servicio web, cliente, librería) software que
permitan a los equipos de desarrollo generar un esqueleto para agilizar los
desarrollos de nuevas aplicaciones, así como homogeneizar las arquitecturas,
patrones, librerías y soluciones utilizados.
 El acceso a la plataforma DevOps estará securizado mediante validación contra
Directorio Activo (LDAP), además de la gestión de roles gestionada por cada
herramienta.
 Al final del proyecto debe quedar consolidado un equipo de servicio, el Equipo
DevOps, que se encargará de atender la operativa diaria desde las instalaciones de
Cliente.
 Se debe generar la documentación necesaria para:
o Perfiles técnicos que realizarán el mantenimiento y evolución de la
plataforma.
o Usuarios (equipos de desarrollo de las áreas funcionales) que utilizarán el
servicio DevOps
OBJETIVOS
OBJETIVOS COMUNES:
 Plazo de 12 meses. Inicio con el Acta de Constitución y finalización con la entrega

del proyecto.
 Se debe integrar en las metodologías y normativa presentes en el marco del Cliente
 La puesta en marcha del servicio debe incluir una selección de proyectos piloto (que
aborden el total de la casuística) preparados para realizar el ciclo completo sobre
las herramientas del nuevo Servicio DevOps.
OBJETIVOS INTERNOS:
 Reducir los costes un 10% por debajo de lo planificado

 Alianza con el Cliente para futuras evoluciones del Servicio.
 Posicionamiento diferenciador con respecto a la Competencia.
 Posesión de ‘Know-How’ que beneficiará al resto de proyectos de desarrollo que
la compañía tiene con el Cliente
 Desarrollo de sinergias en nuestra compañía
 Lecciones aprendidas para el desarrollo de un posible Servicio DevOps como
producto para otros Clientes
 Incorporación y Formación de profesionales Junior
 Trabajar con un Cliente de reconocido prestigio internacional
17
SUPUESTOS Y RESTRICCIONES
SUPUESTOS:
 El Cliente nos facilitará el hardware necesario.
 El Cliente nos facilitará las máquinas maquetadas.
 El Cliente asume la gestión de las Licencias Software de las herramientas a
implantar.
 Será responsabilidad del Cliente seleccionar y comunicar los proyectos piloto.
 Todo el código generado, así como la documentación asociada será propiedad del
Cliente.
RESTRICCIONES:
 Debemos conocer las metodologías y procedimientos del Cliente para solicitar
recursos u operaciones sobre los mimos.
 Informes semanales del estado de la implantación.
 Una herramienta no se considerará implantada hasta que se aporte referencia
documental sobre la misma. Dicha referencia documental debe constar en el
gestor documental del Cliente.
 El equipo de DevOps continuará prestando servicio mediante un nuevo contrato
por bolsa de horas.
RIESGOS INICIALES DE ALTO NIVEL Y OPORTUNIDADES
TABLA DE RIESGOS:
RIESGO TIPO PROBABILIDAD IMPACTO
Rotación de personal Interno Moderada Medio
Reducción de presupuesto Externo Baja Alto
No satisfacción de las necesidades de
Interno Baja Alto
Cliente
Desviación de objetivos y cambios de
Interno Baja Alto
alcance
Falta de recursos durante las visitas a
Externo Baja Medio
Cliente
No se entregan los servidores en el plazo
Externo Media Medio
acordado
Sobrepasar el presupuesto acordado Interno Baja Alto
Problemas con los suministros (luz y agua) Interno Baja Medio
Ausentismo de los trabajadores Interno Baja Medio
Cambios en la
Interno Baja Medio
organización/equipo/dirección
18
Errores de planificación Interno Media Alto

Fallos de comunicación Interno Baja Alto
Mala estimación de esfuerzos Interno Media Alto
Quejas por parte del Cliente Interno Baja Alto
Diseño de soluciones con deuda técnica Interno Media Medio
Retraso en la entrega de equipo
Externo Baja Alto
informático
Problemas de obtención de licencia de Int.
Externo Baja Alto
Contínua
Equipo informático con taras Externo Baja Medio
Fallos de comunicación entre servidores Externo Media Alto
Virus en nuestra infraestructura Externo Baja Alto
Softare mal configurado Interno Media Medio
TABLA DE OPORTUNIDADES:
OPORTUNIDAD TIPO PROBABILIDAD IMPACTO
Finalización adelantada de la ejecución Interno Media Medio
Posibilidad de obtener un nuevo proyecto Interno Media Medio
si presentamos un dossier de futuras
líneas de evolución
Equipo de Proyecto motivado, dinámico y Interno Alto Alto
comprometido
Posibilidad de trabajar desde las Externo Alto Medio
instalaciones Cliente
Posibilidad de saltar burocracia de Cliente Externo Bajo Bajo
Posibilidad de obtener información útil Interno Alta Alto
mediante el uso de encuestas de
satisfacción
Equipo de Proyecto cohesionado y Interno Alto Alto
multidisciplinar
Afianzarnos como proveedor y poder Interno Media Alto
participar en otros proyectos del Cliente
19
CRONOGRAMA DE HITOS PRINCIPALES
HITO FECHA
Firma contrato 06/11/2017
Acta de Constitución 10/11/2017
Modelado solución 05/03/2018
Obtencion recursos 09/04/2018
Implantación repositorio 30/04/2018
Implantación integracion continua 23/07/18
Implantacion scripts despliegue 20/08/2018
Implantacion arquetipos 15/20/2013
Implantacion plugin 15/20/2016
Integración proyectos piloto 15/10/2018
Acta de Cierre 22/10/2018
PRESUPUESTO ESTIMADO
Coste Proyecto
Implantación Servicio DevOps 173270,22€
Recursos técnicos 6000,00€
Mobiliario oficina 1.280,00 €
Licencia Servidores Integración Contínua 44000,00€
TOTAL (sin reservas) 224550,22€
Reserva de contingencias (5%) 11227,51€
Reserva de gestión (2%) 4491,00€
TOTAL (con reservas) 240268,74€
Resultado
IVA (21%) 50.456,44 €
IMPORTE COSTE PLANIFICADO 290.725,18 €
IMPORTE COSTE VENTA 319.797,69 €
MARGEN DEL PROYECTO (10% venta) 29.072,52 €
20
LISTA DE INTERESADOS
 Áreas funcionales Cliente

o Tienda
o Logística y Comercial
o eCommerce
o RRHH
o Financiero
o Expansión
 Áreas transversales Cliente
o Arquitectura de Software
o Arquitectura y Administración Hardware
o BBDD
o Telecomunicaciones
o Seguridad
o Operaciones
 Áreas adjuntas
o Oficina de Proyectos
o Oficina Técnica
o Coordinación y control
o Coordinación Internacional
 Empresas de la competencia
 Proveedores material oficina
 Proveedores recursos hardware
 Proveedores licencias
 Resto de proyectos con sinergias en nuestra empresa
 Equipo de Gestión de Proyectos
RECURSOS
 Equipo de Gestión de Proyecto – 6 Personas

 Equipo Devops – 5 personas
 Equipo Arquetipos – 5 personas
 Material informático - 16PCs
 Material oficina – 16Puestos
21
ORGANIGRAMA DE ALTO NIVEL
Director de
Proyecto
Responsable de Responsable de
Responsable de
Responsable de Calidad Riesgos, Responsable de
Adquisiciones y
Costos y Tiempo Seguimiento y Comunicaciones e Desarrollo TIC
Recursos
Control Interesados
Ilustración 10 - Organigrama alto nivel [Antonio Garea]
APROBACIONES & FIRMAS
Cliente: Director Proyecto:

John Doe Antonio Garea Muiña
Firma: Firma:
22
2.1.2. Identificar a los interesados
INTERESADO TIPO ROL
Director de Proyecto Interno Director de Proyecto

Equipo de Proyecto Interno Equipo de Proyecto
Áreas transversales Cliente: Interno Cliente/Promotor
 Arquitectura de
Software
Áreas transversales Cliente: Interno Colaboradores
 Arquitectura y
Administración
Hardware
 BBDD
 Telecomunicaciones
 Seguridad
 Operaciones
Áreas funcionales Cliente: Externo Usuario
 Tienda
 Logística y Comercial
 eCommerce
 RRHH
 Financiero
 Expansión
Atlassian Externo Soporte de aplicación
Proveedores informática Externo Proveedor
Proveedor oficina Externo Proveedor
Otras empresas que ofrecen Externo Informado
productos similares
Potenciales clientes Externo Informado
Resto de proyectos de nuestra Interno Colaborador
empresa con sinergias
Atlassian Bamboo Externo Proveedor de licencias
23
2.2. GRUPO DE PROCESOS DE PLANIFICACIÓN
2.2.1. Plan para la dirección del proyecto

Será elaborado por el Director de Proyecto junto con el Equipo de Proyecto, dentro del mismo
se incluirá:
 Análisis y compresión del alcance. Esto abarca los requisitos del proyecto y del producto,
 criterios, supuestos, restricciones y otras influencias relativas a un proyecto y el modo
en que ellas se gestionarán o abordarán dentro del proyecto de implantación de un
Servicio DevOps.
 Entender de qué manera utilizar la información identificada y transformarla luego en un
plan para la dirección del proyecto con un enfoque estructurado, haciendo uso de una
metodología mixta que integre el enfoque predictivo (PMBOK®) con un enfoque ágil
(SCRUM®).
 Realizar actividades para producir los entregables requeridos para el proyecto de
restructuración y apertura. Medir y controlar todos los aspectos del avance del proyecto
y realizar las acciones apropiadas para cumplir con los objetivos planteados.
A continuación, se presenta el flujo de Gestión de Cambios desarrollado:
Ilustración 11- Flujo gestión de cambios [Antonio Garea]
24
2.2.2. Gestión del Alcance

El objetivo principal de la Gestión del Alcance del Proyecto es definir y controlar qué se va a
incluir y qué no en el proyecto.
2.2.2.1. Planificar la gestión del alcance

Mediante el diagrama de flujo que sigue se indica cómo se define, aprueba y verifica el alcance
del proyecto:
Ilustración 12 - Flujo gestión de alcance [Antonio Garea]
2.2.2.2. Recopilación de requisitos

Consiste en definir los objetivos y condiciones de aprobación del proyecto de manera específica,
para ello nos apoyamos en los criterios SMART:
Ilustración 13 - Criterios SMART [Antonio Garea]
Las técnicas y herramientas que utilizamos para obtener la información necesaria que nos
permite identificar y especificar requisitos son:
25
 Reuniones con el Cliente: Se realizan reuniones con los interesados identificados, con
el fin de determinar que se quiere y que no se quiere, así como identificar sinergias y
puntos críticos.
 Analizar de tendencias de mercado: Conocer las capacidades de las herramientas, así
como las tendencias actuales y posibles evoluciones de las tecnologías, será
determinante para presentar al Cliente las líneas de trabajo alternativas y seleccionar
de entre ellas las que mejor se adapten al proyecto.
 Estudio de normativa: Conocer que normativa aplica al ámbito de ejecución del
proyecto, así como conocer qué elementos específicos desea el Cliente que se cumplan
o adapten.
 Estudio y documentación online: A través de diferentes páginas oficiales de información
se obtiene documentación relevante para la elaboración del alcance del proyecto.
 Contacto con proveedores del conjunto Toolchain: El contacto con los proveedores de
las herramientas que implantaremos nos posibilita incluir en el alcance configuraciones
que posibiliten una sencilla actualización de la plataforma o bien evitar malas prácticas.
 Comparativa de las alternativas: existentes en el mercado para formar nuestro
Toolchain.
 Pruebas de concecpto y pilotos: Para obtener una visión de lo que cada elemento puede
llegar a ofrecer.
Requisitos identificados:
ID REQUISITO PRIORIDAD
REQ01 El Servicio DevOps permitirá realizar despliegues automáticos de ALTA

nuevas versiones de las aplicaciones en un tiempo máximo de diez
minutos en todos los entornos.
REQ02 El servicio DevOps permitirá realizar al menos veinte builds en BAJA
paralelo
REQ03 El servicio DevOps permitirá realizar al menos cinco despliegues en MEDIA
paralelo.
REQ04 El Cliente aporta una lista de veinte proyectos que deben quedar BAJA
integrados en el Servicio DevOps, de forma previa al cierre del mismo.
REQ05 La plataforma DevOps debe constar de: ALTA
 Repositorio de Código
 Servidor Integración Contínua
 Servidor de Artefactos
 Servidor de análisis de código y generación de métricas
 Servidor de ejecución de despliegues
REQ06 La plataforma de Integración Contínua debe realizar los pasos: ALTA

 Obtener el código fuente desde los repositorios
 Construir la aplicación a partir del código (Build)
 Generar un nuevo tag versionado del código fuente
 Invocar el análisis de código y obtención de métricas
 Realizar el despliegue (o no, en función de la configuración)
 Enviar notificaciones de estado para cada actividad generada
26
REQ07 El servidor de Integración Contínua debe contar con soporte 24x7 por MEDIA
parte del fabricante.
REQ08 Realizar un plugin que integre la herramienta de seguimiento de ALTA
proyectos e incidencias del Cliente (Jira) con la plataforma DevOps,
permitiendo arrancar el proceso de liberación de versiones.
REQ09 En caso de detectarse un problema con la nueva versión será posible ALTA
realizar Rollback (en menos de dos minutos) a la versión previa de
forma automática desde Jira, mediante el plugin.
REQ10 Los despliegues se podrán parametrizar en base a configuración MEDIA
realizada en el servidor de integración contínua o bien por los
parámetros que le llegan desde el plugin.
REQ11 Los despliegues en producción (incluso rollback) no se realizarán de ALTA
forma automática, la característica quedará deshabilitada. Estos
despliegues se gestionaran mediante tickets Jira, petición expresa del
Cliente.
REQ12 Crear arquetipos-maven (batch, web, servicio web, cliente, librería) ALTA
software que permitan a los equipos de desarrollo generar un
esqueleto para agilizar los desarrollos de nuevas aplicaciones, así
como homogeneizar las arquitecturas, patrones, librerías y
soluciones utilizados.
REQ13 El acceso a la plataforma DevOps estará securizado mediante ALTA
validación contra Directorio Activo (LDAP), además de la gestión de
roles gestionada por cada herramienta.
REQ14 Generar documentación necesaria para que los equipos de desarrollo MEDIA
sepan cómo invocar la liberación de versiones desde Jira, mediante el
plugin.
REQ15 Generar documentación necesaria para que los equipos de desarrollo BAJA
puedan comenzar a utilizar los nuevos arquetipos software.
REQ16 Generar la documentación necesaria para instrumentar desde cero un BAJA
repositorio de código (Subversion y Git) en un entorno productivo.
REQ17 Generar la documentación necesaria para realizar la configuración del BAJA
servidor de artefactos (Artifactory) en un entorno productivo.
REQ18 Generar la documentación necesaria para realizar la configuración del BAJA
servidor de integración contínua (Bamboo) en un entorno productivo.
REQ19 Generar dossier de documentación con la información necesaria para BAJA
realizar la integración del Toolchain en un entorno productivo.
REQ20 Al final del proyecto debe quedar consolidado un equipo de servicio, BAJA
el Equipo DevOps, que se encargará de atender la operativa diaria
desde las instalaciones de Cliente.
REQ21 La plataforma DevOps debe permitir escalabilidad horizontal y estar BAJA
preparado soportar la carga de tres mil proyectos Java.
REQ22 Todas las automatizaciones deben poder ser ejecutadas de forma ALTA
manual a modo de contingencia, por lo que debe constar en la
27
referencia documental referencia a cada uno de los scripts

desarrollados.
REQ23 Generar la documentación necesaria para que un perfil técnico pueda BAJA
incorporarse al Equipo DevOps con garantías
REQ24 Generar la documentación necesaria para que un perfil técnico pueda MEDIA
hacerse con el desarrollo del plugin con garantías.
REQ25 Generar la documentación necesaria para que un perfil técnico BAJA
puedar hacerse con el desarrollo de los arquetipos con garantías
2.2.2.3. Definición de alcance

En la definición de alcance se tratan los elementos objetivos, entregables, supuestos,
restricciones y exclusiones.
OBJETIVOS
OBJETIVOS COMUNES:
 Plazo de 12 meses. Inicio con el Acta de Constitución y finalización con la entrega

del proyecto.
 Se debe integrar en las metodologías y normativa presentes en el marco del Cliente
 La puesta en marcha del servicio debe incluir una selección de proyectos piloto (que
aborden el total de la casuística) preparados para realizar el ciclo completo sobre
las herramientas del nuevo Servicio DevOps.
OBJETIVOS INTERNOS:
 Reducir los costes un 10% por debajo de lo planificado

 Alianza con el Cliente para futuras evoluciones del Servicio.
 Posicionamiento diferenciador con respecto a la Competencia.
 Posesión de ‘Know-How’ que beneficiará al resto de proyectos de desarrollo que
la compañía tiene con el Cliente
 Desarrollo de sinergias en nuestra compañía
 Lecciones aprendidas para el desarrollo de un posible Servicio DevOps como
producto para otros Clientes
 Incorporación y Formación de profesionales Junior
 Trabajar con un Cliente de reconocido prestigio internacional
28
ENTREGABLES
HITO FECHA
Firma contrato 06/11/2017
Acta de Constitución 10/11/2017
Modelado solución 05/03/2018
Obtencion recursos 09/04/2018
Implantación repositorio 30/04/2018
Documentación repositorio 30/04/2018
Implantación integracion continua 23/07/18
Documentación integracion continua 23/07/19
Implantacion scripts despliegue 20/08/2018
Documentación scripts despliegue 21/08/2018
Arquetipos Backlog 23/05/2018
Plugin Backlog 30/05/2018
Implantacion arquetipos 15/20/2013
Documentación arquetipos 15/20/2014
Dossier Bitácora SCRUM arquetipos 15/20/2015
Implantacion plugin 15/20/2016
Documentación plugin 15/20/2017
Dossier Bitácora SCRUM plugin 15/20/2018
Integración proyectos piloto 15/10/2018
Dossier actas de seguimiento semanal 15/10/2018
Acta de Cierre 22/10/2018
SUPUESTOS Y RESTRICCIONES
SUPUESTOS:
 El Cliente nos facilitará el hardware necesario.
 El Cliente nos facilitará las máquinas maquetadas.
 El Cliente asume la gestión de las Licencias Software de las herramientas a
implantar.
 Será responsabilidad del Cliente seleccionar y comunicar los proyectos piloto.
 Todo el código generado, así como la documentación asociada será propiedad del
Cliente.
29
RESTRICCIONES:
 Debemos conocer las metodologías y procedimientos del Cliente para solicitar
recursos u operaciones sobre los mimos.
 Informes semanales del estado de la implantación.
 Una herramienta no se considerará implantada hasta que se aporte referencia
documental sobre la misma. Dicha referencia documental debe constar en el
gestor documental del Cliente.
 El equipo de DevOps continuará prestando servicio mediante un nuevo contrato
por bolsa de horas.
2.2.2.4. Estructura de desglose de trabajo (EDT)
Implantación
Servicio Devops
Gestión Y Diseño Y
Administración Desarrollo
Actividades De
Actividades De Actividades De Actividades De
Ejecución Y
Inicio Planificación Cierre
Control
Acta De Constitución Plan Para La Gestión Informe de Checklist De

De Proyecto Del Proyecto Seguimiento Semanal Validación
Dossier De Gestión De Acta De Cierre De

Cambios Proyecto
Actas SCRUM Weekly Dossier De Lecciones

Aprendidas
Bitácora SCRUM Daily
Actas SCRUM Sprint
Ilustración 14 - EDT I [Antonio Garea]
30
Implantación
Servicio Devops
Gestión Y
Diseño Y Desarrollo
Administración
Trabajos Trabajos De
Trabajos
Trabajos De Maquetación Desarrollo Del
Maquetación
Adecuación Entorno Plugin De
Entorno TESTING
PRODUCCIÓN Integración
Entorno Testing Entorno Producción

Entrega Recursos Plugin Integrado
Configurado Configurado
Dossier De Documentación
Oficinas Habilitadas
Licencias Plugin
Recursos Formados
Ilustración 15 - EDT II [Antonio Garea]
Implantación
Servicio Devops
Gestión Y Diseño Y
Administración Desarrollo
Trabajos De Trabajos De Trabajos De Trabajos De

Trabajos De
Desarrollo De Desarrollo De Configuración Plataformado
Documentación
Arquetipos Scripts Proyectos Piloto Devops IC
Proyectos Dossier De Dossier De

Arquetipos Scripts
Pilotos Plataformado Operación
Integrados Integrados
Adaptados Devops Devops
Documentación Documentación
Arquetipos Scripts
Ilustración 16- EDT III [Antonio Garea]
2.2.2.5. Diccionario de la EDT

Se puede consultar el diccionario en el ANEXO A17 – Diccionario de la EDT.
31
2.2.3. Integración de metodología SCRUM

Para realizar la integración de la metodología SCRUM generamos dos bloques de actividades
diferenciados:
 Los SCRUM Backlog: Una lista de requisitos del producto que se a generar.
 Los SCRUM Sprints: Períodos en los que se realiza un incremento del producto, hasta
conseguir el producto finalizado.
Para ver más en profundidad, ANEXO A5 - Modelo SCRUM.
2.2.4. Gestión del Tiempo

2.2.4.1. Secuenciar y estimación de las actividades
NOMBRE DE TAREA DURACIÓN COMIENZO FIN
Elaboración Acta de Constitución 5 días lun 06/11/17 vie 10/11/17

Elaborar Checklist aceptación 1 día lun 13/11/17 lun 13/11/17
Elaborar Plan de Gestión 40 días mar 14/11/17 lun 08/01/18
MODELADO SOLUCIÓN 40 días mar 09/01/18 lun 05/03/18
Análisis de alternativas 30 días mar 09/01/18 lun 19/02/18
Planteamiento de la solución 10 días mar 20/02/18 lun 05/03/18
OBTENCION DE RECURSOS 25 días mar 06/03/18 lun 09/04/18
IMPLANTACION DE SERVIDORES 90 días mar 17/04/18 lun 20/08/18
Implantación repositorio de código 10 días mar 17/04/18 lun 30/04/18
Implantación servidor Integración Continua 60 días mar 01/05/18 lun 23/07/18
Implantación Scripts Despliegue 20 días mar 24/07/18 lun 20/08/18
SCRUM BACKLOG 12 días mar 15/05/18 mié 30/05/18
Arquetipos Backlog 7 días mar 15/05/18 mié 23/05/18
Plugin Backlog 5 días jue 24/05/18 mié 30/05/18
IMPLANTACIÓN DE ARQUETIPOS 40 días mar 21/08/18 lun 15/10/18
Sprint 1 10 días mar 21/08/18 lun 03/09/18
IMPLANTACIÓIN PLUGIN INTEGRACIÓN 40 días mar 21/08/18 lun 15/10/18
32

Integración proyectos piloto 20 días mar 18/09/18 lun 15/10/18
Validación Checklist aceptación 2 días mar 16/10/18 mié 17/10/18
Elaborar Acta de Cierre 3 días jue 18/10/18 lun 22/10/18
SEGUIMIENTO Y CONTROL 150,38 días lun 19/03/18 lun 15/10/18
Acta de reunión de seguimiento semanal 150,25 días lun 19/03/18 lun 15/10/18
SCRUM Plugin Integración 38,38 días mié 22/08/18 lun 15/10/18
Daily 38,03 días mié 22/08/18 lun 15/10/18
Weekly 35,38 días lun 27/08/18 lun 15/10/18
SCRUM Arquetipos 38,38 días mié 22/08/18 lun 15/10/18
Daily 38,03 días mié 22/08/18 lun 15/10/18
Weekly 35,38 días lun 27/08/18 lun 15/10/18
2.2.4.2. Cronograma
Ilustración 17 - Cronograma [Antonio Garea]
Para ver más en detalle consultar el ANEXO A13 – Detalle Gantt.
33
2.2.5. Gestión de los Costos
2.2.5.1 Tipos
Diferenciamos dos grupos, costes materiales y costes de mano de obra:
Costes materiales:
Se contemplan como costo material:
Material informático: Se compra material informático por valor de 24.000,00€. Considerando

un período de amortización de cuatro años, el coste final que repercute en el proyecto es de
6.000€.
Mobiliario de oficina: Se compra material de oficina por valor de 12.800,00€. Considerando un

período de amortización de diez años, el coste final que repercute en el proyecto es de
1.280,00€.
Siguiendo el principio de prudencia ambos costos serán asignados a la actividad inicial ‘Acta de
Constitución’.
Licencia servidor integración contínua: Se compra la licencia para implantar la plataforma por
valor de 44.000,00€ (ver: https://es.atlassian.com/software/bamboo/pricing). Será asignado a
la tarea ‘Obtención de recursos’.
Coste de mano de obra:
Constituyen las tarifas/hora de los recursos que realizarán las actividades del proyecto. El
salario base del empleado se incrementa un 0,55%, que se corresponde con el coste para la
empresa (horas de formación, ausencias remuneradas, Seguridad Social...).
RECURSO SALARIO BASE COSTE TOTAL (+0,55%)
Director de Proyecto 60.000,00 € 93.000,00 €

Resp. Recursos y Adquisiciones 37.000,00 € 57.350,00 €
Resp. Costos y Tiempo 37.000,00 € 57.350,00 €
Resp. Calidad, Seguimiento y 37.000,00 € 57.350,00 €
Control
Resp. Riesgos, Comunicaciones e 37.000,00 € 57.350,00 €
Int.
Resp. Desarrollo TIC 37.000,00 € 57.350,00 €
Arquitecto Java Fullstack 34.000,00 € 52.700,00 €
Diseñador Grafico 22.000,00 € 34.100,00 €
Devops Lead 33.000,00 € 51.150,00 €
Analista Funcional 33.000,00 € 51.150,00 €
Programador Java Backend 22.000,00 € 34.100,00 €
Programador Java Frontend 22.000,00 € 34.100,00 €
Programador Java Fullstack 24.000,00 € 37.200,00 €
34
Ingeniero Devops Senior 24.000,00 € 37.200,00 €

Ingeniero Devops Junior 19.000,00 € 29.450,00 €
Programador Java Fullstack 24.000,00 € 37.200,00 €
2.2.5.2 Determinar el presupuesto
ACTIVIDAD COSTO
Elaboración Acta de Constitucióin 10.048,72 €

Elaborar Checklist aceptación 357,40 €
Elaborar Plan de Gestión 11.130,63 €
MODELADO SOLUCIÓN 11.130,63 €
Análisis de alternativas 8.347,97 €
Planteamiento de la solución 2.782,66 €
OBTENCION DE RECURSOS 50.956,64 €
IMPLANTACION DE SERVIDORES 45.729,09 €
Implantación repositorio de código 4.588,60 €
Implantación servidor Integración Continua 30.855,37 €
Implantación Scripts Despliegue 10.285,12 €
SCRUM BACKLOG 13.330,64 €
Arquetipos Backlog 7.562,24 €
Plugin Backlog 5.768,40 €
IMPLANTACIÓN DE ARQUETIPOS 33.181,60 €
Sprint 1 8.740,80 €
Sprint 2 8.740,80 €
Sprint 3 7.850,00 €
Sprint 4 7.850,00 €
IMPLANTACIÓIN PLUGIN INTEGRACIÓN 30.542,00 €
Sprint 1 8.740,80 €
Sprint 2 7.840,80 €
Sprint 3 6.980,20 €
Sprint 4 6.980,20 €
Integración proyectos piloto 9.228,43 €
Validación Checklist aceptación 484,17 €
Elaborar Acta de Cierre 834,80 €
SEGUIMIENTO Y CONTROL 7.595,47 €
35
TOTAL
TOTAL (sin reservas) 224550,22€
Reserva de contingencias (5%) 11227,51€
Reserva de gestión (2%) 4491,00€
TOTAL (con reservas) 240268,74€
RESULTADO
IVA (21%) 50.456,44 €
IMPORTE COSTE PLANIFICADO 290.725,18 €
IMPORTE COSTE VENTA 319.797,69 €
MARGEN DEL PROYECTO (10% venta) 29.072,52 €
2.2.6. Gestión de la Calidad
2.2.6.1. Roles
ROL RESPONSABILIDAD
Cliente Responsable financiero y final del proyecto.

Director del Proyecto Responsable supervisar el plan de gestión de la calidad así
como de la correcta ejecución de los proceso de aseguramiento
y control de esta.
Responsable de Calidad y Responsable de elaborar el plan de gestión de la calidad,
Seguimiento y Control realizar el aseguramiento y el control de esta.
Equipo de Proyecto Elaborar los entregables cumpliendo con el plan de gestión de
la calidad.
2.2.6.2. Línea base de calidad
FACTOR OBJETIVO A CUMPLIR MÉTRICA PERIODICIDAD REVISIÓN
En cuanto a tiempo SPI=≥0,95 Índice de Semanal

desempeño de
cronograma
En cuanto a coste CPI=≥0,95 Índice de Semanal
desempeño del
coste
Satisfacción cliente Nivel superior al 80% Reuniones y Tras cada reunión y como
encuesta de paso previo al cierre del
satisfacción proyecto.
36
La encuesta de satisfacción permitirá conocer si las expectativas del cliente se cumplen.

Constará de 10 cuestiones que podrán ser contestadas utilizando la siguiente escala:
 Excelente, 5 puntos
 Bueno, 4 puntos
 Regular,3 puntos
 Deficiente, 1 punto
Para saber el grado de satisfacción bastará con realizar la división: <puntuación_obtenida>/50.
Utilizaremos Microsoft Project para obtener el CPI y el SPI. Y en caso de que el resultado sea
desfavorable (cuando no es mayor que 1), habrá que analizar la causa y realizar los ajustes
necesarios.
2.2.6.3. Matriz de actividad
DOCUMENTO NORMA/ESTÁNDAR APLICADO CONTROL
Acta de constitución Metodología PMI Aprobada por Cliente y

Director de Proyecto
Plan de gestión de proyecto Metodología PMI Aprobado por el Director de
Proyecto
Acta de reunión Plantilla propia Aprobado por el Director de
Proyecto
Acta de cierre Metodología PMI Aprobado por el Director de
Proyecto
Checklist validación Plantilla propia Aprobado por el Director de
Proyecto
Informe de seguimiento Plantilla propia Aprobado por el Director de
Proyecto
2.2.6.4. Procedimiento de control y aseguramiento de la calidad
CONTROL ACCIONES
De documentación  Los documentos deben identificar autor, fecha, control de

cambios sobre el mismo.
 Si varios documentos tratan un tema no debe haber
discrepancia entre los mismos.
 El documento debe seguir el diseño de una plantilla y estar
estructurado correctamente.
De pruebas  Las pruebas a realizar deben ser públicas, fácilmente
reproducibles y automatizadas.
 Deben contar con la documentación necesaria para
llevarlas a cabo e interpretar claramente los resultados.
37
De procesos  Los flujos deben estar convenientemente definidos, y en

caso de haber cambios en los mismos deben registrar y
versionarse.
 Debe haber una documentación clara que permita
identificar unívocamente el que punto del proceso dónde
nos encontramos y bajo qué condiciones se pasa al
siguiente paso.
De métricas  Se debe comprobar que se realizan correctamente los
análisis en base a las métricas definidas.
 Se debe controlar que las métricas utilizadas están
actualizadas.
De normativa Cliente  Se debe comprobar que se cumple con la normativa
interna del Cliente.
De especificaciones  Se debe controlar que los requisitos técnicos son claros y
se genera documentación detallada y de valor sobre los
mismos.
2.2.7. Gestión de los Recursos

2.2.7.1. Organigrama Completo
Director de
Proyecto
Responsable de Responsable de
Responsable de
Responsable de Calidad Riesgos, Responsable de
Adquisiciones y
Costos y Tiempo Seguimiento y Comunicaciones e Desarrollo TIC
Recursos
Control Interesados
Arquitecto Java
Diseñador Gráfico DeOps Lead Analista Funcional
FullStack
Programador Java Ingerniero Devops

BackEEnd Perfil Senior
Programador Java Ingeniero DevOps

FrontEnd perfil Junior
Programador Java Programador Java

FullStack FullStack
Ilustración 18 - Organigrama completo [Antonio Garea]
2.2.7.2. Calendario de recursos

El proyecto se realizará en aproximadamente en 50 semanas.
MIEMBRO DEL EQUIPO SEMANA INICIO SEMANA FIN
Director de Proyecto (Abrev. DP) Semana 0 Semana 50

Resp. Adquisiciones y Recursos (Abrev. RAR) Semana 0 Semana 50
38
Resp. Costos y Tiempo (Abrev. RCT) Semana 0 Semana 50

Resp. Calidad, Seguimiento y Control Semana 0 Semana 50
(Abrev. RCSC)
Resp. Riesgos, Comunicaciones e Interesados Semana 0 Semana 50
(Abrev. RRCI)
Resp. Desarrollo TIC (Abrev. RDT) Semana 0 Semana 50
Arquitecto Java FullStack (Abrev. ARQ) Semana 0 Semana 49
Diseñador Gráfico (Abrev. DIS) Semana 0 Semana 49
DevOps Lead (Abrev. DLEAD) Semana 0 Semana 49
Analista Funcional (Abrev. AFUN) Semana 0 Semana 49
Programador Java BackEnd (Abrev. PJBACK) Semana 20 Semana 49
Programador Java FrontEnd (Abrev. PJFRNT) Semana 20 Semana 49
Programador Java FullStack (Abrev. PFULL) Semana 20 Semana 49
Ingeniero DevOps Senior (Abrev. IDEVS) Semana 20 Semana 49
Ingeniero DevOps Junior (Abrev. IDEVJ) Semana 20 Semana 49
Programador Java FullStack (Abrev. PFULL) Semana 20 Semana 49
2.2.7.3. Paquetes de trabajo por recursos
R: responsable
A: aprueba
PJBACK
PJFRNT
DLEAD
C: consultado
PFULL
PFULL
IDEVS
AFUN
IDEVJ
RCSC
RRCI
ARQ
RAR
RDT
RCT
I: informado
DIS
DP
Firma
R
contrato
Acta de
R C C C C C
Constitución
Modelado
A C C C C C R R R R
solución
Obtencion
A R I I I I I I I I
recursos
Implantación
I I I I I A R R R R R
repositorio
Documentaci
ón I I I I I C R A R R R R
repositorio
Implantación
integracion I I I I I A R R R R R
continua
Documentaci
ón
I I I I I C R A R R R R
integracion
continua
39
Implantacion
scripts I I I I I A R R R R R
despliegue
Documentaci
ón scripts I I I I I C R A R R R R
despliegue
Arquetipos
I I I I I A R R R C C C
Backlog
Plugin
I I I I I A C R R C C C
Backlog
Implantacion
I I I I I A R R R R R R
arquetipos
Documentaci
I I I I I C R R R R R R
ón arquetipos
Dossier
Bitácora
I I I I A R I I I I I
SCRUM
arquetipos
Implantacion
I I I I I A R R R R R R
plugin
Documentaci
I I I I I C R A R R R R
ón plugin
Dossier
Bitácora
I I I I A I I I I I I
SCRUM
plugin
Integración
proyectos I I I I I I A C R I
piloto
Dossier actas
de
R C C C C C I I I I I I I I I I
seguimiento
semanal
Acta de
R C C C C C
Cierre
2.2.8. Gestión de las Comunicaciones
DETALLE DOCUMENTO RESPONSABLE DESTINATARIO FRECUENCIA MODO
Acta de Director de Correo

Inicio Promotor Una vez
Constitución Proyecto electrónico
Plan de Director de Equipo de Correo
Planificación Una vez
Gestión Proyecto proyecto electrónico
Promotor y
Cambio de Solicitud de Director de Cuando sea Correo
Equipo de
alcance cambio Proyecto necesario electrónico
proyecto
Promotor y
Estado del Informe de Director de Correo
Equipo de Semanales
proyecto seguimiento Proyecto electrónico
proyecto
40
Miembro del
Acta de equipo de Equipo de Correo
Reunión Semanales
reunión proyecto proyecto electrónico
asignado
Promotor y
Acta de Director de Correo
Cierre Equipo de Una vez
Cierre Proyecto electrónico
proyecto
Se definen los siguientes elementos para hacer mejorar las comunicaciones:
ELEMENTO DETALLE
Reuniones eficaces Las reuniones se realizarán en base a las siguientes prácticas:

 Convocatoria con una antelación mínima de 3 días a la fecha
de celebración.
 Se informará en la convocatoria de los puntos del día.
 Se identificará en la convocatoria al moderador asignado
 Se convocará al menor número de personas necesarias.
 El tiempo máximo de reunión no excederá las 2 horas.
 Se tratarán únicamente los puntos del día, cualquier otro
adicional será tenido en cuenta de cara a la próxima
reunión, y por tanto constará en acta.
 El moderador asignado, enviará el acta de reunión en un
plazo máximo de 1 día.
 Si no hay comunicación de disconformidad en 2días, se
asume que todas las partes están de acuerdo con el
contenido del acta.
Nomenclatura de El nombrado de los documentos se realizará atendiendo a unas
documentos reglas básicas:
CCCC-TTTT-V.V.V.XXX
 CCCC: código de proyecto
 TTTTT: tipo de documento
o MANOP: manual de operación
o ACTRE: acta de reunión
o INFSE: informe de seguimiento
o ACTCO: acta de constitución
o ACTCI: acta de cierre
o SOLCA: solicitud de cambio
o DISTE: diseño técnico
o DISFU: diseño funcional
o …
 V.V.V: versión del documento
41
2.2.9. Gestión de los Riesgos
Los riesgos son circunstancias o eventos inciertos que, de producirse, tendrían un impacto
negativo o positivo sobre al menos algún objetivo del proyecto (alcance, tiempo, coste o
calidad).
El fin del “Plan de Gestión de Riesgos” es doble, por un lado, minimizar el impacto de los
riesgos positivos, y por otro maximizar las oportunidades (riesgos positivos).
Este plan define, la estrategia, que en cada caso particular se va a seguir, y cómo serán
organizadas y llevadas a cabo las actividades de gestión de riesgos.
Ilustración 19 - Flujo de gestion de riesgos [Antonio Garea]
42
Es de vital importancia para obtener la aceptación y el apoyo de los interesados, con el fin de
que los procesos de gestión de riesgos sean llevados a cabo de forma eficaz durante el ciclo de
vida de nuestro proyecto.
1 Identificación de los Riesgos

Este proceso consiste en determinar qué riesgos podrán afectar a nuestro proyecto y
documentar sus características. Involucra al Director y Equipo de Proyecto al completo, junto
con expertos externos, áreas transversales y usuarios finales.
Este proceso es continuo e iterativo, lo que implica que, según avance el proyecto existe la
posibilidad de que se presente nuevos riesgos y evolucionen los planificados inicialmente.
Ver ANEXO A6.1 – Identificación de riesgos
2 Análisis Cualitativo de los Riesgos

Este proceso consiste en priorizar los riesgos para su análisis o acción posterior, evaluando y
combinando la probabilidad de ocurrencia e impacto de los mismos. Esto permite reducir el
nivel de incertidumbre y centrarse en los riesgos que ataquen más a nuestro proyecto.
A cada riesgo se le asignan valores subjetivos para la probabilidad y el impacto, usualmente

basados en la experiencia en proyectos similares y el conocimiento de las condiciones de
entorno. La combinación de los dos parámetros, mediante el uso de una matriz, nos permite
obtener el valor cualitativo del riesgo analizado.
Realizaremos la valoración cualitativa en base a la siguiente matriz de probabilidad/impacto:
Muy Muy Muy

Moderado Alto Alto
PROBABILIDAD
Alta Alto Alto

Muy
Alta Moderado Moderado Alto Alto
Alto
Moderada Moderado Moderado Moderado Alto Alto
Baja Bajo Bajo Moderado Moderado Moderado
Muy
Bajo Bajo Bajo Moderado Moderado
Baja
Muy Bajo Bajo Moderado Alto Muy Alto
IMPACTO
Ver ANEXO A6.2 – Análisis cualitativo
3. Análisis Cuantitativo de los Riesgos

Este proceso consiste en priorizar los riesgos para su análisis o acción posterior, evaluando y
combinando la probabilidad de ocurrencia e impacto de los mismos. Esto permite reducir el
nivel de incertidumbre y centrarse en los riesgos que ataquen más a nuestro proyecto.
A cada riesgo se le asignan valores numéricos para la probabilidad y el impacto, usualmente

basados en la experiencia en proyectos similares y el conocimiento de las condiciones de
43
entorno. La combinación de los dos parámetros, mediante el uso de una matriz, nos permite
obtener el valor cuantitativo del riesgo analizado.
Realizaremos la valoración cualitativa en base a la siguiente matriz de probabilidad/impacto:

Muy
0,9 0,5 0,09 0,18 0,36 0,72
PROBABILIDAD
Alta
Alta
0,7 0,4 0,07 0,14 0,28 0,56
Moderada
0,5 0,3 0,05 0,1 0,2 0,4
Baja
0,3 0,02 0,03 0,06 0,12 0,24
Muy
Baja 0,1 0,01 0,01 0,02 0,04 0,08
0,05 0,1 0,2 0,4 0,8
Muy Bajo Bajo Moderado Alto Muy Alto
IMPACTO
Ver ANEXO A6.3 – Análisis cuantitativo
4. Planificar la Respuesta a los Riesgos

Una vez identificados los riesgos se procederá a realizar el plan de acción para cada uno de
ellos, para ello establecemos una clasificación atendiendo a la estrategia seleccionada:
 Transferir: se transfiere un riesgo a otra compañía, por ejemplo, outsourcing o

seguros.
 Mitigar: se enfoca a reducir el riesgo ajustando problemas que puedan elevar esos
niveles de riesgo.
 Evitar: se trata de evitar lo que nos puede molestar.
 Aceptar: reconocer y asumir que hay que trabajar con riesgos
 Favorecer: emprender acciones para provocar el riesgo (positivo).
Ver ANEXO A6.4 – Respuesta a los riesgos
2.2.10. Gestión de las Adquisiciones

Por la naturaleza del proyecto, esté será un proceso que no se ejecutará, debido a que el
proyecto está planificado para llevarse a cabo sin adquisiciones.
44
2.2.11. Gestión de los Interesados
PODER vs INFLUENCIA DE LOS INTERESADOS
PODER SOBRE EL PROYECTO
ALTO BAJO
• Equipo de Gestión de Proyecto • Áreas funcionales Cliente

ALTA
INFLUENCIA EN EL PROYECTO
• Áreas transversales Cliente • Proveedores licencias
• Empresas de la competencia
• Proveedores recursos hardware
BAJA
• Áreas adjuntas • Proveedores material oficina

• Resto de proyectos con sinergias en
nuestra empresa
En base al análisis previo tendremos que tener especial atención en los siguientes grupos de
influencia:
 Áreas transversales cliente: Son las que más pueden influir en nuestro proyecto, de
ellas dependemos en ciertos puntos para poder sacar las actividades adelante. Por ello
deberemos prestar especial atención a las relaciones e intercambios de información
con este grupo.
 Áreas funcionales Cliente: Tienen poder, ya que podrían ocasionar desajustes
(presupuestos) o presiones (cambio de plazos) en las actividades del proyecto, pero
directamente no tienen influencia en el desarrollo de las mismas.
 Proveedores licencias: Tienen poder, ya que podrían ocasionar desajustes
(presupuestos) o presiones (cambio de plazos) en las actividades del proyecto, pero
directamente no tienen influencia en el desarrollo de las mismas.
 Áreas adjuntas: A pesar de tener poder, de entrada, no deberíamos vernos afectados
una vez arrancado el proyecto.
 El resto de grupos: Tienen poca capacidad de influencia y poder.
45
2.3. GRUPO DE PROCESOS DE EJECUCIÓN
En este apartado trataremos el ‘Grupo de Procesos de Ejecución', veremos el enfoque ágil

(SCRUM) que se utiliza en el desarrollo de varios módulos del Proyecto enmarcado por el
conjunto de procesos descritos por el PMBOK.
2.3.1. Agilizar aplicando metodología SCRUM

Cabe resaltar la presencia de dos productos que se crearán durante la ejecución del proyecto:
 Arquetipos para el desarrollo de proyectos software

 Plugin de integración para la automatización de los despliegues
En ambos casos existe una gran incertidumbre, así como la necesidad de adaptarse rápidamente
a los avances de configuración del entorno DevOps, por lo que se arrancarán como POC (prueba
de concepto), y en consecuencia recibirán una capa de gestión adicional, la capa de Metodología
SCRUM.
De este modo dado que aplicaremos una metodología mixta, durante la ejecución entraran en
juego los siguientes elementos:
 Generación del ‘backlog’:

Bajo metodología PMBOK se realizará de forma planificada la tarea de definir el
conjunto de ‘historias de usuario’ (y el desglose de las mismas en unidades con
funcionalidad) con los objetivos a cubrir una vez finalizados los elementos citados.
 Desarrollo mediante ‘sprints’:
Se realizarán un número de iteraciones concreto con una frecuencia determinada, que
fueron definidos durante la Planificación del Proyecto.
 Generación de ‘tareas sprint_1’:
Al finalizar la tarea de ‘Generación de backlog’ tendrá lugar la selección de los primeros
elementos a tratar durante la primera iteración (sprint).
Se puede consultar un anexo explicativo de esta metodología en el ANEXO A5 - Modelo SCRUM.
2.3.2. Dirigir y gestionar el trabajo del proyecto

Con la información generada en las etapas de inicio y planificación, y comenzando nuestro
proyecto el 06.11.2017, tenemos el objetivo de finalizar las obras el 26.10.2018. Para ello:
 Desarrollaremos las actividades recogidas en el cronograma de acuerdo al alcance de

nuestro Contrato
 Realizaremos las actividades de acuerdo a los requisitos comprometidos con la calidad
acordada
 Lograremos cada uno de los entregables parciales hasta la consecución del entregable
final.
A lo largo de la ejecución, se realizarán de forma sistemática controles acerca del desarrollo

del avance del proyecto sobre cronograma:
 Estado de los entregables
46
 Costes incurridos
 Desviaciones
 Proyecciones de beneficios/pérdidas a final de proyecto
 Posibilidades de solicitudes de cambio
Del mismo modo, la documentación generada hasta este momento por el equipo del proyecto
durante la ejecución será actualizada y, se implementarán cambios en lo que refiere a
cualquier concepto relativo al proyecto:
 Requisitos
 Cronograma
 Costes
 Calidad
 Recursos y Adquisiciones
 Riesgos
 Comunicaciones
2.3.3. Gestionar el conocimiento del proyecto

Durante la ejecución del proyecto, tratándose de tecnologías desconocidas para los empleados
de la empresa, se generará documentación. La documentación no tendrá carácter exclusivo del
proyecto, sino que el objetivo es que sean activos de la Organización para utilizar en futuros
proyectos de similares características/tecnologías.
Igualmente, en este proceso se generarán las lecciones aprendidas pertinentes, en conjunto
sobre la gestión de equipos multidisciplinares.
A destacar, la integración de metodologías ágiles con metodología predictiva, generando un
plan de gestión mixto formará parte de las citadas lecciones aprendidas.
2.3.4. Gestionar la participación de los interesados
Consistirá en comunicarse con los interesados y trabajar en conjunto a lo largo del ciclo de vida
del proyecto para incrementar el apoyo con la finalidad de aumentar el éxito del proyecto. A
través del plan para la gestión de los interesados se pueden extraer datos significativos sobre
cómo tratar y el objetivo de comunicación entre las partes en esta área.
2.3.5. Adquirir recursos
Adquirir el Equipo del Proyecto es el proceso de confirmar la disponibilidad de recursos
humanos y obtener el equipo necesario para completar las actividades del proyecto.
2.3.6. Desarrollar el equipo

Desarrollar el Equipo del Proyecto es el proceso de mejorar las competencias, la
interacción entre los miembros y el entorno general del equipo para lograr un mejor
desempeño del proyecto.
Para facilitar la comunicación y la dimensión de equipo se ha planteado introducir procesos
ágiles:
 Existen reuniones diarias, concisas y breves, que facilitan la interrelación entre los
miembros del equipo.
 Se realizarán reuniones de planificación de sprint cuyo objetivo es que todos los
miembros del equipo conozcan qué tareas va a realizar cada miembro del equipo y
hacia dónde se dirige el proyecto.
47
2.3.7. Dirigir el equipo

El tipo de liderazgo aplicado se caracterizará por ser ‘participativo’. De modo que se prioriza la
participación de todo el grupo. El líder promueve el diálogo en el grupo para que entre todos
se llegue a la mejor conclusión.
Las principales características que aporta este tipo de liderazgo:
 Se fomenta la participación ‘activa’ del grupo

 Se agradece la opinión del grupo y no margina a nadie
 El objetivo es el bien grupal
 El líder ejerce una escucha activa teniendo en cuenta todas las opiniones
 El líder delega tareas en otros y confía en la capacidad de su grupo
 El líder ofrece ayuda y orientación
2.3.8. Gestionar las comunicaciones

La distribución de la información se realizará según la planificado en el plan de gestión de las
comunicaciones. La relación de documentos que formarán parte de la información circulante:
 Actas de Reunión
 Informes de estado y desempeño
 Notificaciones a los interesados
 Estado de Solicitudes de cambio
 Lecciones aprendidas
2.3.9. Efectuar las adquisiciones

De todos modos, si una solicitud de cambio aprobada implicase este cambio, el proceso seguido
se describe a continuación:
 Búsqueda y selección de proveedores
 Negociación
 Adjudicación
 Cierre
2.3.10. Gestionar la calidad

Es el proceso de auditar los requisitos de calidad y los resultados obtenidos a partir de las
medidas de control de calidad, a fin de garantizar que se utilicen los estándares de calidad y las
definiciones operativas adecuadas.
Este proceso, debido a la naturaleza del proyecto, lo realizará el Director de Proyecto en las tares
relativas a generar informe de seguimiento. En base a la actualización del cronograma se podrá
realizar el control de costes y plazos, dos de los aspectos más relevantes en cuanto al plan de
calidad planteado
Se realizará el control de calidad de los entregables finales, así como el proceso de ejecución de
cada uno de los lotes de trabajo en los que se ha dividido el proyecto.
Deberá quedar constancia de la realización del proceso de aseguramiento de la calidad
mediante informes en los que se incluirán los resultados.
48
2.3.11. Implementar las respuestas a los riesgos

En este proceso, en el caso que se manifiesten alguno de los riesgos detectados en el plan de
gestión de riesgos, se implementará la respuesta asociada a dicho riesgo.
Tras implementar la respuesta, deberemos analizar si dicha respuesta incluye nuevos riesgos o
modifica los ya contemplados, para actualizar el plan de gestión de riesgos evitando imprevistos
futuros.
2.4. PROCESOS DE SEGUIMIENTO Y CONTROL
2.4.1. Seguir y controlar el trabajo del proyecto

Es el proceso de dar seguimiento, revisar e informar el avance a fin de cumplir con los objetivos
de desempeño definidos en el plan para la dirección del proyecto.
Se llevan a cabo reuniones durante el desarrollo del proyecto para realizar el seguimiento del
trabajo y ver el avance del mismo.
Las herramientas:
 Microsoft Project
 Atlassian Jira, ver ANEXO A1.2 – Jira.
2.4.2. Realizar el control integrado de cambios

Es el proceso que consiste en analizar todas las solicitudes de cambios, aprobar los mismos y
gestionar los cambios a los entregables, los activos de los procesos de la organización, los
documentos del proyecto y el plan para la dirección del proyecto, así como comunicar las
decisiones correspondientes. Revisa todas las solicitudes de cambio a del proyecto y aprueba o
rechaza dichos cambios.
Las herramientas:

 Plantilla gestión del cambio, ver ANEXO A9 – Plantilla gestión del cambio.
2.4.3. Gestión ágil del cambio con metodología SCRUM

Como particularidad, al incluir conceptos de metodología ágil durante la ejecución del
proyecto, los cambios o adaptaciones de origen interno se integran directamente en la
ejecución del proyecto. Estos, requieren por parte del Director de Proyecto una actualización
de la documentación relativa al proyecto, aunque no siguen estrictamente el proceso definido
de gestión de cambios provenientes del cliente.
Las herramientas:
 Pizarra SCRUM, ver ANEXO A7 – Pizarras SCRUM.

 Gráfico BurnDown, ver ANEXO A14 – Gráfico BurnDonw.
49
2.4.4. Controlar el involucramiento de los interesados

Es el proceso de seguir las relaciones generales de los interesados del proyecto y ajustar las
estrategias y los planes para involucrar a los interesados.
Este proceso es utilizado para realizar un seguimiento de la participación de los

interesados del proyecto. Con ello, se pretende establecer relaciones más fuertes con
aquellos interesados que no están implicados plenamente en el proyecto, así como
afianzar las relaciones con los que se encuentran plenamente involucrados.
Durante todo el proyecto pueden darse continuos cambios en los intereses, influencia y
poder de los interesados en el proyecto. El control de la Participación de los Interesados
ha de ser un proceso vivo.
Este proceso debe centrarse en:
 Tener siempre presente la lista de interesados en el proyecto, para asegurarse de que

todos sean incluidos en las comunicaciones relativas al proyecto.
 Tener claro, las metas y objetivos de cada interesado y el nivel de comunicación con
cada uno durante el proyecto.
 En caso de que suceda algún incidente, es muy importante que se informe a todas las
personas afectadas y asegurarse de que comprenden lo ocurrido.
 Mantener relaciones laborales óptimas y constructivas entre los diferentes
interesados, incluyendo a los miembros del equipo.
 Realizar un documento del cambio, informando sobre el cambio realizado y el impacto
que este supone en las distintas áreas del proyecto como el tiempo, el coste y el
riesgo.
Las herramientas:
 Atlassian Confluence, ver ANEXO A1.3. – Confluence, mantendremos una página en

formato WIKI en la que reflejaremos la información de los puntos comentados en
una matriz.
 Periódicamente sondearemos los procesos para identificar cualquier cambio en la
lista de interesados.
 Durante las reuniones planificadas consultaremos si existe algún cambio que haya
que tener en cuenta para actualizar la matriz de interesados.
 Cuando convoquemos una reunión daremos la posibilidad de extender la
convocatoria, de este modo podríamos identificar nuevos interesados o reemplazos
(vacaciones, bajas, refuerzos…)
2.4.5. Controlar el cronograma

Semanalmente seguiremos el estado de las actividades del proyecto para actualizar el avance
del mismo y gestionar los cambios de la línea base del cronograma a fin de cumplir el plan.
50
Las herramientas:
2.4.6. Controlar los costos

Es el proceso de monitorear el estado del proyecto para actualizar sus costos y gestionar
cambios de la línea base de costo.
Las herramientas:
 Atlassian Tempo, ver ANEXO A8 – Tempo.
 Microsoft Excel
2.4.7. Controlar las comunicaciones

Es el proceso de seguir y controlar las comunicaciones a lo largo de todo el ciclo de vida del
proyecto para asegurar que se satisfagan las necesidades de información de los interesados del
proyecto.
Se tendrá en cuenta el Plan de Gestión de las comunicaciones, así como la matriz de

comunicaciones.
Las herramientas:
 Establecer reuniones-efectivas periódicas de informe de situación:

o Vía presencial
o Vía Skype empresarial, posibilitando la participación desde diferentes zonas
geográficas
o Solución mixta presencial + Skype empresarial
 por temas de aforo
 por añadir a interesados para que estén informados aunque no
participen activamente en los contenidos
 Enviar informes y comunicaciones por las vías:
o eMail nominal
o eMail lista de distribución
o eMail de alta difusión o newsletter
 Mantendremos un archivo de comunicaciones en Confluence securizado por
usuario, en el que se podrá consultar en todo momento la información generada
correctamente clasificada:
o Actas de reunión
o Newsletter publicadas
51
2.4.8. Controlar los riesgos

Es el proceso de implementar los planes de respuesta a los riesgos, dar seguimiento a los riesgos
identificados, seguir los riesgos residuales, identificar nuevos riesgos y evaluar la efectividad del
proceso de gestión de los riesgos a través del proyecto.
La finalidad del control de los riesgos es:
 Verificar que los supuestos del proyecto siguen siendo válidos.

 Ver si los riesgos contemplados han cambiado, podríamos:
o Descartar
o Actualizar
o Añadir
 Seguir con los procesos de gestión de los riesgos.
Las herramientas:
 Confluence, ver ANEXO A1.3 – Confluence, contendrá actualizado los documentos

de gestión de riesgos en formato WIKI
 Periódicamente sondearemos los procesos para identificar cualquier cambio en la
matriz de riesgos.
 Durante las reuniones planificadas consultaremos si existe algún cambio que
potencialmente podría generar un nuevo riesgo (positivo o negativo).
2.4.9. Control de riesgos ágil con metodología SCRUM

Durante el desarrollo software, gracias a los sprints SCRUM, es posible identificar la presencia
de riesgos (nuevos o ya conocidos) y arrancar los mecanismos para su tratamiento, ganando
tiempo.
Las herramientas:
 Reuniones SCRUM Daily, ver anexo A5 –Modelo SCRUM.

 Reuniones SCRUM Weekly, ver anexo A5 –Modelo SCRUM.
2.4.10. Controlar la calidad

Es el proceso de seguir y registrar los resultados de la ejecución de las actividades de calidad, a
fin de evaluar el desempeño y recomendar los cambios necesarios.
Las herramientas:
 Se realizará una encuesta de satisfacción que permitan conocer la opinión del

cliente sobre el desempeño del equipo de proyecto, ver ANEXO A11 – Encuesta de
satisfacción.
52
2.4.11. Controlar los recursos

Es el proceso de seguir y registrar los resultados de los recursos humanos con el objetivo de
detectar problemas de rendimiento ya sean por conflictos personales, laborales o de cualquier
otra índole que impidan la correcta ejecución del proyecto.
Estas tareas se realizar con reuniones tanto formales como informales siendo grupales y/o
individuales según decida el Director de Proyecto en cada caso.
Las herramientas:
 Tempo
 Reuniones de concertación
 Reuniones de equipo
2.4.12. Control ágil de los recursos con metodología SCRUM

Durante el desarrollo software, gracias a los sprints SCRUM, es posible disponer de mucha
información sobre los recursos, lo que propicia identificar y corregir situaciones de:
 Bajo rendimiento
 Conflicto
 Disponibilidad
Las herramientas:
 Reuniones SCRUM Daily, ver anexo A5 –Modelo SCRUM.

 Reuniones SCRUM Weekly
2.4.13. Validar el alcance

Consiste en formalizar la aceptación de los entregables del proyecto que se hayan completado,
va aumentando las posibilidades de que el resultado final sea aceptado mediante la validación
de cada entregable individual, es un proceso que va ligado a los procesos de Control de
Calidad.
A medida que el proyecto se va desarrollando se van comparando los requisitos del proyecto
con los entregables, si estos cumplen con las expectativas del cliente se consideran aceptados,
por este motivo se realizará una recepción y revisión formal. En caso contrario, se dará lugar a
una no conformidad y como consecuencia a una solicitud de cambio.
Las herramientas:
 Checklist, ver ANEXO A10 – Modelo Checklist.
53
2.4.14. Controlar el alcance

Consiste en el seguimiento del estado del alcance del proyecto y de la línea base. Es común
que se produzcan cambios en los proyectos, generalmente en la búsqueda de satisfacer a los
interesados, sin embargo, a través de este proceso se procura que estos no impacten
negativamente en los términos de calidad, precio y plazo definidos inicialmente.
Las herramientas:
 Reuniones-efectivas
 Actas de reunión
 Herramientas software:
o Atlassian Jira, ver ANEXO A1.2 – Jira.
o Microsoft Project
o Microsoft Excel
o Atlassian Confluence, ver ANEXO A1.3 – Confluence.
 Informe de seguimiento, ver ANEXO A12 – Modelo informe seguimiento.
2.4.15. Controlar el alcance mediante metodología SCRUM

La inclusión de ‘sprints ágiles’ facilita este proceso durante la ejecución del mismo dividiendo
el desarrollo de software en varias etapas en las que se realiza al final de cada una un control
de alcance del proyecto.
La inclusión de ‘agilidad’ mediante elementos gestionados en base a Metodología SCRUM

incorpora un conjunto de elementos específicos que posibilitan un control detallado y rápida
adaptación para hacer frente a requisitos cambiantes o imprecisos:
ELEMENTO DESCRIPCIÓN HERRAMIENTA
Reunión ‘Daily’ Se ponen en común los El Scrum Manager asignado

avances realizados, bloqueos mantendrá una bitácora con
identificados… los puntos del día
mencionados, ideas,
sinergias…
Reunión ‘Weekly’ Cada semana tiene lugar una El Scrum Manager dejará
retrospectiva con los constancia mediante el uso
avances y puntos críticos de ‘Actas de Sprint’.
identificados, de este modo
todos los integrantes del
equipo se mantienen
alineados con los objetivos y
la realidad del proyecto
Reunión ‘Sprint’ Al finalizar cada una de las El Scrum Manager dejará
etapas de desarrollo, tendrá constancia mediante el uso
lugar una retrospectiva para de ‘Actas de Sprint’.
contrastar el alcance del
proyecto con los avances
realizados
54
Nótese que, aunque las metodologías ágiles abogan por ‘no documentar todo’ en este caso si
se considera de utilidad el mantener traza de los temas vistos en las reuniones, por:
 Ser la base de futuras lecciones aprendidas

 Tener respaldo y justificación con el cliente de los puntos tratados
 Identificar ideas, sinergias y futuras líneas de evolución
 Mantener traza, tener el conocimiento de lo que:
o Se hizo y por qué
o No se hizo y por qué
Las herramientas:
 Actas de reunión
 Pizarra SCRUM, ver ANEXO A7 – Pizarras SCRUM.
 Gráfico BurnDown SCRUM, ver ANEXO A14 – Gráfico BurnDown.
2.4.16. Controlar las adquisiciones

2.5. PROCESOS DE CIERRE
El Director de Proyecto, con la finalidad de comprobar y demostrar que todos los objetivos
marcados fueron cumplidos bajo los criterios pactados, será el responsable de:
 Supervisar que todos los entregables planificados fueron completados

satisfactoriamente
 Recopilar la información adicional respecto a las variaciones con el plan establecido
A continuación, se describen los procesos utilizados en el cierre de la Implantación.
2.5.1. Cerrar el proyecto

Es la finalización formal de las actividades del proyecto enmarcadas dentro de los grupos de
procesos utilizados y se considera completada con la firma del Acta de Cierre.
Por tanto, de forma previa se debe preparar la Documentación de Cierre, así como la
Documentación de las Lecciones Aprendidas, adicionalmente se reflejan los datos finales más
relevantes del desempeño del proyecto: cumplimiento de coste, plazo y calidad.
Las herramientas:
 Plantilla de lecciones aprendidas

 Acta de Cierre de Proyecto
55
 Checklist de validación
 Project
56
3. CONCLUSIÓN
La elaboración de este proyecto permitió colocar en práctica los conocimientos adquiridos en

el máster DIP durante el curso 2017-2018, siguiendo la metodología DIP, sobre un proyecto de
implantación de un servicio DevOps.
Mencionar el uso de una metodología en dos capas, que hace uso de:
Lo mejor de la metodología predictiva Lo mejor de la metodología ágil
 Se tienen en cuenta todos los aspectos  Hay una gestión continua del riesgo
del proyecto de una manera global  Existe una total flexibilidad en las
 Se puede estimar una fecha de modificaciones
finalización, a través del cálculo del  Se mantiene una comunicación
camino crítico (CPM) constante con el cliente, y los demás
 Resulta posible identificar cuellos de interesados del proyecto
botella (PERT y CPM)  Las especificaciones del producto final se
 Las dependencias entre las actividades adaptan a parámetros realistas en el
son las que definen un flujo realista de contexto del proyecto
trabajo y una correcta asignación de  Revisión y control continuo de los plazos
recursos (PERT) - El proyecto se ajusta a y costes
una estimación de presupuesto  Se da una correcta gestión de la
 Existe una visión global de los objetivos a incertidumbre, que permite rapidez de
conseguir en el cierre del proyecto y unas respuesta ante situaciones inesperadas
especificaciones concretas - Existe una  Se aprende de las lecciones aprendidas
predicción de recursos, y es posible durante la ejecución del proyecto
predecir sobre asignaciones
 Se pueden estimar costes, recursos y
resultados a medio y largo plazo
Adicionalmente, comentar las siguientes reflexiones:

 Como directores de proyecto tenemos que ser capaces de adaptarnos al entorno
(mejora contínua) y tomar riesgos (decidir).
 Los proyectos se realizan con personas y de ellas depende que podamos alcanzar el
éxito (habilidades, actitudes, experiencia, conflictos, intereses y motivaciones).
Debemos rodearnos de un gran equipo profesional y hacer que sus logros crezcan
junto con los nuestros.
En el momento de redactar el presente documento, el proyecto todavía se encuentra en fase de

ejecución. Contamos con el entorno de ‘Integración Contínua’ totalmente operativo en el
entorno ‘TEST’ y estamos llevando las configuraciones a ‘PRODUCCION’. Los primeros análisis
indican resultados muy positivos y se muestra claramente una ganancia en tiempo y calidad de
los desarrollos utilizamos para testear la nueva plataforma. Se puede consultar el detalle en el
ANEXO A15 – Primeros resultados. (Se puede consultar los primeros el registros de lecciones
aprendidas, ver ANEXO A16 – Lecciones aprendidas).
57
4. ANEXOS
A1 – Ecosistema Cliente
A1.1 – Estructura
El Departamento de Sistemas se encuentra dividido en áreas, que a su vez según su
naturaleza se clasifican en:
Áreas transversales, orientadas a dar soporte y cubrir necesidades del resto de áreas:
 Arquitectura de Software
 Arquitectura y Administración Hardware
 BBDD
 Telecomunicaciones
 Seguridad
 Operaciones
Áreas funcionales, orientadas a los demás Departamentos de Negocio de la empresa:

 Tienda
 Logística y Comercial
 eCommerce
 RRHH
 Financiero
 Expansión
Áreas adjuntas a Dirección del Departamento de Sistemas:
 Oficina de Proyectos, se ocupa de coordinar transversalmente todo el Departamento de

Sistemas, posee una cartera de proyectos completa y única con la especificación,
alcance e hitos principales de los mismos.
 Oficina Técnica, lidera la implantación de soluciones técnicas y de arquitectura en los
proyectos.
 Coordinación y control, se ocupa de la confección y seguimiento del presupuesto de
Sistemas, la coordinación de las compras y la relación con todos los proveedores de
manera coordinada con Servicios Centrales de la Empresa.
 Coordinación Internacional, se ocupa de la relación con todas las filiales del mundo.
En conjunto el total de los equipos involucrados reúne directa o indirectamente un total

cercano a las quinientas personas. Este hecho tiene consecuencias:
 Beneficiosas:
o Mucha agilidad en el desarrollo y mantenimiento.
o Desarrolladores con un alto grado de conocimiento de los sistemas de cada área
de negocio.
 Mejorables:
o No existe una cultura de procesos comunes.
o No hay un estándar de calidad común en los procesos.
o No se desarrolla una cultura de mejora de procesos.
58
Las aplicaciones Java que se desarrollan en el seno del Departamento de Sistemas son de los
siguientes tipos:
• Aplicaciones WEB
• Servicios WEB
• Aplicaciones cliente
• Procesos Bach, para ser ejecutados periódicamente o bajo petición
Los equipos pueden integrar en sus desarrollos el uso de los siguientes recursos:
• Maven: La compilación, empaquetado, construcción, ejecución de tests unitarios
y generación de informes de código del proyecto se realizará con la herramienta
Maven.
• Hibernate: Para el acceso a datos se usará el mapeador objeto-relacional (ORM)
Hibernate. Se podrá prescindir en algunos casos del uso de Hibernate siempre
que Arquitectura de Software lo valide bajo petición justificada del equipo de
diseño y desarrollo.
• Spring Framework: Para la gestión de la transaccionalidad sobre Hibernate, la
inyección de dependencias (inyección de las implementaciones de los interfaces),
la integración de las distintas tecnologías usadas en el proyecto, se usa Spring
Framework.
• Spring MVC: En los proyectos con interfaz Web se usará como framework Model-
View-Controller para integrar la capa de modelo con la capa de vista la librería
Spring MVC.
A1.2 – Jira
JIRA es una aplicación Web en Java, desarrollada por Atlassian, para el seguimiento
de incidencias y para la gestión operativa de proyectos.
Inicialmente Jira se utilizó para el desarrollo de software, sirviendo de apoyo para la gestión de
requisitos, seguimiento del estados y errores. Jira puede ser utilizado para la gestión y mejora
de procesos gracias a sus funciones para la organización de flujos de trabajo.
La herramienta ha sido adaptada a las necesidades y modo de trabajo en el Departamento de

Sistemas. En la que aparece a continuación se definen una serie de términos importantes a la
hora de utilizar Jira:
TÉRMINO DEFINICIÓN
Petición Trabajo a realizar, que según los equipos/áreas involucrados puede ser de
ámbito:
 Local: tareas, incidencias, mejoras,... a resolver por lo integrantes de
un proyecto o área concretos.
 Trasversal: cuando los trabajos se derivan hacia otras áreas del
Departamento de Sistemas.
Proyecto Se identifican como proyecto:
 Proyecto: trabajo o conjunto de trabajos definidos como tal por
Oficina de Proyectos.
 Agrupación funcional/técnica: conjunto de trabajos en los que
dividimos/agrupamos el evolutivo y correctivo por aplicación y/o
tecnología.
59
Tipo de Clasificación de los trabajos a realizar en un proyecto en Jira

Petición
 Incidencia: mantenimiento correctivo.
 Mejora: mantenimiento evolutivo.
 Tarea: trabajo o acción que no supone incidencia o mejora.
 Peticiones áreas transversales: Petición BBDD, Petición ArqSw,
Petición ArqSist, Petición Telecomunicaciones, Petición Seguridad,
etc. A través de las cuales los proyectos, solicitan la realización de un
trabajo a las áreas transversales desde sus propios proyectos.
Página principal de Jira:
Ilustración 20 - Dashboard Jira [Ref: E04]
A1.3 – Confluence
Confluence es un “wiki” corporativo desarrollado en Java, comercializado por Atlassian. Es la
principal base de conocimiento para los equipos de trabajo y a través de esta herramienta
pueden acceder a información sobre los diferentes procesos que deben conocer para desarrollar
su actividad. (Por ejemplo, los procedimientos de interacción entre Áreas
Transversales y Áreas Funcionales).
Las principales ventajas del producto:

• Seguridad, sistema de permisos.
• Sencilla instalación y gestión.
• Interfaz WYSIWYG fácil de usar
• Herramientas para la búsqueda y la estructuración de su “wiki”.
60
• Una API abierta para la ampliación y la integración.
Confluence posee un sistema de permisos muy granular, que permite controlar quién
puede ver, crear, editar, comentar… contenidos. Es una herramienta intuitiva, fácil de utilizar,
no requiere conocimientos específicos.
Todo proyecto del Departamento de Sistemas tendrá claramente diferenciadas dos

secciones en Confluence:
• Documentación Privada, de acceso restringido, únicamente tendrá acceso el equipo
responsable del proyecto.
(Documentación detallada en la metodología, actas de reunión, prototipos,..)
• Documentación Pública, acceso público, con información que el equipo responsable
de proyecto desee compartir.
Página principal de Confluence:
Ilustración 21 - Dashboard Confluence [Antonio Garea]
61
Espacio de un proyecto en Confluence:
Ilustración 22 - Espacio de proyecto en Confluence [Antonio Garea]
A2 – Herramientas DevOps
Como DevOps pretende ser un modo de trabajo interfuncional, en lugar de una sola herramienta
de DevOps existen conjuntos o toolchains de múltiples herramientas. Se espera que tales
herramientas de DevOps encajen en una o más de estas categorías, que reflejen los aspectos
clave del proceso de desarrollo y entrega:
1. Código: desarrollo y revisión de código, herramientas de administración de código

fuente, fusión de código
2. Construcción: herramientas de integración continua, estado de compilación
3. Prueba: herramientas de prueba continuas que brindan retroalimentación sobre los
riesgos comerciales
4. Paquete: repositorio de artefactos, distribución previa a la implementación de la
aplicación
5. Lanzamiento: gestión de cambios, aprobaciones de versiones, automatización de
versiones
6. Configurar: configuración y gestión de la infraestructura, Infraestructura como código
7. Monitor: monitoreo del rendimiento de las aplicaciones, experiencia del usuario final
Algunas categorías son más esenciales en una cadena de herramientas DevOps que otras;
especialmente la integración continua (por ejemplo, Jenkins) y la infraestructura como código
(por ejemplo, Docker).
62
En el siguiente gráfico podemos ver representadas el conjunto de herramientas más utilizadas,

así como su ámbito de aplicación dentro del marco DevOps:
Ilustración 23- Herramientas DevOps [E08]
63
A3 – Modelo Simplificado DevOps
Ilustración 24- Modelo Simplificado DevOps [Antonio Garea]
64
A4 - Beneficios que aporta SCRUM al proceso de desarrollo

BENEFICIO DETALLE
Es muy común en los desarrollos tradicionales que, desde la toma de
1.- Gestión de las
requisitos hasta la entrega del producto terminado, pase mucho tiempo
expectativas del
y las necesidades y expectativas del cliente cambien. Con SCRUM, el
Cliente
cliente establece sus expectativas indicando el valor que le aporta a
cada requisito del proyecto y cuándo espera que esté completado. Así,
el cliente comprueba de manera regular si se van cumpliendo sus
expectativas durante todo el desarrollo del proyecto, dándole la
posibilidad de poder cambiar los requisitos y prioridad de los mismos.
¿En definitiva? Se ahorra esfuerzo y tiempo al evitar hipótesis.

2.- Reducción en Al finalizar cada iteración, se entregan funcionalidades completas y
tiempo de funcionales, por lo que el usuario es capaz de utilizarlo desde ese
desarrollo y mismo momento sin la necesidad de que el proyecto esté
puesta en completamente finalizado.
marcha
3.- Capacidad de Gracias a que, con SCRUM, el cliente está revisando el producto al final
adaptación de cada iteración, éste es capaz de adaptar los requerimientos o la
prioridad de los casos de uso.
4.- Aumento de SCRUM se basa en un proceso de mejora continua, con una constante
la productividad revisión del trabajo, realizada por el propio equipo, identificando las
fortalezas y debilidades del mismo, con el objetivo de mejorar al
máximo el sprint anterior.
En el inicio de la iteración, los miembros del equipo estiman de manera
5.- Estimación de
conjunta el esfuerzo necesario para completar requisitos y tareas.
esfuerzo
continua
A5 - Modelo SCRUM
Ilustración 25- Modelo SCRUM [Ref: E09]
65
A5.1 - Roles dentro de un equipo Scrum
Se definen varios roles, que juntos forman el equipo Scrum. Tendrán distintas funciones durante
el desarrollo del proyecto:
 Scrum Master: es la persona encargada de gestionar el proyecto Scrum, quedando al

servicio del equipo. Se ha de asegurar de que el equipo entiende y adopta la forma de
trabajo Scrum. También ayuda a las personas externas al equipo Scrum a entender qué
interacciones pueden ser productivas.
 Dueño del producto o product owner: gestiona las características que ha de tener el
producto final. Organiza la prioridad de las tareas, y se ha de asegurar de que el equipo
entiende todos los elementos del trabajo que han de realizar.
 Equipo de desarrollo o development team: está compuesto por un equipo de 3 a 9
miembros, sin ninguna jerarquía determinada, que se autogestionan. Este modelo de
equipo está diseñado para facilitar la flexibilidad, la creatividad y la productividad.
A5.2 - Tareas de Scrum
 Lista de producto o product backlog: es una lista de los requisitos del producto. El dueño
del producto es el único responsable de su contenido y el orden de prioridades de las
tareas. Puede actualizarse en cualquier momento.
 Lista de pendientes del sprint o sprint backlog: elementos de la lista de producto
seleccionados para el próximo sprint.
 Incremento o increment: elementos de la lista de productos completados durante un
sprint.
A5.3 - Fases de Scrum
En Scrum existen eventos predefinidos, con la idea de minimizar las reuniones no programadas.
 Sprint: es la parte central de Scrum. Es un periodo de tiempo de 1 a 4 semanas, durante

el cual se crea un incremento del producto. Cada nuevo sprint comienza
inmediatamente después del anterior.
 Reunión de planificación de sprint o sprint planning meeting: en una reunión de unas 8
horas (para sprints de 4 semanas), el equipo Scrum al completo planificará lo que se va
a hacer en el próximo sprint.
 Objetivo del sprint o sprint goal: es la meta que se ha establecido, y que se puede
alcanzar completando la lista de producto.
 Scrum diario o daily Scrum: reunión diaria de 15 minutos donde el equipo de desarrollo
crea un plan de trabajo para el día.
 Revisión de sprint o sprint review: reunión informal de 4 horas (para sprints de 4
semanas) en la que se inspecciona el incremento y se cambia la lista de producto si se
considera necesario. En estas reuniones colaboran el equipo Scrum y cualquier otro
interesado, y entre otros temas se tratan la revisión del presupuesto y de la línea de
tiempo.
 Retrospectiva de sprint o sprint retrospective: es una reunión para el equipo Scrum en
la cual se proponen mejoras para el siguiente Sprint. Tiene lugar después de la revisión
de sprint, y una duración de 3 horas (para sprints de 4 semanas).
66
A6 – Gestión de riesgos
A6.1. – Identificación de riesgos
ID RIESGO NEGATIVO CLASIFICACIÓN
RN01 Reducción de presupuesto Externo

RN02 Políticas de contención en el Cliente Externo
RN03 No satisfacción de las necesidades del cliente Interno
RN04 Desviación de los objetivos y cambios de alcance Interno
Falta de recursos durante las visitas en las instalaciones de Externo
RN05 Cliente
RN06 Reuniones improductivas en Cliente Interno
RN07 No se nos entrega el entorno de Testing en plazo Externo
RN08 No se nos entrega el servidor SVN en plazo Externo
RN09 No se nos entrega el servidor IC PRO en plazo Externo
RN10 No se nos entrega el repositorio de artefactos PRO en plazo Externo
Aparición de otros proveedores de la competencia que podrían Externo
RN11 asumir la evolución de nuestro servicio
No se gestiona correctamente el acceso del Equipo de Proyecto Externo
RN12 a los recursos de Cliente
Problemas de tráfico impiden llegar puntualmente a una Externo
RN13 reunión con el Cliente
RN14 Problemas derivados de calendario y jornada laboral de Cliente Interno
RN15 Sobrepasar el presupuesto acordado Interno
RN16 Incumplimiento de los plazos establecidos Interno
RN17 Incumplimiento de los hitos establecidos Interno
RN18 Dificultad para conseguir el equipamiento necesario Interno
RN19 Pérdida o robo de equipamiento durante la ejecución Interno
RN20 Retraso en la recepción de recursos Externo
RN21 Problemas con los suministros básicos (luz y agua) Externo
RN22 Equipos y materiales con taras Interno
RN23 Problemas con los proveedores Interno
RN24 Errores en la gestión de dietas por desplazamiento Interno
RN25 Problemas con el servicio ‘Tarjeta/Ticket Restaurant’ Interno
RN26 Períodos de ‘baja laboral’ en los equipos Interno
RN27 Ausentismo trabajadores Interno
RN28 Cambios en la organización/equipo/dirección Interno
RN29 Personal poco cualificado Interno
67
RN30 Problemas de coordinación de equipo Interno

RN31 Errores de planificación Interno
RN32 Aumento del valor de los costes de producción Interno
RN33 Huelga de trabajadores Interno
RN34 Quiebra de la empresa Interno
RN35 Problemas de confidencialidad en el Equipo de Proyecto Interno
RN36 Problemas de conducta/actitud en el Equipo de Proyecto Interno
RN37 Fallos o imprecisiones al comunicar la evolución de os trabajos Interno
RN38 Problemas derivados de la falta de documentación Interno
Malas estimaciones a la hora de valorar el tiempo necesario en Interno
RN39 cumplir la normativa y procesos del ecosistema de Cliente
Mala estimación en los tiempos y procesos necesarios para Interno
RN40 aplicar llevar un cambio a Producción
RN41 No medir adecuadamente el grado de satisfacción del Cliente Interno
No establecer pautas claras de comunicación con los Interno
RN42 interesados
RN43 Presiones por parte del Cliente al Director Externo
Presiones por parte del Cliente a los miembros del Equipo de Externo
RN44 Proyecto
RN45 Quejas por parte del Cliente Externo
RN46 Quejas por parte de equipos colaboradores del Cliente Externo
RN47 Equipo de Proyecto desmotivado Interno
RN48 Equipo de Proyecto desinformado Interno
RN49 Problemas internos en el Equipo de Proyecto Interno
RN50 Director de proyecto con poca experiencia Interno
Problemas de adaptación al modelo propuesto por parte de los Externo
RN51 usuarios
Reticencia a la hora de adoptar los nuevos estándares por parte Externo
RN52 de los usuarios
RN53 Problemas de disponibilidad del servicio Interno
RN54 Problemas de integridad del servicio Interno
RN55 Problemas de confidencialidad y seguridad en el servicio Interno
RN56 Software mal configurado Interno
RN57 Diseño de soluciones con deuda técnica Interno
Servidores mal dimensionados, impiden dar un servicio Interno
RN58 correcto al total de los proyectos
RN59 Filtros firewall mal definidos Externo
68
RN60 Fallos de coordinación al realizar la puesta en marcha inicial Interno

Fallos de coordinación al realizar una actualización durante la Interno
RN61 fase de garantía y en adelante
RN62 Problemas con el proceso de parada y puesta en servicio Interno
Problemas o conflicto de intereses con otros equipos Externo
RN63 transversales
RN64 Problema con la obtención de Licencia IC Bamboo Externo
Problema el dimensionamiento en agentes permitido por la Interno
RN65 Licencia IC Bamboo
RN66 Problema con la obtención de Licencia Repositorio Artifactory Externo
Retrasos en los despliegues y actualizaciones por la Externo
RN67 participación del resto de equipos involucrados
Problemas con las ventanas de despliegue y cambio de Externo
RN68 configuración establecidas por procedimiento
Conflictos de intereses con otros equipos para la realización de Externo
RN69 ‘nuestras’ tareas.
RN70 Retraso en el servicio de atención de incidencias Atlassian Externo
RN71 Retraso en el servicio de atención de incidencias Jfrog Externo
Mala estimación de crecimiento a medio plazo podría causar Interno
RN72 bloqueo y lentitud en la plataforma
Un mala secuencia de recuperación podría ocasionar bloqueos Interno
RN73 y lentitud en el proceso
RN74 Fallos en BBDD Externo
RN75 Fallos en almacenamiento local Externo
RN76 Fallos en discos de red NAS Externo
RN77 Fallos de comunicaciones entre máquinas Externo
RN78 Fallos en los servidores IC Externo
RN79 Fallos en los sistemas de Backup Externo
RN80 Fallos en los agentes IC Externo
RN81 Virus en nuestra infraestructura Interno
RN82 Virus en la infraestructura de cliente Externo
RN83 Incendio en nuestra infraestructura Interno
RN84 Incendio en la infraestructura de Cliente Externo
ID RIESGO POSITIVO CLASIFICACIÓN
RP01 Finalización adelantada de la ejecución Interno
69
RP02 El equipo de Arquitectura Sistemas asume la solicitud de reglas Externo

firewall
RP04 El equipo Middleware destina recursos dedicados para Externo
‘nuestras’ máquinas.
RP05 Posibilidad obtener un nuevo proyecto si presentamos un Interno
dossier futuras líneas de evolución del servicio
RP06 Equipo de Proyecto motivado, dinámico y comprometido Interno
RP07 Posibilidad de trabajar desde las instalaciones de Cliente Externo
RP08 Posibilidad de saltar burocracia administrativa de Cliente Externo
RP09 Desarrollo de creatividad del Director/Equipo de Proyecto Interno
RP10 Desarrollo de habilidades del Director/Equipo de Proyecto Interno
RP11 Generar un dossier de lecciones aprendidas de valor Interno
RP12 Posibilidad de obtener información dirigida mediante encuestas Interno
de satisfacción
RP13 Un equipo bien cohesionado y multidisciplinar Interno
RP14 Director de proyecto sin vicios, con conocimientos y muchas Interno
ganas de hacerlo bien y aprender
RP15 Director de proyecto enérgico, actitud positiva y abierta Interno
RP16 Aparición de otros proveedores de la competencia con los que Externo
podríamos colaborar a futuro
RP17 Afianzarnos como proveedor y poder participar en otros Interno
proyectos del Cliente
RP18 Posibilidad de establecer relación de Partner con Altassian Interno
RP19 Formar ‘Equipo’ Interno
A6.2 – Análisis cualitativo

ID PROBABILIDAD IMPACTO CLASIFICACIÓN
RN01 Baja Muy Alto Moderado

RN02 Moderada Muy Alto Alto
RN05 Baja Bajo Bajo
RN06 Moderada Moderado Moderado
RN07 Alta Muy Alto Muy Alto
RN08 Baja Alto Moderado
RN09 Moderada Alto Alto
70
RN11 Muy Baja Muy Bajo Bajo

RN12 Muy Alta Muy Alto Muy Alto
RN13 Muy Baja Moderado Bajo
RN14 Baja Bajo Bajo
RN16 Alta Alto Alto
RN19 Muy Baja Bajo Bajo
RN21 Muy Baja Alto Moderado
RN22 Baja Moderado Moderado
RN24 Baja Bajo Bajo
RN25 Baja Bajo Bajo
RN32 Muy Baja Muy Alto Moderado
RN43 Muy Alta Bajo Moderado
RN44 Muy Alta Alto Muy Alto
71
RN46 Baja Bajo Bajo

RN51 Baja Bajo Bajo
RN52 Alta Bajo Bajo
RN57 Moderada Muy bajo Moderado
RN60 Alta Bajo Bajo
RN66 Moderada Bajo Moderado
RN67 Alta Moderado Alto
RN68 Alta Moderado Alto
RN71 Baja Bajo Bajo
72

RP01 Moderada Alto Alto

RP02 Alta Alto Alto
RP04 Moderada Alto Alto
RP05 Alta Muy Alto Muy Alto
RP06 Moderada Muy Alto Alto
RP07 Alta Alto Alto
RP08 Alta Bajo Moderado
RP09 Moderada Moderada Moderado
RP10 Alta Alta Alto
A6.3 – Análisis cuantitativo

RN01 0,3 0,8 0,24

RN02 0,5 0,8 0,4
RN03 0,5 0,8 0,4
RN04 0,5 0,8 0,4
RN05 0,3 0,1 0,03
RN06 0,5 0,2 0,1
RN07 0,7 0,8 0,56
73
RN08 0,3 0,4 0,12

RN09 0,5 0,4 0,2
RN10 0,5 0,4 0,2
RN11 0,1 0,05 0,01
RN12 0,9 0,8 0,72
RN13 0,1 0,2 0,02
RN14 0,3 0,1 0,03
RN15 0,3 0,4 0,12
RN16 0,7 0,4 0,28
RN17 0,5 0,8 0,4
RN18 0,1 0,2 0,02
RN19 0,1 0,1 0,01
RN20 0,5 0,2 0,1
RN21 0,1 0,4 0,04
RN22 0,3 0,2 0,06
RN23 0,3 0,2 0,06
RN24 0,3 0,1 0,03
RN25 0,3 0,1 0,03
RN26 0,1 0,4 0,04
RN27 0,3 0,4 0,12
RN28 0,3 0,2 0,06
RN29 0,1 0,4 0,04
RN30 0,5 0,4 0,2
RN31 0,3 0,8 0,24
RN32 0,1 0,8 0,08
RN33 0,1 0,2 0,02
RN34 0,1 0,8 0,08
RN35 0,3 0,4 0,12
RN36 0,3 0,8 0,24
RN37 0,3 0,4 0,12
RN38 0,5 0,4 0,2
RN39 0,7 0,8 0,56
RN40 0,7 0,8 0,56
RN41 0,5 0,8 0,4
RN42 0,5 0,8 0,4
74
RN43 0,9 0,1 0,09

RN44 0,9 0,4 0,36
RN45 0,5 0,8 0,4
RN46 0,3 0,1 0,03
RN47 0,1 0,8 0,08
RN48 0,5 0,8 0,4
RN49 0,1 0,8 0,08
RN50 0,5 0,8 0,4
RN51 0,3 0,1 0,03
RN52 0,7 0,1 0,07
RN53 0,1 0,4 0,04
RN54 0,1 0,4 0,04
RN55 0,1 0,4 0,04
RN56 0,5 0,2 0,1
RN57 0,5 0,05 0,3
RN58 0,3 0,8 0,24
RN59 0,1 0,2 0,02
RN60 0,7 0,1 0,07
RN61 0,5 0,8 0,4
RN62 0,5 0,8 0,4
RN63 0,3 0,2 0,06
RN64 0,5 0,2 0,1
RN65 0,5 0,4 0,2
RN66 0,5 0,1 0,05
RN67 0,7 0,2 0,14
RN68 0,7 0,2 0,14
RN69 0,3 0,2 0,06
RN70 0,3 0,8 0,24
RN71 0,3 0,1 0,03
RN72 0,5 0,2 0,1
RN73 0,5 0,8 0,4
RN74 0,1 0,4 0,04
RN75 0,1 0,4 0,04
RN76 0,1 0,4 0,04
RN77 0,1 0,4 0,04
75
RN78 0,5 0,8 0,4

RN79 0,1 0,2 0,02
RN80 0,5 0,2 0,1
RN81 0,1 0,2 0,02
RN82 0,1 0,05 0,01
RN83 0,1 0,2 0,02
RN84 0,1 0,05 0,01
RP01 0,5 0,4 0,2

RP02 0,7 0,4 0,28
RP04 0,5 0,4 0,2
RP05 0,7 0,8 0,56
RP06 0,5 0,8 0,4
RP07 0,7 0,4 0,28
RP08 0,7 0,1 0,07
RP09 0,5 0,2 0,1
RP10 0,7 0,4 0,28
RP11 0,7 0,8 0,56
RP12 0,7 0,8 0,56
RP13 0,7 0,8 0,56
RP14 0,7 0,8 0,56
RP15 0,7 0,8 0,56
RP16 0,5 0,8 0,4
RP17 0,7 0,8 0,56
RP18 0,5 0,8 0,4
RP19 0,5 0,8 0,4
A6.4. – Respuesta a los riesgos

ID CLASIFICACIÓN ESTRATEGIA PLAN DE ACCIÓN RESPONSABLE
RN01 Moderado Mitigar La planificación debe seguirse de forma Director

ajustada y alineada con el Cliente, de Proyecto,
modo que en el momento de ajuste Responsable
presupuestario el impacto sea lo menor Financiero,
posible. E incluso podamos encontrar un Cliente
76
modo de finalización adaptado a las

circunstancias.
RN02 Importante Mitigar La planificación debe seguirse de forma Director
ajustada y alineada con el Cliente, de Proyecto,
modo que en el momento de ajuste Responsable
presupuestario el impacto sea lo menor Financiero,
posible. E incluso podamos encontrar un Cliente
modo de finalización adaptado a las
circunstancias.
RN03 Importante Evitar Debemos contrastar la evolución del Director
proyecto con la planificación así como Proyecto,
prestar atención al cliente, indagando e Equipo
intentando obtener ‘feedback’ que nos Devops
permita anticiparnos y corregir los
procesos que causan desacuerdo.
RN04 Importante Evitar Debemos contrastar la evolución del Director
proyecto con la planificación para Proyecto,
minimizar y atajar cualquier desvío no Equipo
planificado. Cualquier cambio de alcance Devops,
debe ser valorado y, en caso de Cliente
aceptación, se llevará a la planificación
actual con garantía de éxito.
RN05 Tolerable Mitigar Comunicaremos al Cliente nuestras Director
necesidades en las visitas programadas. Proyecto,
Los trabajadores desplazados llevarán su Equipo
laptop y todos los elementos necesarios Devops
para trabajar en remoto.
RN06 Moderado Evitar Siempre se tendrán claros y acordados Director
previamente los puntos de la orden del Proyecto,
día de cada convocatoria. Se nombrarán Cliente
moderadores para velar por reuniones
eficaces.
RN07 Inaceptable Evitar Solicitaremos el entorno en cuanto Director
tengamos la información necesaria para Proyecto,
arrancar los procedimientos internos del Equipo
Cliente. Haremos un seguimiento diario Devops,
para saber en qué estado está la petición ArqSistemas
y poder aplicar medidas correctivas.
RN08 Moderado Evitar Solicitaremos el servidor en cuanto Director
RN09 Importante Evitar Solicitaremos el servidor en cuanto Director
Cliente. Haremos un seguimiento diario
77
para saber en qué estado está la petición Devops,

y poder aplicar medidas correctivas. ArqSistemas
RN10 Importante Evitar Solicitaremos el servidor en cuanto Director
RN11 Tolerable Aceptar Mantendremos nuestro código ético Director
profesional. Cumpliremos el contrato Proyecto,
con el Cliente del mejor modo, Equipo
asegurando el éxito de nuestro proyecto Devops,
y, en caso de ser necesario, colaborar Cliente,
con el nuevo proveedor. Informaríamos Nuevo
a RRHH para evitar fugas de talento a la proveedor,
competencia. RRHH
RN12 Inaceptable Evitar Crearemos un dossier con tondos los Director
accesos necesarios y gestionaremos los Proyecto,
accesos en bloques. Simplificamos la Equipo
depuración de errores, mantener la traza Devops
y hacer un seguimiento sobre la
solicitud.
RN13 Tolerable Aceptar Comunicaremos con la mayor brevedad Director
el contratiempo, solicitando Proyecto,
mantener/cancelar/mover la reunión. Equipo
Mantendremos actitud abierta antes las Devops
opciones que nos presente el Cliente.
RN14 Tolerable Mitigar Trasladaremos a nuestro calendario una Director
previsión de eventos del Cliente para Proyecto
mantener las fechas ajustadas con
nuestras actividades.
RN15 Moderado Evitar Debemos contrastar la evolución del Director
proyecto con la planificación, cuando Proyecto,
detectemos un desvío que incurra en Responsable
coste lo comunicaremos Financiero
inmediatamente, para buscar el modo
de corregir y hacer uso de las partidas de
contingencia disponibles.
RN16 Importante Evitar Llevaremos un seguimiento ajustado del Director
proyecto en base a la planificación. Si Proyecto,
detectamos un desvío que impida Equipo
completar una tarea en una fecha Devops
comprometida lo comunicaremos lo
antes posible, en busca de un acuerdo
de nueva entrega y de este modo mitigar
posibles consecuencias.
78
RN17 Inaceptable Evitar Llevaremos un seguimiento ajustado del Director

proyecto en base a la planificación, Proyecto,
debemos cumplir los hitos especificados. Equipo
Devops
RN18 Tolerable Mitigar Dispondremos de contratos con varios Director de
proveedores que nos garanticen que Proyecto,
pueden cumplir con los suministros Responsable
solicitados en un tiempo máximo. de Recursos
RN19 Tolerable Transferir Dispondremos de un seguro para cada Director de
uno de los equipos itinerantes. Proyecto,
Utilizaremos los de equipos de reserva o Equipo
utilizaremos una partida presupuestaria Devops,
de contingencia. Responsable
Financiero,
Responsable
de Recursos
RN20 Moderado Mitigar Dispondremos de contratos con varios Director de
proveedores que nos garanticen que Proyecto,
pueden cumplir con los suministros Responsable
solicitados en un tiempo máximo. de Recursos
RN21 Moderado Aceptar Debemos tener al día las órdenes de Responsable
pago de los suministros. En caso de de Recursos,
incidente la contingencia será el trabajo Responsable
en remoto desde Cliente o teletrabajo. Financiero,
Director
Proyecto,
Equipo
Devops
RN22 Moderado Aceptar Solicitaremos un nuevo equipo al Director de
proveedor. Utilizaremos los de equipos Proyecto,
de reserva o utilizaremos una partida Responsable
presupuestaria de contingencia. de Recursos,
Responsable
Financiero
RN23 Moderado Evitar Mantendremos al día los pagos, en caso Responsable
de detectar problemas con uno de los de Recursos,
proveedores, resolveremos de forma Responsable
cordial y utilizaremos otro alternativo. Financiero
RN24 Tolerable Aceptar En caso de falla de los servicios se Responsable
gestionará la solución de la incidencia y de Recursos,
se abonarán en nómina las facturas Responsable
correspondientes. Financiero
RN25 Tolerable Aceptar En caso de falla de los servicios se Responsable
gestionará la solución de la incidencia y de Recursos,
se abonarán en nómina las facturas Responsable
correspondientes. Financiero
79
RN26 Moderado Aceptar Se comunicarán con la mayor brevedad y Director

en caso de ser necesario se buscarían Proyecto,
nuevas incorporaciones el Equipo de Responsable
Proyecto. RRHH,
Responsable
Financiero
RN27 Moderado Mitigar Se comunicarán con la mayor brevedad y Director
en caso de ser necesario se tomarán las Proyecto,
medidas correctivas oportunas. Para Responsable
evitar esta situación se realizará una RRHH,
supervisión cercana del equipo. Responsable
Financiero
RN28 Moderado Aceptar Se comunicarán con la mayor brevedad, Director
se hará en la medida de lo posible un Proyecto,
traspaso de conocimiento y reuniones Equipo
eficaces para comunicar los Devops
detalles/responsabilidades /roles
RN29 Moderado Evitar El equipo de RRHH debe seleccionar a los Responsable
candidatos más capacitados para el RRHH,
puesto. El Director de Proyecto junto Director
con el resto de Equipo de Proyecto debe Proyecto,
detectar las carencias e intentar Equipo
potenciar la adquisición de Devops
competencias.
RN30 Importante Evitar Se deben realizar reuniones eficaces y Director
comunicar los objetivos, alcance y Proyecto,
estado de las actividades. Del mismo Equipo
modo buscar sinergias, mejoras… Devops
RN31 Inaceptable Evitar Debemos realizar una planificación Director
adecuada, desglosando las tareas y Proyecto,
ordenarlas en el cronograma con Expertos
garantías. Establecer mecanismos de
control para identificar errores y
detectarlos en las primeras fases. Nos
apoyaremos en lecciones aprendidas y
juicio de expertos.
RN32 Moderado Evitar Debemos tener en cuenta en el cálculo Director
de los costes de producción la Proyecto,
variabilidad del valor de los recursos Responsable
utilizados durante el ciclo de vida del Financiero
proyecto.
RN33 Tolerable Aceptar Se comunicarán y evaluará el impacto Director
con la mayor brevedad, se determinará Proyecto,
si es necesario designar un equipo de Equipo
servicios mínimos. Devops,
Responsable
RRHH, Cliente
80
RN34 Moderado Aceptar Se aportarán las tareas y documentación Director

finalizados hasta la fecha a Cliente. Se Proyecto,
realizará una reunión para tratar el tema Responsable
y cerrar formalmente la colaboración. Financiero
RN35 Inaceptable Evitar Desde el minuto cero se informará Director
convenientemente de las consecuencias Proyecto,
de fallar en este aspecto. Responsable
RRHH
RN36 Importante Mitigar Se aplicarán las medidas correctivas Director
oportunas buscando restaurar la Proyecto
cordialidad y buen hacer en el Equipo de
Proyecto.
RN37 Moderado Mitigar Se establecerán comunicaciones eficaces Director
y en base al plan de gestión de las Proyecto,
comunicaciones se tendrán en cuenta Equipo
todos los aspectos para asegurar que la Devops
información siga los canales
establecidos.
RN38 Importante Mitigar Se elaborará y validará documentación Director
de calidad en base a controles Proyecto,
específicos, como cualquier otro Equipo
desarrollo pero atendiendo a formato y Devops
soporte utilizados.
RN39 Inaceptable Evitar Debemos familiarizarnos con todos la Director
normativa y procedimientos Cliente, y en Proyecto,
la medida de lo posible adelantar las Equipo
ejecuciones/solicitudes con pilotos, Devops
antes de la necesidad real.
RN40 Inaceptable Evitar Debemos familiarizarnos con todos la Director
normativa y procedimientos Cliente, y en Proyecto,
la medida de lo posible adelantar las Equipo
ejecuciones/solicitudes con pilotos, Devops
antes de la necesidad real.
RN41 Importante Mitigar Se realizarán encuestas dirigidas y se Director
consultará la opinión y puntos de mejora Proyecto,
detectados por el Cliente. De este modo Cliente
podremos tener una visión clara de
nuestra evolución y puntos a corregir o
potenciar.
RN42 Importante Mitigar Se establecerán comunicaciones eficaces Director
y en base al plan de gestión de las Proyecto,
comunicaciones se tendrán en cuenta Equipo
todos los aspectos para asegurar que la Devops
información siga los canales establecidos
llegando a todos los interesados.
RN43 Moderado Mitigar Manteniendo la cabeza fría y siguiendo Director
la planificación inicial, sin encajar nada Proyecto
81
nuevo sin hacer la valoración y gestión

del cambio correspondiente.
Manteniendo una actitud asertiva y no
cerrando la opción del diálogo que
posibilite futuras oportunidades.
RN44 Inaceptable Evitar El Director de Proyecto debe amparar Director
bajo su figura al resto del Equipo de Proyecto
Trabajo. Trasladando él mismo la
información, pero dejando al Equipo de
Proyecto al margen de las presiones
externas.
RN45 Importante Mitigar Atenderemos las cuestiones que nos Director
trasladan, integrando controles en Proyecto
nuestras actividades para intentar
detectar y corregir prácticas que lleven
nuevamente al descontento. Transmitir
que se han tomado medidas correctivas
RN46 Tolerable Aceptar Escuchar y en las cuestiones que se Director
trasladan intentar aplicar la mejora para Proyecto,
fomentar una buena colaboración. Pero Equipo
sin transmitir que se han tomado Devops
medidas correctivas ni incurrir en
desvíos de la planificación.
RN47 Moderado Evitar Se debe mantener al Equipo activo, Director
reconociendo méritos y haciendo Proyecto
hincapié en los puntos fuertes de
trabajar para este Proyecto/Cliente.
Preguntar sus necesidades y escalarlas
para que sean tenidas en cuenta de cara
a futuro.
RN48 Importante Evitar Realizar reuniones eficaces, focalizando Director
en que todo el mundo tenga claro Proyecto
rol/responsabilidades/objetivo/sinergias.
Si es necesario tener posteriormente
reuniones individuales.
RN49 Moderado Mitigar Se aplicarán las medidas correctivas Director
oportunas buscando restaurar la Proyecto
cordialidad y buen hacer en el Equipo de
Proyecto.
RN50 Importante Mitigar Además de una base sólida en DIP, el Director
‘Juicio de Expertos’ junto con el dossier Proyecto
de ‘Lecciones Aprendidas’ y la actitud-
compromiso serán determinantes.
RN51 Tolerable Aceptar Cada elemento del Servicio DevOps Equipo
contará con referencia documental para Devops
los usuarios. Además como parte del
servicio se establece un canal de Soporte
al usuario.
82
RN52 Tolerable Transferir Los proyectos piloto son seleccionados Director

por el Cliente, así como las pautas de Proyecto,
incorporación de nuevos proyectos. Por Equipo
ello, recae sobre él activar los Devops
mecanismos de presión que estime
oportunos. Tan solo comunicaremos los
conflictos (nuevos/solucionados).
RN53 Moderado Transferir Coordinaremos implantación de la Director
monitorización de las máquinas, pero no Proyecto,
participaremos en ella. En base a los Equipo
procedimientos y documentación Devops,
realizada el personal asignado ArqSistemas
restablecerá el servicio. Si detectamos la
anomalía la comunicaremos.
RN56 Moderado Mitigar Se debe analizar concienzudamente las Director
necesidades y realizar una Proyecto,
documentación del proceso de Equipo
configuración detallada. Siguiendo la Devops
guía, salvo error humano, reduciremos
las posibles ocurrencias.
RN57 Moderado Aceptar Dado lo ajustado de los plazos Director
implantamos con la solución ‘que Proyecto,
funciona’. Lo registramos y Equipo
comunicamos internamente como punto Devops
de mejora. Hacemos partícipe al Cliente
para evitar una mala valoración y
acordamos vías de corrección.
RN58 Moderado Transferir Comunicamos las necesidades y Equipo
software necesario, los servidores son Devops,
maquetados, configurados y mantenidos ArqSistemas
por Cliente.
RN59 Tolerable Transferir Se comunica la detección de ‘no Equipo
comunicación’ entre máquinas. Devops,
ArqSistemas
83
RN60 Tolerable Transferir Se facilita la documentación a los Equipo

equipos involucrados para que se Devops,
orqueste la puesta en marcha. ArqSistemas
RN61 Importante Evitar Es necesario asegurarse de que los Director
procedimientos y contingencias están en Proyecto,
manos de las personas adecuadas. Todos Equipo
los interesados deben estar informados Devops
y la fecha/hora de actualización haber
sido acordad por todas las partes
involucradas.
RN62 Importante Evitar Es necesario asegurarse de que los Director
procedimientos y contingencias están en Proyecto,
manos de las personas adecuadas. Todos Equipo
los interesados deben estar informados Devops
y la fecha/hora de actualización haber
sido acordad por todas las partes
involucradas.
RN63 Moderado Transferir Si después de un análisis inicial son Director
relevantes o pueden implicar impacto Proyecto
serán escalados a Cliente.
RN64 Moderado Transferir Se solicitará a Cliente Director
Proyecto
la obtención de la licencia con el mayor
margen posible y la configuración
completa de la necesidad.
RN65 Importante Transferir Se comunica y solicita a Cliente la Director
corrección de la licencia. Proyecto
RN66 Moderado Transferir Se comunica y solicita a Cliente la Director
corrección de la licencia. Proyecto
RN67 Importante Evitar Se comunica a los interesados. Director
Proyecto
RN68 Importante Evitar Se comunica a los interesados. Director
Proyecto
RN69 Moderado Evitar Se realiza una propuesta para los Director
cambios, si en un período anunciado no Proyecto
se anuncian problemas, se confirman la
realización de las tareas previstas.
RN70 Moderado Aceptar Se debe proporcionar con rigurosidad y Director
evidencias el máximo de información Proyecto,
posible para evitar iteraciones y que nos Equipo
ofrezcan solución de forma ágil. Devops
RN71 Tolerable Aceptar Se debe proporcionar con rigurosidad y Director
evidencias el máximo de información Proyecto,
posible para evitar iteraciones y que nos Equipo
ofrezcan solución de forma ágil. Devops
84
RN72 Moderado Mitigar Se aplicarán los mecanismos de control Director

necesarios para evaluar el desempeño Proyecto,
del servicio y valorar una ampliación. Equipo
Devops,
ArqSistemas
RN73 Inaceptable Transferir Se debe establecer un control para Director
valorar la salud y funcionamiento de los Proyecto,
sistemas de recuperación establecidos. Equipo
Devops
RN74 Moderado Transferir Se comunicará cualquier incidencia Director
detectada a los equipos de Soporte Proyecto,
Cliente. Equipo
Devops
Cliente. Equipo
Devops
Cliente. Equipo
Devops
Cliente. Equipo
Devops
RN78 Importante Transferir Se establecen controles de salud en el Director
servidor IC. Se comunicará cualquier Proyecto,
incidencia detectada a los equipos de Equipo
Soporte Cliente. Además se comunicará Devops
a los usuarios e interesados.
RN79 Tolerable Transferir Se comunicará cualquier incidencia Director
Cliente. Equipo
Devops
RN80 Moderado Mitigar Se establecen controles de salud de los Director
agentes. Se comunicará cualquier Proyecto,
incidencia detectada a los equipos de Equipo
Soporte Cliente. Además se comunicará Devops,
a los usuarios e interesados. ArqSistemas
RN81 Importante Evitar Se adopta la normativa y mecanismos de Director
defensa corporativos. Se hace uso Proyecto,
responsable de los recursos. Equipo
Devops,
Responsable
Financiero,
Responsable
Seguridad
85
RN82 Importante Mitigar Se adopta la normativa y mecanismos de Director

defensa corporativos. Se hace uso Proyecto,
responsable de los recursos. Equipo
Proyecto,
Responsable
Financiero,
Responsable
Seguridad
RN83 Tolerable Mitigar Nos aseguraremos de seguir toda la Director
normativa de seguridad preventiva y del Proyecto,
buen estado de los mecanismos anti Equipo
incendio. Proyecto,
Responsable
Financiero,
Responsable
Seguridad
RN84 Tolerable Aceptar Delegamos el control de la normativa y Director
seguridad preventiva en manos de los Proyecto,
gestores del Cliente. Equipo
Proyecto,
Responsable
Financiero,
Responsable
Seguridad
ID Clasificación Estrategia Plan de acción Responsable

RP01 Aceptar Proponer futuras líneas de evolución. Director
Encuestas de satisfacción. Generar el Proyecto
Bueno dossier de ‘lecciones aprendidas’.
RP02 Favorecer Facilitar la documentación y establecer las Director
monitorizaciones y canales de Proyecto,
comunicación propicios. Equipo Devops,
Bueno ArqSistemas
RP04 Favorecer Facilitar la documentación y establecer las Director
monitorizaciones y canales de Proyecto,
comunicación propicios. Equipo Devops,
Bueno Middleware
RP05 Favorecer A medida que avanzamos los trabajos del Director
proyecto vamos generando líneas de Proyecto,
mejora para analizar. Hacemos una Responsable
propuesta atractiva en retorno para Financiero,
Importante Cliente. Equipo Devops
RP06 Favorecer Estimular unas buenas relaciones y Director
condiciones de trabajo entre los Proyecto,
Bueno integrantes del Equipo de Proyecto. Equipo Proyecto
86
RP07 Aceptar Al cliente le gustaría tenernos en sus Director

instalaciones, consciente de que se Proyecto
favorece la realización efectiva de algunas
Bueno tareas.
RP08 Evitar Evitaremos saltar burocracia, los procesos Director
ad-hoc y/u ocultos podrían generar Proyecto
inconsistencias y necesidad de
Moderado regularización a futuro.
RP09 Mitigar Deben adoptarse una visión crítica y utilizar Director
lo conocido, este proyecto no es el Proyecto
Moderado adecuado para experimentar.
RP10 Favorecer El crecimiento del Equipo de Proyecto Director
depende de aprovechar cada ocasión para Proyecto,
Bueno mejorar. Equipo Proyecto
RP11 Favorecer Tomar consciencia desde el primer Director
momento de la utilidad de este documento Proyecto,
y aprovechar cada ocasión para añadir Equipo Proyecto
Importante información de valor al mismo.
RP12 Favorecer Tomar consciencia desde el primer Director
momento de la utilidad de este documento Proyecto
y enfocarlo a obtener información que nos
permita potenciar virtudes y corregir
Importante defectos.
RP13 Favorecer Favorecer el intercambio de información y Director
una moderada participación en tareas Proyecto
entre equipos de diferente especialidad. La
idea es tener una visión global y ‘ver el
Importante bosque’.
RP14 Favorecer Debe buscarse apoyo en las bases de Director
conocimiento de la Empresa, así como en el Proyecto,
‘juicio de expertos’. Adicionalmente recibir Expertos,
formación especializada y hacer un Responsable
seguimiento más cuidado de cada Financiero
Importante planificación y su cumplimiento.
RP15 Favorecer Debe conectar con el Equipo de Proyecto y Director
con el Cliente, de modo que su actitud Proyecto
trascienda al resto. Su predisposición a
escuchar y mejorar determinará buenas
Importante relaciones.
RP16 Aceptar Mantener relaciones cordiales utilizando Director
los canales destinados a tal fin. No infringir Proyecto,
Bajo la ética profesional. Equipo Proyecto
RP17 Favorecer Cuidar cada aspecto para ser exitosos a Director
ojos del Cliente, cumplir los parámetros Proyecto,
acordados y presentar líneas de evolución Equipo Devops,
Importante atractivas.
87
Responsable
Financiero
RP18 Evitar Somos una empresa de desarrollo software Director
Bueno no nos interesa ahora esta colaboración. Proyecto
RP19 Favorecer Favorecer el intercambio de información y Director
una moderada participación en tareas Proyecto
entre equipos de diferente especialidad. La
idea es tener una visión global y ‘ver el
Bueno bosque’.
A7- Pizarras SCRUM

Las pizarras son una herramienta visual que utiliza la metodología SCRUM para organizar el
trabajo a realizar, veamos un ejemplo:
Ilustración 26 - Pizarra SCRUM [Ref. E12]
Podemos observar unos casos reales de la herramienta en su versión virtual (Jira) y física:
Ilustración 27 - Pizarra SCRUM Virtual vs Física [Ref. E04]
88
A continuación, se muestra un dashboard de Jira adaptado para reflejar el trabajo con SCRUM:
Ilustración 28 - Dashboard Jira [Ref. E04]
A8 - Tempo
Tempo es un plugin desarrollado para extender las capacidades de Jira en lo concerniente a
time tracking y gestión de recursos. En nuestro caso utilizamos la funcionalidad que permite
llevar un control de las horas incurridas en cada una de las tareas Jira. Una vez registradas es
posible exportar la información en Excel y llevarlo a otras plataformas.
Ilustración 29 - Tempo [Ref. E04]
89
Junto con los datos extraídos de Microsoft Project nos facilita llevar una correcta gestión de los
costos, así como determinar si el equipo es productivo y bajo qué circunstancias.
A9 – Plantilla gestión del cambio
Ilustración 30 - Plantilla gesión del cambio [Antonio Garea]
A10 – Modelo Checklist
Ilustración 31 - Modelo Checklist [Antonio Garea]
90
A11 – Encuesta de satisfacción
Ilustración 32 - Encuesta satisfacción [Antonio Garea]
91
A12 – Modelo informe seguimiento
Ilustración 33- Modelo informe seguimiento [Antonio Garea]
A13 – Detalle Gantt

A13.1 – Ejecución SCRUM
Ilustración 34 - Diagrama gantt ejecución SCRUM [Antonio Garea]
A13.2 – Seguiento y control
Ilustración 35- Diagrama gantt seguimiento y control [Antonio Garea]
92
A14 – Gráfico BurnDown

El gráfico burndown es una técnica para poder medir cuánto vamos a tardar realmente en
terminar el proyecto que tenemos entre manos.
A continuación, un ejemplo:
Ilustración 36 - Gráfico BurnDown [Ref. E10]
El gráfico muestra el número de tareas en el proyecto, así como sus iteraciones. Si el proyecto
está avanzado, la línea se inclinará hacia abajo para mostrar el progreso. Una pendiente hacia
arriba indicará un aumento de las tareas del proyecto, identificando la presencia de problemas
u obstáculos.
93
A15 – Primeros resultados

La plataforma de integración contínua que se está desarrollando es análoga al modelo que
sigue:
Ilustración 37- Integración contínua [Ref. E11]
Para la obtención de datos se tomaron como referencia los diez proyectos que mejor funcionaba
en el Cliente y se incorporaron al modelo de integración contínua. Así cada nueva versión era
tratada en paralelo.
Los resultados obtenidos:
Metrica Sin integración contínua Con integración contínua
Tiempo medio en desplegar 3,5horas 25 minutos

una versión desde que el
código está en el
repositorio.
Tiempo en ejecutar los 15 minutos 2 minutos
casos de prueba
Dificultad en la traza de los Alta Baja
cambios
Versiones de código 13% 0%
desplegadas erróneamente
Fiabilidad de los controles Baja Alta
94
Los tiempos de despliegue rondan los 25 minutos (como requisito el tiempo máximo no debe
exceder los 10 minutos), sin embargo, esto es debido a que no tenemos todavía el plugin que
actuaría como disparador del proceso y con el esquema actual se revisan los cambios de código
cada 20 minutos (de ahí los tiempos). Con el plugin integrado los tiempos cumplirán con la
checklist.
En base a estos datos, claramente vemos el primer retorno de la implantación, se reduce el TTM,
aumenta la calidad y la fiabilidad del proceso de desarrollo.
A16 – Lecciones aprendidas

A pesar de que todavía no finalizó el proyecto y no tenemos el registro completo de lecciones
aprendidas si identificamos situaciones que deberíamos haber gestionado mejor:
ID VALORACIÓN PROBLEMÁTICA SOLUCIÓN
LA01 Mejora Cuando la construcción del Desde un comienzo crear grupos

producto es realizada de trabajo con responsabilidad
parcialmente por equipos end-to-end (representantes de
interno y externos, en la unión todos los equipos). De este modo
de las tareas identificamos que la transición entre tareas y
actuaban como equipos colaboración surge de forma más
diferenciados, generándose natural y enfocada.
pequeños conflictos.
LA02 Mejora En los productos en los que se Desde un comienzo plantear y
colabora con equipos externos, acordar una forma de trabajo
no hay procedimientos claros común con los equipos externos.
de comunicación o forma de
trabajo clara. Esto provocó
ineficiencias y situaciones de
conflicto.
A17 – Diccionario de la EDT
Gestión Y Administración
 Acta De Constitución De Proyecto: Documento que ofrece una visión global del
documento, con información de alto nivel.
 Plan Para La Gestión Del Proyecto: Documento que define como se va a ejecutar el
proyecto.
 Informe de Seguimiento Semanal: Documento que refleja la situación del proyecto en
el momento de su realización.
 Dossier De Gestión De Cambios: Documento que recoge el registro de cambios
realizados para el proyecto.
 Actas SCRUM Weekly: Documentos que reflejan la situación y conclusiones semanales
de los spring.
95
 Bitácora SCRUM Daily: Registro de conclusiones, avances y bloqueos surgidos en el día

a día de actividades gestionadas mediante SCRUM.
 Actas SCRUM Sprint: Documentos que reflejan la retrospectiva final de cada spring.
 Checklist De Validación: Documento que enumera las comprobaciones de aceptación
del proyecto.
 Acta De Cierre De Proyecto: Documento que acredita la entrega del producto final.
 Dossier De Lecciones Aprendidas: Registro del conocimiento adquirido sobre los
diferentes procesos ejecutados, a través de la reflexión y el análisis crítico sobre los
factores que pueden haber afectado positiva o negativamente.
Diseño Y Desarrollo
 Entorno Testing Configurado: El entorno de 'test' se encuentra maquetado.

 Entorno Producción Configurado: El entorno de 'producción' se encuentra maquetado.
 Dossier De Licencias: Documento que recoge el conjunto de licencias necesario para el
uso de las herramientas.
 Plugin Integrado: El componente que posibilita la comunicación entre plataformas, se
encuentra instalado. Del mismo modo el código fuente se encuentra depositado en el
repositorio.
 Documentación Plugin: Conjunto de documentos técnicos y operativos del plugin.
 Arquetipos Integrados: Los modelos para futuros proyectos, se encuentran publicados
en las herramientas, así como el código en el repositorio.
 Documentación Arquetipos: Conjunto de documentos técnicos y operativos de los
arquetipos.
 Scripts Integrados: Las automatizaciones se encuentran integradas en la plataforma.
 Proyectos Pilotos Adaptados: Los proyectos seleccionados se encuentran integrados en
la nueva plataforma DevOps.
 Dossier De Plataformado Devops: Conjunto de documentos técnicos DevOps
 Dossier De Operación Devops: Conjunto de documentos operativos DevOps.
96
5. BIBLIOGRAFÍA Y EGRAFÍA
5.1. BIBLIOGRAFÍA
 [B01] Material didáctico MDIP, 2018
 [B02] PMBOK 6ª Edición, 2017
 [B03] Gestión de proyectos en el mundo real, Bonnie Biafore &Teresa S. Stover, 2012
 [B04] Microsoft Project 2016 Step by Step, Carl Chatfield & Timothy Johnson, 2016
 [B05] Gestión de Proyectos, Dr. William Wallace,2002
 [B06] The DevOps Handbook, Gene Kim, Jez Humble, Patrick Debois, John Willis, John
Allspaw,2016
 [B07] Essential Scrum: A Practical Guide to the Most Popular Agile Process, Kenneth S.
Rubin, 2012
5.2. EGRAFÍA
 [E01] SCRUM, http://www.scrumguides.org/, 2018
 [E02] Project Management, https://www.projectmanagement.com, 2018
 [E03] Manifiesto ágil, http://agilemanifesto.org/iso/es/manifesto.html, 2018
 [E04] Atlassian. Bamboo Jira Confluence SCRUM, https://www.atlassian.com, 2018
 [E05] Tempo, https://www.tempo.io/, 2018
 [E06] DevOps, http://www.hositech.com, 2018
 [E07] DevOps, http://software.microfocus.com, 2018
 [E08] DevOps, https://idevops.blog, 2018
 [E09] SCRUM, https://rahulchaitanya.wordpress.com, 2018
 [E10] SCRUM, https://gustavopeiretti.com/, 2018
 [E11] Integración Contínua, https://insights.sei.cmu.edu, 2018
 [E12] SCRUM Pizarra, www.patboard.com, 2018
97
98
2018
99

Antonio Garea Muina TFM MasterDip

Cargado por

Copyright:

Formatos disponibles

Antonio Garea Muina TFM MasterDip

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Antonio Garea Muina TFM MasterDip

Cargado por

Copyright:

Formatos disponibles

Implantación de un Servicio

en una Empresa de Desarrollo Software con

“Implantación dun Servicio DevOps nunha Empresa de Desenrolo

En el presente Trabajo de Fin de Máster se plantea la dirección de un proyecto de tecnologías

 Metodología Predictiva, PMBOK®

Implantación, DevOps, Metodología, Predictiva, Ágil, Mixta, Integración, PMBOK, SCRUM,

2.3.8. Gestionar las comunicaciones .................................................................................. 48

A6 – Gestión de riesgos .......................................................................................................... 67

1.1.1. Desarrollo tradicional de software y problemática detectada

Ilustración 1- Desarrollo tradicional [Antonio Garea]

 Tiempo: La transición entre los diferentes procesos del desarrollo de un proyecto

 Talento: Estamos desperdiciando el talento de los empleados en tareas monótonas que

1.1.1.1. Problemática general en el desarrollo de aplicaciones

Problemas con la gestión de código

Problemas con la generación de artefactos

Problemas con la puesta en producción

 Las pruebas y validaciones no son imparciales

1.1.1.2. Problemática derivada de las nuevas exigencias de mercado

Ilustración 2- Problemática [Antonio Garea]

1.1.2. La solución: DevOps

DevOps establece una “intersección” entre

Ilustración 3 - Interrelaciones DevOps [Antonio

A continuación, la representación del ciclo de desarrollo DevOps, en contraste ya deja entrever

Ilustración 4 - Ciclo DevOps [Ref: E06]

Entrando más en detalle podemos observar el ‘road map’ de un ciclo DevOps:

Ilustración 5 - Mapa de ruta DevOps [Ref: E07]

 ANEXO A2 - Herramientas DevOps, desarrollamos este tema.

Características y beneficios de implementar DevOps

Ilustración 6 - Características DevOps [Antonio Garea]

DevOps tiene como objetivo maximizar la previsibilidad, eficiencia, seguridad y mantenimiento

1.1.3. Metodologías Ágiles – SCRUM

1. Los individuos y su interacción: Por encima de los procesos y herramientas.

Ilustración 8 - Ciclo SRUM [Antonio Garea]

BENEFICIOS QUE APORTA SCRUM

1.- Gestión de las expectativas del Cliente

Para más detalle se puede consultar los recursos:

 ANEXO A4 – Beneficios que aporta SCRUM al proceso de desarrollo

1.2. DESCRIPCIÓN DEL PROYECTO

La singularidad de su modelo de gestión, basado en la innovación y la flexibilidad, y los logros

 Mejora del TTM (time-to-market)

Para ello implantaremos un servicio DevOps y utilizaremos las metodologías tradicional

1.4. CICLO DE VIDA DEL PROYECTO

El proyecto deberá ser realizado en un plazo de 12 meses, con un presupuesto de 319.797,69 €.

Ilustración 9 - Ciclo de Vida Proyecto [Antonio Garea]

2. PLAN PARA LA DIRECCIÓN DEL PROYECTO

2.1. GRUPO DE PROCESOS DE INICIO

2.1.1. Acta de Constitución

DATOS DEL PROYECTO

PROYECTO Implantación de un Servicio DevOps en una

PROPÓSITO Y JUSTIFICACIÓN DEL PROYECTO

DESCRIPCIÓN DEL PROYECTO Y ENTREGABLES

El proyecto consiste en la Implantación de un Servicio DevOps en una Compañía de

Para ello la solución aportada constará.

REQUISITOS DE ALTO NIVEL

 El Servicio DevOps permitirá realizar despliegues automáticos de nuevas versiones

o Invocar el análisis de código y obtención de métricas

 Plazo de 12 meses. Inicio con el Acta de Constitución y finalización con la entrega

 Reducir los costes un 10% por debajo de lo planificado

RIESGOS INICIALES DE ALTO NIVEL Y OPORTUNIDADES