UNIVERSIDAD PARA LA COOPERACIÓN INTERNACIONAL (UCI)

Transcripción

1 UNIVERSIDAD PARA LA COOPERACIÓN INTERNACIONAL (UCI) PLAN DE GESTIÓN PARA LA ACTUALIZACIÓN DE LA METODOLOGÍA DE ADMINISTRACIÓN DE PROYECTOS EN LA EMPRESA STACK POINTER CON ENFOQUE EN DESARROLLO ÁGIL RUTHFORD FRANCIS JAY ARCHBOLD PROYECTO FINAL DE GRADUACIÓN PRESENTADO COMO REQUISITO PARCIAL PARA OPTAR POR EL TÍTULO DE MÁSTER EN ADMINISTRACIÓN DE PROYECTOS San José, Costa Rica Abril, 2014

2 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 Murillo Blanco PROFESOR TUTOR Pedro Céspedes Calderón LECTOR No.1 Fabio Muñoz Jiménez LECTOR No.2 Ruthford Francis Jay Archbold SUSTENTANTE

3 iii DEDICATORIA A Dios por la sabiduría y fortaleza que me dio, a mi esposa Ana María y mi hijo Samuel José, quienes son el motor de mi vida; su amor y apoyo incondicional me han permitido alcanzar esta meta.

4 iv AGRADECIMIENTOS A mi familia, quienes siempre han estado a mi lado en todo momento de mi vida, en las buenas y en las malas. Porque siempre han sido un ejemplo de entrega y coraje; por iluminar mi camino y darme la pauta para poder realizarme en mis estudios y en mi vida. Pero especialmente gracias por su amor, trabajo y sacrificios en todos estos años. A mis compañeros que durante todo el proceso estuvieron compartiendo y llenando mi camino de grandes experiencias. A mi tutor quien fue mi guía para la culminación de este proceso, gracias a todos ustedes he logrado llegar hasta aquí.

5 v ÍNDICE HOJA DE APROBACIÓN ii DEDICATORIA iii AGRADECIMIENTO iv ÍNDICE v ÍNDICE DE FIGURAS viii ÍNDICE CUADROS ix ÍNDICE DE ABREVIATURAS x RESUMEN EJECUTIVO xi 1. INTRODUCCIÓN Antecedentes Problemática Justificación del Problema Objetivo General Objetivos Específicos MARCO TEÓRICO Marco Institucional Antecedentes de la Institución Misión y Visión Estructura Organizativa de Stack Pointer Productos que Ofrece Teoría de Administración de Proyectos Proyecto Administración de Proyectos Ciclo de Vida de un Proyecto Procesos en la Administración de Proyectos Áreas de Conocimiento de la Administración de Proyectos Modelos de Madurez Definición de Madurez... 27

6 vi Modelo de Madurez de Capacidad Integrado Scrum El Equipo Scrum (Scrum Team) Eventos de Scrum Artefactos de Scrum MARCO METODOLÓGICO Fuentes de Información Fuentes Primarias Fuentes Secundarias Métodos de Investigación Método Analítico Método Inductivo Método de Observación Herramientas y Técnicas Entrevista Juicio Experto EDT Formularios o Plantillas Software Diagramas de Flujo Investigación Bibliográfica DESARROLLO Análisis de la Situación Actual Herramientas De Gestión Actual Análisis Metodológico Puntos Críticos de Mejora Áreas de Conocimiento y Planes de Gestión Plan de Gestión del Alcance Plan de Gestión del Tiempo Plan de Gestión de la Calidad... 79

7 vii Plan de Gestión de las Comunicaciones Plan de Gestión de los Costos Plan de Gestión de los Riesgos Estrategia de Desarrollo e Implementación CONCLUSIONES RECOMENDACIONES BIBLIOGRAFIA ANEXOS Anexo 1: ACTA DEL PROYECTO PFG Anexo 2: CRONOGRAMA DEL PFG Anexo 3: EDT DEL PFG Anexo 4: ACTA DEL PROYECTO Actualización de Metodología para Administración de Proyectos con enfoque en desarrollo ágil Anexo 5: CRONOGRAMA DEL PROYECTO Actualización de Metodología para Administración de Proyectos con enfoque en desarrollo ágil Anexo 6: EDT DEL PROYECTO Actualización de Metodología para Administración de Proyectos con enfoque en desarrollo ágil Anexo 7: Cálculo Priorización de Requisitos Según Gerencia Anexo 8: Cálculo Priorización de Requisitos Según Dpto. de Desarrollo Anexo 9: Cálculo Priorización de Requisitos Según Dpto. de Soporte

8 viii ÍNDICE DE FIGURAS Figura 1 - Estructura Organizativa de Stack Pointer... 9 Figura 2 - Procesos de la Administración de Proyectos Figura 3 - Niveles de Madurez Figura 4 - Flujo Scrum para un Sprint Figura 5 Pantalla Inicial de Pointer Desk Figura 6 Pantalla de Tareas Reportadas Figura 7 Pantalla de Seguimiento de Tareas Figura 8 Pantalla de Actividad Seleccionada Figura 9 Pantalla de Actividades Relacionas Figura 10 Pantalla de Creación de Nueva Actividad Figura 11 - EDT Niveles Básicos del Proyecto Figura 12 - Resumen Cronograma... 78

9 ix ÍNDICE DE CUADROS Cuadro 1 - Fuentes de Información Utilizadas Cuadro 2 - Métodos de Investigación Utilizadas Cuadro 3 - Herramientas Utilizadas Cuadro 4 Valores de Priorización Cuadro 5 - Priorización de Interesados Cuadro 6 - Priorización de Requisitos Cuadro 7 - Lista de Tareas Cuadro 8 - Estimación de los Recursos en las Tareas Cuadro 9 - Estimación de la Duración de las Tareas Cuadro 10 - Factores Relevantes de Calidad Cuadro 11 - Métricas de Calidad Cuadro 12 - Línea Base de Calidad Cuadro 13 - Matriz de Comunicaciones Cuadro 14 - Costo por Hora de Recursos Cuadro 15 - Estimación de Costos por Tarea Cuadro 16 - Línea Base de Costo Cuadro 17 - Presupuesto Cuadro 18 - Identificación de Riesgos Cuadro 19 - Escala de Probabilidad e Impacto Cuadro 20 - Matriz PxI Cuadro 21 - Categorías Cuadro 22 - Matriz Probabilidad Impacto Cuadro 23 - Estrategias, Acciones Preventivas, Contingencias y Respaldos Cuadro 24 - Cálculo de Priorización Según Gerencia Cuadro 25 - Cálculo de Priorización Según Departamento de Desarrollo Cuadro 26 Cálculo de Priorización Según Departamento de Soporte

10 x ÍNDICE DE ABREVIATURAS Abreviatura CMM CMMI COP EDT LTDA MOPROSOFT OCP OCSP OPP PMBOK PMI PMO SEI WBS Significado Capability Maturity Model Capability Maturity Model Integration Pesos Colombianos Estructura de Desglose del Trabajo Limitada Modelo de Procesos para la Industria del Software Oracle Certified Professional Oracle Certified Solution Partner Output Post Processor Project Management Body of Knowledge Project Management Institute Project Management Office Software Engineering Institute Work Breakdown Structure

11 xi RESUMEN EJECUTIVO Stack Pointer es una empresa Colombiana, dedicada a la creación de software a la medida. Sus principales clientes son empresas de explotación minera, servicio de telecomunicaciones, entre otros. En Stack Pointer existe un documento de estándares de programación para cualquier tipo de proyecto de software. La empresa cuenta con un documento de políticas que exige una metodología única para llevar a cabo el desarrollo de software. Este documento es presentado a cada nuevo miembro de la empresa y se debe cumplir a cabalidad en todos los proyectos. La empresa en los últimos años se ha caracterizado por tomar proyectos con retos tecnológicos, la gran mayoría han sido proyectos con dispositivos móviles. Pero la empresa ha decidido pensar en implementar una metodología que ayude al desarrollo ágil de aplicaciones. Al implementar la actualización de la metodología de proyectos en la empresa Stack Pointer incorporando algún marco de desarrollo ágil, ésta permitirá mitigar los riesgos que se puedan presentar en un proyecto de tecnología desconocida o con altos problemas de deuda técnica. Uno de los marcos de trabajo ágil con mayor representación en el mercado es Scrum, el cual sería de gran ayuda para el día a día de la empresa. El objetivo principal del presente proyecto es la elaboración del plan integral de administración para el proyecto de actualización a la metodología actual de la compañía Stack Pointer en el que se espera mejorar los procesos de desarrollo de software y servicio de soporte a clientes con la incorporación de marcos de desarrollo ágil, que permitan brindar productos de calidad y con eficientes tiempos de entrega.

12 xii La teoría formal de administración de proyectos en la que se basa el presente documento fue tomada del libro PMBOK (PMI, 2008) y de los estándares de práctica de ciertas áreas específicas. El producto final es un conjunto de planes de gestión de seis de las nueve áreas de conocimiento de la administración de proyectos, que en el futuro cercano se utilizará para llevar a cabo el proyecto de actualización de la metodología de la empresa Stack Pointer. Al realizar la investigación inicial de la empresa se identificaron varios desafíos a los cuales el presente proyecto deberá hacer frente: la metodología actual no está siendo utilizada por el departamento de soporte, los formatos que se están utilizando no coinciden con los exigidos por la metodología MoproSoft, el personal que asigna los presupuestos no tiene la experiencia sobre el tema. Para resolución de todos estos inconvenientes se debe crear un compromiso en el que todos aporten su mayor esfuerzo para salir adelante con el proyecto. Con el presente proyecto se concluyó que la administración formal de proyectos puede favorecer en gran medida a la empresa Stack Pointer, tanto en el logro de los objetivos relacionados a proyectos específicos, como en la mejora de la distribución de tiempo entre los empleados que se verán involucrados en el proceso de actualización, que es el área operativa donde se necesita más atención. Con respecto a las recomendaciones realizadas, sería muy importante cumplirlas de manera inmediata, recordando que una oficina de proyectos debe ser dedicada a la gestión y mejora continua de los procesos, con esto se beneficia la metodología que se quiere actualizar.

13 1 1. INTRODUCCIÓN 1.1. Antecedentes Stack Pointer nace de una iniciativa para brindar servicio a las empresas de la región caribe en la zona norte de Colombia. Una de las cualidades que caracteriza a Stack Pointer es el potencial en su recurso humano, quienes han logrado un gran posicionamiento entre las cadenas de software de la costa caribe. Gracias a los proyectos realizados con lo más altos retos tecnológicos, ha logrado adquirir grandes clientes, y gran posición a nivel Latinoamérica. Los proyectos llevados a cabo por Stack Pointer la mayoría de veces se encuentran con problemas de deuda técnica, a los cuales se debe enfrentar sin afectar los cronogramas ya establecidos con los clientes. Uno de los eslabones de la cadena serían los proyectos de desarrollo móvil, que hasta la fecha han sido día a día fuente de conocimiento y de lecciones aprendidas, las cuales han llevado a mejorar los proyectos. En el año 2009, Stack Pointer inicia el desarrollo de un proyecto sobre dispositivos móviles industriales para un sistema operativo obsoleto, al cual la casa matriz no brindaba soporte desde hace 2 años, con una demanda de características que eran imposibles para la culminación del producto en el tiempo estipulado. El proyecto tuvo sus retrasos pero al final se le cumplió al cliente con todos los requerimientos tecnológicos que el cliente solicitó. El proyecto fue terminado en su totalidad sin dejar ganancias y pérdidas a Stack Pointer, sin embargo este tipo de inconvenientes tecnológicos se han convertido en una camisa de fuerza, ya que para cada proyecto con los clientes se debía utilizar tecnología que ya no era soportada en el mercado, esto debido a que la compra de cada uno de estos dispositivos de última generación incrementaba el

14 2 costo del proyecto en un 260% con lo cual el cliente solicitaba el apoyo de Stack Pointer en evitar estos altos costos. Con la cantidad de problemas que se presentan en proyectos que tiene alta deuda técnica, se decidió crear una actualización sobre la metodología MoproSoft que se lleva actualmente para el desarrollo de las aplicaciones. La metodología que se lleva en la empresa Stack Pointer es MoproSoft (Modelo de Procesos para la Industria del Software), la cual consiste en un modelo para mejorar y evaluar los procesos de desarrollo de software y soporte de aplicaciones. Stack Pointer opta por esta metodología ya que está dirigida a empresas o áreas internas dedicadas al desarrollo y/o mantenimiento de software. La metodología MoproSoft se debe integrar marcos de trabajo ágil, esto con el fin de mitigar la cantidad de problemas que se enfrentan y definir unos lineamientos claves para el seguimiento y control de los proyectos Problemática Actualmente en la empresa Stack Pointer existe un documento de estándares de programación para cualquier tipo de proyecto de software. Adicionalmente hay un documento de políticas que exige una metodología única para la gestión de proyectos de desarrollo de software, pero en una aplicación móvil se deben contemplar otros factores tales como tecnología, rendimiento del dispositivo, restricción de almacenamiento, entre otros. Hasta el momento se han llevado a cabo varios proyectos con aplicaciones móviles en la empresa y por fortuna no se han presentado retrasos que puedan comprometer la imagen con el cliente, sin embargo por falta de unos lineamientos claros se presentan este tipo de inconvenientes.

15 3 Se han realizado documentos donde se registran las lecciones aprendidas y lo que no se debe realizar en los próximos proyectos, pero cada proyecto que se inicia tiene algo que aún no se ha explorado y siempre se encuentran nuevos problemas. Stack Pointer se ha caracterizado por ser una empresa que se enfrenta a cualquier reto tecnológico, sin embargo por falta de documentación o por no tener unas políticas claras en los proyectos de cierta tecnología sufre con retrasos o con tiempos muertos con los cuales no se contaba en el cronograma del proyecto. Esto se debe a no tener claro que hacer en una situación por falta del KNOW HOW (Como se Hace) que sin duda alguna es uno de los mayores retos en las empresas de tecnología. Es muy cierto decir que algo es fácil cuando se lleva mucho tiempo haciendo lo mismo, pero para Stack Pointer ningún proyecto tiene las mismas características. Sin embargo, la metodología MoproSoft que se utiliza para el desarrollo de los proyectos ha funcionado, ya que en las aplicaciones de Cliente Servidor se maneja una estructura parecida y no se tienen tantos problemas de incompatibilidad o problemas de rendimiento. Realizar proyectos en dispositivos móviles es algo que toma mucho tiempo, y con la gran variedad de dispositivos esto hace que el software sea demasiado fragmentado por la cantidad de Sistemas Operativos para móviles que existen en la actualidad. Se pensaría que el desarrollo para un celular con sistema operativo ios es lo mismo que para un celular con sistema operativo Android o lo mismo con un Windows Phone, pero esta es una equivocación que se comete al decir si ya está hecho en un sistema, debe ser fácil migrarlo a otro, pero no es así de transparente.

16 4 Este sería grosso modo el panorama del desarrollo de proyectos móviles, los cuales tienen una fragmentación de sistemas operativos donde el cliente es el que decide qué plataforma desea utilizar, qué componentes desea ver e incluso cómo quiere que se comporte el sistema que solicitó. El gran problema que se presenta en Stack Pointer es que la metodología MoproSoft, esta se queda atrás en los procesos que involucran nuevas tecnologías y nuevos métodos para el desarrollo de aplicaciones modernas. Esto se debe solucionar incursionando marcos de trabajo ágil orientados a la gestión de proyectos de desarrollo de software Justificación del Problema El realizar la actualización de la metodología MoproSoft de proyectos en la empresa Stack Pointer permitirá mitigar los riesgos que se puedan presentar en el desarrollo de un proyecto de software móvil. Sin embargo, para que este proyecto tenga el mejor resultado se deben utilizar ciertas prácticas que explica el marco de trabajo SCRUM. Esto no quiere decir que para la metodología completa se aplicará este marco de trabajo, pero si se deben utilizar sus más relevantes actores, como lo es el Product Owner (Dueño del Producto) y el SCRUM Developer (Programador SCRUM). Para esta metodología se hará caso omiso del SCRUM Master, esto con el fin de no hacer un cambio total en la metodología que se está utilizando en la empresa. La inclusión de estos nuevos componentes en el proceso va a implicar ciertos costos adicionales en la gestión de los proyectos.

17 5 Uno de los puntos clave de este cambio será el Daily Meeting (Reunión Diaria), el cual nos permitiría tener un panorama claro del proyecto con las siguientes inquietantes Cómo está?, Qué se hace hoy?, Quién lo hace? y Cuándo lo termina?. Esto con el fin llevar un control diario de lo que se tiene realizado y lo que hace falta por realizar, es una simple inspección que ayuda a cambiar la visión del proyecto día tras día Objetivo General Crear un Plan de Gestión para la actualización de la Metodología de Administración de Proyectos en la Empresa Stack Pointer, con un enfoque en desarrollo ágil Objetivos Específicos Los objetivos específicos del proyecto son: Elaborar un análisis sobre la situación actual de la empresa Stack Pointer y su metodología de proyectos. Desarrollar un Plan de Gestión del Alcance para determinar los puntos que se deben afectar en la metodología actual e identificar las áreas que deben mejorar. Desarrollar un Plan de Gestión del Tiempo para determinar el cronograma de las actividades requeridas para incluir técnicas de desarrollo ágil sobre la metodología actual. Desarrollar un Plan de Gestión de Calidad para asegurar y controlar los resultados del proyecto. Desarrollar un Plan de Gestión de Comunicaciones para dar conocimiento a los interesados del desarrollo del proyecto. Desarrollar un Plan de Gestión de Costos para estimar y presupuestar los recursos que se deben invertir para efectuar el proyecto.

