Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
UNIVERSIDAD PARA LA COOPERACIÓN INTERNACIONAL (UCI)
PLAN DE GESTIÓN PARA EL DESARROLLO DE UNA METODOLOGÍA DE ADMINISTRACIÓN DE PROYECTOS PARA EL ÁREA DE MANTENIMIENTO Y
PROYECTOS MENORES DE PACIFIC E&P
JAMES ALIRIO CHAVEZ SANDOVAL
PROYECTO FINAL DE GRADUACIÓN PRESENTADO COMO REQUISITO PARCIAL PARA OPTAR POR EL TÍTULO DE MASTER EN ADMINISTRACIÓN
DE PROYECTOS
San José, Costa Rica
ABRIL 2016
ii
UNIVERSIDAD PARA LA COOPERACIÓN INTERNACIONAL (UCI)
Este Proyecto Final de Graduación fue aprobado por la Universidad como requisito parcial para optar al grado de Máster en Administración de Proyectos
__________________________ Carlos Luis Murillo Blanco
PROFESOR TUTOR
_________________________ Luis Diego Arguello Araya
LECTOR No.1
__________________________ Fabio Muñoz Jiménez
LECTOR No.2
________________________ James Alirio Chavez Sandoval
SUSTENTANTE
iii
DEDICATORIA
Con mucho Amor a mis padres Rafael Chavez y Rebeca Sandoval, a mi
maravillosa hija Daniela Chavez Ramírez, mi esposa Ximena Ramírez, mis
hermanas Claudia y Francy y mis sobrinos Luisita, Josecito, Anita y Juancho.
iv
AGRADECIMIENTOS
A todos los profesores de la Universidad, en especial al Ing. Carlos Luis Murillo
Blanco, Tutor del PFG.
Al Ing. Arbey Rojas, Gerente de Mantenimiento y Proyectos Menores, a los Supervisores de Mantenimiento del Campo Rubiales y mis colegas del Área de
Mantenimiento por su apoyo durante este proyecto.
A mis compañeros de clase con quienes compartí materias y desarrollo de trabajos, por todo el apoyo y la amistad que hoy nos une.
A todas aquellas personas que de una u otra forma me animaron a seguir
adelante con este proyecto.
v
INDICE
HOJA DE APROBACION ii
DEDICATORIA iii
AGRADECIMIENTO iv
INDICE v
INDICE DE FIGURAS ix
INDICE DE CUADROS x
LISTA DE ABREVIATURAS Y TÉRMINOS xii
RESUMEN EJECUTIVO xiv
1. INTRODUCCION ............................................................................................16
1.1 Antecedentes .................................................................................................... 16
1.2 Problemática ..................................................................................................... 17
1.3 Justificación del Problema ................................................................................ 18
1.4 Objetivo General ............................................................................................... 20
1.5 Objetivos Específicos ........................................................................................ 20
2. MARCO TEORICO .........................................................................................22
2.1 Marco institucional ............................................................................................ 22
2.1.1 Antecedentes de la Institución ...................................................................... 22
2.1.2 Misión ........................................................................................................... 24
2.1.3 Visión ............................................................................................................ 24
2.1.4 Estructura Organizativa ................................................................................. 25
2.1.5 Productos que Ofrece ................................................................................... 26
2.2 Teoría de Administración de Proyectos............................................................. 26
2.2.1 Proyecto........................................................................................................ 26
2.2.2 Administración de Proyectos ......................................................................... 27
2.2.3 Ciclo de Vida de un Proyecto ........................................................................ 27
2.2.4 Procesos en la Administración de Proyectos ................................................ 28
2.2.5 Áreas de Conocimiento de la Administración de Proyectos........................... 29
2.3 Teoría y Conceptos del Tema de Interés de este PFG ..................................... 34
2.3.1 Concepto de Metodología ............................................................................. 34
vi
2.3.2 Metodologías Ágiles ...................................................................................... 35
2.3.3 Comparativa entre Metodologías Ágiles y no Ágiles...................................... 38
2.3.4 Scrum ........................................................................................................... 39
3. MARCO METODOLOGICO ............................................................................65
3.1 Fuentes de información .................................................................................... 65
3.1.1 Fuentes Primarias ......................................................................................... 65
3.1.2 Fuentes Secundarias .................................................................................... 66
3.2 Métodos de Investigación ................................................................................. 68
3.2.1 Método Analítico – Sintético .......................................................................... 68
3.2.2 Método Particulares y Específicos ................................................................ 69
3.3 Herramientas .................................................................................................... 74
3.3.1 Juicio de Expertos ......................................................................................... 74
3.3.2 Estructura de Desglose del Trabajo (EDT) .................................................... 74
3.3.3 Diagrama de Flujo ......................................................................................... 74
3.3.4 Diagrama de Gantt ........................................................................................ 74
3.3.5 Plantillas ....................................................................................................... 75
3.3.6 Curva S ......................................................................................................... 75
3.3.7 Reuniones ..................................................................................................... 75
3.3.8 Entrevistas .................................................................................................... 75
3.3.9 Método de la Ruta Crítica ............................................................................. 75
3.4 Supuestos y Restricciones ................................................................................ 77
3.5 Entregables ...................................................................................................... 80
4. DESARROLLO ...............................................................................................82
4.1 Análisis de la Situación Actual .......................................................................... 82
4.1.1 Herramientas de Gestión Actual ................................................................... 82
4.2 Áreas de Conocimiento y Planes de Gestión del Proyecto .............................. 102
4.2.1 Plan de Gestión de la Integración del Proyecto ........................................... 102
4.2.2 Plan de Gestión del Alcance del Proyecto ................................................... 105
4.2.3 Plan de Gestión del Tiempo del Proyecto ................................................... 114
4.2.4 Plan de Gestión de los Costos del Proyecto ............................................... 122
vii
4.2.5 Plan de Gestión de la Calidad del Proyecto ................................................ 134
4.2.6 Plan de Gestión de los Recursos Humanos del Proyecto ........................... 137
4.2.7 Plan de Gestión de las Comunicaciones del Proyecto ................................ 145
4.2.8 Plan de Gestión de los Riesgos del Proyecto .............................................. 151
4.2.9 Plan de Gestión de las Adquisiciones del Proyecto ..................................... 160
4.2.10 Plan de Gestión de los Interesados del Proyecto .................................... 161
4.3 Estrategia de Desarrollo e Implementación ..................................................... 165
4.3.1 Definición de la Metodología ....................................................................... 165
4.3.2 Fases de la Metodología ............................................................................. 167
4.3.3 Plan de Implementación de la nueva Metodología ...................................... 173
5. CONCLUSIONES ......................................................................................... 175
6. RECOMENDACIONES ................................................................................. 179
7. BIBLIOGRAFÍA ............................................................................................ 182
8. ANEXOS ....................................................................................................... 184
ANEXO 1: ACTA DE CONSTITUCION DEL PROYECTO DEL PFG............................. 185
ANEXO 2: EDT DEL PROYECTO DEL PFG ................................................................. 190
ANEXO 3: CRONOGRAMA DEL PROYECTO DEL PFG .............................................. 191
ANEXO 4: ACTA DE CONSTITUCIÓN – PROYECTO METODOLOGÍA ...................... 192
ANEXO 5: EDT – PROYECTO METODOLOGÍA ........................................................... 196
ANEXO 6: CRONOGRAMA – PROYECTO METODOLOGÍA ....................................... 197
ANEXO 7: RUTA CRÍTICA – PROYECTO METODOLOGÍA ......................................... 201
ANEXO 8: ACTA DE CONSTITUCION – PROYECTO METODOLOGÍA ...................... 202
viii
ANEXO 9: DEFINICION DEL ALCANCE – PROYECTO METODOLOGÍA ................... 204
ANEXO 10: CONTROL DE CAMBIO – PROYECTO METODOLOGÍA ......................... 206
ANEXO 11: PREGUNTAS DEL PROFESOR LUIS DIEGO ARGUELLO ARAYA......... 208
ix
ÍNDICE DE FIGURAS
Figura 1 – Operaciones de PACIFIC E&P en Colombia ....................................... 23
Figura 2 – Organigrama Área de Mantenimiento .................................................. 25
Figura 3 – Ciclo de Vida de un Proyecto ............................................................... 27
Figura 4 – Grupo de Procesos de la Dirección de Proyectos ................................ 28
Figura 5 – Áreas de Conocimiento de la Administración de Proyectos ................. 33
Figura 6 – Elementos Básicos de una Metodología .............................................. 34
Figura 7 – Ciclo de Desarrollo Ágil ........................................................................ 38
Figura 8 – Roles del Scrum ................................................................................... 46
Figura 9 – Los Elementos del Scrum .................................................................... 50
Figura 10 – Reuniones Habituales en Scrum ........................................................ 52
Figura 11 – Scrum – Visión General del Proceso ................................................. 54
Figura 12 – Ficha Sinóptica de Scrum .................................................................. 55
Figura 13 – Scrum + PMBOK® ............................................................................. 63
Figura 14 – Grupo de Procesos de la Dirección de Proyectos .............................. 83
Figura 15 – Gestión Actual de los Proyectos ........................................................ 96
Figura 16 – Gestión Actual de los Proyectos – Análisis Cuantitativo .................... 98
Figura 17 – Matriz FODA ...................................................................................... 99
Figura 18 – Organigrama del Proyecto ................................................................145
Figura 19 – Fases de la Metodología Propuesta..................................................167
Figura 20 – Procesos de Visión del Producto ......................................................168
Figura 21 – Procesos de Hoja de Ruta del Proyecto ...........................................170
Figura 22 – Procesos de Plan de Lanzamiento....................................................171
Figura 23 – Procesos de Definición del Sprint .....................................................172
Figura 24 – Procesos de Cierre ...........................................................................172
x
ÍNDICE DE CUADROS
Cuadro 1 – PACIFIC E&P – Destacados Operacionales en el 2014..................... 24
Cuadro 2 – Correspondencia de los Grupos de Procesos con las Áreas de
Conocimiento de la Guía PMBOK® ...................................................................... 31
Cuadro 3 – Diferencias entre Metodologías Ágiles y no Ágiles ............................. 39
Cuadro 4 – Scrum y los 5 Grupos de Procesos .................................................... 56
Cuadro 5 – Scrum y las 10 Áreas de Conocimiento .............................................. 59
Cuadro 6 – Fuentes de Información Utilizadas ..................................................... 67
Cuadro 7 – Métodos de Investigación Utilizadas .................................................. 72
Cuadro 8 – Herramientas Utilizadas ..................................................................... 76
Cuadro 9 – Supuestos y Restricciones ................................................................. 77
Cuadro 10 – Entregables ...................................................................................... 80
Cuadro 11 – Análisis del Grupo de Procesos de Iniciación ................................... 85
Cuadro 12 – Análisis del Grupo de Procesos de Planificación.............................. 86
Cuadro 13 – Análisis del Grupo de Procesos de Ejecución .................................. 90
Cuadro 14 – Análisis del Grupo de Procesos de Monitoreo y Control .................. 92
Cuadro 15 – Análisis del Grupo de Procesos de Cierre ........................................ 94
Cuadro 16 – Gestión Actual de los Proyecto – Análisis Cuantitativo .................... 97
Cuadro 17 – Matriz FODA ....................................................................................100
Cuadro 18 – Recopilación de Interesados ...........................................................107
Cuadro 19 – Definición del Alcance del Proyecto ................................................110
Cuadro 20 – Lista de Actividades.........................................................................115
Cuadro 21 – Secuencia de Actividades ...............................................................118
Cuadro 22 – Costo del Entregable Seminario de Graduación .............................124
Cuadro 23 – Costo del Entregable Análisis Situación Actual ...............................124
Cuadro 24 – Costo del Entregable Metodologías Ágiles – Scrum........................125
Cuadro 25 – Costo del Entregable Desarrollo de los Planes de Gestión .............126
Cuadro 26 – Costo del Entregable Cierre ............................................................127
xi
Cuadro 27 – Reservas de Contingencia para el Proyecto ...................................128
Cuadro 28 – Costos de los Entregables del Proyecto ..........................................129
Cuadro 29 – Costo Estimado del Proyecto y Reserva de Gestión .......................134
Cuadro 30 – Declaración de las Expectativas de los Involucrados ......................136
Cuadro 31 – Entregables con sus Respectivos Criterios de Aceptación ..............137
Cuadro 32 – Requerimiento de Recursos Humanos del Proyecto .......................139
Cuadro 33 – Roles y Responsabilidades del Equipo de Trabajo .........................140
Cuadro 34 – Matriz de Asignación de Responsabilidades RACI..........................142
Cuadro 35 – Criterios de Liberación de los Recursos ..........................................143
Cuadro 36 – Índice de la Matriz de Comunicaciones del Proyecto ......................147
Cuadro 37 – Matriz de Comunicaciones del Proyecto .........................................148
Cuadro 38 – Roles y Responsabilidades en el Proyecto .....................................152
Cuadro 39 – Riesgos del Proyecto .......................................................................153
Cuadro 40 – Riesgos – Escala de Probabilidad ...................................................154
Cuadro 41 – Riesgos – Escala de Impacto ..........................................................155
Cuadro 42 – Evaluación del Impacto de un Riesgo en los Objetivos ...................156
Cuadro 43 – Matriz de Probabilidad por Impacto .................................................157
Cuadro 44 – Niveles de Calificación de Probabilidad e Impacto ..........................157
Cuadro 45 – Matriz de Plan de Mitigación de Riesgos .........................................158
Cuadro 46 – Interesados del Proyecto .................................................................162
Cuadro 47 – Clasificación de los Interesados del Proyecto .................................163
Cuadro 48 – Matriz de Poder/Interés de los Interesados .....................................164
xii
LISTA DE ABREVIATURAS Y TÉRMINOS
AIT Siglas de Automatización, Instrumentación y
Telecomunicaciones.
BOE/D Barrels of oil equivalent per day (siglas en inglés de
“Barriles de petróleo equivalente por día”).
CMMS Computerized Maintenance Management System (siglas
en inglés de “Sistema de Gestión de Mantenimiento
Asistido por Computadora”).
COP Signo Representativo del Peso Colombiano.
EDT Estructura de Desglose del Trabajo.
KPI Key Performance Indicators (siglas en inglés de
“Indicadores Clave de Desempeño).
METODOLOGIA Disciplina que indicará cuales métodos y técnicas deben
ser empleadas en cada fase del ciclo de vida del
desarrollo del proyecto.
MMbpe Mllion barrels of oil equivalent per day (siglas en inglés de
“Millones de barriles de petróleo equivalentes”).
Netback Es un esquema de valoración de crudos acordado entre
el productor y el refinador, mediante el cual el productor
garantiza un margen de ganancia al refinador, calculado
como Ingreso por venta de los productos menos costo de
refinación, menos costo de transporte, menos margen de
ganancia del refinador.
PACIFIC E&P Compañía PACIFIC Exploration & Production Corp.
PFG Proyecto Final de Graduación.
PMBOK® Project Management Body of Knowledge (siglas en inglés
de “Guía de los Fundamentos de Gestión de Proyectos”).
xiii
PMI Project Management Institute (siglas en inglés de “Instituto
de Administración de Proyectos”).
PROCESOS Conjunto de actividades que contienen información de
entrada y salida, responden a un evento y tienen una
retroalimentación. Las características fundamentales son:
medibles, responden a eventos específicos, buscan la
satisfacción del cliente y se retroalimentan.
PROYECTO Según el PMBOK® del PMI (2013), es un esfuerzo
temporal realizado para crear un producto, servicio o
resultado único.
ROI Return Of Investment (siglas en inglés de “Retorno de la
Inversión”).
SCRUM Metodologia de desarrollo Ágil, que acepta cambios,
iterativa, que está enfocada en satisfacción al cliente
trabajo colaborativo en equipo para obtener el mejor
resultado posible de un proyecto.
STAKEHOLDERS Nombre dado a los Interesados del Proyecto.
WBS Work Breakdown Structure (siglas en inglés de ”Estructura
de Desglose del Trabajo”).
xiv
RESUMEN EJECUTIVO
El Área de Mantenimiento y Proyectos Menores de PACIFIC E&P Colombia tiene a su cargo asegurar la vida útil de los activos mediante la aplicación de la Gestión de Mantenimiento para asegurar la correcta y continua operación de las instalaciones de los campos petroleros Rubiales y Quifa ubicados en Puerto Gaitán Meta Colombia. Esto lo realiza mediante la implementación de técnicas de mantenimiento soportadas con personal propio y contratistas de las áreas Eléctrica, Mecánica, Instrumentación, Control y Automatización, Integridad y Proyectos Menores. Comúnmente se han ejecutado servicios con terceros bajo la contratación de desarrollo de aplicaciones de software para la operación, manejo de información y análisis de datos que se requieren por parte del personal de Mantenimiento.
Carecer de una metodología de desarrollo para el desarrollo de software en
PACIFIC E&P ha permitido que los proyectos desarrollados por los contratistas no logren los objetivos propuestos y no cumplan con el alcance, tiempo y costos establecidos por la compañía, presentándose continuos retrasos y existiendo necesidades puntuales que no han sido resueltas para el personal que labora en el Área.
El Objetivo general es desarrollar el Plan de Gestión del Proyecto “Desarrollo
de una Metodología de Administración de Proyectos para el Área de Mantenimiento y Proyectos Menores de PACIFIC E&P” para fortalecer el desarrollo y administración de los proyectos en la Compañía. Los Objetivos específicos son: Realizar un diagnóstico de los procesos actuales en Gestión de Proyectos de PACIFIC E&P para identificar las fortalezas y oportunidades de mejora; desarrollar el Plan de Gestión de la Integración del Proyecto para asegurar la correcta coordinación de los elementos del proyecto; desarrollar el Plan de Gestión del Alcance del Proyecto para definir los paquetes de trabajo requeridos para la implementación del proyecto y cumplimiento de expectativas por parte de los Interesados; desarrollar el Plan de Gestión del Tiempo del Proyecto para conocer las fechas de entrega de los productos del proyecto; desarrollar el Plan de Gestión de los Costos del Proyecto para planificar, presupuestar y controlar los costos de modo que se supervise y garantice el cumplimiento del presupuesto inicial aprobado; desarrollar el Plan de Gestión de la Calidad del Proyecto para que el proyecto satisfaga las necesidades por la cuales fue emprendido; desarrollar el Plan de Gestión de los Recursos Humanos del Proyecto para definir los roles y responsabilidades de cada uno de los miembros del proyecto, así como el perfil requerido; desarrollar el Plan de Gestión de las Comunicaciones del Proyecto para establecer una estrategia de comunicación adecuada y eficiente con los Interesados; desarrollar el Plan de Gestión de los Riesgos del Proyecto para favorecer su identificación, análisis, planificación de respuesta y control de los riesgos del proyecto; desarrollar el Plan de Gestión de los Interesados del Proyecto para identificarlos, gestionarlos y controlar sus expectativas e intereses de manera que la gobernabilidad del proyecto
xv
sea posible y construir una estrategia de desarrollo e implementación para asegurar que los involucrados de este Proyecto estén conformes con el producto final, entiendan y puedan utilizar la Guía Metodológica a diseñar.
La metodología del presente PFG es de tipo investigativa. Se realizó un
estudio de las metodologías de desarrollo de software en especial Ágil Scrum, igualmente un diagnóstico cuantitativo y cualitativo de cómo son aplicados los Grupos de Procesos y Áreas de Conocimiento definidas en la Guía del PMBOK® en los proyectos del Área de Mantenimiento y Proyectos Menores, permitiendo encontrar las fortalezas y las oportunidades de mejora en la gestión de proyectos. Después de levantamiento de información y un análisis de los datos se presentó en este proyecto la elaboración de una solución metodológica para desarrollo de proyectos basada en la metodología Ágil Scrum mediante la aplicación de las mejores prácticas para la gestión de proyectos propuestas por el PMI (2013). Esto permite fortalecer la gestión y ejecución de proyectos y garantizar el adecuado logro de los objetivos de los proyectos del Área.
De acuerdo al trabajo desarrollado para este PFG, se concluye que en el
Área de Mantenimiento y Proyectos Menores de PACIFIC E&P es necesario iniciar la aplicación de una manera consciente de las buenas prácticas en la administración de proyectos definidas por la Guía PMBOK®. Igualmente se concluye que Scrum y la Guía de Administración de Proyectos del PMI no se rechazan entre sí. La Guía PMBOK® nos ayuda a entender qué se debería hacer durante la dirección del proyecto, basándonos en un conjunto de buenas prácticas y nos sugiere usar técnicas y herramientas sobre los procesos que apliquen en nuestros proyectos. Por otro lado Scrum es una Metodología que ayuda a describir cómo deberían hacerse las cosas, y el qué y el cómo están presentes durante el ciclo de vida del proyecto, uno después del otro, por ello Scrum y la Guía PMBOK® son complementarias en la búsqueda de un balance ideal en la correcta administración de proyectos.
Se recomienda que Patrocinador del Proyecto que gestione mediante una
fase posterior de desarrollo de este Proyecto la terminación de la Metodología así como la aplicación a un caso de estudio dirigido por profesionales del área que conozcan los fundamentos básicos de la guía, la Metodología Scrum y las buenas prácticas de la gestión de proyectos de la Guía PMBOK®. Igualmente se recomienda al Grupo de la Excelencia de PACIFIC E&P que adicione la presente Metodología propuesta en este PFG a los documentos internos de desarrollo de proyectos, lo cual beneficiará a los Directores de Proyectos de la organización quienes pueden aplicar mejores prácticas y herramientas de control en el desarrollo de los proyectos.
16
1. INTRODUCCION
Desarrollar Software puede resultar una misión imposible cuando no se
tienen claros los objetivos y la funcionalidad que se requieren del producto final,
pero a diferencia de otros tipo de proyectos, el desarrollo de software tiene un riesgo
asociado en la asimilación del producto por parte del cliente o usuario final, el cual
de no gestionarse adecuadamente ocasionará un seguro fracaso del proyecto.
El Área de Mantenimiento y Proyectos Menores de PACIFIC E&P, en la
actualidad ejecuta servicios con personal externo orientados a desarrollar
aplicaciones y herramientas de software, pero al no contar con una guía que defina
los procedimientos de cómo se deberían desarrollar estos proyectos, es muy
frecuente encontrarse con soluciones incompletas que poco tiempo después de su
implementación no son utilizadas por el personal de la compañía.
Debido a lo anterior, nace la idea de elaborar esta propuesta de una Guía
Metodológica basada en Scrum mediante la aplicación de las mejores prácticas para
la gestión de proyectos propuestas por el PMI (2013), en respuesta a esta falencia
de la compañía en la administración y seguimiento de los proyectos.
1.1 Antecedentes
El Área de Mantenimiento y Proyectos Menores maneja un presupuesto
anual de 3 millones de dólares americanos. Su objetivo es mantener operativos los
activos de la compañía y asegurar su vida útil y operación confiable mediante la
implementación de técnicas de mantenimiento soportadas con personal propio y
contratistas de las áreas Eléctrica, Mecánica, Instrumentación, Control y
Automatización, Integridad y Proyectos Menores. Dentro de ese rubro económico,
cada año se han ejecutado servicios con terceros bajo la contratación de desarrollo
17
de aplicaciones de software para la operación, manejo de información y análisis de
datos que se requieren por parte del personal de Mantenimiento.
Lastimosamente, muchos de los proyectos del Área no han, en el mejor de
los casos, alcanzado los resultados esperados, en gran parte debido a la poca
claridad de los entregables y los plazos de ejecución de los proyectos. Por otro lado,
el no poder asignar un rol interno en la dirección del proyecto origina que el
desarrollador de la solución no gestione adecuadamente los requerimientos y su
desconocimiento del proceso se convierte en factores de riesgos que a menudo han
afectado la calidad del producto desarrollado.
1.2 Problemática
El Área de Mantenimiento y Proyectos Menores requiere de herramientas
software que apoyen la ejecución de sus actividades diarias y sean
complementarias y de fácil integración con la actual arquitectura del CMMS –
Computerized Maintenance Management System (siglas en inglés de “Sistema de
Gestión de Mantenimiento Asistido por Computadora”).
Usualmente el desarrollo de estas herramientas es subcontratado con las
compañías registradas como proveedores en la organización. Estas empresas en
su mayoría, aunque cuentan con sus procedimientos y procesos definidos en sus
modelos de gestión de calidad, no se han podido adaptar a la dinámica que
representa la operación típica de un campo petrolero. Las soluciones
implementadas a la fecha no son fácilmente soportadas ni actualizables y el soporte
post venta siempre ha sido un factor de riesgo debido al excesivo deseo del
contratista en devengar ingresos posteriores aunque muchos de los problemas son
parte evidente de las garantías de un producto no conforme.
18
Carecer de una metodología para el desarrollo de software en PACIFIC E&P
ha permitido que los proyectos desarrollados por los contratistas no logren los
objetivos propuestos y no cumplan con el alcance, tiempo y costos establecidos por
la compañía, presentándose continuos retrasos y existiendo necesidades puntuales
que no han sido resueltas para el personal que labora en el Área.
Desde el punto de vista interno, el personal de Mantenimiento que lidera las
implementaciones al no contar con una metodología se le dificulta gestionar
adecuadamente el desarrollo, ya que no existen las herramientas para definir fases
y entregables durante el ciclo de vida de los proyectos y sin roles y
responsabilidades identificados es difícil ejercer una correcta administración y
seguimiento de lo ejecutado por terceros.
1.3 Justificación del Problema
El Área de Mantenimiento y Proyectos Menores tiene a su cargo asegurar la
vida útil de los activos mediante la aplicación de la Gestión de Mantenimiento para
asegurar la correcta y continua operación de las instalaciones de los campos
petroleros Rubiales y Quifa ubicados en Puerto Gaitán, Meta, Colombia.
Dentro de las necesidades con las que cuenta el Área, es evidente la
existencia de una oportunidad de mejora en la gestión de los proyectos que se han
ejecutado para el desarrollo de software cuyo objetivo principal es proveer una mejor
gestión a las actividades diarias del personal de Mantenimiento. Entre las cuales se
destacan sistemas de manejo de la información, reportes de variables críticas del
proceso, reportes de indicadores KPI – Key Performance Indicators (siglas en inglés
de “Indicadores Clave de Desempeño), la planeación y programación de actividades
del personal propio y contratista, seguimiento a la ejecución de contratos, gestión
del sistema energético de los campos y administración de los activos críticos de la
19
operación. Los proyectos desarrollados hasta la fecha no han podido adaptarse al
dinamismo que exige la operación de los campos y son soluciones estáticas que no
pudieron ser actualizadas porque falencias en su diseño. Adicionalmente, no
pueden engranarse a las demás soluciones corporativas de modo que los usuarios
trabajan en islas, lo cual disminuye su eficiencia y se generan errores por el doble
trabajo que significa hacer cosas manuales que pueden ser integradas a nivel de
aplicaciones.
Dentro de los beneficios esperados para el Área de Mantenimiento y
Proyectos Menores Colombia se encuentran:
Estar al día con la gestión y ejecución de los proyectos de software y
garantizar el adecuado logro de sus objetivos, al contar con una Guía
Metodológica que combina los procesos Ágil Scrum y la aplicación de las
mejores prácticas para la gestión de proyectos propuestas por el PMI
(2013).
Al garantizar los objetivos de los diferentes proyectos de desarrollo de
software, el Área podrá mejorar su operación diaria fortaleciendo las
relaciones con los clientes internos y generar un proceso de mejora
continua en la ejecución de las actividades.
Poder iniciar un plan de estructuración en todas las sedes de la
Organización de esta metodología que permite establecer un estándar en
la gestión y ejecución de proyectos de desarrollo de software.
Esta metodología creará las bases necesarias para su aplicación en otros
tipos de proyectos diferentes a desarrollo de software y aplicaciones que
en la actualidad ejecuta el Área y tienen las mismas oportunidades de
mejora en su diseño e implementación.
20
1.4 Objetivo General
Desarrollar el Plan de Gestión del Proyecto “Desarrollo de una Metodología
de Administración de Proyectos para el Área de Mantenimiento y Proyectos
Menores de PACIFIC E&P” para fortalecer el desarrollo y administración de los
proyectos en la Compañía.
1.5 Objetivos Específicos
Realizar un diagnóstico de los procesos actuales en Gestión de Proyectos
de PACIFIC E&P para identificar las fortalezas y oportunidades de mejora.
Desarrollar el Plan de Gestión de la Integración del Proyecto para asegurar
la correcta coordinación de los elementos del proyecto.
Desarrollar el Plan de Gestión del Alcance del Proyecto para definir los
paquetes de trabajo requeridos para la implementación del proyecto y
cumplimiento de expectativas por parte de los Interesados.
Desarrollar el Plan de Gestión del Tiempo del Proyecto para conocer las
fechas de entrega de los productos del proyecto.
Desarrollar el Plan de Gestión de los Costos del Proyecto para planificar,
presupuestar y controlar los costos de modo que se supervise y garantice
el cumplimiento del presupuesto inicial aprobado.
Desarrollar el Plan de Gestión de la Calidad del Proyecto para que el
proyecto satisfaga las necesidades por la cuales fue emprendido.
Desarrollar el Plan de Gestión de los Recursos Humanos del Proyecto
para definir los roles y responsabilidades de cada uno de los miembros del
proyecto, así como el perfil requerido.
Desarrollar el Plan de Gestión de las Comunicaciones del Proyecto para
establecer una estrategia de comunicación adecuada y eficiente con los
Interesados.
21
Desarrollar el Plan de Gestión de los Riesgos del Proyecto para favorecer
su identificación, análisis, planificación de respuesta y control de los
riesgos del proyecto.
Desarrollar el Plan de Gestión de los Interesados del Proyecto para
identificarlos, gestionarlos y controlar sus expectativas e intereses de
manera que la gobernabilidad del proyecto sea posible.
Construir una estrategia de desarrollo e implementación para asegurar que
los involucrados de este Proyecto estén conformes con el producto final,
entiendan y puedan utilizar la Guía Metodológica a diseñar.
22
2. MARCO TEORICO
2.1 Marco institucional
2.1.1 Antecedentes de la Institución
PACIFIC Exploration & Production Corp. (en adelante PACIFIC E&P) es una
compañía dedicada a la exploración y producción de gas natural y petróleo,
constituida en Canadá en el año 2008 y con operaciones en Colombia, Brasil,
Guyana, Perú, Papúa Nueva Guinea, Guatemala y Belice. PACIFIC E&P es
propietaria del 100 por ciento de la empresa Petrominerales que tiene activos de
crudo liviano y pesado en Colombia, y de crudo y gas en Perú.
“En Colombia, PACIFIC E&P es propietaria del 100 por ciento de Meta
Petroleum Corp., compañía que opera –entre otros– los campos de crudo pesado
Rubiales, Pirirí y Quifa, ubicados en la cuenca de los Llanos, y del 100 por ciento de
PACIFIC Stratus Energy Colombia Corp., a través de la cual opera campos de gas
natural y crudo liviano, como La Creciente, en el municipio de San Pedro
(Departamento de Sucre), en el noroccidente del país. La estrategia de PACIFIC
E&P está enfocada en el crecimiento sostenible en producción y reservas y la
generación de valor. Está comprometido a desarrollar su negocio de manera social
y ambientalmente responsable.” (Pacific Exploration & Production Corp., s.f.).
PACIFIC E&P junto con la Petrolera Estatal Colombia Ecopetrol, mantiene
operaciones de extracción, perforación y producción de crudo pesado en Campo
Rubiales mediante un contrato de asociación que terminará el próximo 30 de junio
de 2016. La Figura 1 resume las operaciones de PACIFIC E&P en Colombia.
23
Figura 1 – Operaciones de PACIFIC E&P en Colombia
Fuente: PACIFIC Exploration & Production Corp. Informe Anual y de Sostenibilidad 2014
“En el año 2013, PACIFIC E&P ingresó al ‘Índice de Sostenibilidad Dow
Jones de Norteamérica’, y fue ratificada en 2014 y en 2015. Durante 2014 también
fue reconocida por Robeco SAM (firma especialista, enfocada en inversiones en
sostenibilidad) como una de las empresas más sostenibles del mundo en la industria
de petróleo y gas, en el Sustainability Yearbook. También en 2014 fue seleccionado
por tercer año consecutivo para ser parte del ‘Índice de líderes globales en asuntos
ambientales, sociales y de gobierno corporativo’, de STOXX (líder internacional en
generación de índices).” (Pacific Exploration & Production Corp., s.f.).
2014 fue año muy productivo para PACIFIC E&P, durante el cual hubo una
reducción significativa de los costos de operaciones, aumento de la producción total
por día medida en BOE/D (Barriles de petróleo equivalente por día), incremento del
volumen de crudo producido medido en MMbpe (Millones de barriles de petróleo
equivalentes) y un incremento en el volumen de ventas. El Cuadro 1 resume los
principales factores de éxito en el 2014.
24
Cuadro 1 – PACIFIC E&P – Destacados Operacionales en el 2014
Fuente: Pacific Exploration & Production Corp. Informe Anual y de Sostenibilidad
2014
La producción total alcanzó la cifra de 314.947 BOE/D, un aumento del 1% respecto a 2013.
La participación antes de regalías fue de 176.235 BOE/D, un aumento del 12% respecto a 2013.
La producción neta después de regalías fue de 147.423 BOE/D, un aumento del 14% con respecto a 2013.
El volumen de ventas fue de 158.026 BOE/D, lo que significó un incremento de 17% respecto a 2013.
El volumen de crudo y gas natural producido sumó 53,8 MMbpe comparado con 49,1 MMbpe en 2013.
Logramos un Netback combinado de $54,84/BPE, versus $60,77/BPE en 2013. La reducción se debe a los bajos precios de crudo y gas en el mercado.
Alcanzamos una reducción de US$2,67 en los costos operacionales llegando a US$30,51 BPE.
2.1.2 Misión
“PACIFIC busca la creación de valor en todos los niveles y funciones de la
organización, mediante procesos alineados a su estrategia, que es impulsada a
través de la planeación y el aprendizaje, así como por la adaptación, la innovación,
la estructura por unidades de negocio y grupo corporativo, el valor compartido, la
racionalización de costos y el desarrollo del talento humano.” (Pacific Exploration &
Production Corp., s.f.).
2.1.3 Visión
“La visión de PACIFIC Exploration & Production Corp. es ser la primera
empresa de exploración y producción de petróleo y gas independiente en
Latinoamérica en términos de reservas, producción y generación de valor, y estar
25
entre las más reconocidas por su contribución al desarrollo sostenible de su entorno.
La compañía quiere destacarse por su capacidad para descubrir y desarrollar
reservas de hidrocarburos en forma sostenible, responsable y rentable.” (Pacific
Exploration & Production Corp., s.f.).
2.1.4 Estructura Organizativa
Este proyecto de final de graduación está orientado a definir una Guía
Metodológica De Administración de Proyectos para el Área de Mantenimiento y
Proyectos Menores, del cual se muestra su estructura organizativa en la Figura 2:
Figura 2 – Organigrama Área de Mantenimiento
Fuente: Pacific E&P – P–MTTO–001 Manual de Gestión Integral del Proceso de Mantenimiento, 2013
26
2.1.5 Productos que Ofrece
PACIFIC E&P produce y vende petróleo y gas natural. También compra
subproductos del crudo para sus operaciones internas y fines comerciales. El Área
de Mantenimiento y Proyectos Menores entrega a la corporación unos resultados
acordes para asegurar la continuidad del negocio. Los procesos transformadores
intrínsecos de Mantenimiento son cíclicos regidos por la filosofía de mejora continua
basada en el ciclo de Deming: Planear–Hacer–Verificar–Actuar (P–H–V–A) (Pacific
E&P - P-MTTO-001 MANUAL DE GESTIÓN INTEGRAL DEL PROCESO DE
MANTENIMIENTO, 2013).
2.2 Teoría de Administración de Proyectos
2.2.1 Proyecto
Según la definición que nos proporciona la Guía del PMBOK® “Un proyecto
es un esfuerzo temporal que se lleva a cabo para crear un producto, un servicio, o
resultado único” (Project Management Institute, 2013, pág. 3).
Un proyecto está constituido por un conjunto de actividades secuenciales e
interrelacionadas, que consumen tiempo y recursos, para lograr alcanzar o cumplir
un objetivo general o mayor; tiene un inicio y un fin cronológico. El final se alcanza
cuando se logran los objetivos del proyecto o cuando queda claro que los objetivos
no serán alcanzados o cuando el proyecto sea cancelado.
“… la definición de proyecto no depende de la complejidad o magnitud del
mismo, sino de las características de único y temporal. Podría ser un proyecto
simple como organizar el cumpleaños de tu hijo o algo muy complejo como lanzar
un cohete a la luna.” (Lledó, 2013).
27
2.2.2 Administración de Proyectos
La administración o dirección de proyectos es “La aplicación de
conocimientos, habilidades, herramientas y técnicas, a las actividades de un
proyecto para satisfacer los requisitos del proyecto”. (Project Management Institute,
2013, pág. 6).
2.2.3 Ciclo de Vida de un Proyecto
El ciclo de vida del proyecto es un conjunto de fases del mismo, generalmente
secuenciales y en ocasiones superpuestas, cuyo nombre y número se determinan
por las necesidades de gestión y control de la organización u organizaciones que
participan en el proyecto, la naturaleza propia del proyecto y su área de aplicación.
(Project Management Institute, 2013).
Todos los proyectos pueden configurarse dentro de la estructura genérica de
ciclo de vida ilustrada en la Figura 3:
Figura 3 – Ciclo de Vida de un Proyecto
Fuente: Project Management Institute, 2013, pág. 38
28
2.2.4 Procesos en la Administración de Proyectos
En la Guía del PMBOK® se mencionan cinco grupos de procesos de la
dirección de proyectos los cuales se resumen a continuación y su iteración se ilustra
en la Figura 4:
Procesos de Iniciación: se definen los objetivos del proyecto, se
identifican a los principales Interesados, se nombra al gerente de proyecto
y se autoriza formalmente el inicio del proyecto.
Procesos de Planificación: se define el alcance del proyecto, se refinan
los objetivos y se desarrolla el plan para la dirección del proyecto, que será
el curso de acción para un proyecto exitoso.
Procesos de Ejecución: se integran todos los recursos a los fines de
implementar el plan para la dirección del proyecto.
Procesos de Monitoreo y Control: se supervisa el avance del proyecto
y se aplican acciones correctivas.
Procesos de Cierre: se formaliza con el cliente la aceptación de los
entregables del proyecto.
Figura 4 – Grupo de Procesos de la Dirección de Proyectos
Fuente: Project Management Institute, 2013, pág. 50
29
2.2.5 Áreas de Conocimiento de la Administración de Proyectos
La Guía del PMBOK® está dividida en 47 procesos que se agrupan a su vez
en diez áreas de conocimiento. Estas áreas son las siguientes: Integración, Alcance,
Tiempo, Costo, Calidad, Recursos Humanos, Comunicaciones, Adquisiciones,
Riesgos, Interesados. A continuación se describe cada una existen diez áreas de
conocimiento y el Cuadro 2 muestra la correlación de estos con los 5 Grupos de
Procesos descritos anteriormente:
1. Gestión de la Integración del Proyecto: incluye los procesos y
actividades necesarios para identificar, definir, combinar, unificar y
coordinar los diversos procesos y actividades de dirección del proyecto
dentro de los Grupos de Procesos de la Dirección de Proyectos.
2. Gestión del Alcance del Proyecto: incluye los procesos necesarios para
garantizar que el proyecto incluye todo el trabajo requerido y únicamente
el trabajo para completar el proyecto con éxito.
3. Gestión del Tiempo del Proyecto: incluye los procesos requeridos para
gestionar la terminación en plazo del proyecto.
4. Gestión del Costo del Proyecto: incluye los procesos relacionados con
planificar, estimar, presupuestar, financiar, obtener financiamiento,
gestionar y controlar los costos de modo que se complete el proyecto
dentro del presupuesto aprobado.
5. Gestión de la Calidad del Proyecto: incluye los procesos y actividades
de la organización ejecutora que establecen las políticas de calidad, los
objetivos y las responsabilidades de calidad para que el proyecto satisfaga
las necesidades para las que fue acometido.
6. Gestión de los Recursos Humanos del Proyecto: incluye los procesos
que organizan, gestionan y conducen al equipo del proyecto.
7. Gestión de las Comunicaciones del Proyecto: incluye los procesos
requeridos para asegurar que la planificación, recopilación, creación,
distribución, almacenamiento, recuperación, gestión, control, monitoreo y
30
disposición final de la información del proyecto sean oportunos y
adecuados.
8. Gestión de los Riesgos del Proyecto: incluye los procesos para llevar a
cabo la planificación de la gestión de riesgos, así como la identificación,
análisis, planificación de respuesta y control de los riesgos de un proyecto.
9. Gestión de las Adquisiciones del Proyecto: incluye los procesos
necesarios para comprar o adquirir productos, servicios o resultados que
es preciso obtener fuera del equipo del proyecto.
10. Gestión de los Interesados del Proyecto: Incluye los procesos
necesarios para identificar a las personas, grupos u organizaciones que
pueden afectar o ser afectados por el proyecto, para analizar las
expectativas de los Interesados y su impacto en el proyecto, y para
desarrollar estrategias de gestión adecuadas a fin de lograr la participación
eficaz de los Interesados en las decisiones y en la ejecución del proyecto.
31
Cuadro 2 – Correspondencia de los Grupos de Procesos con las Áreas de Conocimiento de la Guía PMBOK®
Fuente: Elaboración Propia
Áreas de Conocimiento
Grupo de Procesos de la Dirección de Proyectos
Grupo de Procesos
de Iniciación
Grupo de Procesos de Planificación
Grupos de Procesos de
Ejecución
Grupo de Procesos de Monitoreo y
Control
Grupo de Procesos de Cierre
4. Gestión de la Integración del Proyecto
4.1 Desarrollar el Acta de Constituci
ón del Proyecto
4.2 Desarrollar el Plan para la Dirección del
Proyecto
4.3 Dirigir y Gestionar el Trabajo del Proyecto
4.4 Monitorear y Controlar el Trabajo del Proyecto
4.5 Realizar el Control
Integrado de Cambios
4.6 Cerrar el Proyecto
o Fase
5. Gestión del Alcance del
Proyecto
5.1 Planificar la Gestión del
Alcance 5.2 Recopilar
Requisitos 5.3 Definir el
Alcance 5.4 Crear la
EDT
5.5 Validar el Alcance
5.6 Controlar el Alcance
6. Gestión del Tiempo del Proyecto
6.1 Planificar la Gestión del Cronograma 6.2 Definir las Actividades
6.3 Secuenciar las
Actividades 6.4 estimar los Recursos de
las Actividades
6.5 Estimar la Duración de
las Actividades
6.6 Desarrollar el
Cronograma
6.7 Controlar
el Cronograma
7. Gestión de los Costos del
Proyecto
7.1 Planificar la Gestión de
Costos 7.2 Estimar
7.4 Controlar los Costos
32
Áreas de Conocimiento
Grupo de Procesos de la Dirección de Proyectos
Grupo de Procesos
de Iniciación
Grupo de Procesos de Planificación
Grupos de Procesos de
Ejecución
Grupo de Procesos de Monitoreo y
Control
Grupo de Procesos de Cierre
los Costos 7.3
Determinar el Presupuesto
8. Gestión de la Calidad del
Proyecto
8.1 Planificar la Gestión de
la Calidad
8.2 Realizar el Aseguramiento
de Calidad
8.3 Controlar la Calidad
9. Gestión de los Recurso Humanos del
Proyecto
9.1 Planificar la Gestión de
Recursos Humanos
9.2 Adquirir el Equipo del Proyecto
9.3 Desarrollar el Equipo del
Proyecto 9.4 Dirigir el Equipo del Proyecto
10. Gestión de las
Comunicaciones del
Proyecto
10.1 Planificar la Gestión de
las Comunicacion
es
10.2 Gestionar las
Comunicaciones.
10.3 Controlar las
Comunicaciones
11. Gestión de los Riesgos del Proyecto
11.1 Planificar la Gestión de
Riesgos 11.2 Identificar
los Riesgos 11.3 Realizar
el Análisis Cualitativo de
Riesgos 11.4 Realizar
el Análisis Cuantitativo de Riesgos
11.5 Planificar la Respuesta a los Riesgos
6 Controlar los
Riesgos
12. Gestión de las
Adquisiciones del Proyecto
12.1 Planificar la Gestión de
las Adquisiciones del Proyecto
12.2 Efectuar las
Adquisiciones
12.3 Controlar las
Adquisiciones
12.4 Cerrar las
Adquisiciones
http://wikibes.salleurl.edu/index.php?title=12.4_Cerrar_las_Adquisiciones&action=edit&redlink=1http://wikibes.salleurl.edu/index.php?title=12.4_Cerrar_las_Adquisiciones&action=edit&redlink=1http://wikibes.salleurl.edu/index.php?title=12.4_Cerrar_las_Adquisiciones&action=edit&redlink=1http://wikibes.salleurl.edu/index.php?title=12.4_Cerrar_las_Adquisiciones&action=edit&redlink=1
33
Áreas de Conocimiento
Grupo de Procesos de la Dirección de Proyectos
Grupo de Procesos
de Iniciación
Grupo de Procesos de Planificación
Grupos de Procesos de
Ejecución
Grupo de Procesos de Monitoreo y
Control
Grupo de Procesos de Cierre
13. Gestión de los
Interesados del Proyecto
13.1 Identificar
a los Interesado
s
13.2 Planificar la Gestión de
los Interesados
13.3 Gestionar la Participación
de los Interesados
13.4 Controlar la
Participación de los
Interesados
Los directores de proyecto necesitan tener las habilidades y conocimiento de
cada una de estas Áreas de Conocimiento con el fin de garantizar el éxito de los
proyectos. Estas áreas no son islas independientes entre sí, sino que generalmente
están interrelacionadas como se ilustra en la Figura 5.
Figura 5 – Áreas de Conocimiento de la Administración de Proyectos
Fuente: Lledó, 2013, pág. 37 y el Autor
34
2.3 Teoría y Conceptos del Tema de Interés de este PFG
2.3.1 Concepto de Metodología
Una Metodología se puede definir como la disciplina que indica cuales
métodos y técnicas deben ser empleadas en cada fase del ciclo de vida del
desarrollo del proyecto. Los elementos que componen una Metodología se ilustran
en la Figura 6:
Figura 6 – Elementos Básicos de una Metodología
Fuente: Elaboración propia.
No todas las Metodologías son iguales, pero si deben tener en común los
siguientes puntos para ser considerada una Metodología aplicable a la solución de
problemas y apoyar procesos de mejora continua:
Debe ser una Metodología impersonal.
Tiempo reducido de aprendizaje.
Uso de un estándar para la documentación.
Fases
Documentación
Técnicas y Herramientas
Metodos
Control y Evaluación
35
Que cubra todo o la mayor parte del ciclo de vida del proyecto.
Que sea de fácil mantenimiento.
Que evolucione y mejore.
2.3.2 Metodologías Ágiles
En febrero de 2001, tras una reunión celebrada en Utah–EEUU, nace el
término “Métodos Ágiles” aplicado al desarrollo de software. En esta reunión
participan un grupo de 17 expertos de la industria del software, incluyendo algunos
de los creadores o impulsores de metodologías de software. Su objetivo fue esbozar
los valores y principios que deberían permitir a los equipos desarrollar software
rápidamente y respondiendo a los cambios que puedan surgir a lo largo del
proyecto. Se pretendía ofrecer una alternativa a los procesos de desarrollo de
software tradicionales, caracterizados por ser rígidos y dirigidos por la
documentación que se genera en cada una de las actividades desarrolladas.
(Letelier, Canós, & Penadés).
Tras esta reunión se creó The Agile Alliance, una organización, sin ánimo de
lucro, dedicada a promover los conceptos relacionados con el desarrollo Ágil de
software y ayudar a las organizaciones para que adopten dichos conceptos. El punto
de partida es fue el Manifiesto Ágil, un documento que resume la filosofía “Ágil”. Los
integrantes de la reunión resumieron en cuatro postulados lo que ha quedado
denominado como “Manifiesto Ágil”, que son los valores sobre los que se asientan
estos métodos y el cual establece:
“Estamos descubriendo formas mejores de desarrollar software tanto por
nuestra propia experiencia como ayudando a terceros. A través de este trabajo
hemos aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas
36
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
Esto es, aunque valoramos los elementos de la derecha, valoramos más los
de la izquierda.” (www.agilemanifesto.org, 2001).
Los 12 Principios del Manifiesto Ágil
El Manifiesto Ágil, tras los postulados de estos cuatro valores en los que se
fundamenta, establece estos 12 principios:
1. Nuestra principal prioridad es satisfacer al cliente a través de la entrega
temprana y continua de software de valor.
2. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al
desarrollo. Los procesos Ágiles se doblegan al cambio como ventaja
competitiva para el cliente.
3. Entregar con frecuencia software que funcione, en períodos de un par de
semanas hasta un par de meses, con preferencia en los períodos breves.
4. Las personas del negocio y los desarrolladores deben trabajar juntos de
forma cotidiana a través del proyecto.
5. Construcción de proyectos en torno a individuos motivados, dándoles la
oportunidad y el respaldo que necesitan y procurándoles confianza para
que realicen la tarea.
6. La forma más eficiente y efectiva de comunicar información de ida y vuelta
dentro de un equipo de desarrollo es mediante la conversación cara a cara.
7. El software que funciona es la principal medida del progreso.
8. Los procesos Ágiles promueven el desarrollo sostenido. Los
patrocinadores, desarrolladores y usuarios deben mantener un ritmo
constante de forma indefinida.
37
9. La atención continua a la excelencia técnica enaltece la agilidad.
10. La simplicidad como arte de maximizar la cantidad de trabajo que se hace,
es esencial.
11. Las mejores arquitecturas, requisitos y diseños emergen de equipos que
se auto organizan.
12. En intervalos regulares, el equipo reflexiona sobre la forma de ser más
efectivo y ajusta su conducta en consecuencia.
Ciclo de Desarrollo Ágil
El desarrollo Ágil parte del concepto general del producto, y produce de forma
continua incrementos en la dirección apuntada por la visión; y en el orden de
prioridad que necesita el negocio del cliente. Los ciclos breves de desarrollo, se
denominan iteraciones y se realizan hasta que se decide no evolucionar más el
producto.
Este esquema está formado por cinco fases que se detallan en la Figura 7 y
de acuerdo con Palacio & Ruata estas fases se definen de la siguiente manera:
1. Concepto: En esta fase se crea la visión del producto y se determina el
equipo que lo llevará a cabo.
2. Especulación: Una vez que se sabe qué hay que construir, el equipo
especula y formula hipótesis basadas en la información de la visión, que
per se es muy general e insuficiente para determinar las implicaciones de
un desarrollo (requisitos, diseño, costes etc.).
3. Exploración: Se desarrolla un incremento del producto, que incluye las
funcionalidades determinadas en la fase anterior.
4. Revisión: Equipo y usuarios revisan lo construido hasta ese momento.
Trabajan y operan con el producto real contrastando su alineación con el
objetivo.
38
5. Cierre: Al llegar a la fecha de entrega de una versión de producto (fijada
en la fase de concepto y revisada en las diferentes fases de especulación),
se obtiene el producto esperado.
Figura 7 – Ciclo de Desarrollo Ágil
Fuente: Palacio & Ruata, Safe Creative, 2011, Pág. 44
2.3.3 Comparativa entre Metodologías Ágiles y no Ágiles
El Cuadro 3 detalla las principales diferencias de las metodologías Ágiles con
respecto a las tradicionales (“no Ágiles”):
39
Cuadro 3 – Diferencias entre Metodologías Ágiles y no Ágiles
Fuente: Letelier, Canós, & Penadés, 2003
Metodologías Ágiles Metodologías Tradicionales
Basadas en heurísticas provenientes de prácticas de producción de código
Basadas en normas provenientes de estándares seguidos por el entorno de desarrollo
Especialmente preparados para cambios durante el proyecto
Cierta resistencia a los cambios
Impuestas internamente (por el equipo) Impuestas externamente
Proceso menos controlado, con pocos principios Proceso mucho más controlado, con numerosas políticas/normas
No existe contrato tradicional o al menos es bastante flexible
Existe un contrato prefijado
El cliente es parte del equipo de desarrollo El cliente interactúa con el equipo de desarrollo mediante reuniones
Grupos pequeños (
40
apartado, algunos conservan su nombre en inglés ya que su traducción no es
práctica como por ejemplo el termino Sprint y Sprint Master.
Sprint: En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos
(iteraciones de un mes natural y hasta de dos semanas, denominadas Sprint). Cada
Sprint tiene que proporcionar un resultado completo, un incremento de producto final
que sea susceptible de ser entregado con el mínimo esfuerzo al cliente cuando lo
solicite.
Incremento: El incremento es la parte del producto producida en un Sprint,
y tiene como característica el estar completamente terminada y operativa, en
condiciones de ser entregada al cliente.
Daily Scrum: En español “Scrum Diario”, es una reunión con un bloque de
tiempo de 15 minutos para que el Equipo de Desarrollo sincronice sus actividades
y cree un plan para las siguientes 24 horas. Esto se lleva a cabo inspeccionando el
trabajo avanzado desde el último Scrum Diario y haciendo una proyección acerca
del trabajo que podría completarse antes del siguiente.
Development Team: En español “Equipo de Desarrollo”, consiste en los
profesionales que desempeñan el trabajo de entregar un Incremento de producto
“Terminado”, que potencialmente se pueda poner en producción, al final de cada
Sprint. Solo los miembros del Equipo de Desarrollo participan en la creación del
Incremento.
Product Backlog: En español “Lista de Producto”, es una lista ordenada de
todo lo que podría ser necesario en el producto, y es la única fuente de requisitos
para cualquier cambio a realizarse en el producto.
Product Owner: En español “Dueño de Producto”, es el responsable de
maximizar el valor del producto y del trabajo del Equipo de Desarrollo.
Scrum Master: El Scrum Master es el responsable de asegurar que Scrum
es entendido y adoptado. Los Scrum Masters hacen esto asegurándose de que el
Equipo Scrum trabaja ajustándose a la teoría, prácticas y reglas de Scrum.
41
Scrum Team: En español “Equipo Scrum”, consiste en un Dueño de
Producto (Product Owner), el Equipo de Desarrollo (Development Team) y un Scrum
Master. Los Equipos Scrum son autos organizados y multifuncionales.
Definition of “Done”: En español “Definición de Terminado”, es una
descripción de un elemento de la Lista de Producto o un Incremento que define su
estado o características para que se pueda entender como “Terminado”. Aunque
esto varía significativamente para cada Equipo Scrum, los miembros del Equipo
deben tener un entendimiento compartido de lo que significa que el trabajo esté
completado, para asegurar la transparencia.
Sprint Backlog: En español “Lista de Pendientes” del Sprint, es el conjunto
de elementos de la Lista de Producto seleccionados para el Sprint, más un plan
para entregar el Incremento de producto y conseguir el Objetivo del Sprint.
Sprint Goal: En español “Objetivo del Sprint”, es una meta establecida para
el Sprint que puede ser alcanzada mediante la implementación de la Lista de
Producto. Proporciona una guía al Equipo de Desarrollo acerca de por qué está
construyendo el incremento.
Sprint Planning Meeting: En español “Reunión de Planeación del Sprint”,
es una reunión que se sostiene con el fin de planificar el trabajo del Sprint. Este plan
se crea mediante el trabajo colaborativo del Equipo Scrum completo. La Reunión de
Planificación de Sprint tiene un máximo de duración de ocho horas para un Sprint
de un mes.
Sprint Retrospective: En español “Retrospectiva del Sprint” es una
oportunidad para el Equipo Scrum de inspeccionarse a sí mismo y crear un plan de
mejoras que sean abordadas durante el siguiente Sprint.
Sprint Review: En español “Revisión del Sprint”, es un chequeo al final del
Sprint para inspeccionar el Incremento y adaptar la Lista de Producto si fuese
necesario. Durante la Revisión de Sprint, el Equipo de Desarrollo y los Interesados
colaboran acerca de lo que se hizo durante el Sprint.
42
Origen
Scrum es un modelo de desarrollo Ágil caracterizado por:
Adoptar una estrategia de desarrollo incremental, en lugar de la
planificación y ejecución completa del producto.
Basar la calidad del resultado más en el conocimiento tácito de las
personas en equipos auto organizados, que en la calidad de los procesos
empleados.
Solapamiento de las diferentes fases del desarrollo, en lugar de realizar
una tras otra en un ciclo secuencial o de cascada.
Este modelo fue identificado y definido por Ikujiro Nonaka e Hirotaka
Takeuchi a principios de los 80, al analizar cómo desarrollaban los nuevos productos
las principales empresas de manufactura tecnológica: Fuji–Xerox (fotocopiadora
FX–3500), Canon (copiadora personal PC–10), Honda (auto de 1200cc), Nec
(ordenador personal PC 8000), Epson, Brother, 3M y Hewlett–Packard. (Nonaka &
Takeuchi, 1986).
En su estudio, Nonaka y Takeuchi compararon la nueva forma de trabajo en
equipo, con el avance en formación de Scrum de los jugadores de Rugby, a raíz de
lo cual quedó acuñado el término “Scrum” para referirse a ella.
En los años 1990, Ken Schwaber y Jeff Sutherland emplearon en sus
respectivas empresas unos modelos de aproximación al trabajo definido por Nonaka
y Takeuchi. Ya en el año de 1995 Ken Schwaber presentó “Scrum Development
Process” en OOPSLA 95 (Object–Oriented Programming Systems & Applications
Conference) (Scrum Development Process), un marco de reglas para desarrollo de
software, basado en los principios de Scrum, y que él había empleado en el
43
desarrollo de Delphi, y Jeff Sutherland en su empresa Easel Corporation siendo ésta
la primera aparición pública de la metodología. (Palacio, Safe Creative, 2014).
Durante los siguientes años, Ken Schwaber y Jeff Sutherland trabajaron
juntos para consolidar sus experiencias, artículos y mejores prácticas de la industria
confirmando lo que ahora se conoce como Scrum. En 2001, Ken Schwaber y Mike
Beedle, definieron la metodología en el libro Agile Software Development With
Scrum.
En la actualidad la metodología Scrum ha evolucionado y según Palacio &
Ruata (2011) las implementaciones de Scrum para desarrollo de software se vienen
enriquecendo desde entonces, y poco tienen que ver las implementaciones actuales
con la original de Ken Schwaber y Jeff Sutherland.
Introducción al Modelo
Scrum es una metodología de desarrollo muy simple, que requiere trabajo
duro, porque no se basa en el seguimiento de un plan, sino en la adaptación
continua a las circunstancias de la evolución del proyecto. (Palacio & Ruata, Safe
Creative, 2011).
Como Método Ágil:
Es un modo de desarrollo adaptable, antes que predictivo.
Orientado a las personas, más que a los procesos.
Emplea el modelo de construcción incremental basado en iteraciones y
revisiones.
Scrum comparte los principios estructurales del desarrollo Ágil detallados en
la Figura 7 a partir del concepto o visión de la necesidad del cliente, construye el
44
producto de forma incremental a través de iteraciones breves que comprenden
fases de especulación –exploración y revisión. Estas iteraciones (en Scrum
llamadas Sprint) se repiten de forma continua hasta que el cliente da por cerrado el
producto.
De acuerdo con Palacio y Ruata:
Se comienza con la visión general del producto, especificando y dando
detalle a las funcionalidades o partes que tienen mayor prioridad de negocio, y que
pueden llevarse a cabo en un período de tiempo breve (según los casos pueden
tener duraciones desde una semana hasta no más de dos meses). Cada uno de
estos períodos de desarrollo es una iteración que finaliza con la entrega de una
parte (incremento) operativa del producto.
Estas iteraciones son la base del desarrollo Ágil, y Scrum gestiona su
evolución en reuniones breves diarias donde todo el equipo revisa el trabajo
realizado el día anterior y el previsto para el siguiente (Palacio & Ruata, Safe
Creative, 2011, pág. 59).
Teoría
“Scrum emplea un enfoque iterativo e incremental para optimizar la
predictibilidad y el control del riesgo. Tres pilares soportan toda la implementación
del control de procesos empírico: transparencia, inspección y adaptación.”
(Schwaber & Sutherland, 2013).
Le definición de estos tres pilares es como sigue:
Transparencia. Los aspectos significativos del proceso deben ser visibles
para aquellos que son responsables del resultado. La transparencia requiere que
dichos aspectos sean definidos por un estándar común, de tal modo que los
observadores compartan un entendimiento común de lo que se está viendo.
45
Inspección. Los usuarios de Scrum deben inspeccionar frecuentemente los
artefactos de Scrum y el progreso hacia un objetivo, para detectar variaciones. Su
inspección no debe ser tan frecuente como para que interfiera en el trabajo. Las
inspecciones son más beneficiosas cuando se realizan de forma diligente por
inspectores expertos, en el mismo lugar de trabajo.
Adaptación. Si un inspector determina que uno o más aspectos de un
proceso se desvían de límites aceptables, y que el producto resultante no será
aceptable, el proceso o el material que está siendo procesado deben ser ajustados.
Dicho ajuste debe realizarse cuanto antes para minimizar desviaciones mayores.
“Scrum prescribe cuatro eventos formales, contenidos dentro del Sprint, para
la inspección y adaptación:
Reunión de Planificación del Sprint (Sprint Planning Meeting).
Scrum Diario (Daily Scrum).
Revisión del Sprint (Sprint Review).
Retrospectiva del Sprint (Sprint Retrospective)”. (Schwaber & Sutherland,
2013)
El Equipo (Scrum Team)
Todas las personas que intervienen, o tienen relación directa o indirecta con
el proyecto, se clasifican en dos grupos: comprometidos e implicados. En círculos
de Scrum es frecuente llamar a los primeros (sin ninguna connotación peyorativa)
“cerdos” y a los segundos “gallinas”. La Figura 8 muestra los Roles de Scrum y a
que círculo pertenece.
46
Figura 8 – Roles del Scrum
Fuente: Palacio & Ruata, Safe Creative, 2011, pág. 61
El origen de estos nombres es esta metáfora que ilustra de forma gráfica la
diferencia entre “compromiso” e “implicación” con el proyecto:
Una gallina y un cerdo paseaban por la carretera. La gallina preguntó al
cerdo: “¿Quieres abrir un restaurante conmigo?”.
El cerdo consideró la propuesta y respondió: “Sí, me gustaría. ¿Y cómo lo
llamaríamos?”.
La gallina respondió: “Jamón con huevos”.
El cerdo se detuvo, hizo una pausa y contestó: “Pensándolo mejor, creo que
no voy a abrir un restaurante contigo.
Yo estaría realmente comprometido, mientras que tú estarías sólo implicada”.
(Palacio & Ruata, Safe Creative, 2011).
El Dueño del Producto (Product Owner)
De acuerdo con (IBM, 2010), Las responsabilidades del Product Owner (que
puede ser interno o externo a la organización) son:
47
Ser el representante de todas las personas interesadas en los
resultados del proyecto (internas o externas a la organización, promotores
del proyecto y usuarios finales [idealmente también debería ser un usuario
clave] o consumidores finales del producto) y actuar como interlocutor
único ante el equipo, con autoridad para tomar decisiones.
Definir los objetivos del producto o proyecto.
Dirigir los resultados del proyecto y maximizar su ROI – Return Of
Investment (siglas en inglés de “Retorno de la Inversión).
o Es el propietario de la planificación del proyecto: crea y mantiene la
lista priorizada con los requisitos necesarios para cubrir los objetivos
del producto o proyecto, conoce el valor que aportará cada requisito
y calcula el ROI a partir del coste de cada requisito que le proporciona
el equipo.
o Reparte los objetivos/requisitos en iteraciones y establece un
calendario de entregas.
o Antes de iniciar cada iteración replantea el proyecto en función de los
requisitos que aportan más valor en ese momento, de los requisitos
completados en la iteración anterior y del contexto del proyecto en
ese momento (demandas del mercado, movimientos de la
competencia, etc.).
Colaborar con el equipo para planificar, revisar y dar detalle a los objetivos
de cada iteración:
o Participar en la reunión de planificación de iteración, proponiendo los
requisitos más prioritarios a desarrollar, respondiendo a las dudas del
equipo y detallando los requisitos que el equipo se comprometer a
hacer.
o Estar disponible durante el curso de la iteración para responder a las
preguntas que puedan aparecer.
48
o No cambiar los requisitos que se están desarrollando en una
iteración, una vez está iniciada.
o Participar en la reunión de demostración de la iteración, revisando
los requisitos completados.
El Equipo de Desarrollo (Development Team)
De acuerdo con (IBM, 2010), es un grupo de personas que de manera
conjunta desarrollan el producto del proyecto. Tienen un objetivo común, comparten
la responsabilidad del trabajo que realizan (así como de su calidad) en cada
iteración y en el proyecto. El tamaño del equipo está entre 5 y 9 personas. Realiza
de manera conjunta las siguientes actividades:
Seleccionar los requisitos que se compromete a completar en una
iteración, de forma que estén preparados para ser entregados al cliente.
Estimar la complejidad de cada requisito en la lista de requisitos priorizada
del producto o proyecto.
En la reunión de planificación de la iteración decide cómo va a realizar su
trabajo:
o Seleccionar los requisitos que pueden completar en cada iteración,
realizando al cliente las preguntas necesarias.
o Identificar todas las tareas necesarias para completar cada requisito.
o Estimar el esfuerzo necesario para realizar cada tarea.
o Cada miembro del equipo se auto asigna a las tareas.
Durante la iteración, trabajar de manera conjunta para conseguir los
objetivos de la iteración. Cada especialista lidera el trabajo en su área y el
resto colaboran si es necesario para poder completar un requisito.
Al finalizar la iteración:
o Demostrar al cliente los requisitos completados en cada iteración.
49
o Hacer una retrospectiva la final de cada iteración para mejorar de
forma continua su manera de trabajar.
Scrum Master
De acuerdo con (IBM, 2010), es quien lidera al equipo llevando a cabo las
siguientes responsabilidades:
Velar por que todos los participantes del proyecto sigan las reglas y
proceso de Scrum, encajándolas en la cultura de la organización, y guiar
la colaboración intraequipo y con el cliente de manera que las sinergias
sean máximas. Esto implica:
o Asegurar que la lista de requisitos priorizada esté preparada antes
de la siguiente iteración.
o Facilitar las reuniones de Scrum (planificación de la iteración,
reuniones diarias de sincronización del equipo, demostración,
retrospectiva), de manera que sean productivas y consigan sus
objetivos.
o Enseñar al equipo a auto gestionarse. No da respuestas, si no que
guía al equipo con preguntas para que descubra por sí mismo una
solución.
Quitar los impedimentos que el equipo tiene en su camino para conseguir
el objetivo de cada iteración (proporcionar un resultado útil al cliente de la
manera más efectiva) y poder finalizar el proyecto con éxito. Estos
obstáculos se identifican de manera sistemática en las reuniones diarias
de sincronización del equipo y en las reuniones de retrospectiva.
Proteger y aislar al equipo de interrupciones externas durante la ejecución
de la iteración (introducción de nuevos requisitos, "secuestro" no previsto
de un miembro del equipo, etc.). De esta manera, el equipo puede
mantener su productividad y el compromiso que adquirió sobre los
50
requisitos que completaría en la iteración [notar, sin embargo, que el
equipo debe reservar tiempo para colaborar con al cliente en la
preparación de la lista de requisitos para la próxima iteración.
Artefactos (Los Elementos)
De acuerdo con Palacio & Ruata, los Elementos o Artefactos de un “sprint”
son el Product Backlog, Sprint Backlog y el Incremento. La Figura 9 ilustra los
elementos y se detallan a continuación:
Pila del producto (Product Backlog): Lista de requisitos de usuario que
a partir de la visión inicial del producto crece y evoluciona durante el
desarrollo.
Pila del sprint (Sprint Backlog): Lista de los trabajos que debe realizar
el equipo durante el sprint para generar el incremento previsto.
Incremento: Resultado de cada sprint
Figura 9 – Los Elementos del Scrum
Fuente: Palacio & Ruata, Safe Creative, 2011, pág. 61
51
Las Reuniones
De acuerdo con Palacio & Ruata, los “Sprint” se organizan de la siguiente
manera:
Planificación del sprint: Jornada de trabajo previa al inicio de cada sprint
en la que se determina cuál va a ser el trabajo y los objetivos que se deben
conseguir en la iteración.
Seguimiento del sprint: Breve revisión diaria, en la que cada miembro
describe tres cuestiones:
o El trabajo que realizó el día anterior.
o El que tiene previsto realizar.
o Cosas que puede necesitar o impedimentos que deben suprimirse
para realizar el trabajo.
Cada persona actualiza en la pila del sprint el tiempo pendiente de sus tareas,
y con esta información se actualiza también el gráfico con el que el equipo
monitoriza el avance del sprint (Burndown).
Revisión del sprint: Análisis y revisión del incremento generado.
La Figura 10 muestra las reuniones del Scrum.
52
Figura 10 – Reuniones Habituales en Scrum
Fuente: Palacio & Ruata, Safe Creative, 2011, pág. 61
Control de la Evolución del Proyecto
Palacio & Ruata definen que Scrum controla de forma empírica y adaptable
la evolución del proyecto, a través de las siguientes prácticas de la gestión Ágil:
1. Revisión de las Iteraciones: Al finalizar cada iteración (sprint) se lleva a
cabo una revisión con todas las personas implicadas en el proyecto. Es
por tanto la duración del sprint, el período máximo que se tarda en
reconducir una desviación en el proyecto o en las circunstancias del
producto.
2. Desarrollo Incremental: Las personas implicadas no trabajan con
diseños o abstracciones. El desarrollo incremental implica que al final de
cada iteración se dispone de una parte de producto operativa, que se
puede inspeccionar y evaluar.
3. Desarrollo Evolutivo: Los modelos de gestión Ágil se emplean para
trabajar en entornos de incertidumbre e inestabilidad de requisitos. Intentar
predecir en las fases iniciales cómo será el resultado final, y sobre dicha
53
predicción desarrollar el diseño y la arquitectura del producto no es
realista, porque las circunstancias obligarán a remodelarlo muchas veces.
¿Para qué predecir los estados finales de la arquitectura o del diseño si
van a estar cambiando? Scrum considera a la inestabilidad como una
premisa, y se adoptan técnicas de trabajo para permitir la evolución sin
degradar la calidad de la arquitectura que también evoluciona durante el
desarrollo. Durante el desarrollo se genera el diseño y la arquitectura final
de forma evolutiva. Scrum no los considera como productos que deban
realizarse en la primera “fase” del proyecto. (El desarrollo Ágil no es un
desarrollo en fases).
4. Auto–organización: En la ejecución de un proyecto son muchos los
factores impredecibles en todas las áreas y niveles. La gestión predictiva
confía la responsabilidad de su resolución al gestor de proyectos. En
Scrum los equipos son auto–organizados (no auto–dirigidos), con margen
de decisión suficiente para tomar las decisiones que consideren
oportunas.
5. Colaboración: Las prácticas y el entorno de trabajo Ágiles facilitan la
colaboración del equipo. Ésta es necesaria, porque para que funcione la
auto–organización como un control eficaz cada miembro del equipo debe
colaborar de forma abierta con los demás, según sus capacidades y no
según su rol o su puesto.
Visión General del Proceso
Bajo la metodología Scrum se denomina “Sprint” a cada iteración de
desarrollo con una duración recomendable de máximo un mes de duración la cual
depende de las características del proyecto. El “Sprint” es el núcleo central que
proporciona la base de desarrollo iterativo e incremental. Ver Figura 11.
54
Figura 11 – Scrum – Visión General del Proceso
Fuente: https://msdn.microsoft.com/es–es/library/vstudio/dd997796(v=vs.100).aspx
La Figura 12 resume el ciclo de vida de un proyecto administrado bajo Scrum,
integrando el macro proceso con sus roles, actividades y artefactos.
55
Figura 12 – Ficha Sinóptica de Scrum
Fuente: Palacio & Ruata, Safe Creative, 2011, pág. 63
56
Scrum y los 5 Grupos de Procesos de la Gerencia de Proyectos
A continuación se correlaciona Scrum con los 5 Grupos de Procesos
establecidos por la Guía PMBOK®. En Scrum, estos Grupos de Procesos no se
presentan una vez durante el ciclo de vida del proyecto, por el contrario aparecen
continuamente y de manera iterativa. Esto quiere decir que los Grupos de Procesos
se definen y ejecutan por cada Sprint.
A continuación en el Cuadro 4, se detalla cómo correlaciona Scrum con los 5
Grupos de Procesos establecidos por la Guía PMBOK®:
Cuadro 4 – Scrum y los 5 Grupos de Procesos
Fuente: Project Management Institute, 2013, Lledó, 2013, Arango Lyons, 2012, Vásquez, 2012 y el Autor
Grupo de Procesos
PMBOK® Scrum
1. INICIACION
El objetivo de este grupo de procesos es definir y autorizar lo que se va a hacer en el proyecto
La organización define los objetivos del proyecto, se identifican a los principales Interesados, el sponsor asigna al Director del Proyecto y se autoriza formalmente el inicio del proyecto. (Lledó, 2013).
Se definen los objetivos del proyecto, se identifican a los principales Interesados, se nombra al gerente de proyecto y se autoriza formalmente el inicio del proyecto. (Project Management Institute, 2013).
Lo que se va a hacer en el proyecto se define en primer lugar mediante el artefacto Product Backlog definido por el Product Owner, quien representa al cliente. El Product Backlog es un documento que describe las funcionalidades y características del producto deseadas por el Cliente y será discutido en el Sprint Planning Meeting que se realiza al comienzo de cada Sprint. Los resultados serán reflejados en el Sprint Goal.
Entradas: Product Backlog
Herramientas: Sprint Planning Meeting
Salidas: Sprint Goal
2. PLANIFICACION
Los Interesados definen el alcance del proyecto y refinan los objetivos; el equipo desarrolla el plan para la dirección del proyecto que será la guía para un proyecto exitoso. (Lledó, 2013).
Aquí se debe definir el libreto a seguir para alcanzar los objetivos del Sprint.
Entradas: Product Backlog y Sprint Goal.
57
Grupo de Procesos
PMBOK® Scrum
Se define el alcance del proyecto, se refinan los objetivos y se desarrolla el pla