18 6 Diseñar un Plan de Gestión de Riesgo para aumentar las probabilidades de éxito del proyecto dentro del alcance, tiempo y costo establecido. Establecer lineamientos iniciales para la implementación de las mejoras en la metodología actual.

19 7 2. MARCO TEÓRICO 2.1 Marco Institucional Antecedentes de la Institución Stack Pointer nació en el año 1997, en la ciudad de Barranquilla Colombia, como respuesta a la creciente demanda para el desarrollo de soluciones de software, incorporando en el año 2000 los servicios de consultoría en implementación de estrategias para Internet, comercio electrónico y e-business. La empresa tiene como objetivo seguir creciendo en el mercado, brindando tiempos de desarrollo corto, soluciones efectivas y flexibles, y entregarle un alto grado de satisfacción al cliente. En noviembre del año 2000, Stack Pointer obtuvo la credencial de OCSP del programa OPP de ORACLE Colombia Ltda., grado que a la fecha solo ha sido entregado a tres compañías en Colombia, siendo éste el segundo de tres niveles, credencial que las acredita como integrantes del programa mundial de ORACLE Corporation ORACLE Alliance. Este logro fue obtenido gracias al tiempo de experiencia en manejo ORACLE, conocimiento de los productos ORACLE, la certificación de los ingenieros dentro del programa OCP y nivel de ventas reportado. El programa de OCP, es una credencial que se obtiene por medio de la aprobación de exámenes que evalúan los conocimientos adquiridos en determinada área. Sólo aquellas personas que demuestren un alto nivel de competencia en el uso de los productos ORACLE pueden obtener dicha certificación corporativa, válida mundialmente. Stack Pointer cuenta con dos ingenieros que han sido certificados dentro de éste programa.

20 8 En mayo del 2000, 2001, 2002, 2003 y 2004 Stack Pointer obtiene un reconocimiento por parte de ORACLE como uno de los cinco canales con el mayor volumen de ventas a nivel nacional, lo que permite hacer realidad el objetivo de ser la empresa de desarrollo de soluciones con mayor crecimiento en la región norte del país. Stack Pointer trabaja con un esquema ganar-ganar con sus clientes, escuchando activamente sus necesidades para ofrecer soluciones integrales que permitan lograr los objetivos trazados a corto plazo. Se estudia la problemática de su negocio y sus requerimientos, ofreciéndole soluciones estratégicas y técnicas concretas; estructura las soluciones en un esquema modular el cual permite planificar correctamente el proyecto. El Equipo Técnico desarrolla la solución más adecuada para la actividad del cliente, con un alto nivel de personalización, garantizando confidencialidad en todos los procedimientos. (Stack Pointer, 2013) Misión y Visión A continuación se presenta la misión y la visión de la empresa Stack Pointer obtenida de su sitio Web. Misión Somos una organización comprometida con brindar a nuestros Clientes soluciones integrales basadas en tecnologías de la información utilizando las mejores prácticas de la industria, generando valor a su negocio; comprometida con el crecimiento profesional y personal de nuestros empleados y con el nivel de rentabilidad esperado por nuestros accionistas. (Stack Pointer, 2013)

21 9 Visión Ser reconocidos en los próximos 3 años como una de las empresas líderes en soluciones IT de América debido a nuestra contribución en la consecución de los objetivos de nuestros clientes y aliados de negocio. (Stack Pointer, 2013) Valores Corporativos Para cumplir la misión Stack Pointer necesita que su personal comparta los siguientes valores: Excelencia Integridad Honestidad Seriedad Disposición Responsabilidad Compromiso Estructura Organizativa de Stack Pointer Figura 1 - Estructura Organizativa de Stack Pointer Fuente: Elaboración Propia

22 Productos que Ofrece La empresa Stack Pointer se caracteriza por la calidad de producto que ofrece a sus clientes. A continuación se realizará una breve explicación de los servicios y productos que ofrece la empresa Fábrica de Software Desarrollo de soluciones orientadas a lograr continuidad de negocio en áreas operativas, basadas en tecnologías y enfocadas a clientes corporativos. Ingeniería de Software aplicada a: Arquitectura. Testing de Aplicaciones. Diseño y Construcción de Software. Outsourcing de Recursos Especializados. Levantamiento Requerimientos y Especificación Funcional. Formulación y Dimensionamiento de Soluciones de Software. Personalización y migración de aplicaciones Servicios de Soporte Ofrece a los Clientes los servicios de un grupo de profesionales especializados con la experiencia requerida para brindar el soporte que permita la continuidad de la operación en las instalaciones del cliente: Soporte de Aplicaciones Soporte Infraestructura de Software Soporte Infraestructura de Hardware

23 Tipos de Servicio Al firmar los contratos de soporte con los clientes, se determinan niveles de servicios en términos de tiempos de atención a sus solicitudes. La metodología aplicada obliga a realizar seguimiento a cada solicitud en los siguientes aspectos: En Sitio: El ingeniero de servicio se debe desplazar hasta las instalaciones donde se esté presentando el problema. Remoto: El ingeniero de servicio por medio de herramientas tecnológicas se conecta de manera virtual con el cliente para resolver su problema. On Call: El ingeniero de servicio estará disponible para una llamada de emergencia durante las 24 horas del día, los 7 días de la semana Capacitación En lo referente al entrenamiento en el uso de las soluciones, Stack Pointer se preocupa por capacitar y entrenar a los clientes. Durante las etapas de diseño y desarrollo de los proyectos, se tiene en cuenta las necesidades, capacidades y requerimientos de los usuarios finales de las soluciones. Se complementan las actividades ofreciendo cursos orientados a la utilización de las opciones administrativas que se detallaron en la descripción técnica de los productos. Los servicios de capacitación son ampliamente reconocidos por su sentido práctico, instructores de primer nivel y flexibilidad. 2.2 Teoría de Administración de Proyectos A continuación se presenta una breve descripción de lo que es un proyecto y de que atributos viene acompañado.

24 Proyecto Según Pablo Lledó en su Libro Administración de proyectos: El ABC para un Director de proyectos exitoso se define Proyecto como esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único (Lledó et al. 2013, Página 13). Esto hace una diferencia muy marcada con el Trabajo Operativo que consiste en efectuar permanentemente actividades que generan un mismo producto o proveen un servicio repetitivo (Lledó et al. 2013, Página 13). Ampliando el concepto Proyecto según el PMI, es conveniente citar los siguientes atributos: Temporal, Productos, Servicios o Resultados Únicos y Elaboración Gradual, los cuales se describen a continuación. Temporal Temporal significa que cada proyecto tiene un comienzo definido y un final definido. El final se alcanza cuando se han logrado los objetivos del proyecto o cuando queda claro que los objetivos del proyecto no serán o no podrán ser alcanzados, o cuando la necesidad del proyecto ya no exista y el proyecto sea cancelado. Temporal no necesariamente significa de corta duración; muchos proyectos duran varios años. En cada caso, sin embargo, la duración de un proyecto es limitada. Los proyectos no son esfuerzos continuos. Además, temporal no es aplicable generalmente al producto, servicio o resultado creado por el proyecto. La mayoría de los proyectos se emprenden para obtener un resultado duradero. Por ejemplo, un proyecto para erigir un monumento nacional creará un resultado que se espera que perdure durante siglos. Con frecuencia, los proyectos también pueden generar impactos sociales, económicos y ambientales, intencionales o no, que perduran mucho más que los propios proyectos.

25 13 La naturaleza temporal de los proyectos puede aplicarse también a otros aspectos de la empresa: La oportunidad o ventana de negocio normalmente es temporal: algunos de los proyectos tienen un período limitado para producir sus productos o servicios. El equipo del proyecto, como unidad de trabajo, pocas veces perdura después del proyecto: un equipo creado con el único fin de llevar a cabo un proyecto lo desarrollará y luego se disolverá, y los miembros del equipo serán reasignados una vez que concluya el proyecto. Productos, Servicios o Resultados Únicos Un proyecto crea entregables únicos. Los proyectos pueden crear: Un producto o artículo, que es cuantificable y que puede ser un elemento terminado o un componente. La capacidad de prestar un servicio como, por ejemplo, la capacidad de formular y echar a andar las funciones del negocio que respaldan la producción o la distribución. Un resultado como, por ejemplo, salidas o documentos. Por ejemplo, de un proyecto de investigación se obtienen conocimientos que pueden usarse para determinar si existe o no una tendencia o si un nuevo proceso beneficiará a la sociedad. La singularidad es una característica importante de los entregables de un proyecto. Por ejemplo, se han construido muchos miles de edificios de oficinas, pero cada edificio individual es único: diferente propietario, diferente diseño, diferente ubicación, diferente contratista, etc. La presencia de elementos repetitivos no cambia la condición fundamental de único del trabajo resultante.

26 14 Elaboración Gradual La elaboración gradual es una característica de los proyectos que acompaña a los conceptos de temporal y único. Elaboración gradual significa desarrollar en pasos e ir aumentando mediante incrementos. Por ejemplo, el alcance de un proyecto se define de forma general al comienzo del proyecto y se hace más explícito y detallado a medida que el equipo del proyecto desarrolla un mejor y más completo entendimiento de los objetivos y de los productos entregables. La elaboración gradual no debe confundirse con la corrupción del alcance. La elaboración gradual de las especificaciones de un proyecto debe ser coordinada cuidadosamente con la definición adecuada del alcance del proyecto, particularmente si el proyecto se ejecuta en virtud de un contrato. Una vez definido correctamente el alcance del proyecto, el trabajo a realizar deberá controlarse a medida que se elaboran gradualmente las especificaciones del proyecto y del producto. Lo que indica es que la elaboración gradual de los proyectos se convierte en un común denominador, ya que mientras más avanza el proyecto y se desarrollan las tareas propias de los objetivos planteados, más se acerca al resultado final o productos esperado. Una oficina de gestión de proyectos (PMO), debe contar con el personal que tenga la capacidad de crecer intelectualmente, además que su rendimiento a medida que el proyecto transcurre vaya mejorando hasta proceso de culminación Administración de Proyectos En esencia, la dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para cumplir con los requisitos del mismo (PMI, 2008).

27 15 La dirección de proyectos es una tarea integradora que requiere que cada proceso del producto y del proyecto esté alineado y conectado de manera adecuada con los demás procesos, a fin de facilitar la coordinación (PMI, 2008). La administración de proyectos, en su forma moderna, comenzó a afianzarse hace sólo unas décadas. A partir de principios de los años sesenta, las empresas y organizaciones comenzaron a observar las ventajas de organizar el trabajo en forma de proyectos. Esta perspectiva de organización centrada en proyectos evolucionó aún más cuando las organizaciones empezaron a entender la necesidad fundamental de que sus empleados se comuniquen y colaboren entre sí al tiempo que integran su trabajo en diferentes departamentos, profesiones y, en algunos casos, industrias completas. Según Microsoft (2013) Podemos remontarnos aún más atrás, a la segunda mitad del siglo XIX, cuando el mundo empresarial comenzaba a ser cada vez más complejo, para observar cómo la administración de proyectos evolucionó a partir de principios básicos de administración. Los proyectos gubernamentales a gran escala fueron el impulso para tomar decisiones importantes que se convirtieron en la base de la metodología de la administración de proyectos. Por ejemplo, en los Estados Unidos, el primer proyecto verdaderamente grande del gobierno fue el ferrocarril transcontinental, cuya construcción comenzó en los años sesenta del siglo XIX. De repente, los líderes empresariales debieron enfrentarse a la enorme tarea de organizar el trabajo manual de miles de trabajadores, además del procesamiento y montaje de las materias primas en cantidades sin precedentes. Entre finales del siglo XIX y principios del XX, se comenzaron a realizar estudios detallados del trabajo, se aplicó el razonamiento científico y se demostró que el trabajo puede analizarse y mejorarse si se centra en las partes fundamentales. Se

28 16 puso en práctica las ideas en las tareas realizadas en las fundiciones de acero como recoger arena con la pala y levantar y trasladar piezas. Anteriormente, la única manera de mejorar la productividad era exigir a los trabajadores más esfuerzo y más horas de trabajo. También se presentó el concepto de trabajar con más eficiencia en lugar de más esfuerzo y tiempo. A la vez se estudió detalladamente el orden de las operaciones en el trabajo. Los estudios de administración se centraron en la construcción de embarcaciones para la marina durante la Primera Guerra Mundial. Los diagramas de Gantt, que contienen barras de tareas y marcadores de hitos, describen la secuencia y duración de todas las tareas de un proceso. Los diagramas de Gantt demostraron ser una herramienta analítica tan eficaz para los gerentes que se mantuvieron prácticamente sin cambios durante casi cien años. A comienzos de los años noventa del siglo XX, Microsoft Office Project agregó por primera vez líneas de vínculo a estas barras de tareas, que representan de manera más precisa las dependencias entre las tareas. A mediados del siglo XX, durante la Segunda Guerra Mundial, los complejos proyectos militares y gubernamentales, además del suministro reducido de mano de obra en época de guerra, exigieron nuevas estructuras organizativas. Se presentaron diagramas de red complejos, denominados diagramas de red y el método de ruta crítica; esto permitió a los administradores tener más control sobre proyectos muy complejos y con un alto grado de ingeniería (como sistemas de armamento militar con su enorme variedad de tareas e interacciones numerosas en muchos momentos).

29 17 Para el año 1969 se fundó el Project Management Institute (PMI, 2008), cuyo objetivo es impulsar la excelencia en la administración de proyectos, obtener un reconocimiento mundial mediante el profesionalismo de esta disciplina y establecer buenas prácticas en la Administración de Proyectos. Según el PMI (PMI, 2008, p. 5), La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades del proyecto para satisfacer los requerimientos del proyecto.. En 1996 el PMI logra el desarrollo, publicación y distribución de una norma reconocida para la Administración de Proyectos: A Guide to the Project Management Body of Knowledge, conocida como la Guía del PMBOK. El PMBOK es una guía de mejores prácticas y como tal no implica la aplicación de los conocimientos descritos en forma uniforme en todos los proyectos. Bajo la responsabilidad del equipo de dirección del proyecto está la tarea de establecer lo más apropiado para cada proyecto. Su finalidad principal es identificar el subconjunto de Fundamentos de la Dirección de Proyectos generalmente reconocido como buenas prácticas y generalmente aplicables a la mayoría de los proyectos, sobre las cuales existe un amplio consenso sobre el valor y utilidad. La Guía del PMBOK (PMI, 2008) se ha convertido en una herramienta básica para los administradores de proyectos. Actualmente, el considerar a una empresa como el organismo de un ser humano implica que, para que un negocio pueda sobrevivir y prosperar, todas sus piezas funcionales deben trabajar en conjunto hacia objetivos o proyectos específicos. En las décadas posteriores a los años sesenta, este enfoque hacia la administración de proyectos comenzó a afianzarse en sus formas modernas.

30 Ciclo de Vida de un Proyecto Los proyectos son la conformación de un conjunto de fases, en muchos de los casos secuenciales, que conectan por medio de un inicio y un fin. Esta descomposición del proyecto en etapas graduales se justifica en la necesidad de simplificar los entregables. La estructura simple del ciclo de vida del proyecto sin importar el tamaño o complejidad, está compuesta por las fases de inicio, planificación, ejecución y cierre. Algunas características del ciclo de vida son: Define las actividades de cada fase. Define los criterios de aceptación de los subproductos y entregables. Define los recursos necesarios para cada fase del proyecto. Define los controles y monitoreo de cada fase. Normalmente, el ciclo de vida del proyecto está contenido dentro de uno o más ciclos de vida del producto. Debe tenerse cuidado en diferenciar el ciclo de vida del proyecto del ciclo de vida del producto. Todos los proyectos tienen un propósito u objetivo, pero en aquellos casos donde el objetivo es un servicio o resultado, puede haber un ciclo de vida para el servicio o resultado, pero no un ciclo de vida del producto (PMI, 2008) Procesos en la Administración de Proyectos Un proceso es un conjunto de acciones y actividades interrelacionadas realizadas para obtener un producto, resultado o servicio predefinido. Cada proceso se caracteriza por sus entradas, por las herramientas y técnicas que puedan aplicarse y por las salidas que se obtienen (PMI, 2008).

31 19 En el PMI (2008) se presentan cinco grupos de procesos de la dirección de proyectos tal como se muestra en la Figura 2: Iniciación: Define los objetivos del proyecto, identifica a los interesados, se nombra al director del Proyecto y se autoriza formalmente el inicio del proyecto. Planificación: Define el alcance del proyecto, se verifican los objetivos y se desarrolla el Plan para la Dirección del Proyecto. Ejecución: Integran todos los recursos a fin de implementar el Plan para la Dirección del Proyecto. Monitoreo y Control: Supervisa el avance del proyecto y se aplican acciones de corrección. Cierre: Se acepta los entregables del proyecto. Figura 2 - Procesos de la Administración de Proyectos Fuente: Elaboración Propia basada en PMBOK (2008) Áreas de Conocimiento de la Administración de Proyectos A continuación se describen las nueve áreas de conocimiento que se incluyen en la Guía del PMBOK Gestión de la Integración La 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 la dirección de proyectos dentro de los grupos de procesos de dirección de proyectos (PMI, 2008).

32 20 Los procesos de Gestión de la Integración según PMI 2008 son: Desarrollar el Acta de Constitución del Proyecto: Es el proceso que consiste en desarrollar un documento que autoriza formalmente un proyecto. Desarrollar el Plan para la Dirección del Proyecto: Es el proceso que consiste en documentar las acciones necesarias para definir, preparar, integrar y coordinar todos los planes subsidiarios. Dirigir y Gestionar la Ejecución del Proyecto: Es el proceso que consiste en ejecutar el trabajo definido en el plan para la dirección del proyecto para cumplir con los objetivos del mismo. Monitorear y Controlar el Trabajo del Proyecto: Es el proceso que consiste en monitorear, revisar y regular el avance a fin de cumplir con los objetivos de desempeño definidos en el plan para la dirección del proyecto. Realizar el Control Integrado de Cambio: Es el proceso que consiste en revisar todas las solicitudes de cambio, y en aprobar y gestionar los cambios en los entregables, en los activos de los procesos de la organización, en los documentos del proyecto y en el plan para la dirección del proyecto. Cerrar Proyecto o Fase: Es el proceso que consiste en finalizar todas las actividades en todos los grupos de procesos de dirección Gestión del Alcance La Gestión del Alcance del Proyecto incluye los procesos necesarios para garantizar que el proyecto incluya todo (y únicamente todo) el trabajo requerido para completarlo con éxito. El objetivo principal de la Gestión del Alcance del Proyecto es definir y controlar qué se incluye y qué no se incluye en el proyecto (PMI, 2008).

33 21 Los procesos de Gestión del Alcance según PMI 2008 son: Recopilar Requisitos: Es el proceso que consiste en definir y documentar las necesidades de los interesados a fin de cumplir con los objetivos del proyecto. Definir el Alcance: Es el proceso que consiste en desarrollar una descripción detallada del proyecto y del producto. Crear la EDT: Es el proceso que consiste en subdividir los entregables y el trabajo del proyecto en componentes más pequeños y más fáciles de manejar. Verificar el Alcance: Es el proceso que consiste en formalizar la aceptación de los entregables del proyecto que se han completado. Controlar el Alcance: Es el proceso que consiste en monitorear el estado del alcance del proyecto y del producto, y en gestionar cambios a la línea base del alcance Gestión del Tiempo La Gestión del Tiempo del Proyecto incluye los procesos requeridos para administrar la finalización del proyecto a tiempo (PMI, 2008).

34 22 Los procesos de Gestión del Tiempo según PMI 2008 son: Definir las Actividades: Es el proceso que consiste en identificar las acciones específicas a ser realizadas para elaborar los entregables del proyecto. Secuenciar las Actividades: Es el proceso que consiste en identificar y documentar las interrelaciones entre las actividades del proyecto. Estimar los Recursos de las Actividades: Es el proceso que consiste en estimar el tipo y las cantidades de materiales, personas, equipos o suministros requeridos para ejecutar cada actividad. Estimar la Duración de las Actividades: Es el proceso que consiste en establecer aproximadamente la cantidad de períodos de trabajo necesarios para finalizar cada actividad con los recursos estimados. Desarrollar el Cronograma: Es el proceso que consiste en analizar la secuencia de las actividades, su duración, los requisitos de recursos y las restricciones del cronograma para crear el cronograma del proyecto. Controlar el Cronograma: Es el proceso por el que se da seguimiento al estado del proyecto para actualizar el avance del mismo y gestionar cambios a la línea base del cronograma Gestión de los Costos La Gestión de los Costos del Proyecto incluye los procesos involucrados en estimar, presupuestar y controlar los costos de modo que se complete el proyecto dentro del presupuesto aprobado (PMI, 2008). Los procesos de Gestión de los Costos según PMI 2008 son: Estimar los Costos: Es el proceso que consiste en desarrollar una aproximación de los recursos financieros necesarios para completar las actividades del proyecto.

35 23 Determinar el Presupuesto: Es el proceso que consiste en sumar los costos estimados de actividades individuales o paquetes de trabajo para establecer una línea base de costo autorizada. Controlar los Costos: Es el proceso que consiste en monitorear la situación del proyecto para actualizar el presupuesto del mismo y gestionar cambios a la línea base de costo Gestión de la Calidad La Gestión de la Calidad del Proyecto incluye los procesos y actividades de la organización ejecutante que determinan responsabilidades, objetivos y políticas de calidad a fin de que el proyecto satisfaga las necesidades por las cuales fue emprendido (PMI, 2008). Implementa el sistema de gestión de calidad por medio de políticas y procedimientos, con actividades de mejora continua de los procesos llevados a cabo durante todo el proyecto, según corresponda (PMI, 2008). Los procesos de Gestión de Calidad según PMI 2008 son: Planificar la Calidad: Es el proceso por el cual se identifican los requisitos de calidad y/o normas para el proyecto y el producto, documentando la manera en que el proyecto demostrará el cumplimiento con los mismos. Realizar el Aseguramiento de Calidad: Es el proceso que consiste en auditar los requisitos de calidad y los resultados de las medidas de control de calidad, para asegurar que se utilicen las normas de calidad apropiadas y las definiciones operacionales. Realizar el Control de Calidad: Es el proceso por el que se monitorean y registran los resultados de la ejecución de actividades de control.

36 Gestión de los Recursos Humanos La Gestión de los Recursos Humanos del Proyecto incluye los procesos que organizan, gestionan y conducen el equipo del proyecto. El equipo del proyecto está conformado por aquellas personas a las que se les han asignado roles y responsabilidades para completar el proyecto (PMI, 2008). Los procesos de Gestión de los Recursos Humanos según PMI 2008 son: Desarrollar el Plan de Recursos Humanos: Es el proceso por el cual se identifican y documentan los roles dentro de un proyecto, las responsabilidades, las habilidades requeridas y las relaciones de comunicación, y se crea el plan para la dirección de personal. Adquirir el Equipo del Proyecto: Es el proceso por el cual se confirman los recursos humanos disponibles y se forma el equipo necesario para completar las asignaciones del proyecto. Desarrollar el Equipo del Proyecto: Es el proceso que consiste en mejorar las competencias, la interacción de los miembros del equipo y el ambiente general del equipo para lograr un mejor desempeño del proyecto. Dirigir el Equipo del Proyecto: Es el proceso que consiste en dar seguimiento al desempeño de los miembros del equipo, proporcionar retroalimentación, resolver problemas y gestionar cambios a fin de optimizar el desempeño del proyecto Gestión de las Comunicaciones La Gestión de las Comunicaciones del Proyecto incluye los procesos requeridos para garantizar que la generación, la recopilación, la distribución, el almacenamiento, la recuperación y la disposición final de la información del proyecto sean adecuados y oportunos (PMI, 2008).

37 25 Los procesos de Gestión de Recursos Humanos según PMI 2008 son: Identificar a los Interesados: Es el proceso que consiste en identificar a todas las personas u organizaciones impactadas por el proyecto, y documentar información relevante relativa a sus intereses, participación e impacto en el éxito del mismo. Planificar las Comunicaciones: Es el proceso para determinar las necesidades de información de los interesados en el proyecto y definir cómo abordar las comunicaciones con ellos. Distribuir la Información: Es el proceso de poner la información relevante a disposición de los interesados en el proyecto, de acuerdo con el plan establecido. Gestionar las Expectativas de los Interesados: Es el proceso de comunicarse y trabajar en conjunto con los interesados para satisfacer sus necesidades y abordar los problemas conforme se presentan. Informar el Desempeño: Es el proceso de recopilación y distribución de la información sobre el desempeño, incluyendo los informes de estado, las mediciones del avance y las proyecciones Gestión de los Riesgos La Gestión de los Riesgos del Proyecto incluye los procesos relacionados con llevar a cabo la planificación de la gestión, la identificación, el análisis, la planificación de respuesta a los riesgos, así como su monitoreo y control en un proyecto. Los objetivos de la Gestión de los Riesgos del Proyecto son aumentar la probabilidad y el impacto de eventos positivos, y disminuir la probabilidad y el impacto de eventos negativos para el proyecto (PMI, 2008).

38 26 Los procesos de Gestión de los Riesgos según PMI 2008 son: Planificar la Gestión de los Riesgos: Es el proceso por el cual se define cómo realizar las actividades de gestión de los riesgos para un proyecto. Identificar los Riesgos: Es el proceso por el cual se determinan los riesgos que pueden afectar el proyecto y se documentan sus características. Realizar el Análisis Cualitativo de Riesgos: Es el proceso que consiste en priorizar los riesgos para realizar otros análisis o acciones posteriores, evaluando y combinando la probabilidad de ocurrencia y el impacto de dichos riesgos. Realizar el Análisis Cuantitativo de Riesgos: Es el proceso que consiste en analizar numéricamente el efecto de los riesgos identificados sobre los objetivos generales del proyecto. Planificar la Respuesta a los Riesgos: Es el proceso por el cual se desarrollan opciones y acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto. Monitorear y Controlar los Riesgos: Es el proceso por el cual se implementan planes de respuesta a los riesgos, se rastrean los riesgos identificados, se monitorean los riesgos residuales, se identifican nuevos riesgos y se evalúa la efectividad del proceso contra riesgos a través del proyecto Gestión de las Adquisiciones La Gestión de las Adquisiciones del Proyecto incluye los procesos de compra o adquisición de los productos, servicios o resultados que es necesario obtener fuera del equipo del proyecto. La organización puede ser la compradora o vendedora de los productos, servicios o resultados de un proyecto. La Gestión de las Adquisiciones del Proyecto incluye los procesos de gestión del contrato y de control de cambios requeridos para desarrollar y administrar contratos u órdenes de compra emitidas por miembros autorizados del equipo del proyecto. La Gestión

39 27 de las Adquisiciones del Proyecto también incluye la administración de cualquier contrato emitido por una organización externa (el comprador) que esté adquiriendo el proyecto a la organización ejecutante (el vendedor), así como la administración de las obligaciones contractuales contraídas por el equipo del proyecto en virtud del contrato (PMI, 2008). Los procesos de Gestión de adquisiciones según PMI 2008 son: Planificar las Adquisiciones: Es el proceso de documentar las decisiones de compra para el proyecto, especificando la forma de hacerlo e identificando a posibles vendedores. Efectuar las Adquisiciones: Es el proceso de obtener respuestas de los vendedores, seleccionar un vendedor y adjudicar un contrato. Administrar las Adquisiciones: Es el proceso de gestionar las relaciones de adquisiciones, monitorear la ejecución de los contratos, y efectuar cambios y correcciones según sea necesario. Cerrar las Adquisiciones: Es el proceso de completar cada adquisición para el proyecto. 2.3 Modelos de Madurez Los modelos de madurez son métodos de evaluación a los procesos de una empresa. Estos fueron desarrollados por el SEI (Software Engineering Institute) y se encontraban orientados al desarrollo de software en sus inicios Definición de Madurez El término madurez es una referencia que indica el grado de desarrollo o experiencia de la organización para realizar o lograr algo. La madurez es un atributo de las organizaciones que trabajan siguiendo procesos homogéneamente implantados, definidos con mayor o menor rigor, conocidos y ejecutados por todos

40 28 los equipos, así como medidos y mejorados de forma constante. Definición de madurez según Kerzner: Es el desarrollo de sistemas y procesos que son repetitivos y ofrecen una alta probabilidad de que cada proyecto sea un éxito. Los procesos y sistemas repetitivos no garantizan el éxito. Simplemente aumentan la probabilidad de éxito (Kerzner, 2004, pág. 32) Modelo de Madurez de Capacidad Integrado CMMI (Modelo de Madurez de Capacidad Integrado) pertenece a la familia de modelos desarrollados por el SEI, para evaluar las capacidades de las organizaciones de ingeniería de sistemas, ingeniería de software, además del desarrollo integrado del producto y del proceso. CMMI es un modelo descriptivo que detalla los atributos esenciales que deberían caracterizar a una organización en un determinado nivel de maduración. Es importante destacar que muchos modelos están principalmente basados en los conceptos del modelo CMM (Modelo de Madurez de Capacidad) desarrollado por el SEI, además, incorpora elementos de la guía del PMBOK. Los modelos presentan por lo general una estructura de cinco niveles para categorizar el estado de madurez de una organización. Desde un nivel uno (ausencia casi total de procesos y conciencia del problema) hasta un nivel cinco que indica una total ejecución de los procesos y un estado de mejora permanente. En la Figura 3 se muestra como está diseñada la escala de niveles.

41 29 Figura 3 - Niveles de Madurez Fuente: Elaboración Propia Es un modelo normativo donde las prácticas detalladas caracterizan los tipos normales de comportamiento esperables en una organización que ejecuta proyectos a gran escala. La mejora continua de los procesos se basa en muchos pasos pequeños y evolutivos en vez de innovaciones revolucionarias. CMMI proporciona un marco para organizar estos pasos evolutivos dentro de cinco niveles de maduración que sientan fundamentos sucesivos para la mejora continua del proceso. Niveles de Madurez Un Nivel de Madurez es una plataforma evolutiva bien definida destinada a lograr un proceso de software maduro. Cada nivel de madurez proporciona una capa en los cimientos para un proceso de mejora continua. Cada nivel comprende un conjunto de objetivos que, una vez alcanzados, estabilizan un componente importante del proceso de software. Al alcanzar cada nivel del marco de madurez se establece un componente diferente en el proceso de software, resultando en un incremento en la capacidad de proceso de la

42 30 organización. Cabe decir que los niveles de madurez en una empresa se empiezan a medir desde el nivel 2, ya que el nivel 1 de madurez trata de la conformación de la empresa como tal. Nivel de Madurez 2 - Administrado: En el nivel Administrado de madurez la empresa asegura que sus procesos pasan por todos los puntos fundamentales del aseguramiento de la calidad. Todas las fases son definidas y documentadas. Todos los objetivos establecidos son realizados y entregados a tiempo. Nivel de Madurez 3 - Definido: En el nivel Definido los procesos ya son definidos, este cumple con todos los estándares definidos por la empresa, y en cada momento aporta medidas para el mejoramiento de los procesos. La diferencia entre un nivel Administrado y un Nivel Definido es el enfoque, ya que un nivel Administrado se enfoca en los proyectos mientras que el nivel Definido se enfoca en los estándares de la compañía. Nivel de Madurez 4 - Cuantitativamente Administrado: En el nivel Cuantitativamente Administrado los procesos son controlados usando métodos estadísticos y técnicas cuantitativas. Se establecen objetivos de calidad y rendimiento, los cuales son usados como criterio para administrar los procesos. La diferencia entre el nivel Definido y el Nivel Cuantitativamente Administrado es el nivel de rendimiento de los procesos que son estadísticamente predecibles. Nivel de Madurez 5 - Nivel Optimizado: En el nivel Optimizado los procesos son mejorados continuamente en base a las causas comunes de variación. Su enfoque es la mejora continua del rendimiento a través de mejoras innovadoras. La diferencia entre el nivel Cuantitativamente Administrado y el Nivel Optimizado son los tipos de variación a las que se dirige.

43 31 CMMI, como todo modelo de mejora de procesos, proporciona beneficios a las organizaciones que los utilizan: Mayor fiabilidad de las planificaciones (estimaciones basadas en hechos). Reducción de retrabajos. Acuerdos claros sobre el servicio y la funcionalidad del producto a entregar. Cumplimiento de fechas. Visibilidad sobre el proceso y sobre el producto. Utilización de estándares documentados. Personal formado. Reducción de errores. Mayor calidad de los productos entregados. Gestión ordenada de los acuerdos y contratos con proveedores. 2.4 Scrum Scrum es un marco de trabajo estructurado para dar soporte al desarrollo de productos complejos. Scrum consiste en los Equipos Scrum y en sus roles, eventos, artefactos y reglas asociadas. Cada componente dentro del marco de trabajo sirve a un propósito específico y es esencial para el éxito de Scrum y para su uso (Guía Scrum, 2013). En la Figura 4 se muestra cual es comportamiento del Flujo Scrum para un Sprint.

44 32 Figura 4 - Flujo Scrum para un Sprint Fuente: Elaboración Propia Scrum comprende un conjunto de componentes que, una vez estén implementados, brindan una gran solidez al marco de trabajo y a una buena implementación del marco de desarrollo ágil. A continuación se describen los diferentes componentes de SCRUM El Equipo Scrum (Scrum Team) El equipo Scrum es el encargado de recopilar los roles propios del marco de trabajo, dando a cada uno sus funciones puntuales para el mejor provecho de éste. Los equipos de Scrum son los encargados del desarrollo del producto de forma incremental y maximizada, esto se refiriere que en cada Entrega el equipo mejora las no conformidades del cliente e implementa las lecciones aprendidas de cada entrega.

45 33 Los actores del Equipo Scrum son: El Dueño de Producto (Product Owner) Es el responsable de maximizar el valor del producto y del trabajo del Equipo de Desarrollo. El cómo se lleva esto a cabo puede variar ampliamente entre distintas organizaciones, Equipos Scrum, e individuos (Guía Scrum, 2013). El Dueño de Producto puede hacer el trabajo anterior, o delegarlo en el Equipo de Desarrollo. Sin embargo, en ambos casos el Dueño de Producto sigue siendo el responsable de dicho trabajo. El Dueño de Producto es aquel quien explica el qué se debe hacer y cuándo se debe entregar, para cumplir con las demandas del cliente. Adicionalmente el Dueño de Producto es quien verifica el estado de los requerimientos solicitados, se preocupa que estos sean claros, y bien definidos para que todo el equipo Scrum lo entienda. El Equipo de Desarrollo (Development Team) Consiste en los profesionales que desempeñan el trabajo de entregar un Incremento de producto Hecho, potencialmente utilizable, al final de cada Sprint. Sólo los miembros del Equipo de Desarrollo participan en la creación del Incremento (Guía Scrum, 2013). Los Equipos de Desarrollo son capaces de gestionar su propio trabajo, son autoorganizados y multifuncionales. Para el marco de trabajo Scrum un desarrollador es cualquier elemento del equipo con habilidades, no existe nivel jerárquico entre los Scrum Developers. Aunque todos tienen asignaciones independientes si algo no resulta la responsabilidad es del Equipo de Desarrollo en conjunto. Es recomendable para un Equipo de Desarrollo un tamaño de dos (2)

46 34 a seis (6) miembros, esto con el fin de mantener un óptimo desempeño en el equipo, lo suficiente para permanecer en el ámbito ágil. El Scrum Master Es el responsable de asegurar que Scrum es entendido y llevado a cabo. 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. El Scrum Master es un líder servil, al servicio del Equipo Scrum (Guía Scrum, 2013). El Scrum Master no necesariamente debe ser el miembro de la compañía con más habilidades técnicas, este debe ser un rol de ayuda en el cual es necesario tener habilidades técnicas, pero no a un nivel elevado. El Scrum Master ayuda a encontrar técnicas para gestionar los elementos de un entregable de manera más efectiva, comunica al Equipo de Desarrollo el alcance de los objetivos pactados para una entrega, enseña el concepto de agilidad a todo el equipo, es quien lidera la implementación de Scrum en la empresa Eventos de Scrum En la teoría de Scrum ya hay existencia de eventos prescritos, con el fin de minimizar el número de reuniones que hacen parte del Scrum diario. Esto asegura una buena gestión del tiempo y que no se realice reproceso en la planificación.

47 35 Los elementos de los Eventos Scrum son: El Sprint Es la arteria vital de Scrum, es un período de tiempo comprendido de una (1) a cuatro (4) semanas, durante el cual se realiza un entregable del producto. Un Sprint debe iniciar cada vez que se termine uno previo. Algo que caracteriza los Sprint es que ya iniciado no se realizan cambios que afectarían al Objetivo del Sprint, el Equipo de Desarrollo se mantiene constante y el alcance puede ser clarificado y renegociado entre el Dueño de Producto y el Equipo de Desarrollo a medida que se va aprendiendo más. Cancelación de un Sprint Un Sprint puede ser cancelado antes de que el bloque de tiempo llegue a su fin. Sólo el Dueño de Producto tiene la autoridad para cancelar el Sprint, aunque puede hacerlo bajo la influencia de los interesados, del Equipo de Desarrollo o del Scrum Master. Un Sprint sería cancelado si el Objetivo del Sprint se quedase obsoleto. Esto podría ocurrir si cambiase la dirección de la compañía, o si cambiasen las condiciones del mercado o de la tecnología. En general, un Sprint debería cancelarse si no tuviese sentido seguir con él dadas las circunstancias. Pero debido a la corta duración de los Sprints, es muy extraño que la cancelación realmente tenga sentido. Reunión de Planificación de Sprint (Sprint Planning Meeting) El trabajo a realizar durante el Sprint es planificado en la Reunión de Planificación de Sprint. Este plan es creado mediante el trabajo colaborativo del Equipo Scrum al completo.

48 36 La Reunión de Planificación de Sprint está restringida a una duración de ocho horas para un Sprint de un mes. Para Sprints más cortos, el evento es proporcionalmente más corto. Por ejemplo, los Sprints de dos semanas tienen una Reunión de Planificación de Sprint de cuatro horas. Objetivo del Sprint (Sprint Goal) El Objetivo del Sprint proporciona al Equipo de Desarrollo algo de flexibilidad en relación a la funcionalidad que se implementa en el Sprint. A medida que el Equipo de Desarrollo va trabajando, mantiene este objetivo en mente. Para satisfacer el Objetivo del Sprint, implementa la funcionalidad y tecnología necesarias. Si el trabajo resulta ser diferente del que el Equipo de Desarrollo esperaba, colaboran con el Dueño de Producto para negociar el alcance de la Pila de Sprint dentro del Sprint. El Objetivo de Sprint puede constituir un hito en el marco de la hoja de ruta de propósito más amplio del producto. Scrum Diario (Daily Scrum) El Scrum Diario es una reunión restringida a 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 predicción acerca del trabajo que podría ser completado antes del siguiente. Revisión de Sprint (Sprint Review) Al final del Sprint se lleva a cabo una Revisión de Sprint, para inspeccionar el Incremento y adaptar la Pila de Producto si fuese necesario. Durante la Revisión de Sprint, el Equipo Scrum y los interesados colaboran acerca de lo que se ha hecho durante el Sprint. Basándose en eso, y en cualquier cambio a la Pila de

49 37 Producto hecho durante el Sprint, los asistentes colaboran para determinar las siguientes cosas que podrían hacerse. Se trata de una reunión informal, y la presentación del Incremento tiene como objetivo facilitar la retroalimentación de información y fomentar la colaboración. Retrospectiva de Sprint (Sprint Retrospective) La Retrospectiva de 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. La Retrospectiva de Sprint tiene lugar después de la Revisión de Sprint y antes de la siguiente Reunión de Planificación de Sprint. Se trata de una reunión restringida a un bloque de tiempo de tres horas para Sprints de un mes. Para Sprints más cortos se reserva un tiempo proporcionalmente menor Artefactos de Scrum Los artefactos de Scrum representan trabajo o valor en diversas formas que son útiles para proporcionar transparencia y oportunidades para la inspección y adaptación. Los artefactos definidos por Scrum, están específicamente diseñados para maximizar la transparencia de la información clave, que es necesaria para asegurar que los Equipos Scrum tengan éxito al entregar un Incremento Hecho (Guía Scrum, 2011). Los Artefactos de Scrum son: Pila de Producto (Product Backlog) La Pila de Producto es una lista ordenada de todo lo que podría ser necesario en el producto, y es la única fuente de requerimientos para cualquier cambio a realizarse en el producto. El Dueño de Producto (Product Owner) es el

50 38 responsable de la Pila de Producto, incluyendo su contenido, disponibilidad y ordenación. Una Pila de Producto nunca está completa. El desarrollo más temprano de la misma sólo prepara los requerimientos conocidos inicialmente y mejor entendidos. La Pila de Producto evoluciona a medida de que el producto y el entorno en el que será usado también lo hacen. La Pila de Producto es dinámica; cambia constantemente para identificar lo que el producto necesita para ser adecuado, competitivo y útil. Mientras el producto exista, su Pila de Producto también existe. Seguimiento del Progreso Hacia un Objetivo En cualquier momento, es posible sumar el trabajo total restante para alcanzar el objetivo. El Dueño de Producto hace seguimiento de este trabajo restante total al menos una vez por cada Revisión de Sprint. El Dueño de Producto compara esta cantidad con el trabajo restante en Revisiones de Sprint previas, para evaluar el progreso hacia la finalización del trabajo proyectado en el tiempo objetivo deseado. Esta información se muestra de forma transparente a todos los interesados. Pila de Sprint (Sprint Backlog) La Pila de Sprint es el conjunto de elementos de la Pila de Producto seleccionados para el Sprint, más un plan para entregar el Incremento de producto y conseguir el Objetivo del Sprint. La Pila de Sprint es una predicción hecha por el Equipo de Desarrollo acerca de qué funcionalidad formará parte del próximo Incremento y del trabajo necesario para entregar esa funcionalidad. Seguimiento del Progreso del Sprint En cualquier momento durante un Sprint, es posible sumar el trabajo restante total en los elementos de la Pila de Sprint. El Equipo de Desarrollo hace seguimiento de este trabajo restante total al menos una vez por cada Scrum Diario. El Equipo de

51 39 Desarrollo monitoriza estas sumas diariamente y proyecta la posibilidad de conseguir el Objetivo del Sprint. Haciendo seguimiento del trabajo restante a lo largo del Sprint, el Equipo de Desarrollo puede gestionar su progreso. Scrum no tiene en cuenta el tiempo empleado en trabajar en los elementos de la Pila de Sprint. El trabajo restante y la fecha son las únicas variables de interés. Incremento El Incremento es la suma de todos los elementos de la Pila de Producto completados durante un Sprint y durante todos los Sprints previos. Al final de un Sprint, la nueva parte del Incremento debe estar Hecha, lo cual significa que está en condiciones de ser utilizada y que cumple la Definición de Hecho del Equipo Scrum. Debe estar en condiciones de ser utilizada sin importar si el Dueño de Producto decide liberarla o no. Definición de Hecho (Definition of Done ) Cuando un elemento de la Pila de Producto o un Incremento es descrito como Hecho, todo el mundo debe entender lo que significa Hecho. 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. Ésta es la Definición de Hecho para el Equipo Scrum, y se utiliza para evaluar cuándo se ha completado el trabajo sobre el Incremento de producto (Guía Scrum, 2013).

52 40 3. MARCO METODOLÓGICO Son todos aquellos documentos o materiales que proporcionan información de valor a la investigación y a la solución propuesta. Las fuentes de información permiten recopilar la información necesaria para definir los lineamientos que se deben seguir para la actualización de una metodología ya impuesta en la empresa, tomando en cuenta los pasos necesarios para establecer procesos y herramientas a emplear en el desarrollo de software móvil con marcos de trabajo de desarrollo ágil. 3.1 Fuentes de Información Lugar donde se encuentran los datos requeridos, que posteriormente se pueden convertir en información útil para el investigador. Los datos son todos aquellos fundamentos o antecedentes que se requieren para llegar al conocimiento exacto de un objeto de estudio. Estos datos, que se deben recopilar de las fuentes, tendrán que ser suficientes para poder sustentar y defender un trabajo (Eyssautier, 2002). En el Cuadro 1 se muestra un análisis de fuentes de Informacion. Las fuentes de información, en fin, son todos aquellos recursos que disponemos para buscar, localizar e identificar información. Pueden desglosarse en: Fuentes de conocimiento: no están en un soporte físico, sino que son las ideas grabadas en nuestro cerebro como resultado de nuestro bagaje profesional. Fuentes documentales: son las que están en un soporte material permanente.

53 41 Fuentes relacionales: se refieren a la información que recibimos a través de la interrelación con otras personas (indicaciones de colegas, conferencias, conversaciones con expertos) (Universidad de Oviedo, 2013) Fuentes Primarias Se refiere a aquellos portadores originales de la información que no han retransmitido o grabado en cualquier medio o documento la información de interés. Esta información de fuentes primarias la tiene la población misma. Para extraer los datos de esta fuente se utiliza el método de encuesta, de entrevista, experimental o por observación (Eyssautier, 2002). Constituyen el objetivo de la investigación bibliográfica o revisión de la literatura y proporcionan datos de primera mano (Dankhe, 1976). Un ejemplo de éstas son los libros, antologías, artículos de publicaciones periódicas, tesis, documentos oficiales (Hernández, 1998) Fuentes Secundarias Se refieren a todos aquellos portadores de datos e información que han sido previamente retransmitidos o grabados en cualquier documento, y que utilizan el medio que sea. Esta información se encuentra a disposición de todo investigador que la necesite (Eyssautier, 2002). Son compilaciones, resúmenes y listados de referencias publicadas en un área de conocimiento en particular (son listados de fuentes primarias). Es decir, reprocesan información de primera mano. (Hernández, 1998).

54 42 Cuadro 1 - Fuentes de Información Utilizadas Fuente: Elaboración Propia. Objetivos Elaborar un análisis sobre la situación actual de la empresa Stack Pointer y su metodología de proyectos. Desarrollar un Plan de Gestión del Alcance para determinar los puntos que se deben afectar en la metodología actual e identificar las áreas que deben mejorar. Desarrollar un Plan de Gestión del Tiempo para determinar el cronograma de las actividades requeridas para incluir técnicas de desarrollo ágil sobre la metodología actual. Fuentes de información Primarias Secundarias Director de Proyectos, PMBOK (PMI, 2008) Consultor de Informes de lecciones Tecnología aprendidas de proyectos de los últimos tres (3) años. Explorar Fuentes Metodológicas en Otras Empresas Gerente, Director de PMBOK (PMI, 2008) Proyectos Gerente, Director de PMBOK (PMI, 2008) Proyectos

55 43 Desarrollar un Plan de Gestión de Calidad para asegurar y controlar los resultados del proyecto. Desarrollar un Plan de Gestión de Comunicaciones para dar conocimiento a los interesados del desarrollo del proyecto. Desarrollar un Plan de Gestión de Costos para estimar y presupuestar los recursos que se deben invertir para efectuar el proyecto. Diseñar un Plan de Gestión de Riesgo para aumentar las probabilidades de éxito del proyecto dentro del alcance, tiempo y costo establecido. Establecer lineamientos iniciales para la implementación de las mejoras en la metodología actual. Gerente, Director de Proyectos Gerente, Director de Proyectos Gerente, Director de Proyectos Gerente, Director de Proyectos Gerente, Director de Proyectos, Dirección de Soporte, Dirección de Desarrollo PMBOK (PMI, 2008) PMBOK (PMI, 2008) PMBOK (PMI, 2008) PMBOK (PMI, 2008) PMBOK (PMI, 2008) Guía de SCRUM (SCRUM, 2013) Documentación de Formatos (Stack Pointer, 2013)

56 Métodos de Investigación La Real Academia Española (2013) define: Metodología, Conjunto de métodos que se siguen en una investigación científica o en una exposición doctrinal. Investigación, que tiene por fin ampliar el conocimiento científico, sin perseguir, en principio, ninguna aplicación práctica. Revela Eyssautier (2002) El método es la ruta que se sigue en las ciencias para alcanzar un fin propuesto; y la metodología el cuerpo de conocimiento que describe y analiza los métodos para el desarrollo de una investigación. Ambos se han particularizado, y son objeto de un tratamiento especial de acuerdo con cada ciencia particular. Los métodos de investigación consisten en procedimientos definidos, que permiten descubrir y definir información que contribuyen al logro de un objetivo determinado. Versiones de métodos de investigación hay muchas que involucran procesos de análisis, síntesis, inducción y deducción Método Analítico El método analítico es aquel método de investigación que se basa en la desagregación de un todo, a nivel de sus elementos o componentes por separado, permitiendo observar las causas, naturaleza y efectos inherentes. Se centra en el conocimiento auto-correctivo y progresivo, y es el que caracteriza a las ciencias descriptivas.

57 45 El método sintético es un proceso de unificación racional de hechos aparentemente aislados, donde el investigador sintetiza las superaciones en la imaginación para establecer una explicación tentativa que someterá a prueba. La utilización del método analítico sintético, permite conocer la situación actual de la institución respecto a la gestión de los proyectos que desarrolla, con el fin que la información recopilada sea la base para la generación del plan de gestión de este proyecto (Eyssautier, 2002) Método Inductivo El método lógico inductivo es un método científico que saca conclusiones generales de algo particular, a través del desarrollo de algunas etapas importantes: observación y registro de todos los hechos, análisis de esos hechos y su clasificación, generalización a partir de los hechos y finalmente, realizar un proceso de contraste o comparación. De manera contraria al inductivismo, el método deductivo es de una lógica general a conclusiones particulares. Se divide en: Método deductivo directo de conclusión inmediata: Se obtiene el juicio de una sola premisa, es decir, que se llega a una conclusión directa sin intermediarios. Método deductivo indirecto o de conclusión mediata: La premisa mayor contiene la proposición universal, la premisa menor contiene la proposición particular, de su comparación resulta la conclusión. La utilización de estos métodos de investigación será relevante durante el desarrollo de este proyecto (Eyssautier, 2002).

58 Método de Observación Es un método para reunir información visual sobre un hecho ocurrido. La observación es, una actividad realizada por el ser humano para detectar y asimilar la información de un hecho, o el registro de datos utilizando instrumentos (Eyssautier, 2002). En el Cuadro 2 se muestran los métodos de investigación utilizados en el proyecto. Cuadro 2 - Métodos de Investigación Utilizadas Objetivos Elaborar un análisis sobre la situación actual de la empresa Stack Pointer y su metodología de proyectos. Desarrollar un Plan de Gestión del Alcance para determinar los puntos que se deben afectar en la metodología actual e identificar las áreas que deben mejorar. Fuente: Elaboración Propia. Métodos de Investigación Método Analítico Método Inductivo Método de Observación Análisis de No Aplica Directo e metodología Indirecto actual y obtención de datos relevantes para cambios. Observación por Análisis de Directo entrevista requerimientos

59 47 Desarrollar un Plan de Composición de Análisis de cada No Aplica Gestión del Tiempo para determinar el cronograma de las actividades requeridas para incluir técnicas de desarrollo ágil sobre la metodología actual. tareas y sub tareas en un cronograma tarea individual para determinar tiempos Desarrollar un Plan de Gestión de Calidad para Descomposición de Análisis de requerimientos de Directo e Indirecto asegurar y controlar los resultados del proyecto. requerimientos de calidad para crear lista de chequeo de calidad calidad del proyecto. Desarrollar un Plan de Elaboración de Análisis de No Aplica Gestión de Comunicaciones para dar conocimiento a los interesados del desarrollo del proyecto. lista de necesidades de comunicación herramientas actuales de comunicación Desarrollar un Plan de Composición de Análisis del No Aplica Gestión de Costos para estimar y presupuestar los recursos que se deben invertir para efectuar el proyecto. costos de tareas y sub tareas para elaboración del presupuesto presupuesto base Diseñar un Plan de Identificación de Matriz de No Aplica

60 48 Gestión de Riesgo para riesgos probabilidad e aumentar las impacto probabilidades de éxito del proyecto dentro del alcance, tiempo y costo establecido. Establecer lineamientos Observación del Con base a Scrum Indirecto iniciales para la Proceso se realizan implementación de las modificaciones mejoras en la que adopten las metodología actual. prácticas de desarrollo ágil. 3.3 Herramientas y Técnicas Para la recolección de la información necesaria para desarrollar el proyecto, se utilizarán las herramientas y técnicas que a continuación se detallan: Entrevista Es un método para recolección de datos, mediante la comunicación en un lugar determinado, entre dos o más personas con el único fin de tratar un tema acordado, logrando así la obtención de información para el trabajo en desarrollo.

61 Juicio Experto Cita el PMBOK (PMI, 2008) que el juicio experto es la experiencia proporcionada por todo grupo o individuo con conocimientos o capacitación especializados. Se encuentra en distintas fuentes que a continuación se detallan: Consultor de Tecnología, quien posee el conocimiento tecnológico sobre el tema. Consultor de Desarrollo, quien se enfrenta a diario con la metodología de proyectos y sus inconvenientes. Experto de Negocios Móviles, quien puede ilustrar sobre las tendencias del mercado. Interesados, quienes realizan la financiación del proyecto EDT La descomposición es la subdivisión de los entregables del proyecto en componentes más pequeños y más manejables, hasta que el trabajo y los entregables queden definidos a nivel de paquetes de trabajo. Se utilizará la herramienta en línea WBS Tool, que permite la creación de estructuras de desglose del trabajo Formularios o Plantillas Documentación de actividades que ha sido utilizada en proyectos previos de la organización y puede ser utilizada como plantilla para un nuevo proyecto, o creación de nuevas plantillas para este plan de gestión.

62 Software Conjunto de componentes lógicos necesarios para la realización de tareas específicas. Estos programas computacionales son herramientas que nos permiten realizar actividades del proyecto: Bizagi Process Modeler, programa que permite la realización de diagramas de flujo. Microsoft Word, programa diseñado para el procesamiento de textos. Microsoft Excel, programa que permite manejar hojas de cálculo. Microsoft Project, programa que permite manejar cronogramas de proyectos Diagramas de Flujo Es una representación gráfica de un proceso que muestra las relaciones entre las etapas del proceso Investigación Bibliográfica La investigación consiste en, lectura de documentos como: libros, especificaciones técnicas, revistas, sitios Web y otros archivos de la institución. En el Cuadro 3 se muestra que herramientas se utilizaran con respecto al objetivo planteado.

63 51 Cuadro 3 - Herramientas Utilizadas Fuente: Elaboración Propia. Objetivos Elaborar un análisis sobre la situación actual de la empresa Stack Pointer y su metodología de proyectos. Herramientas - Entrevistas - Juicio de Expertos - EDT - Diagramas de Flujo Desarrollar un Plan de Gestión del Alcance para determinar los puntos que se deben afectar en la metodología actual e identificar las áreas que deben mejorar. Desarrollar un Plan de Gestión del Tiempo para determinar el cronograma de las actividades requeridas para incluir técnicas de desarrollo ágil sobre la metodología actual. Desarrollar un Plan de Gestión de Calidad para asegurar y controlar los resultados del proyecto. Desarrollar un Plan de Gestión de Comunicaciones para dar conocimiento a los interesados del desarrollo del proyecto. - Formularios o Plantillas - Software - Formularios o Plantillas - Software - Formularios o Plantillas - Software - Formularios o Plantillas - Software

64 52 Desarrollar un Plan de Gestión de Costos para estimar y presupuestar los recursos que se deben invertir para efectuar el proyecto. Diseñar un Plan de Gestión de Riesgo para aumentar las probabilidades de éxito del proyecto dentro del alcance, tiempo y costo establecido. Establecer lineamientos iniciales para la implementación de las mejoras en la metodología actual. - Formularios o Plantillas - Software - Formularios o Plantillas - Software - Juicio de Expertos - Investigación Bibliográfica

65 53 4. DESARROLLO Este capítulo contiene los alcances de cada objetivo propuesto en el acta del proyecto y cuáles deben ser entregas para cumplir las metas del plan, con el fin de construir una línea base de la nueva implementación que se desea lograr en la empresa. Lo más importante es que esto conlleve al desarrollo y ejecución de manera ideal del proyecto. 4.1 Análisis de la Situación Actual La metodología actual de la empresa Stack Pointer está regida por el Modelo de Procesos para la Industria de Software (MoproSoft), la cual permite la estandarización de la operaciones a través de la incorporación de las mejores prácticas en gestión e ingeniería de software. La adopción del modelo permitió que Stack Pointer elevara la capacidad de ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad. Cuando el modelo MoproSoft fue implementado, Stack Pointer tenía claro el alcance de la metodología, la cual está dirigida a las empresas o áreas internas dedicadas al desarrollo y/o mantenimiento de software, también incluye las empresas, que no cuenten con procesos establecidos. Estas empresas pueden usar el modelo ajustándolo de acuerdo a sus necesidades. Mientras que las empresas, que ya tienen procesos establecidos, pueden usarlo como punto de referencia para identificar los elementos que les hace falta cubrir. El desarrollo y mantenimiento de software se lleva a cabo a través de una serie de actividades realizadas por equipos de trabajo. La Ingeniería de Software se ha dedicado a identificar las mejores prácticas para realizar estas actividades recopilando las experiencias exitosas de la industria de software a nivel mundial. Estas prácticas se han organizado por áreas de aplicación, y se han dado a

66 54 conocer como áreas clave de procesos, en caso de CMM, o como procesos de software en ISO/IEC El modelo utilizado en Stack Pointer está enfocado en procesos y considera los tres niveles básicos de la estructura de una organización que son: la Alta Dirección, Gestión y Operación. MoproSoft pretende apoyar a las empresas en la estandarización de sus prácticas, en la evaluación de su efectividad y en la integración de la mejora continua Herramientas De Gestión Actual En la actualidad en la empresa Stack Pointer se utiliza la herramienta Pointer Desk, la cual es una implementación de la herramienta Redmine, la cual es Open Source y permite la gestión de proyectos. Cada usuario de la empresa cuenta con un usuario y contraseña para el ingreso a la aplicación. Al momento de ingresar a la herramienta nos encontramos con la pantalla inicial, la cual nos muestra los últimos proyectos asignados a la persona conectada, tal como lo ilustra la Figura 5.

67 55 Figura 5 Pantalla Inicial de Pointer Desk Fuente: Elaboración Propia En la parte superior cuando hacemos clic sobre el vínculo My Page, este le redirige al resumen de actividades de cada usuario. La primera opción es verificar todas las actividades que cada usuario está realizando a lo largo de un mes tal como lo muestra la Figura 6.

68 56 Figura 6 Pantalla de Tareas Reportadas Fuente: Elaboración Propia Otras de las tantas utilidades que ofrece la herramienta es poder realizar seguimiento a tareas de usuarios. Esta utilidad se le llama visor de tareas la cual permite realizar una suscripción a una tarea específica y ver su seguimiento tal como se muestra en la Figura 7:

69 57 Figura 7 Pantalla de Seguimiento de Tareas Fuente: Elaboración Propia Al realizar clic sobre una de las actividades, la herramienta realiza una redirección a la página donde se muestra el detalle de la actividad seleccionada, ésta será visualizada como se ilustra en la Figura 8.

70 58 Figura 8 Pantalla de Actividad Seleccionada Fuente: Elaboración Propia Como se puede ver en la Figura 8, el detalle de la actividad es muy básico y éste sería uno de los inconvenientes de la herramienta con la metodología actual. Por otra parte sobre una actividad pueden existir tareas relacionadas, esto quiere decir que una activada puede ser un simple padre de muchas actividades tal como se muestra en la Figura 9. Figura 9 Pantalla de Actividades Relacionas Fuente: Elaboración Propia

71 59 Cuando se requiere crear una nueva actividad, la herramienta solicita ciertos datos obligatorios y otros que son de configuración personalizada. Los campos de configuración personalizada son muy vagos pero están relacionados con la metodología de proyectos actual tal como se muestra en la Figura 10. Figura 10 Pantalla de Creación de Nueva Actividad Fuente: Elaboración Propia Análisis Metodológico La metodología MoproSoft implementada en Stack Pointer, cumple con todas las necesidades básicas exigidas por la Alta Gerencia, sin embargo, se está quedando atrás comparada con los marcos de trabajo actuales. Aunque tiene muchas similitudes con la metodología CMMI, la cual en su máximo nivel, implementa la mejora continua, no obstante ésta no incluye procesos de métodos puntuales para las empresas de Software tales como Metodología de Programación Ágil, Metodologías para Selección de Tecnología, entre otras. Es muy cierto que las metodologías son muy flexibles para incluir todo tipo de métodos que contribuyan a su mejora continua. El propósito de realizar este análisis, es identificar las herramientas necesarias para crear una metodología que sea útil para todo tipo de proyecto relacionado

72 60 con el software y que permita realizar la integración con varias metodologías que sean complementarias a la que se encuentra implementada en la empresa Stack Pointer. Este plan nos ayudará a buscar e implementar mejoras substanciales que permitan la mejora en la ejecución de los proyectos con respecto a la metodología que se está llevando actualmente Puntos Críticos de Mejora Después del análisis realizado se detectaron los puntos críticos en los cuales la Metodología Moprosoft no cumple con las políticas de metodologías avanzadas para el desarrollo de software moderno. A continuación se listan los puntos que se deben mejorar: Incluir Líder Técnico en Propuesta de Licitatorias: Stack Pointer ha perdido en varias ocasiones licitaciones con grandes clientes por tener un el personal idóneo que sustente la propuesta técnica que se realiza junto con el departamento de comercial. Implementar Reuniones Cortas Matutinas: Moprosoft solo indica que se debe llevar un cronograma para las actividades que se están llevando a cabo en cada departamento. Al incorporar una herramienta de seguimiento diario o realizar reunión matutinas para identificar el estado de los proyecto, ayudara a ser más versátiles en las entregas de productos. Rotación de Roles: Es prudente en las metodologías de desarrollo ágil rotar los roles de cada individuo del equipo, esto con el fin de refrescar conocimientos y preparar el personal para cualquier labor dentro del departamento.

73 61 Adquisición de Herramienta de Cronogramas: Es importante adquirir una herramienta donde los cronogramas de proyectos ser encuentre publicados de manera rápida y de fácil acceso. Esto brinda un panorama al equipo de qué puntos se deben atacar con mayor prioridad. Publicar Lecciones Aprendidas en Pointer Desk: El acceso a las lecciones aprendidas esta dado para las personas que participaron en el proyecto. Estas lecciones deben ser públicas para todo el personal que las requiera. Se debe crear instructivo para publicarlas en la intranet.

74 Áreas de Conocimiento y Planes de Gestión En este inciso se describen todas las áreas de conocimiento aplicadas en el plan de gestión para la actualización de la metodología Plan de Gestión del Alcance El Plan de Gestión del Alcance asegura que el proyecto contenga todo el trabajo requerido, para llevar a cabo un proyecto de manera exitosa. En la empresa Stack Pointer se maneja una mezcla de marcos de trabajo para la administración de proyectos, por lo cual se realizarán nuevos formatos y plantillas para el manejo de los documentos que cumplan con los requisitos de lo que ya se está trabajando y la inclusión del marco de trabajo para el desarrollo ágil. Todas las plantillas y documentos serán creadas utilizando como base las recomendaciones del PMI (PMI, 2008). Los procesos que se utilizaran para el desarrollo del siguiente plan de gestión serian la Definición del Alcance que tiene como entradas el acta de constitución del proyecto y la documentación actual de procesos, esta será evaluada por los expertos en el tema de metodologías para el desarrollo de software ágil, y obtendremos el documento final donde se limita el alcance del proyecto. Se incluye el proceso de Creación del EDT que tiene como entradas la limitación del alcance del proyecto, por medio de la descomposición se obtiene la EDT y su respectivo formato para el diccionario de la EDT del plan de gestión. En el proceso de Recopilación de Requisitos se tiene como entrada los interesados del proyecto y acta de constitución del proyecto, estos serán evaluados por medio de entrevistas y grupos de opinión para obtener el documento de requisitos del plan de gestión.

75 Definición del Alcance del Proyecto La definición del alcance del proyecto es donde se registran el detalle conceptual del proyecto, sus objetivos y entregables. El éxito del proyecto está muy dependiente a una buena definición del alcance, ya que en ello se argumentará a futuro que es un cambio o error en el proyecto. Mediante reuniones y entrevistas sostenidas con el director de proyecto de la empresa se construyó el siguiente formato: Definición del Alcance del Proyecto Fecha 14/12/2013 Formato Interno SP-DAP-003 Nombre del Proyecto Plan De Gestión Para La Actualización De La Metodología Para Administración De Proyectos En La Empresa Stack Pointer Con Enfoque En Desarrollo Ágil Información General del Proyecto Cliente Stack Pointer LTDA Director de Proyecto Ruthford F. Jay Archbold Descripción del Proyecto Este proyecto es una solución a la problemática que se presenta en la empresa Stack Pointer al no realizar código ágil y sin problemas que afecten la calidad ante los clientes. Para que esto sea posible se debe incluir en la metodología de proyectos que se está llevando a cabo en la empresa un marco de trabajo para desarrollo ágil de aplicaciones. Objetivos

76 64 General: Desarrollar una actualización a la metodología actual de la compañía para que incluya las técnicas de desarrollo ágil en la gestión de proyectos de software. Específicos: Realizar un análisis de la metodología actual para identificar las áreas de mejora con respecto a proyectos software. Diseñar las plantillas requeridas para incluir técnicas de desarrollo ágil. Modificar formatos establecidos en la metodología actual para adaptar la gestión de los proyectos. Declaración del Alcance del Proyecto Entrega 1: Criterio de Aceptación: Documento de Análisis de metodología Se debe realizar el análisis sobre un y puntos de incorporación de marco de proyecto en el cual se hayan presentado trabajo ágil. retrasos y otro que cumplan con el cronograma. Entrega 2: Criterio de Aceptación: Formatos de administración de Los formatos deben cumplir con la proyecto con adaptación de marco de estructura actual y adicionalmente trabajo para desarrollo ágil SCRUM deben tener su valor agregado para la implementación de desarrollo ágil. Entrega Final: Criterio de Aceptación: Compilar Formatos y manual de Se debe preparar evaluación con los usuario de nueva metodología en la empleados del área de soporte y Intranet de la empresa. desarrollo para visto bueno de la nueva metodología y su aceptación Involucrados

77 65 Directos: Indirectos: - Director de Proyectos - Equipo de Soporte - Jefe de Soporte - Equipo de Desarrollo - Jefe de Desarrollo Restricciones / Limitantes / Factores Críticos de Éxito - No se debe aplicar la nueva metodología para proyectos ya realizados - Esta nueva metodología debe estar finalizada antes de julio de Se dispone con un presupuesto inicial de COP $ ,00 Supuestos - La alta gerencia ya ha dado el aval para realizar el proyecto - El Director de proyecto tiene disponibilidad completa para la ejecución - Se puede garantizar que la fecha de inicio del proyecto es aproximadamente para marzo de 2014 Riesgos - No iniciar en la fecha estipulada - Que no se pueda adaptar nuevos proyectos a la nueva metodología - Que el estilo de negocio de la empresa no se adapte a las restricciones del desarrollo ágil Autorizado Ejecutado Antonio González Ruthford F. Jay Archbold Estructura de Desglose del Trabajo Cuando se tiene un proyecto de alta complejidad lo mejor es aplicar el algoritmo de dividir y vencerás, que implica resolver un problema difícil, dividiéndolo en partes más simples tantas veces como sea necesario. Este mismo principio se utiliza cuando estamos en la construcción de la estructura de desglose del trabajo (EDT). En esta se realizará una descomposición jerárquica del trabajo. En la

78 66 Figura 11 se incluyen los niveles básicos del proyecto, en el Anexo 6 se presenta la EDT completa. Figura 11 - EDT Niveles Básicos del Proyecto Fuente: Elaboración Propia Identificación y Documentación de Requisitos Los requisitos de cada grupo de interesados se detallan a continuación: Requisitos del Gerente General Presupuesto estricto: Se dispone de un presupuesto total de COP $ para realizar el proyecto. Plazo de entrega acotado: El plazo de entrega del proyecto implementado en la empresa es de tres (3) meses una vez iniciado. Es necesario tener la implementación antes de iniciar un nuevo proyecto de alta envergadura. Completar cada uno de los entregables: Es necesario cumplir con todo el cronograma del proyecto y establecer los puntos de calidad que se evalúan para cada entrega. Requisitos del Equipo de Desarrollo Metodología aterrizada: No se pueden realizar reprocesos de la metodología actual contra la nueva que se va implementar. Marco de trabajo ágil concreto: El marco de desarrollo ágil seleccionado debe cumplir con los artefactos actuales de la metodología.

79 67 Requisitos del Equipo de Soporte Formatos deben cumplir con requisitos de cliente: Es importante mantener la satisfacción de los clientes, cada formato modificado debe contener un campo de satisfacción por el cliente. Metodología no debe ser cambiante: Luego de la actualización de la metodología se espera que con estos cambios sea un marco de trabajo estable y consistente Priorización de Requisitos A continuación se resume la priorización de los requisitos. Este punto fue realizado a través del método de Análisis de Involucrados. Lo primero que evaluamos el poder de decisión de cada uno de los Interesados en el Proyecto. Cada uno de los interesados es evaluado contra los demás interesados evaluando su poder decisión tal como se muestra en el Cuadro 4. Cuadro 4 Valores de Priorización Fuente: Elaboración Propia. Valor Muy Alto 10,00 Alto 5,00 Medio 0,20 Bajo 0,10 Nulo 0,00 Luego de que se tienen identificados cada uno de los interesados se procede a evaluar su impacto en el proyecto contra otros interesados tal como se muestra en el Cuadro 5. Luego de esta evaluación se procede a realizar promedio para cada Interesado.

80 68 Cuadro 5 - Priorización de Interesados Fuente: Elaboración Propia. Interesados Gerente Desarrollo Soporte Total Valor Relativo Gerente ,00 0,79 Desarrollo 0,1 5 5,10 0,20 Soporte 0,1 0,2 0,30 0,01 25,40 Cuando se obtiene la Priorización de Involucrados se procede a evaluar cada requerimiento con respecto a cada interesado, tal como se encuentra en el Anexo 7, Anexo 8 y Anexo 9. Cuando ya hemos realizado la Priorización de Requerimientos y Priorización de Interesados, se procede a realizar una multiplicación matricial con la cual obtenemos el valor real para cada requerimiento con respecto a los interesados en el proyecto tal como se muestra en el Cuadro 6, donde cada requerimiento muestra su porcentaje de importancia con respecto al Proyecto. Cuadro 6 - Priorización de Requisitos Fuente: Elaboración Propia. Priorización Final Gerencia Desarrollo Soporte Total Presupuesto estricto 0,29 0,00 0,00 0,29 Marco de trabajo ágil concreto 0,26 0,00 0,00 0,26 Plazo de entrega acotado 0,23 0,00 0,00 0,23 Completar cada uno de los 0,00 0,10 0,00 0,11 entregables Metodología aterrizada 0,00 0,09 0,00 0,10 Formatos deben cumplir con requisitos de cliente 0,00 0,00 0,01 0,01

81 69 Metodología no debe ser cambiante 0,00 0,00 0,01 0, Conclusiones sobre la Priorización de Requisitos Se identificó la alta participación de la gerencia para el éxito del proyecto, donde se nota que los requisitos con mayor priorización son los que más influyen con las decisiones gerenciales, aunque el fin del proyecto es la actualización de la metodología actual, la cual es utilizada por el departamento de desarrollo y soporte, es comprensible que si la gerencia no autoriza el presupuesto y los recursos de la empresa, no se puede ejecutar el proyecto Diccionario de la EDT El diccionario de trabajo provee una descripción detallada de los componentes incluidos en la EDT. La siguiente es la plantilla que se deberá utilizar para crear el diccionario de la EDT, se incluyó la información correspondiente al primer paquete de trabajo para hacer más claro el propósito de la plantilla: Diccionario de Paquete de Trabajo Información General Id Paquete Responsable Ruthford Jay Archbold Nombre del Paquete Consultoría MoproSoft Descripción Consultoría que ayudará a verificar cuales son los puntos clave que se deben tener en cuenta en la metodología MoproSoft para incluir desarrollo ágil. Entradas Salidas Marco Metodológico, Acta del Proyecto, Documento de Análisis de Metodología EDT Actual Responsable Recursos Ruthford Jay Archbold Consultor MoproSoft Estimación Fecha Inicio Fecha Finalización 05/03/ /03/2014 Horas de Esfuerzo Costo Total 80 COP $ Detalle de Recursos & Participación

82 - Gerencia 10% - Dirección de Proyectos 10% - Dirección de Soporte 10% - Consultor MoproSoft 100% - Líder de Proyecto 100% 70

83 Plantilla de Control de Cambios La siguiente plantilla será utilizada cuando se requiera solicitar un cambio al proyecto. Debe contener información detallada para que el administrador del proyecto pueda estimar en qué forma se va a ver afectados el alcance, tiempo o costos del proyecto. Control de Cambios en Alcance Nombre del Proyecto Plan De Gestión Para La Actualización De La Metodología Para Administración De Proyectos En La Empresa Stack Pointer Con Enfoque En Desarrollo Ágil Cambio # CSP-0201 Fecha 01/01/2014 Empresa Stack Pointer Nombre de la Tarea Consultoría MoproSoft Justificación del Cambio Se deben contratar dos consultores para dictar cátedras simultaneas, al grupo de soporte y al grupo de desarrollo Impacto Esto afecta Costos ya que se deben contratar dos consultores MoproSoft Solicitado Sabrina Solano Aprobado Antonio González

84 Plan de Gestión del Tiempo En este inciso se define el Plan de Gestión del Tiempo para el proyecto de actualización de la metodología, se procede con un breve explicación de que procesos se involucran en este plan y que herramientas ayudaron en el proceso. Los procesos que se utilizaran para el desarrollo del siguiente plan de gestión serian la Definición de la Actividades que tiene como entradas la documentación actual de procesos y la definición de alcance realizada, esta será evaluada por los expertos en el tema de metodologías para el desarrollo de software ágil y metodologías de proyectos, y obtendremos el documento final donde se listas tareas del plan de gestión del proyecto. Se procede a Estimar los Recursos de las Actividades que tiene como entradas la lista de tareas obtenidas del proceso de definición, por medio de la ayuda de expertos mediante un software de gestión de proyectos (Pointer Desk) se obtiene Estimación de los Recursos en las Tareas del plan de gestión. Se procede Estimar la Duración de las Actividades se tiene como entrada la lista de tareas obtenidas del proceso de definición, por medio juicio de expertos se obtiene la Estimación de los Recursos en las Tareas del plan de gestión. Por último se procede con el Desarrollo del cronograma que gracias a la lista de tareas actualizada en los procesos anteriores Definición, Estimación de Recursos y Estimación de la Duración, se procede a la construcción del cronograma del plan de gestión por medio de una herramienta de planificación de proyectos (Microsoft Project).

85 Lista de Tareas Basado en la EDT del proyecto se puede obtener el siguiente cuadro con la lista de tareas del proyecto. Cuadro 7 - Lista de Tareas Fuente: Elaboración Propia. Id Tarea 1 Actualización de Metodología 1.1 Análisis de Metodología Metodología Actual Consultoría MoproSoft Evaluación de Impacto Evaluación de Rendimiento Desarrollo Ágil Consultoría SCRUM Evaluación de Impacto Evaluación de Rendimiento 1.2 Adaptación de Marco de Trabajo Cambio de Formatos Formato de Requerimientos Formato de Cambios Formato de Incidentes Formato de No Conformidad Formato de Reunión Técnica Incorporación de SCRUM Asignación de Roles Implementación de Daily Meeting Implementación de Backlog 1.3 Socialización de Formatos

86 Reunión con Gerencia Reunión con Desarrollo Reunión con Soporte 1.4 Gestión del Proyecto Acta de Proyecto Alcance de Proyecto EDT Cronograma Análisis de Interesados Informes estado de proyecto Seguimiento y Control Pruebas de Metodología con Proyecto Piloto Aprobación Estimación de los Recursos en las Tareas Basado en la lista de tareas, se definió el tipo y cantidad de recursos humanos necesarios para llevar a cabo el proyecto. Esto se hizo con el propósito de facilitar la estimación de costos y determinar el calendario de recursos. A continuación se muestra la tabla con el resumen de dichas necesidades. Cuadro 8 - Estimación de los Recursos en las Tareas Fuente: Elaboración Propia. Id Tarea Recurso Consultoría MoproSoft Gerencia[10%]; Líder Proyecto; Consultor; Director Desarrollo[10%]; Director Soporte[10%]

87 Evaluación de Impacto Director Desarrollo[50%]; Director Soporte[50%] Evaluación de Rendimiento Director Desarrollo[50%]; Director Soporte[50%] Consultoría SCRUM Consultor; Líder Proyecto; Gerencia[10%]; Director Desarrollo[10%]; Director Soporte[10%] Evaluación de Impacto Director Desarrollo[50%]; Director Soporte[50%] Evaluación de Rendimiento Director Desarrollo[50%]; Director Soporte[50%] Formato de Requerimientos Líder Proyecto Formato de Cambios Líder Proyecto Formato de Incidentes Líder Proyecto Formato de No Conformidad Director Desarrollo[50%]; Director Soporte[50%] Formato de Reunión Técnica Director Desarrollo[50%]; Director Soporte[50%] Asignación de Roles Director Desarrollo[50%]; Director Soporte[50%]; Líder Proyecto Implementación de Daily Meeting Líder Proyecto Implementación de Backlog Líder Proyecto Reunión con Gerencia Gerencia; Líder Proyecto Reunión con Desarrollo Director Desarrollo; Líder Proyecto Reunión con Soporte Director Soporte; Líder Proyecto Acta de Proyecto Líder Proyecto Alcance de Proyecto Líder Proyecto EDT Líder Proyecto

88 Cronograma Líder Proyecto Análisis de Interesados Líder Proyecto Informes estado de proyecto Líder Proyecto Seguimiento y Control Líder Proyecto Pruebas de Metodología con Proyecto Piloto Líder Proyecto; Director Desarrollo[50%]; Director Soporte[50%] Aprobación Líder Proyecto; Gerencia Estimación de la Duración de las Tareas Se recurrió a entrevistas con los encargados de cada área correspondiente para obtener la estimación en tiempo que va a requerir cada tarea para ser completada. Esto junto con la estimación de recursos permitió elaborar la estimación de la duración de las tareas que se presenta en el Cuadro 9. Cuadro 9 - Estimación de la Duración de las Tareas Fuente: Elaboración Propia. Id Tarea Duración Estimada (Horas) Consultoría MoproSoft Evaluación de Impacto Evaluación de Rendimiento Consultoría SCRUM Evaluación de Impacto Evaluación de Rendimiento Formato de Requerimientos Formato de Cambios 32

89 Formato de Incidentes Formato de No Conformidad Formato de Reunión Técnica Asignación de Roles Implementación de Daily Meeting Implementación de Backlog Reunión con Gerencia Reunión con Desarrollo Reunión con Soporte Acta de Proyecto Alcance de Proyecto EDT Cronograma Análisis de Interesados Informes estado de proyecto Seguimiento y Control Pruebas de Metodología con Proyecto Piloto Aprobación 8

90 Cronograma del Proyecto Con base en la lista de tareas y la estimación de recursos y duración de las mismas, se procedió a elaborar el cronograma inicial. En la Figura 12 se presenta un resumen del cronograma, el cual se presenta completo en el Anexo 5. Figura 12 - Resumen Cronograma Fuente: Elaboración Propia

91 Plan de Gestión de la Calidad Se elaboró el siguiente Plan de Gestión de la Calidad para determinar los factores y métricas de calidad a utilizar en el proyecto, para monitorear, verificar y asegurar que los entregables tengan una calidad satisfactoria para la empresa Stack Pointer. El principal enfoque de este plan es hacer un seguimiento a las tareas de alto grado de complejidad y en las que más presupuesto se esté invirtiendo, ya que son las más delicadas y no se puede incurrir en ningún costo adicional. Para la identificación de las tareas críticas se realizó una reunión en la cual primó el juicio de expertos y el monto invertido en la tarea. Los procesos que se utilizaran para el desarrollo del siguiente plan de gestión serian la Planificación de la Calidad que tiene como entradas el cronograma del proyecto, esta será evaluada por los expertos en proyectos, y obtendremos Los Factores Relevantes y las Métricas de Calidad del plan de gestión del proyecto. Se procede con Realizar el Aseguramiento de la Calidad que tiene como entrada las Métricas de Calidad definidas en el proceso de Planificación, se realizara un Análisis de Procesos por medio de una junta de expertos y se obtendrá la Línea Base de Calidad para el plan de gestión del proyecto.

92 Factores Relevantes de Calidad A continuación se describen los factores identificados como críticos para asegurar la calidad del presente proyecto. Cuadro 10 - Factores Relevantes de Calidad Factor Efectividad de Consultoría MoproSoft Efectividad de Consultoría SCRUM Fuente: Elaboración Propia Definición del factor La consultoría sobre la metodología MoproSoft debe cumplir las expectativas esperadas para lograr el propósito trazado en el proyecto. La consultoría sobre SCRUM debe proveer los conocimientos necesarios sobre que artefactos del marco de trabajo se deben implementar de forma obligatoria para mejorar la metodología de proyectos actual incluyendo el desarrollo ágil. Desempeño del Completar satisfactoriamente todos las tareas Cronograma estipuladas en la EDT Desempeño Presupuestal Cumplimiento de todas las tareas del proyecto con el presupuesto asignado Métricas de Calidad Basado en los factores definidos, se detalla a continuación las métricas a utilizar para medir la calidad del proyecto.

93 81 Cuadro 11 - Métricas de Calidad Fuente: Elaboración Propia Factor Métrica Definición de Métrica Efectividad de Porcentaje Se refiere al Consultoría de porcentaje de MoproSoft Inspección estudio que se de haya realizado Metodología sobre la Actual metodología MoproSoft instaurada actualmente en la compañía. Efectividad de Cantidad de Se refiere al Consultoría Artefactos número de SCRUM Incluidos en artefactos que se Metodología van a incluir en la Actual metodología que pertenecen al marco de trabajo SCRUM Desempeño del Porcentaje Se refiere al Cronograma de avance porcentaje de tareas finalizadas con base a la totalidad de tareas definidas para completar el proyecto Resultado Responsable Esperado 100% Consultor 6 Artefactos Consultor Se espera Líder de estar en un Proyecto delta de 2% hacia arriba o hacia abajo del avance esperado

94 82 Desempeño del Porcentaje Se refiere al Se espera Líder de Cronograma de ejecución porcentaje de estar en un Proyecto dinero ejecutado delta de 2% con base al por arriba o presupuesto inicial por debajo del proyecto de la ejecución presupuestal Línea Base de Calidad A manera de resumen, se presenta a continuación la línea base sobre la cual se va a medir la calidad del proyecto. Cuadro 12 - Línea Base de Calidad Factor Efectividad de Consultoría MoproSoft Efectividad de Consultoría SCRUM Fuente: Elaboración Propia Resultado Esperado Métrica Frecuencia / Momento de Medida 100% Porcentaje Diario hasta de alcanzar el Inspección 100% de Metodología Actual 6 Artefactos Cantidad de Diario hasta Artefactos alcanzar el Incluidos en número de Metodología artefactos Actual esperados Frecuencia / Momento de Reporte Quincenal, esta actividad consta de 2 semanas Quincenal, esta actividad consta de 2 semanas

95 83 Desempeño Se espera Porcentaje Quincenal Mensual del estar en un de avance Cronograma delta de 2% hacia arriba o hacia abajo del avance esperado Desempeño Se espera Porcentaje Quincenal Mensual Presupuestal estar en un de ejecución delta de 2% por arriba o por debajo de la ejecución presupuestal

96 Plan de Gestión de las Comunicaciones En este plan se definieron los medios de comunicación a utilizar en el desarrollo del proyecto y la estrategia más eficiente para que los involucrados del proyecto puedan recibir y transmitir información relevante, se procede con un breve explicación de que procesos se involucran en este plan y que herramientas ayudaron en el proceso. Los procesos que se utilizaran para el desarrollo del siguiente plan de gestión serian la Identificación de los Involucrados que tiene como entradas el acta de constitución del proyecto y la documentación actual de procesos, esta se analizarán las perspectivas de cada uno de los involucrados, y obtendremos Registro de Involucrados del plan de gestión del proyecto. Se procede a Planificar las Comunicaciones y como entrada tenemos el Registro de Involucrados que por medio del Análisis de Requisitos de Comunicación, se obtiene la Matriz de Comunicaciones Identificación de los Involucrados A continuación se lista el inventario de involucrados del Plan de Gestión de las Comunicaciones. Gerencia: Tiene especial interés en que las soluciones que brinda la empresa a sus clientes cumplan con los más altos estándares de calidad y sean en los tiempos establecidos o quizás en un menor tiempo. Es el patrocinador del proyecto. Líder de Proyecto: La persona que se encargará de la dirección del proyecto de actualización y buscará que se cumpla el cronograma a cabalidad.

97 85 Consultor Moprosoft: Es quien ayudará a los demás involucrados del proyecto a identificar debilidades y fortalezas que actualmente tiene la metodología instaurada. Consultor SCRUM: Es quien ayudará a identificar cuáles son los puntos críticos en los cuales se requiere inmediatamente la implementación de SCRUM. Además también es quien nos ayudará en la preparación de un caso piloto para realizar las pruebas con la metodología ya instaurada al final del proyecto. Departamento de Desarrollo: Es el encargado de evaluar las mejoras que se van a realizar en la actualización de la metodología, sin embargo debe estar presente durante todo el proceso ya que su participación es alta. Departamento de Soporte: Es el encargado del día a día en la empresa, no está muy involucrado con el seguimiento de proyectos, pero si es de gran interés en la parte donde se incluyan la resolución de Incidentes y No Conformidades presentadas por los clientes.

98 Matriz de Comunicaciones En la siguiente matriz de comunicaciones se detallan los tipos de comunicación que se van a utilizar en el proyecto y quién es el responsable de los mismos. Cuadro 13 - Matriz de Comunicaciones Fuente: Elaboración Propia Tipo de Dirigido A Frecuen- Respon- Propósito Recursos Comunica- cia sable ción Reunión Gerencia Al Inicio Líder de Presentación de Chárter del Inicial de del Proyecto Documentación, proyecto. Proyecto proyecto cronograma y presupuesto Reunión Departa- Diario Líder de Repaso de Tareas con equipo mento de Proyecto Tareas, asignadas interno Desarrollo, Verificar qué se según Departa- hizo, Verificar cronograma mento de qué faltó, y qué Soporte incidentes se presentaron Tertulias de Departa- 4 Consultor Encontrar Documentación Metodología mento de Semanas debilidades y Interna, Desarrollo, Continuas fortalezas en la Formatos, Departa- metodología Manifiesto Ágil mento de actual y en el Soporte marco de trabajo seleccionado

99 87 Reuniones Departa- Semanal Líder de Verificar qué Preparación de Técnicas mento de Proyecto inconvenientes Piloto Desarrollo, se hayan Departa- encontrado con mento de respecto al Soporte planteamiento de la metodología actual y el marco de trabajo SCRUM Reuniones Gerencia Quincenal Líder de Informe sobre EDT, de Proyecto avance en las Cronograma, Avance y asignaciones. Formatos de estatus del Presentar Seguimiento proyecto informe detallado sobre problemas y soluciones encontrados. Pruebas de Departa- Al final Líder de Utilizar proyecto EDT, Criterios Piloto mento de del Proyecto piloto para de Aceptación Desarrollo, Desarrollo verificar cada Departa- una de las mento de actualizaciones Soporte realizadas a la metodología y analizar si la implementación fue exitosa.

100 88 Reunión de Gerencia Al final de Líder de Mostrar el éxito Formato de Cierre y las Proyecto del proyecto Aceptación de Aprobación Pruebas con las Proyecto evidencias obtenidas en el piloto realizado.

101 Plan de Gestión de los Costos En el Plan de Gestión de los Costos se le asignó un valor monetario a cada una de las actividades del proyecto para definir una línea base de costos autorizados que permita llevar el control de los costos del proyecto, se procede con un breve explicación de que procesos se involucran en este plan y que herramientas ayudaron en el proceso. Los procesos que se utilizaran para el desarrollo del siguiente plan de gestión serian la Estimación de los Costos que tiene como entradas el cronograma del proyecto previamente realizado en el área de Tiempo, esta será evaluada por los expertos en el tema de los costos y se analizarán propuestas realizadas en proyectos de la misma línea de investigación, y obtendremos la Estimación de Costos por Tarea del plan de gestión del proyecto. Se procede a Determinar el Presupuesto del proyecto, el cual tiene como entrada la Estimación de Costos por Tarea, con el cual utilizaremos la herramienta de Análisis de Reserva y juicio de expertos para obtener al final el Presupuesto Definitivo del plan de gestión Estimación de Costos Para la estimación de los costos se utilizó la siguiente tabla de costos por hora de cada recurso humano requerido en el proyecto: Cuadro 14 - Costo por Hora de Recursos Fuente: Elaboración Propia. Recurso Costo Por Hora Gerencia COP $ ,00 Líder Proyecto COP $ ,00 Consultor COP $ ,00 Director Desarrollo COP $ ,00 Director Soporte COP $ ,00

102 90 Basado en la duración de cada tarea y la tabla de costos por hora del recurso humano, se obtuvo el siguiente desglose de costos por actividad. Cuadro 15 - Estimación de Costos por Tarea Fuente: Elaboración Propia. Id Tarea Total Consultoría MoproSoft COP $ , Evaluación de Impacto COP $ , Evaluación de Rendimiento COP $ , Consultoría SCRUM COP $ , Evaluación de Impacto COP $ , Evaluación de Rendimiento COP $ , Formato de Requerimientos COP $ , Formato de Cambios COP $ , Formato de Incidentes COP $ , Formato de No Conformidad COP $ , Formato de Reunión Técnica COP $ , Asignación de Roles COP $ , Implementación de Daily Meeting COP $ , Implementación de Backlog COP $ , Reunión con Gerencia COP $ , Reunión con Desarrollo COP $ , Reunión con Soporte COP $ , Acta de Proyecto COP $ , Alcance de Proyecto COP $ , EDT COP $ , Cronograma COP $ , Análisis de Interesados COP $ ,00

103 Informes estado de proyecto COP $ , Seguimiento y Control COP $ , Pruebas de Metodología con Proyecto Piloto COP $ , Aprobación COP $ , Presupuesto del Proyecto Para establecer la línea base de presupuesto se sumaron las tareas requeridas de cada entregable. Stack Pointer tiene como política calcular la reserva de gestión como un 2% del costo. Cuadro 16 - Línea Base de Costo Fuente: Elaboración Propia. Entregable Costo Reserva Line Base Análisis de COP $ COP $ COP $ Metodología Adaptación de COP $ COP $ COP $ Marco de Trabajo Socialización de COP $ COP $ COP $ Formatos Gestión del COP $ COP $ COP $ Proyecto Totales COP $ COP $ COP $ El total de la línea base de costo es de COP $ El presupuesto total del proyecto es de COP $ , que se obtiene al sumar el total de la línea base de costo con la reserva de gestión, lo que se presenta en el Cuadro 17.

104 92 Cuadro 17 - Presupuesto Fuente: Elaboración Propia. Presupuesto Análisis de Metodología COP $ Adaptación de Marco de Trabajo COP $ Socialización de Formatos COP $ Gestión del Proyecto COP $ Línea base de costo COP $ Reserva de gestión 2% COP $ Presupuesto total COP $ Plantilla de Control de Cambios en Costos La siguiente plantilla será utilizada cuando se requiera solicitar un cambio a los costos de una tarea del proyecto. Debe contener información detallada para que el administrador del proyecto pueda estimar en qué forma se va a ver afectados los costos del proyecto. Control de Cambios en Costos Nombre del Proyecto Plan De Gestión Para La Actualización De La Metodología Para Administración De Proyectos En La Empresa Stack Pointer Con Enfoque En Desarrollo Ágil Cambio # Fecha 01/01/2014 Empresa Stack Pointer Nombre de la Tarea Consultoría MoproSoft Valor Presupuestado Valor Por Aprobar

105 93 $ ,00 $ ,00 Valor de Incremento $ ,00 Solicitado Aprobado Sabrina Solano Antonio González

106 Plan de Gestión de los Riesgos El ajuste o actualización a una metodología implantada en una empresa siempre trae consigo riesgos intrínsecos a la naturaleza del mismo proyecto no solamente debido a que siempre hay personal reacio al cambio o personal administrativo que se rehúsa a mejorar algo que ya está bien. A continuación se describe en una matriz de riesgos, contingencias y mitigación los diferentes riesgos detectados así como también las medidas de contingencias (acciones encaminadas a ejecutarse cuando el riesgo se materializa) y las medidas de mitigación (acciones encaminadas a aplicarse para disminuir la probabilidad de materialización del riesgo asociado). Los procesos que se utilizaran para el desarrollo del siguiente plan de gestión serian la Identificación de Riesgos que tiene como entradas el cronograma del plan de gestión y la línea base de alcance, las cuales son analizadas por expertos en metodología de proyectos por medio de análisis de supuestos, y obtendremos Registro de Riesgos del plan de gestión del proyecto. Se procede a realizar el Análisis Cualitativo de los Riesgos que se obtiene del proceso de Identificación y por medio de la Matriz de Probabilidad e Impacto se obtiene la actualización del Registro de Riesgos. Por último se procede a Planificar la Respuesta a los Riesgos obtenidos en el proceso de Identificación, por medio de análisis de Estrategias, Acciones Preventivas, Contingencias y Respaldos se obtiene una actualización del Registro de Riesgos Nomenclatura de los Riesgos Riesgos de Administración de Proyectos (RA): Son aquellos que involucran tiempo y los recursos, falta de adecuación en la calidad del proyecto y cuando se notan las deficiencias en la administración de proyectos.

107 95 Riesgos Externos (RE): Son aquellos que se desenvuelven en los cambios del ambiente legal, asuntos relacionados con la mano de obra, cambios en las prioridades del dueño, riesgos relativos al país, y el clima. Riesgos Organizacionales (RO): Son aquellos que involucran objetivos de costo, tiempo y alcance que son inconsistentes internamente, falta de prioridades en proyectos, fondos inadecuados o interrumpidos, y conflicto de recursos con otros proyectos de la organización. Riesgos Técnicos (RT): Son aquellos que involucran confianza en tecnología no conocida o compleja, metas de desempeño no realistas, cambios a la tecnología utilizada o a los estándares de la industria durante el proyecto Identificación de Riesgos La siguiente es una lista de algunos riesgos identificados para el presente proyecto. No es una lista exhaustiva, sino más bien una muestra representativa para mostrar en el PFG cómo se debe realizar el plan de gestión de riesgos. Una vez iniciado el proyecto se debe revisar esta lista y hacer los ajustes necesarios. Para cada riesgo se identificó su causa y a qué actividad de la estructura de desglose del trabajo está asociado. Cuadro 18 - Identificación de Riesgos Fuente: Elaboración Propia. Código Causa Descripción del Riesgo Referencia EDT Los conocimientos administrados por los Calidad de RA01 Consultoría consultores no sean lo Cursos , Pobre suficiente para realizar una Recibidos por buena evaluación del Personal estado de la metodología.

108 96 RT02 Evaluaciones que no brindan valor agregado al proyecto Los resultados entregados por el Departamento de Desarrollo y Soporte no son lo suficientemente consistentes para proceder con los cambios. Evaluación de Resultados en Metodología , , , RA03 Formatos que no son de fáciles de adaptar Los formatos implementados para la nueva metodología no son los aptos para el día a día del personal. Reprocesos en Documentación Suministrada No contar con Cuando se definan los el personal roles en la empresa se Contratación RA04 apto para debe contar con personal de Personal desempeñar idóneo para Idóneo cada Rol desempeñarlos Se presenten quejas por el RT05 Fracaso en la socialización de Formatos personal de Soporte y Desarrollo, quienes son los más afectados con los nuevos formatos Reprocesos en Documentación Suministrada 1.3 implementados Análisis Cualitativo El análisis cualitativo de riesgos es el proceso que consiste en priorizar los riesgos para realizar otros análisis o acciones posteriores, evaluando y combinando la probabilidad de ocurrencia y el impacto de dichos riesgos (PMBOK, 2008). En este caso se utilizará para realizar una evaluación de los riesgos que deben ser mitigados y eliminados del proyecto.

109 97 Para maximizar la utilización de los recursos destinados a la gestión del riesgo, se deberá priorizar la lista de riesgos identificada. Para este fin, se utilizará una matriz de probabilidad e impacto. La primera tabla muestra las escalas relativas a la probabilidad de que un riesgo suceda y el valor del puntaje del impacto asociado. Se utilizan las siguientes escalas para cuantificar el riesgo: Cuadro 19 - Escala de Probabilidad e Impacto Fuente: Elaboración Propia. Escala Probabilidad Impacto Muy Baja Baja Media Alta Muy Alta Producto de la combinación de los puntajes de probabilidad e impacto se obtiene la matriz PxI, el resultado de este producto se muestra en la siguiente tabla: Cuadro 20 - Matriz PxI Probabilidad Fuente: Elaboración Propia. Impacto Muy Baja Baja Media Alta Muy Alta Muy Baja 0,005 0,01 0,02 0,04 0,08 Baja 0,015 0,03 0,06 0,12 0,24 Media 0,025 0,05 0,1 0,2 0,4 Alta 0,035 0,07 0,14 0,28 0,56 Muy Alta 0,045 0,09 0,18 0,36 0,72 Así se podrán identificar los riesgos de acuerdo con las siguientes categorías:

110 98 Cuadro 21 - Categorías Fuente: Elaboración Propia Categoría Rango Bajo [0,01-0,04] Moderado [0,05-0,17] Alto [0,18-0,99] Matriz Probabilidad Impacto En la siguiente tabla se asigna la probabilidad de que el riesgo ocurra y el impacto que esto generaría en el proyecto, para cada uno de los riesgos identificados: Cuadro 22 - Matriz Probabilidad Impacto Fuente: Elaboración Propia. Código Causa Probabilidad Impacto Rango Riesgo PxI Consultoría RA01 Pobre Media Alto 0,2 Alto RT02 Evaluaciones que no brindan valor agregado al proyecto Baja Medio 0,06 Moderado RA03 Formatos que no son de fáciles de adaptar Alta Medio 0,14 Moderado

111 99 RA04 RT05 No contar con el personal apto para desempeñar cada Rol Fracaso en la socialización de Formatos Media Medio 0,1 Moderado Baja Bajo 0,03 Bajo Estrategias, Acciones Preventivas, Contingencias y Respaldos En la siguiente tabla se detallan las estrategias y las acciones preventivas para reducir la probabilidad de que los riesgos ocurran, adicionalmente se determinó el plan de contingencia a seguir si los riesgos se llegaran a materializar. Cuadro 23 - Estrategias, Acciones Preventivas, Contingencias y Respaldos Fuente: Elaboración Propia. Códi- Causa Riesgo Estra- Acciones Respaldos Plan para go tegia Preven- Contin- tivas gencias Consultar con Solicitar clúster de certificación tecnología Consul- Contratar de empresas para verificar RA01 toría Alto Transferir Personal de que hayan si tienen Pobre Alta Calidad tomado la personal con misma capacidades consultoría para realizar la consultoría

112 100 Evalua- Basar la ciones Realizar Evaluación en que no seguimiento una empresa RT02 brindan valor Moderado Mitigar sobre las evalua- Formatos de Seguimiento que tenga las mismas agregado ciones caracterís- al realizadas ticas que proyecto Stack Pointer Realizar reuniones con el Buscar RA03 Formatos que no son de fáciles de adaptar Moderado Mitigar personal para verificar la facilidad de cada formato Formatos de Otras empresas que hayan implementado este marco implemen- de trabajo tado o modificado

113 101 Solicitar a la gerencia una evaluación de No desempeño contar de cada Entrena- RA04 con el personal apto para desem- Moderado Transferir empleado antes de empezar con la Exámenes de Competencia miento de Personal en cada Rol implemen- peñar asignación tado cada Rol de roles Fracaso en la RT05 socialzación Bajo Aceptar de Formatos

114 Estrategia de Desarrollo e Implementación Un desafío importante que implica este proyecto es la adaptación de un marco de desarrollo ágil, para ser más precisos sería Scrum. La implementación de este marco puede conllevar grandes dificultades, pero el reto de este proyecto es realizar una abstracción de la metodología actual MoproSoft, obtener los componentes con falencias y mezclarlos con Scrum. El primer cambio que se debe realizar para el éxito del proyecto es el cambio de paradigma de programación que se lleva actualmente en la empresa. No siempre lo conocido es lo ideal, se deben realizar una mejora en las reuniones técnicas, explorar más alternativas, dejar la zona de confort en la que se encuentran el departamento de desarrollo y soporte. Se debe reestructurar la oficina de proyectos, en la cual se están llevando a cabo labores administrativas que no le corresponden. Esta oficina solo debe estar encargada en velar la mejora continua de los procesos y metodología de proyectos. Realizar inversión en capacitaciones para el personal técnico, si Stack Pointer quiere llegar a estar en la vanguardia de la casa de software del país y obtener un nivel optimizado y de mejora continua en CMMI, se debe capacitar el personal en últimas tecnologías. Es cierto que cada persona debe buscar la superación personal, pero la empresa debe ayudar a que cada empleado sienta la necesidad de querer más conocimiento.

115 103 Nuestra estrategia privilegia una evolución hacia la tecnología ágil. En la primera implantación e inicio del camino hacia las tecnologías agiles se realizan los siguientes pasos: Diagnosticar al equipo y su situación actual de roles y personas que los desempeñan. Determinar cómo se cubrirán las responsabilidades asociadas al rol Product Owner, es decir, qué tipo de cliente podemos conseguir en el producto. Para esto se identifican al menos tres responsabilidades involucradas, con las siguientes preguntas: o Quién debería decidir qué debe implementarse en el producto? o Quién debería determinar en detalle cada cambio implementado en el producto? o Quién debería especificar/explicar los requisitos a los desarrolladores? Determinar cuánto puede acercarse el equipo de desarrollo al rol Development Team. Lo primero que se debe evaluar es la viabilidad de prescindir del rol Jefe de Proyecto o Director de Proyecto, es decir, quien dirige al equipo, organizando y supervisando el trabajo. Además, si se quiere y puede llevar el concepto de self-organizing a fondo, habría que resolver qué reubicación se le daría al actual Jefe de Proyecto o Director de Proyecto.

116 CONCLUSIONES En el presente apartado se detallan las conclusiones más importantes obtenidas en la elaboración del presente plan de gestión. Con respecto al objetivo principal sobre elaborar un plan integral de administración para el proyecto, la probabilidad de éxito del proyecto se incrementó al realizar una planificación adecuada, y contar con una línea base sobre la cual hacer control del proyecto. Como hay un cronograma y un presupuesto establecido con el cual llevar a cabo el seguimiento, es mucho más sencillo para los involucrados en el proyecto atender cualquier emergencia que se presente en el trabajo diario y luego volver a enfocarse en el trabajo del proyecto. Además, con la elaboración del plan integral del proyecto se logró una mejora significativa en la coordinación entre departamentos. Los Departamentos de Soporte y Desarrollo se mostraron especialmente con disposición a colaborar en la nueva iniciativa si era posible saber de antemano la carga de trabajo requerida de la gente de su departamento, para así planificar y que no se afecten las labores diarias. Con respecto a la investigación sobre la situación actual de la empresa, se concluyó que requiere una mejora en el marco de trabajo implementado actualmente, donde se deben incorporar metodologías de desarrollo ágil las cuales incrementarán potencialmente el rendimiento en los proyectos y en el seguimiento que se les lleva. Fue fundamental para el proyecto de gestión diseñar cada uno de los planes de las diferentes áreas de conocimiento, pues cada área mostró un aspecto

117 105 importante del proyecto que, si se hubiera dejado de lado, hubiera ocasionado problemas a la hora de realizar la implementación. Al elaborar los planes de gestión de cada área de conocimiento, se logró determinar que el área donde se requiere más atención es en la gestión del tiempo, puesto que la empresa no cuenta con muchos recursos en las áreas operativas y se debe llevar una estricta planificación del tiempo en el cual estos recursos harán sus aportes al proyecto de actualización. Mediante la elaboración del plan de gestión de costos se determinó que la empresa está realizando una gran inversión para mejorar la calidad de los productos y proyectos que se ofrecen a los clientes. Mediante la elaboración del plan de gestión de calidad se identificaron las áreas de mejora en este tema que pueden ser aplicadas para el resto de la empresa. Especialmente la identificación de factores y métricas de calidad que permitan determinar cuándo la metodología se verá afectada por la incorporación de nuevos artefactos y objetos que impliquen riesgos de mayor cuantía.

118 RECOMENDACIONES Con el propósito de mejorar la metodología de proyectos en la empresa Stack Pointer, se recomienda que en un futuro cercano y para otros proyectos se tome en cuenta lo siguiente: El Gerente debe incluir ciertas áreas de conocimiento del PMBoK en la metodología de proyectos que actualmente se utiliza en Stack Pointer. La Gerencia debe considerar la creación de una oficina de administración de proyectos dentro en Stack Pointer para que actualice y estandarice los procesos de administración de proyectos y se encargue de mantener actualizadas las plantillas de seguimiento y control utilizadas en los mismos. El Equipo de Soporte y Desarrollo en la medida que no se afecte el servicio prestado por la empresa a sus clientes, se deben convertir las iniciativas informales actuales a proyectos establecidos formalmente, para realizar un mejor seguimiento y control. El Equipo de Soporte y Desarrollo debe utilizar las plantillas obtenidas mediante este plan de gestión de proyecto como base para lograr una estandarización en la planificación y control de otros proyectos en Stack Pointer. El futuro de las metodologías de Software están dirigidas al desarrollo ágil, Stack Pointer debe optar por una de ellas y combinar el marco de trabajo del PMBoK y un marco de trabajo ágil como Scrum.

119 BIBLIOGRAFIA Chrissis M., Konrad M., Shrum S., (2011). CMMI for Development: Guidelines for Process Integration and Product Improvement. (3 ra Ed.). Carnegie Mellon University Dankhe, G.L. (1976). Investigación y Comunicación. (2 da Ed.). México: McGraw-Hill. Eyssautier De La Mora, M. (2002). Metodología de la Investigación. (3 ra Ed.). México: Thompson División Iberoamericana. Hernández, R. (1998). Metodología de la Investigación. (2 da Ed.). México: McGraw-Hill. Kerzner, H. (2004). Advanced Project Management: Best Practices on Implementation. (2 da Ed.). Canada: John Wiley & Sons. Lledo, P. (2013). Administración de proyectos: El ABC para un Director de proyectos exitoso. Victoria, BC, Canadá. Microsoft. (2013). Extraído el 28 Noviembre, 2013, de Project Management Institute. (2008). Guía de los Fundamentos para la Dirección de Proyectos. (4ta Ed.). Newtown Square, PA: Project Management Institute. Real Academia Española. (2001). Diccionario de la Lengua Española. (22 a Ed.).

120 108 Extraído el 15 septiembre, 2013, de Sims, C., Louise, Johnson, H. (2012). Scrum: a Breathtakingly Brief and Agile Introduction. Dymaxicon. Scrum. (2013). Extraído el 28 noviembre, 2013, de Guide.pdf Stack Pointer. (2013). Extraído el 15 septiembre, 2013, de Universidad de Oviedo. (2013). Extraído el 15 septiembre, 2013, de Whitaker, S. (2013). PMP Training Kit. California: Microsoft Press Books.

121 ANEXOS Anexo 1: ACTA DEL PROYECTO PFG ACTA DEL PROYECTO Fecha Nombre de Proyecto 15/09/2013 Plan de Gestión para la Actualización de la metodología de Administración de Proyectos en la Empresa Stack Pointer con Enfoque en Desarrollo Ágil Áreas de conocimiento / Área de aplicación (Sector / Actividad): procesos: Procesos: Iniciación, Planificación, Sector: Tecnología de la Información Ejecución, Seguimiento y Control, Cierre. Áreas: Actividad: Desarrollo de Software a La Medida. Integración, Alcance, Tiempo, Calidad, Comunicaciones, Costos y Riesgos. Fecha de inicio del proyecto Fecha tentativa de finalización del proyecto 30/09/ /02/2014 Objetivos del proyecto (general y específicos) General: Crear un Plan de Gestión para la actualización de la Metodología de Administración de Proyectos en la Empresa Stack Pointer, con un enfoque en desarrollo ágil.

122 110 Específicos: Los objetivos específicos del proyecto son: Elaborar un análisis sobre la situación actual de la empresa Stack Pointer y su metodología de proyectos. Desarrollar un Plan de Gestión del Alcance para determinar los puntos que se deben afectar en la metodología actual e identificar las áreas que deben mejorar. Desarrollar un Plan de Gestión del Tiempo para determinar el cronograma de las actividades requeridas para incluir técnicas de desarrollo ágil sobre la metodología actual. Desarrollar un Plan de Gestión de Calidad para asegurar y controlar los resultados del proyecto. Desarrollar un Plan de Gestión de Comunicaciones para dar conocimiento a los interesados del desarrollo del proyecto. Desarrollar un Plan de Gestión de Costos para estimar y presupuestar los recursos que se deben invertir para efectuar el proyecto. Diseñar un Plan de Gestión de Riesgo para aumentar las probabilidades de éxito del proyecto dentro del alcance, tiempo y costo establecido. Establecer lineamientos iniciales para la implementación de las mejoras en la metodología actual. Justificación o propósito del proyecto (Aporte y resultados esperados) Actualmente en la empresa Stack Pointer existe un documento de estándares de programación para cualquier tipo de proyecto. Adicionalmente hay un documento de políticas que exige una metodología única para llevar a cabo cualquier tipo proyecto. Hasta el momento se han llevado a cabo varios proyectos de aplicaciones en la empresa y por fortuna no se han presentado retrasos que puedan comprometer la imagen con el cliente, sin embargo por falta de unos lineamientos claros se

123 111 presentan este tipo de inconvenientes de deuda técnica. El propósito del proyecto es desarrollar un plan de gestión de proyectos en el cual se desarrollarán planes de alcance, tiempo, calidad y costos, dado que se desea actualizar la metodología que nos permita mitigar en su máxima expresión los riesgos que se puedan presentar en un proyecto de software. Descripción del producto o servicio que generará el proyecto Entregables finales del proyecto Plan de Gestión del proyecto: 1. Plan de Gestión del Alcance 2. Plan de Gestión del Tiempo 3. Plan de Gestión de la Calidad 4. Plan de Gestión de las Comunicaciones 5. Plan de Gestión de los Costos 6. Plan de Gestión de los Riesgos Supuestos El marco de trabajo para desarrollo ágil que se utilizará como guía del plan de gestión es SCRUM. Restricciones Se cuenta con un tiempo máximo de 3 meses para la elaboración del Plan de Gestión del Proyecto. Información histórica relevante Hace tres años la empresa intentó la certificación de CMMI nivel 5, sin embargo fue un fracaso ya que los pares evaluadores nos informaron que la empresa debía adquirir un nivel intermedio antes de pensar en alcanzar la mejora continua, que es el enfoque del nivel 5. Sin embargo la empresa no se detuvo en su deseo de certificación a la calidad y madurez, y empezó una certificación en MoproSoft el cual consiste en un modelo para la mejora y evaluación de los procesos de desarrollo y

124 112 mantenimiento de sistemas y productos de software. No obstante la empresa sigue en su lucha por alcanzar la mejora continua de los procesos internos de desarrollo de software, y una idea para esto es incorporar mejoras en la metodología que se está llevando a todos los proyectos, algo como acotar cada proyecto a sus necesidades y no utilizar una plantilla única para todos los proyectos. Identificación de grupos de interés (Stakeholders) Cliente(s) directo(s): Empresa Stack Pointer Cliente(s) indirecto(s): No Aplica Realizado por: Ruthford Jay Archbold Firma: Aprobado por: Carlos Murillo Blanco Firma:

125 113 Anexo 2: CRONOGRAMA DEL PFG Nombre de tarea Duración Comienzo Fin Proyecto Final Grado 240 horas jue 05/12/13 vie 14/02/14 Creación de Nuevo Charter 10 horas jue 05/12/13 sáb 07/12/13 Desarrollo Situación Actual y Metodología 36 horas sáb 07/12/13 mar 17/12/13 Entrega Plan de Alcance 24 horas mar 17/12/13 jue 26/12/13 Desarrollo de Alcance 16 horas mar 17/12/13 sáb 21/12/13 Revisión Tutor 4 horas dom 22/12/13 dom 22/12/13 Correcciones 4 horas lun 23/12/13 jue 26/12/13 Entrega Plan de Tiempo 24 horas jue 26/12/13 vie 03/01/14 Desarrollo de Tiempo 16 horas jue 26/12/13 lun 30/12/13 Revisión Tutor 4 horas lun 30/12/13 jue 02/01/14 Correcciones 4 horas jue 02/01/14 vie 03/01/14 Entrega Plan de Calidad 24 horas sáb 04/01/14 sáb 11/01/14 Desarrollo de Calidad 16 horas sáb 04/01/14 mié 08/01/14 Revisión Tutor 4 horas jue 09/01/14 vie 10/01/14 Correcciones 4 horas vie 10/01/14 sáb 11/01/14 Entrega Plan de Comunicaciones 24 horas sáb 11/01/14 sáb 18/01/14 Desarrollo de Comunicaciones 16 horas sáb 11/01/14 mié 15/01/14 Revisión Tutor 4 horas mié 15/01/14 jue 16/01/14 Correcciones 4 horas vie 17/01/14 sáb 18/01/14 Entrega Plan de Costo 24 horas sáb 18/01/14 vie 24/01/14 Desarrollo de Costo 16 horas sáb 18/01/14 mié 22/01/14 Revisión Tutor 4 horas mié 22/01/14 jue 23/01/14 Correcciones 4 horas jue 23/01/14 vie 24/01/14 Entrega Plan de Riesgos 24 horas sáb 25/01/14 vie 31/01/14 Desarrollo de Riesgos 16 horas sáb 25/01/14 mar 28/01/14

126 114 Revisión Tutor 4 horas mié 29/01/14 jue 30/01/14 Correcciones 4 horas jue 30/01/14 vie 31/01/14 Recomendaciones 20 horas vie 31/01/14 mié 05/02/14 Desarrollo de Recomendaciones 12 horas vie 31/01/14 lun 03/02/14 Revisión Tutor 4 horas lun 03/02/14 mar 04/02/14 Correcciones 4 horas mar 04/02/14 mié 05/02/14 Conclusiones 20 horas jue 06/02/14 mar 11/02/14 Desarrollo de Conclusiones 12 horas jue 06/02/14 sáb 08/02/14 Revisión Tutor 4 horas dom 09/02/14 dom 09/02/14 Correcciones 4 horas lun 10/02/14 mar 11/02/14 Correcciones Finales 8 horas mar 11/02/14 jue 13/02/14 Entrega Final 2 horas vie 14/02/14 vie 14/02/14

127 Anexo 3: EDT DEL PFG 115

128 116 Anexo 4: ACTA DEL PROYECTO Actualización de Metodología para Administración de Proyectos con enfoque en desarrollo ágil ACTA DEL PROYECTO Fecha Nombre de Proyecto 28/02/2014 Actualización de Metodología para Administración de Proyectos en la empresa Stack Pointer con enfoque en desarrollo ágil Áreas de conocimiento / Área de aplicación (Sector / Actividad): procesos: Procesos: Iniciación, Planificación, Sector: Tecnología de la Información Ejecución, Seguimiento y Control, Cierre. Actividad: Desarrollo de Software a La Medida. Áreas: Integración, Alcance y Comunicaciones. Fecha de inicio del proyecto Fecha tentativa de finalización del proyecto 05/03/ /07/2014 Objetivos del proyecto (general y específicos) General: Desarrollar una actualización a la metodología actual de la compañía para que incluya las técnicas de desarrollo ágil en la gestión de proyectos. Específicos: Realizar un análisis de la metodología actual para identificar las áreas de mejora con respecto a proyectos móviles. Diseñar las plantillas requeridas para incluir técnicas de desarrollo ágil

129 117 enfocadas a los proyectos de software. Modificar formatos establecidos en metodología actual para adaptar la nueva metodologia de gestión de proyectos. Crear un plan de capacitación para dar a conocer los cambios y mejoras propuestos a la metodología a todos los involucrados. Justificación o propósito del proyecto (Aporte y resultados esperados) Actualmente en la empresa Stack Pointer existe un documento de estándares de programación para cualquier tipo de proyecto. Adicionalmente hay documento de políticas que exige una metodología única para llevar a cabo cualquier tipo proyecto, pero para una aplicación móvil se deben contemplar otros factores, como rendimiento del dispositivo, restricción de almacenamiento entre otros. Hasta el momento se han llevado a cabo varios proyectos con aplicaciones móviles en la empresa y por fortuna no se han presentado retrasos que puedan comprometer la imagen con el cliente, sin embargo por falta de unos lineamientos claros se presentan este tipo de inconvenientes de deuda técnica. Por lo cual se desea actualizar la metodología que nos permita mitigar en su máxima expresión los riesgos que se puedan presentar en un proyecto de software móvil. Descripción del producto o servicio que generará el proyecto Entregables finales del proyecto Entrega 1: Se entregará un documento a la gerencia con los puntos identificados que hayan sido fallas en otros proyectos móviles o que hagan parte de las lecciones aprendidas.

130 118 Entrega 2: Se entregará un documento de cómo se puede mitigar el impacto de estas fallas o inconvenientes que han tenido con los proyectos e identificar qué puntos de la metodología actual se deben modificar para que puedan gestionar de manera ideal los proyectos de software. Entrega 3: Se establece como parte de la metodología el Daily Meeting, el cual hace parte del marco de trabajo SCRUM, y se presenta el diseño del formato con el cual se harán los registros de estas reuniones. Entrega 4: Se realizarán las modificaciones pertinentes a los formatos establecidos por la oficina de proyectos para incluir las mejoras a los proyectos de software con desarrollo ágil. Entrega 5: Se realizarán capacitaciones con el personal involucrado de la empresa y los altos mandos para presentar los cambios realizados a la metodología de proyectos actual y explicar brevemente que beneficios le ofrecerá a la compañía este cambio. Supuestos - Esta metodología será aplicada en todos los proyectos de desarrollo móvil a partir de su constitución. Restricciones - Esta metodología estará basada en el documento actual de estándares de desarrollo de Stack Pointer - La metodología de desarrollo ágil que se utilizará es SCRUM. Información histórica relevante Hace tres años la empresa intentó la certificación de CMMI nivel 5, sin embargo fue un fracaso ya que los pares evaluadores nos informaron que la empresa debía adquirir un nivel intermedio antes de pensar en alcanzar la mejora continua, que es el enfoque del nivel 5.

131 119 Sin embargo la empresa no se detuvo en su deseo de certificación a la calidad y madurez, y empezó una certificación en MoproSoft el cual consiste en un modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software. No obstante la empresa sigue en su lucha por alcanzar la mejora continua de los procesos internos de desarrollo de software, y una idea para esto es incorporar mejoras en la metodología que se está llevando a todos los proyectos, algo como acotar cada proyecto a sus necesidades y no utilizar una plantilla única para todos los proyectos. Identificación de grupos de interés (Stakeholders) Cliente(s) directo(s): Antonio Gonzalez (Gerente) Sabrina Solano (Director de Proyecto) Ruthford Jay (Lider de Proyecto) Cliente(s) indirecto(s): Jose Camilo Aleman (Consultor de Tecnología) Realizado por: Firma: Ruthford Jay Archbold Aprobado por: Carlos Murillo Blanco Firma:

132 120 Anexo 5: CRONOGRAMA DEL PROYECTO Actualización de Metodología para Administración de Proyectos con enfoque en desarrollo ágil Nombre de tarea Duración Comienzo Fin Actualización de Metodología 652 horas 05/03/ /07/2014 Análisis de Metodología 240 horas 05/03/ /04/2014 Metodología Actual 120 horas 05/03/ /03/2014 Consultoría MoproSoft 80 horas 05/03/ /03/2014 Evaluación de Impacto 40 horas 19/03/ /03/2014 Evaluación de Rendimiento 40 horas 19/03/ /03/2014 Desarrollo Ágil 120 horas 27/03/ /04/2014 Consultoría SCRUM 80 horas 27/03/ /04/2014 Evaluación de Impacto 40 horas 10/04/ /04/2014 Evaluación de Rendimiento 40 horas 10/04/ /04/2014 Adaptación de Marco de Trabajo 172 horas 21/04/ /05/2014 Cambio de Formatos 80 horas 21/04/ /05/2014 Formato de Requerimientos 24 horas 21/04/ /04/2014 Formato de Cambios 32 horas 24/04/ /04/2014 Formato de Incidentes 24 horas 30/04/ /05/2014 Formato de No Conformidad 40 horas 21/04/ /04/2014 Formato de Reunión Técnica 32 horas 28/04/ /05/2014 Incorporación de SCRUM 92 horas 06/05/ /05/2014 Asignación de Roles 24 horas 06/05/ /05/2014 Implementación de Daily Meeting 32 horas 09/05/ /05/2014 Implementación de Backlog 36 horas 15/05/ /05/2014 Socialización de Formatos 24 horas 21/05/ /05/2014 Reunión con Gerencia 8 horas 21/05/ /05/2014

133 121 Reunión con Desarrollo 8 horas 22/05/ /05/2014 Reunión con Soporte 8 horas 23/05/ /05/2014 Gestión del Proyecto 216 horas 26/05/ /07/2014 Acta de Proyecto 8 horas 26/05/ /05/2014 Alcance de Proyecto 16 horas 27/05/ /05/2014 EDT 16 horas 29/05/ /06/2014 Cronograma 16 horas 03/06/ /06/2014 Análisis de Interesados 24 horas 05/06/ /06/2014 Informes estado de proyecto 32 horas 10/06/ /06/2014 Seguimiento y Control 60 horas 16/06/ /06/2014 Pruebas de Metodología con Proyecto Piloto 36 horas 27/06/ /07/2014 Aprobación 8 horas 04/07/ /07/2014

134 122 Anexo 6: EDT DEL PROYECTO Actualización de Metodología para Administración de Proyectos con enfoque en desarrollo ágil