Marco ágil para PMI en pequeñas y medianas empresas de desarrollo de software 1

Transcripción

1 Marco ágil para PMI en pequeñas y medianas empresas de desarrollo de software 1 Luis Bastidas 2, Álvaro Zapata 3 Resumen El presente trabajo de investigación no se desarrolla en una organización en particular dado que los lineamientos y recomendaciones resultantes serán de utilidad en un marco ágil para PMI en pequeñas y medianas empresas de desarrollo de software Las tecnologías de Información juegan un papel clave en esta evolución y presentan nuevas herramientas e iniciativas de apoyo a la administración de proyectos, las cuales deben adoptarse considerando las características y objetivos propios de la organización. Dado el creciente aumento de pequeñas y medianas empresas de software que se constituyen no cuentan con una oficina de proyectos y una metodología ágil que les ayude a desarrollar con orden y eficacia las diferentes etapas y procesos que involucra la dirección general de la empresa (planificación, organización, selección de personal, ejecución y control de las operaciones) y el ciclo de vida de los proyectos que administran, aunado con la influencia de nuevas tecnologías; surge la necesidad de implementar nuevas formas de trabajo para estos ambientes de desarrollo que involucren en forma natural la administración de proyectos ágil, sin dejar de lado la colaboración a distancia, el outsourcing, la mejora de calidad, generación y distribución de conocimiento y coordinación de varios proyectos, entre otras. Palabras claves. Metodología tradicional, Metodología Ágil, PMBOK, SCRUM, XP. 1 Esta investigación hace parte del trabajo de investigación de Luis Bastidas y Álvaro Zapata. 2 Candidato a Especialista en Gestión Integral de Proyectos de la Universidad San Buenaventura Seccional Cali. Contador Público de la universidad San Buenaventura lcarlos2050@gmail.com 3 Candidato a Especialista en Gestión Integral de Proyectos de la Universidad San Buenaventura Seccional Cali. Ingeniero de Sistema de la Universidad Antonio Nariño, azapata0216@hotmail.com

2 1. Introducción 1.1. Situación Cerca ya de dos (2) décadas el incremento en el uso de metodologías ágiles y la aplicación de metodologías tradicionales para la administración de proyectos en el desarrollo de software, ha causado un dilema a una gran cantidad de pequeñas y medianas empresas de desarrollo de software: identificar cuál método es más efectivo y eficiente a la hora de desarrollar los proyectos. Esta gran confusión se da debido a que cada método tiene sus propias técnicas, que en ciertos casos son muy afines a los principios de administración de proyectos, pero que en otros casos son muy diferentes y van en contravía con los mismos. Los métodos ágiles rompen el paradigma de que son solo una forma de desarrollar software, estos van más allá, ya que requieren de la aplicación de enfoques particulares de administración de proyectos. La forma en que son aplicados, cambia las interacciones en que patrocinadores, usuarios y stakeholders se comprometen en un proyecto. De igual forma los enfoques ágiles emplean diferentes procesos para la planificación, ejecución y control. (Letelier Patricio, 2006) Ante la necesidad de las PYMES de aplicar las técnicas ágiles para el desarrollo de software y cumplir con los principios y las recomendaciones del PMBOK 4TH_EDITION, se elabora este proyecto de investigación para documentar, analizar y proponer un marco de trabajo, que contribuya al desarrollo más ameno en los proyectos. Para lograr el cumplimiento de los objetivos planteados, se espera hacer una revisión del material existente y bibliografía sobre las metodologías agiles y tradicionales existentes para la administración de proyectos de desarrollo de software. El desarrollo de este proyecto de investigación se centra concretamente en identificar los beneficios y características, respecto al uso de metodologías ágiles para la administración de proyectos de software, al alinearlos con el marco de referencia del PMBOK 4TH_EDITION.

3 1.2. Administración de proyectos bajo PMI Según el PMBOK 4TH_EDITION, un proyecto es un esfuerzo que se lleva a cabo para crear un producto, servicio o resultado único, y tiene la característica de ser naturalmente temporal, es decir, que tiene un inicio y un final establecidos. (P.M.I., 2008) Qué es el PMBOK? PMBOK es el estándar para la Administración de Proyectos y cuyas siglas significan en inglés Project Management Body of Knowledge (el Compendio del Saber de la Gestión de Proyectos en español).(p.m.i., 2008). Éste a su vez puede ser entendido como una colección de sistemas, procesos y áreas de conocimiento que son universalmente aceptados y reconocidos como los mejores dentro de la gestión de proyectos. La tabla No. 1 describe los diferentes conceptos de dirección de proyectos emitidos por distintos autores. Tabla 1. Cuadro conceptual de la dirección de proyectos. Autor Concepto Descripción PMI Erly Delgado Expósito Omar Higinio Caballero Cervantes Michele Sliger Desarrollo de estándares para la Administración de Proyectos. Metodologías de desarrollo de software. Cuál es el camino? Tecnologías de información y herramientas para la administración de proyectos de Software. Relación a las prácticas del PMBOK prácticas ágiles El PMI desarrolla estándares de la profesión Project Management alrededor de todo el mundo. Uno de sus más conocidos estándares la Guide to the Project Management Body of Knowledge (PMBOK Guide) es mundialmente reconocida y está aprobada como un estándar por el American National Standards Institute (ANSI). El PMI está enfocado en la expansión del conjunto de conocimientos de la profesión Project Management a través de encuestas propias, investigaciones externas, una base de datos de información. Adicionalmente, necesidades, información, conocimientos y mejores prácticas son recolectados y distribuidos. Hoy en día existen numerosas propuestas metodológicas que inciden en distintas dimensiones del proceso de desarrollo. Un ejemplo de ellas son las propuestas tradicionales centradas específicamente en el control del proceso. Estas han demostrado ser efectivas y necesarias en un gran número de proyectos; sobre todo, en aquellos proyectos de gran tamaño (respecto a tiempo y recursos). La experiencia ha demostrado que las metodologías tradicionales no ofrecen una buena solución para proyectos donde el entorno es volátil y donde los requisitos no se conocen con exactitud, porque no están pensadas para trabajar con incertidumbre. En el siglo pasado innumerables áreas de Tecnología han tenido progresos considerables, pero una se destaca sobre las demás, no porque haya dejado de existir o por que se haya convertido en una innovación radical, sino porque ha cambiado tanto que apenas es reconocible a la situación en la que se encontraba hace 10 años: la Administración de Proyectos. Los profesionales PMP de la gestión de proyectos tradicionales atraviesan algunas dificultades a medida que hacen la transición de enfoques impulsados por el plan a las nuevas metodologías ágiles. Irónicamente, para todas las diferencias en Project Management Institute (PMI) y las filosofías ágiles, se ha encontrado que muchas de las prácticas identificadas en la Dirección de Proyectos del Conocimiento (PMBOK) son totalmente compatibles con las prácticas ágiles. Fuente. Elaboración propia a partir de la lectura de los autores mencionados anteriormente.

4 1.4. Síntesis de los grupos de procesos del PMBOK. La tabla No. 2 muestra el nombre del grupo, el objetivo, la descripción y la conclusión de la administración de proyectos basado en las mejores prácticas mencionadas en el PMBOK. Tabla 2. Grupo de procesos para la administración de proyectos basados en las mejores prácticas del PMBOK. Grupo Objetivo Descripción Conclusión Iniciación Definir los Este grupo está compuesto por aquellos procesos procesos para realizados para definir un nuevo proyecto o un nuevo empezar una nueva fase de un proyecto ya proyecto. existente mediante la autorización para empezar dicho proyecto o fase. En esta fase se define el alcance inicial y se comprometen los recursos financieros iniciales, se identifican los interesados internos y externos que van a interactuar o ejercer una influencia en el proyecto y se selecciona el director del proyecto, toda esta información se documenta en el Acta de Constitución del Proyecto y Registro de Interesados. Cuando el Acta de Constitución es Aprobada el proyecto se considera autorizado. Planificación Establecer el alcance del proyecto Ejecución Realizar y/o completar el trabajo definido en el plan para la dirección de proyectos. Monitoreo y Realizar Control seguimiento, analizar y regular el progreso y el desempeño del proyecto. Es el mayor grupo de procesos pues es donde se define el alcance en base a los requisitos estableciendo la estructura desglosada de trabajo o EDT; se define la secuencia, recursos y duración de las actividades estableciendo el cronograma del proyecto; se estiman los costos estableciendo el presupuesto del proyecto; se identifican los riesgo; y el plan de respuesta para dichos riesgos; además de planificar la calidad, los recursos humanos, las comunicaciones y adquisiciones que luego serán integrados todos juntos en el plan de gestión del proyecto. Es donde se consumen la mayor cantidad de recursos y del presupuesto del proyecto, coordinando todas las actividades para ejecutar el trabajo del proyecto asegurando que se cumplan todos los objetivos definidos y que la información sea distribuida a todos los interesados según el plan establecido para las comunicaciones. Un aspecto fundamental para la buena marcha de un proyecto son las actividades de supervisión, inspección, análisis y corrección a través de la identificación de aquellos aspectos del proyecto que requieran realizar cambios preventivos o correctivos y así estar mejor preparados para desviaciones que podrían presentarse durante la gestión del proyecto. Involucrar a los clientes o interesados, desde la fase de iniciación, mejora la probabilidad de obtener propiedad compartida, en la aceptación de entregables con la satisfacción del cliente e interesados. Bajo este grupo de procesos se desarrolla el plan para la dirección del proyecto y los documentos que se utilizan para llevarlo a cabo. A medida que se recopilan o comprenden más detalles del proyecto, puede ser necesaria mayor planificación. A estos procesos repetitivos y continuos de planificación se les denomina planificación gradual. Éste grupo de procesos implica coordinar personas y recursos, así como integrar y realizar actividades del proyecto en conformidad con el plan para la dirección del proyecto. - Controlar los cambios y recomendar acciones preventivas para evitar posibles problemas. - Monitorear las actividades del proyecto, comparándolas con el plan y la línea base para el desempeño del proyecto. - Influir en los factores que pueden eludir el control integrado de cambios de modo que únicamente se implementen

5 Cierre Fuente. PMI Finalizar todas las actividades a través de todos los grupos de procesos, a fin de cerrar formalmente el proyecto o una fase del mismo. Asegura el cierre formal del proyecto obteniendo la aceptación del cliente o usuario final y consiguiendo que se concluyan todas las actividades comprometidas en el proyecto, realizando la documentación de las lecciones aprendidas y el archivo físico o electrónico de toda la información relacionada a los entregables que se constituirán en los activos de la organización. cambios aprobados. - Obtener la aceptación del cliente o del patrocinador. - Realizar una revisión tras el cierre del proyecto o la finalización de una fase. - Registrar los impactos de la adaptación de un proceso. - Documentar las lecciones aprendidas. - Archivar todos los documentos relevantes del proyecto en el sistema de información para la dirección de proyectos. - Cerrar las adquisiciones Síntesis de las áreas de conocimiento del PMBOK. La tabla No. 3 muestra el área, la descripción y objetivo de las áreas de conocimiento basado en las mejores prácticas mencionadas en el PMBOK. Tabla 3. Áreas del conocimiento de la administración de proyectos Área Descripción Objetivos Gestión de la Integración Gestión del Alcance Gestión del Tiempo Gestión del Costo Describe los procesos requeridos para asegurar que los elementos varios de un proyecto están coordinados apropiadamente. Consiste en el desarrollo de un plan de proyecto, ejecución del plan de proyecto, y el control de cambios en general. Describe el proceso requerido para asegurar que el proyecto incluye todo el trabajo, para completar el proyecto de manera exitosa. Consiste en la iniciación, planeación del alcance, definición del alcance, verificación del alcance, y control de cambio al alcance Describe los procesos requeridos para asegurar la terminación a tiempo del proyecto. Consiste en la definición de las actividades, secuencia de las actividades, estimación de duración de las actividades, desarrollo del cronograma y control de la programación. Describe los procesos requeridos para asegurar que el proyecto es completado dentro del presupuesto aprobado. Consiste en la planificación de recursos, estimación de costos, presupuesto de costos, y control de costos. - Integrar y coordinar todo el proyecto, planear y crear un documento constante, coherente. - Realizar el plan del proyecto, realizando todas las actividades. - Control a los cambios que coordinan a través del proyecto entero - Autorizar el proyecto o la fase. - Desarrollar una declaración escrita del alcance como la base para las decisiones futuras del proyecto. - subdividir los entregables principales del proyecto en componentes más pequeños, más manejables. - Formalización de la aceptación del alcance del proyecto. - Cambios que controlan al alcance del proyecto - Identificar las actividades específicas que se deben realizar en cada una de las fases del proyecto. - Estimar el número de períodos del trabajo que serán necesarios para terminar actividades individuales. - Analizar secuencias de la actividad, duraciones de la actividad, y requisitos de recurso de crear el horario del proyecto. - Controlar cambios al horario del proyecto. - Determinar qué recursos (gente, equipo, materiales) y qué cantidades de cada uno se deben utilizar para realizar actividades del proyecto. - Desarrollar una aproximación (estimación) del costo de los recursos que se necesita para terminar actividades del proyecto.

6 Gestión de la Calidad Gestión del Recurso Humano Gestión de Comunicaciones Gestión del Riesgo Gestión de Adquisiciones Fuente. PMI Describe los procesos requeridos para asegurar que el proyecto satisfaga las necesidades, para lo cual fue desarrollado. Consiste en la planeación de la calidad, seguranza de la calidad, y control de calidad. Describe los procesos requeridos para hacer el uso más eficiente de las personas involucradas en el proyecto. Consiste en la planeación organizacional, adquisición de staff, y desarrollo del equipo. Describe los procesos requeridos para asegurar la generación apropiada a tiempo, almacenamiento y la disposición final de la información del proyecto. Consiste en la planeación de la comunicación, distribución de la información, reportes de desempeño, y el cierre administrativo. Describe los procesos concernientes con la identificación, análisis, y respuesta al riesgo del proyecto. Consiste en la identificación del riesgo, cuantificación del riesgo, desarrollo de la respuesta al riesgo, y en el control de la respuesta al riesgo. Describe los procesos requeridos para adquirir bienes y servicios de fuera de la organización ejecutora. Consiste en la planeación de la gestión de la adquisición, planear la selección de proveedores, administración de contratos, y cierre de contratos. - Controlar al presupuesto de proyecto - Identificar que estándares de calidad son relevantes al proyecto y determinar cómo satisfacerlos. - Asegurar que el proyecto satisfaga los estándares de calidad relevantes. - Supervisar el proyecto para determinar que esté cumpliendo los estándares. - Identificar, documentar, y asignar papeles del proyecto, responsabilidades, y relaciones de divulgación. - Conseguir los recursos humanos necesarios para trabajar en el proyecto. - Identificar las habilidades del individuo y del grupo para asignar roles en el proyecto. - Determinar la información y las necesidades de comunicaciones para el equipo de proyecto (quién, que, cuando y como necesita la información). - Hacer que la información necesaria esté disponible para proyectarla al equipo del proyecto de una manera oportuna. - Generar, recolectar, y diseminar la información para formalizar la terminación de la fase o del proyecto. - Determinar qué riesgos pudieran afectar el proyecto y la documentación de sus características. - Realizar análisis cualitativo de riesgos y dar prioridad a aquellos que afecte los objetivos del proyecto. - Medir la probabilidad y las consecuencias de los riesgos y estimar sus implicaciones para los objetives del proyecto. - Planear respuesta efectivas al posible riesgo - Determinar qué adquirir y cuando. - Documentar requisitos del producto e identificar fuentes potenciales. - Identificar el vendedor potencial. - Administrar la relación con el vendedor. - Administrar los contratos. - Cerrar el contrato 1.7. Administración de proyectos con Metodología ágil. Cada vez más, los estudios y las experiencias demuestran que la forma tradicional, de la administración de proyecto de desarrollo de software, es errónea en las actuales circunstancias y necesidades de dinamismo y adaptabilidad de los sistemas de software. Por tal motivo, ha surgido la necesidad de investigar y desarrollar nuevas técnicas que tienden hacia el rápido desarrollo de aplicaciones y que la vida útil de un producto sea más corta. En un entorno dinámico, inestable, que tiene como principal protagonista el cambio y una evolución rápida y continua, la ventaja competitiva se encuentra en aumentar la productividad para satisfacer las necesidades del cliente en el menor tiempo posible para agregar valor al negocio (Boehm, 2006).

7 1.8. El Manifiesto Ágil. El Manifiesto Ágil, promulga que están poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y ayudando a otros a que lo hagan ; tras la reunión de Utah, un documento que resume la filosofía ágil estableciendo cuatro valores y doce principios (Tabla No. 4). La tabla No. 4 Describe como el Manifiesto comienza enumerando los principales valores del desarrollo ágil Tabla 4. Principales valores del desarrollo Ágil A los individuos y su interacción, por encima de los proceso y las herramientas. La gente es el principal factor de éxito de un proyecto software. En resumen, es más importante construir un buen equipo que construir el entorno. El software que funciona, por encima de la documentación exhaustiva. Aunque un software sin documentación es un desastre, la regla a seguir es no producir documentos a menos que sean estrictamente necesarios. La colaboración con el cliente, por encima de la negociación contractual. Se evita el fracasar por intentar cumplir unos plazos y unos costos preestablecidos al inicio del proyecto. Por ello, se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. La respuesta al cambio, por encima del seguimiento de plan. La habilidad de responder a los cambios que puedan surgir a lo largo del proyecto, determina también el éxito o fracaso del mismo. Fuente: (Letelier Patricio, 2006) 1.9. Conceptos Metodología Ágil. La tabla No. 5 describe los diferentes conceptos emitidos por distintos autores de metodologías ágiles. Tabla 5. Cuadro Conceptual de metodologías agiles PERIODO AUTORES BREVE DESCRIPCIÓN ALGUNAS REFERENCIAS CLAVES Gustavo Martinez Muchas metodologías ágiles ya operaban en estos años, pero no tenían reconocimiento y las empresas o desarrolladores no las utilizaban, porque no eran confiables y no habían sido probadas. - Martinez, Gustavo (2011) Hirotaka Describieron una nueva aproximación holística que incrementa la rapidez y la flexibilidad en el desarrollo de nuevos productos comerciales, denominada SCRUM. Es comparado con el rugby, donde el equipo entero «actúa como un sólo hombre para intentar - Chin, Gary (2004).

8 Takeuchi llegar al otro lado del campo, pasando el balón de uno a otro» Ikujiro Nonaka James Womack Daniel T. Jones Daniel Roos 2001 Kent Beck Define un método llamado Lean Development (LD), en el cual los cambios se consideran riesgosos, pero si se manejan adecuadamente se pueden convertir en oportunidades que mejoren la productividad del cliente. Su principal característica es introducir un mecanismo para implementar dichos cambios. Impulsa un movimiento, donde diecisiete críticos de los modelos iterativo e incremental, de desarrollo de software, basados en procesos, se reunieron en Salt Lake City, Utah, para tratar sobre técnicas y procesos para desarrollar software; como resultado nace el Manifiesto ágil, donde a todo el movimiento, se le da el nombre de Metodologías Ágiles. -Mary Poppendieck, Michael A. Cusumano, "Lean Software Development (2003). - o.org -Letelier Patricio, P. M. (2006, 01 15) Miembros del Manifiesto ágil Establecen la Alianza Ágil, una organización sin fines de lucro, que promueve el desarrollo ágil de aplicaciones y da apoyo a todas las Metodologías Ágiles, que surgen como alternativa a las metodologías tradicionales. rg Fuente: Elaboración propia a partir de investigaciones de los autores arriba mencionados Metodología ágil Scrum Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos. En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales. (Albaladejo, 2009). La figura No. 1 se muestra los grupos de procesos utilizados en scrum.

9 Figura 1. -Grupo de procesos de SCRUM (Ortega, 2010 ) PMBOK Fase Subfase SCRUM Release Sprint En la tabla No. 6 se describe por componente los participantes y el esquema utilizado en Scrum. Tabla 6. Grupo de componentes para la administración de proyectos con SCRUM. SCRUM Componentes Participantes Esquema Roles en Scrum Roles Principales Product Owner: Representa la voz del cliente. Se asegura de que el equipo Scrum trabaje de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de usuario, las prioriza, y las coloca en el Product Backlog. Scrum Master (o Facilitador): Su trabajo primario es eliminar los obstáculos que impiden que el equipo alcance el objetivo del sprint. El Scrum Master no es el líder del equipo (porque ellos se autoorganizan), sino que actúa como una protección entre el equipo y cualquier influencia que le distraiga. El Scrum Master se asegura de que el proceso Scrum se utiliza como es debido. El Scrum Master es el que hace que las reglas se cumplan. Equipo de desarrollo: El equipo tiene la responsabilidad de entregar el producto. Un pequeño equipo de 3 a 9 personas con las habilidades transversales necesarias para realizar el trabajo (análisis, diseño, desarrollo, pruebas, documentación, etc). El equipo debe ser Auto - Gestionado Auto - Organizado y Multi Funcional.

10 Reuniones de Scrum Roles Auxiliares Son aquellos que no tienen un rol formal y no se involucran frecuentemente en el "proceso Scrum", sin embargo deben ser tomados en cuenta. Participantes: Producto Owner + Scrum Manager + Equipo Duración: 1 jornada de trabajo. Participantes: Equipo + Scrum Manager (los demás solo pueden mirar) Duración: 15 minutos (es dirigida por el Scrum Manager) Participantes: Todos. Duración: 4 horas aproximadamente. Stakeholders (Clientes, Proveedores, Vendedores, etc): Se refiere a la gente que hace posible el proyecto y para quienes, el proyecto producirá el beneficio acordado que justifica su producción. Sólo participan directamente durante las revisiones del sprint. Usuarios (Administradores, otros): Son aquellas personas para las que se desarrolla el producto. Planificación del Sprint (Sprint Planning) Seleccionar qué trabajo se hará. Preparar, con el equipo completo, el Pila del Sprint (lista de historias incluidas en el Sprint), que detalla el tiempo que tomará hacer el trabajo. Identificar y comunicar cuánto del trabajo es probable que se realice durante el actual Sprint. Fijar una fecha para la Demo del Sprint. Reunión diaria (Daily Scrum) La reunión comienza puntualmente a su hora. Todos son bienvenidos, pero sólo los involucrados en el proyecto pueden hablar. La reunión debe ocurrir en la misma ubicación y a la misma hora todos los días. Durante la reunión, cada miembro del equipo contesta a tres preguntas: Qué has hecho desde ayer? Qué es lo que harás hasta la reunión de mañana? Has tenido algún problema que te haya impedido alcanzar tu objetivo? Revisión del Sprint (Sprint Review) Revisar el trabajo que fue completado y no completado Presentar el trabajo completado a los interesados (alias demo ) El trabajo incompleto no puede ser demostrado Retrospectiva del Sprint (Sprint Retrospective) Después de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los miembros del equipo dejan sus impresiones sobre el sprint recién superado. El propósito de la retrospectiva es realizar una mejora continua del proceso. Artefactos de Scrum Pila del producto (Product Backlog) : Es un documento de alto nivel para todo el proyecto. Contiene descripciones genéricas de todos los requisitos, funcionalidades deseables, etc. priorizadas según su retorno sobre la inversión (ROI). Es abierto y solo puede ser modificado por el product owner. Contiene estimaciones realizadas a grandes rasgos, tanto del valor para el negocio, como del esfuerzo de desarrollo requerido. Esta estimación ayuda al product owner a ajustar la línea temporal (KEV) y, de manera

11 (Schwaber, 1995) - (Albaladejo, 2009) limitada, la prioridad de las diferentes tareas. Pila del sprint (Sprint Backlog) : Es un documento detallado donde se describe el cómo el equipo va a implementar los requisitos durante el siguiente sprint. Las tareas se dividen en hora; donde ninguna tarea debe superar a 16 horas. Si una tarea es mayor de 16 horas, deberá ser dividida en otras menores. Las tareas en el sprint backlog nunca son asignadas, son tomadas por los miembros del equipo del modo que les parezca oportuno. Trabajo pendiente (Burndown chart): Es una gráfica mostrada públicamente, que mide la cantidad de requisitos en el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una línea que conecte los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal es que esta línea sea descendente (cuando los requisitos están bien definidos desde el principio y no varían nunca) hasta llegar al eje horizontal, momento en el cual el proyecto se ha terminado (no hay más requisitos pendientes). Si durante el proceso se añaden nuevos requisitos la recta tendrá pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos la pendiente variará Mapeando las prácticas del PMI al marco de trabajo SCRUM Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un estudio de la manera de trabajar de equipos altamente productivos. Las siguientes tablas describen un mapeo de algunas áreas de conocimiento del PMBOK y las prácticas de SCRUM, esto indica que podría ser posible administrar proyectos de corto y mediano plazo con una metodología ágil pero enfocada en las prácticas mencionadas en el PMBOK. La tabla No. 7 muestra la práctica mapeada del área de conocimiento Gestión de la integración en PMBOK a su equivalente en SCRUM. Tabla 7. Práctica mapeada del área de conocimiento Gestión de la integración en PMBOK a su equivalente en SCRUM. Área de Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente Gestión de la Integración Desarrollar lanzamiento del proyecto donde se define, justifica y autoriza el proyecto. El Product Owner y el equipo desarrollan el Roadmap del producto, la visión y el Backlog.

12 Desarrollar un plan formal de gestión del proyecto Dirigir y gestionar la ejecución del proyecto conforme el plan. Monitorear y controlar el proyecto. Realizar el control de cambios del proyecto. Cerrar el proyecto o la fase. Cierres administrativos o auditorios. El equipo desarrolla el Release-plan a alto nivel y con más detalle el plan para el siguiente Sprint. El equipo ejecuta y entrega. El Scrum Master se encarga de asegurar que se cumplan los principios de Scrum. En vez de dirigir y gestionar a los equipos, los equipos se auto-dirigen usando revisiones de sprint, retrospectiva y ajustan el proceso (mejora continua). El Control de cambios se lleva por parte del Product Owner y el equipo, por medio del Product backlog ordenado. Hay un constante Feedback durante la iteración y la revisión. Revisiones de Sprint/Retrospectiva del proyecto. Si hace falta un cierre administrativo, se usará un Sprint n + 1 (en caso de ser necesario). (P.M.I., 2008) - (Albaladejo, 2009) Un Director de Proyecto tradicional es responsable de hacer que todos los procesos de esta área de conocimiento se realicen bajo un mismo patrón de gestión. Un Scrum Master tiene una función un poco más ligera, es responsable de hacer que el equipo trabaje para definir la planificación y las iteraciones. El Director de proyecto en un ambiente ágil, deberá aprender a ceder el control. La tabla No. 8 muestra la práctica mapeada del área de conocimiento Gestión del alcance en PMBOK a su equivalente en SCRUM. Tabla 8. Práctica mapeada del área de conocimiento Gestión del alcance en PMBOK a su equivalente en SCRUM. Área de Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente Gestión del Alcance Identificar los requisitos. Obtener y documentar los requisitos funcionales del trabajo a realizar Definir el Alcance. Entregables, lo que está incluido, lo que no está incluido, restricciones, excepciones y dependencias. Crear la WBS. Desarrollar y ordenar el Product Backlog. Seleccionar los ítems del Product Backlog que se incluyen en cada release o Sprint. Crear una descomposición de las características para el reléase, mostrando las que se incluyen en cada reléase. Descomponer las características por Sprint.

13 Verificar el Alcance (Aceptación formal, cambios en los requerimientos, etc.) Control del Alcance. A través de mecanismos de aceptación de las características del Sprint (por el product owner), se puede utilizar herramientas de trazabilidad y el propio Product Backlog. Gestionarlo vía Product Backlog. Proteger la iteración. (P.M.I., 2008) - (Albaladejo, 2009) La gestión del alcance es inherente al proceso SCRUM, se gestiona desde el Product Backlog. Scrum mantiene fijo el tiempo y los costos y lo único negociable es el alcance el cual es fijado al inicio del Sprint. La tabla No. 9 muestra la práctica mapeada del área de conocimiento Gestión del tiempo en PMBOK a su equivalente en SCRUM. Tabla 9. Práctica mapeada del área de conocimiento Gestión del tiempo en PMBOK a su equivalente en SCRUM. Área de Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente Definir Actividades: Identificar las acciones específicas a ser realizadas para elaborar los entregables del proyecto. Establecer la Secuencia de las Actividades: identificar y documentar las interrelaciones entre las actividades del proyecto El equipo selecciona las características que se van a incluir en el Sprint, las tareas necesarias para cumplir con esas funcionalidades son identificadas. El equipo durante el Sprint Planning Meeting realiza la secuencia necesaria de actividades y su estimación. Gestión del Tiempo Estimar las actividades a realizar Desarrollar el Cronograma: Analizar la secuencia de las actividades, su duración, los requisitos de recursos y las restricciones del cronograma del proyecto. Controlar el cronograma: Hacer seguimiento al proyecto para actualizar el avance del mismo y gestionar cambios a la línea base del cronograma. Desarrollar el calendario de lanzamiento y solo las características que son incluidas en el Sprint se desarrollan y estiman (Just-in-time planning). Las estimaciones se refinan basándose en datos empíricos (velocidad del equipo). El equipo es el que gestiona las características que serán desarrolladas en cada sprint. (P.M.I., 2008) - (Albaladejo, 2009)

14 SCRUM no plantea un plan definido totalmente desde el inicio del proyecto, sino que se va adecuando a medida que avanza el tiempo. La tabla No. 10 muestra la práctica mapeada del área de conocimiento Gestión de Costos en PMBOK a su equivalente en SCRUM. Tabla 10. Práctica mapeada del área de conocimiento Gestión de Costos en PMBOK a su equivalente en SCRUM. Área de Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente Estimar los Costos: Consiste en desarrollar una aproximación de los recursos financieros necesarios para completar las actividades del proyecto. Estimar a alto nivel los reléase y los sprint usando veocidad, días ideales, analogías, opiniones de expertos, etc. Estimar detallado cada sprint más adelante para validar las estimaciones a alto nivel. Gestión de Costos Determinar el presupuesto: sumar los costos estimados de actividades individuales o paquetes de trabajo para establecer una línea base de costos autorizada. Controlar los costos: Monitorear la situación del proyecto para actualizar el presupuesto del mismo y gestionar cambios a la línea base de costos. Refinar las estimaciones cuando el equipo va a comenzar el trabajo. Crear una línea base de costos después de realizar las estimaciones. Revisar la línea de costos después de un par de sprint (conocemos ya la velocidad del equipo). Usar gráficos de Burndown como ayuda para el control de los costos. (P.M.I., 2008) - (Albaladejo, 2009) El control de los costos es una función del equipo con el product owner involucrado en la estimación junto al equipo. En SCRUM las estimaciones se realizan a alto nivel (top-down) de todo el proyecto y luego son refinados en el ciclo de vida del proyecto. La tabla No. 11 muestra la práctica mapeada del área de conocimiento Gestión de la Calidad en PMBOK a su equivalente en SCRUM. Tabla 11. Práctica mapeada del área de conocimiento Gestión de la Calidad en PMBOK a su equivalente en SCRUM. Área de Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente Gestión de Planificar la calidad: se identifican los requisitos de calidad y/o normas La calidad está implícita a lo largo de todo el proceso de Scrum. (test temprano y frecuente, software que

15 Calidad para el proyecto y el producto, documentando la manera en que el proyecto demostrará el cumplimiento con los mismos. Realizar el aseguramiento de la calidad: auditar los requisitos de calidad y los resultados de las medidas de control de calidad. Asegurar que se utilicen las normas de calidad. Realizar el control de calidad: Se monitorean y registran los resultados de la ejecución de actividades de control de calidad, a fin de evaluar el desempeño y recomendar cambios necesarios. funciona, eliminación de impedimentos) La calidad es responsabilidad de todo el equipo. Generalmente la lleva a cabo el equipo. En entornos formales puede haber un tercero implicado. Se usan Sprint/Projects Reviews y retrospectiva. Realizado por el propio equipo, usando herramientas de TDD. El Product Owner también realiza QA por medio de las revisiones. Test de aceptación como parte del Product Backlog (las historias de usuario deben incluir los test de aceptación). (P.M.I., 2008) - (Albaladejo, 2009) La calidad es algo implícito en las prácticas de SCRUM, es muy importante estar mentalizado para construir y mantener software de calidad, para lo que hace falta el esfuerzo y compromiso del equipo. El hecho de usar Ágil no es sinónimo de Calidad. Debemos apoyar las prácticas con herramientas que sirvan para garantizarla, con una buena estrategia de pruebas, con un enfoque a TDD (Test Driven Development) y con la mentalidad del equipo para hacer las cosas bien a la primera.. La tabla No. 12 muestra la práctica mapeada del área de conocimiento Gestión del Recurso Humano en PMBOK a su equivalente en SCRUM. Tabla 12. Práctica mapeada del área de conocimiento Gestión del Recurso Humano en PMBOK a su equivalente en SCRUM. Área de Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente Gestión del Recurso Humano Desarrollar el plan de Recursos Humanos: Identificar y documentar los roles dentro de un proyecto, responsabilidades etc. Adquirir el equipo del proyecto: Confirmar personas, disponibilidad y formar el equipo para completar las asignaciones del proyecto. Desarrollar el equipo del proyecto: competencias, interacciones de los En Scrum se define el tamaño del equipo para la duración completa del proyecto. Los equipos no suelen ser muy grandes (5 +- 2). Si el proyecto es muy grande se crearan sub-equipos. El equipo es multifuncional. Se crea al inicio del proyecto y se mantiene intacto hasta el final del mismo. Valores Scrum: Compromiso, coraje, respeto, foco y

16 miembros del equipo y el ambiente del equipo para lograr un mejor desempeño del proyecto. Dirigir el equipo del proyecto: Desempeño del equipo, proporcionar retroalimentación, resolver problemas y gestionar cambios a fin de optimizar el desempeño del proyecto. franqueza. Fomentar la auto organización del equipo. Facilitar un coach que ayude a auto gestionar al equipo. Juega el rol de un líder. (P.M.I., 2008) - (Albaladejo, 2009) Los equipos son dedicados, multifuncionales y auto organizados. El Scrum master actúa como líder. La tabla No. 13 muestra la práctica mapeada del área de conocimiento Gestión de la Comunicación en PMBOK a su equivalente en SCRUM. Tabla 13. Práctica mapeada del área de conocimiento Gestión de la Comunicación en PMBOK a su equivalente en SCRUM. Área de Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente Gestión de Comunicación Identificar a los interesados: Registro de los intervinientes y estrategia para su gestión. Plan de comunicación: necesidades de comunicación de los interesados. Distribución de Información: Poner la información a disposición de los interesados. Gestión de Expectativas. Información sobre el desempeño: Recopilar y distribuir la información sobre el desempeño mediante informes, gráficos, etc. Identificar a los interesados y definir quién es el representante del negocio (Product Owner) que forma parte del equipo Scrum. Los gráficos Burndown, los backlog de proyecto y de Sprint son indicadores visuales del estado del proyecto Los indicadores visuales del estado del proyecto son los radiadores de información La gestión de los intervinientes es realizado por el Product Owner que es parte del equipo Scrum. Los indicadores visuales de Scrum son los que informan sobre el estado del proyecto. (P.M.I., 2008) - (Albaladejo, 2009) Es una de las principales diferencias entre los Proyectos Tradicionales y los Proyecto Scrum, en los primero los métodos de comunicación son más formales, en Scrum los intervinientes son informados a través de los indicadores visuales y una comunicación cara a cara y frecuente.

17 La tabla No. 14 muestra la práctica mapeada del área de conocimiento Gestión del Riesgo en PMBOK a su equivalente en SCRUM. Tabla 14. Práctica mapeada del área de conocimiento Gestión del Riesgo equivalente en SCRUM. Área de Proceso/Práctica PMI Conocimiento en PMBOK a su Proceso/Práctica SCRUM equivalente Gestión del Riesgo Planificar la gestión del Riesgo: Definir el plan de riesgos del proyecto y las estrategias que se seguirán, metodologías, categorías, tolerancias... Identificar los Riesgos: Inventariar todos los posibles riesgos que se puedan presentar en el proyecto. Realizar el Análisis Cualitativo/Cuantitativo de Riesgos. Planificar la respuesta al Riesgo Monitorear y controlar los Riesgos Informar el Risk Planning como parte de Sprint/Release Planning y reuniones de revisión. El quipo entero está involucrado. Identificar los riesgos en las reuniones diarias, revisiones de iteraciones y de planificación. Analizar en conjunto los riesgos. No se prescriben métodos formales. Se puede usar cualquier método como por ejemplo probabilidad x impacto. Eludir, mitigar, transferir, aceptar: no hay diferencia. En Scrum es parte de las tareas del equipo en las revisiones y planificaciones. (P.M.I., 2008) - (Albaladejo, 2009) En cuanto a Riesgos, no hay una práctica concreta de Riesgos dentro de un proyecto Scrum. Lo más significativo es que todo el equipo participa en la identificación, seguimiento y mitigación de los riesgos. Uno de los momentos en los que aparecen es en las reuniones diarias de equipo. Lo que de aquí se derive como riesgo, será seguido y controlado por el Scrum Master (disipador de impedimentos, entre otras cosas). La tabla No. 15 muestra la práctica mapeada del área de conocimiento Gestión de Compras en PMBOK a su equivalente en SCRUM. Tabla 15. Práctica mapeada del área de conocimiento Gestión de Compras en PMBOK a su equivalente en SCRUM. Área de Conocimiento Proceso/Práctica PMI Proceso/Práctica SCRUM equivalente Gestión de Compras Planificar adquisiciones: Documentar las decisiones de compra para el proyecto, El equipo proporciona información necesaria para las adquisiciones usando una iteración temprana o una

18 especificando la forma de hacerlo e identificando a posibles vendedores. Realizar las adquisiciones: Obtener respuestas de los vendedores, seleccionar un vendedor y adjuntar un contrato. Administrar las adquisiciones: Gestionar las relaciones de adquisiciones, monitorear la ejecución de los contratos, y efectuar cambios y correcciones según sea necesario. Cerrar las adquisiciones Prueba de Concepto (PoC). El equipo realiza las evaluaciones y proporciona información para la contratación. Esta práctica estará dirigida por el líder del Proyecto. Scrum permite contratos con una cláusula de terminación temprana (money for nothing) en donde un cliente puede terminar un contrato al final de cualquier Sprint pagando el 20-30% del valor restante del contrato. Otro modelo es Change for free en el cual el cliente puede hacer cambios en el ámbito sin incurrir en costos adicionales si el monto total contratado no cambia. Puede usarse un Sprint adiciona (n+1) para el cierre formal administrativo. (P.M.I., 2008) - (Albaladejo, 2009) Las principales diferencias con los Proyectos Tradicionales se dan en los modelos de contrato. Se elaboran contratos de diversos tipos para proporcionar flexibilidad a los clientes que contratan el proyecto. Es la gestión de Compras quizás lo más controvertido cuando se habla de un proyecto con Scrum. Se tiene la idea de que la flexibilidad y variabilidad del alcance que está siempre en el aire cuando se va a contratar con un proveedor (en el caso de externalizaciones) un proyecto bajo Scrum plantea dificultades de cara a la fijación de un presupuesto entre ambas partes. Hay varios modelos de contrato que se adaptan a los proyectos en ambientes Ágiles, por ejemplo Target Cost es uno de ellos. 2. Metodologia El alcance de la investigación es de tipo Analitico-Sintetico por que se realiza separación de un todo en sus partes o en sus elementos constitutivos y luego se unen los elementos para formar un todo. Para realiza la recolección de la información, se realizó entrevista a dos Pymes de desarrollo de software que trabajan como terceros para Gases de Occidente, las preguntas se realizadas fueron claves para identificar qué de metodología utilizan en sus proyectos de desarrollo de software. Se realiza investigación sobre cada uno de los procesos definidos como buenas prácticas por el PMBOK y la manera como algunas compañías utilizan la metodología de SCRUM. Con esta información se realiza un mapeo entre cada uno de los procesos del PMBOK y los proceso utilizados en SCRUM. Una vez realizado el mapeo entre PMBOK y SCRUM se procedió a redactar la monografía con el mapeo realizado.

19 3. Resultados En primer lugar, aborda el proyecto siempre con enfoque incremental. Hay que romper con la dinámica establecida del ciclo de vida en cascada (waterfall). Puede que esto sea lo que más rompa con la metodología actual de Análisis, Diseño, Construcción y Pruebas. Si ahora cuando se afronta una planificación de un proyecto lo que se debe hacer es que hasta que no finalices una etapa no empiezas la otra, debemos cambiar este concepto. Puede ser complicado al principio, pero enfocarse en crear valor para el usuario/cliente de manera rápida, lo cual se traduce en implementar funcionalidades y características del producto que se está desarrollando antes de haber terminado, por ejemplo todo el análisis del mismo. Es decir, se crea mini-waterfall y entrega producto por incrementos. Está claro que para hacer esto, en primer lugar se debe disponer de los elementos principales de la arquitectura de un producto con plena operatividad, lo cual obliga a tener implantadas las piezas base, los elementos indispensables del core del proyecto para que sobre ellos pueda desplegar las funcionalidades de manera incremental. El enfoque de miniwaterfall puede ser útil en entornos de proyecto donde los formalismos de la Gestión del proyecto son más estrictos: administraciones públicas, entidades financieras etc. donde hay unos patrones metodológicos más rígidos que cumplir. Sobre todo piensa en qué cosas son más importantes y aportan más valor para el cliente/usuario para ir desplegando de una manera gradual los incrementos de producto. Aplicar las técnicas Ágiles poco a poco: puede ser complicado pretender cambiar de golpe y aplicar todas las prácticas al mismo tiempo. Introduce las técnicas de una en una, y una vez que las conozcas todas y se esté familiarizado con ellas, podrá decidir cuáles son las que le pueden dar una mejor aproximación. Ejemplo: 1) La creación de un tablón Scrum donde ir llevando las tareas (tablón físico, con su post-it de colores o un tablón virtual, apóyate en cualquiera de las muchas herramientas que existen en el mercado para este fin). 2) La reunión diaria de equipo alrededor del tablero en donde cada uno de los miembros informa a los demás que lo que ha hecho el día anterior, lo que hará en el siguiente día y los problemas o impedimentos que se ha encontrado para realizar la tarea. Familiarizarse con estas dos prácticas y luego, poco a poco, incluir el resto de prácticas. Preparase para el cambio total: una vez que se haya preparado el proyecto con enfoque incremental y se haya implantado con éxito las dos o tres prácticas más útiles, piense si el equipo está preparado para realizar un cambio total. Esta es una aproximación con más beneficios que las implementaciones parciales, pero implica un cambio más radical y es algo que no se consigue de la noche a la mañana. Todo lleva su tiempo. Esto requiere un cambio de mentalidad en la organización, pues vas a tener que conseguir vender Ágil a tus clientes/usuarios. Necesitará capacitación en otras técnicas Agiles como Técnicas de Planificación de Planning Poker, Técnicas para la definición de Historias de Usuario, Técnicas y herramientas para la elaboración de gráficos de seguimiento y planificación de Sprints, Técnicas para la definición del Backlog o Pila de producto,

20 Retrospectivas, etc. La recomendación es que si se está empezando con Scrum, se deberá tomar con calma, se aplique poco a poco e ir inspeccionando y adaptando. No hay una receta única, no hay un proyecto único, no hay un equipo único, pero tiene que haber una conciencia de cambio, una mentalidad de aportar valor desde el principio y muchas ganas de mejorar.

21 4. Conclusiones Para que un grupo de desarrollo adopte una metodología ágil debe poseer experiencia trabajando con metodologías tradicionales, ya que la experiencia es la que predomina en los momentos cruciales del proyecto, además deben tener la capacidad de ser equipos auto-gestionados, altamente motivados y con gran innovación. Las metodologías de dirección de proyectos son pesadas y que suponen obligatoriamente un todo o nada. Las metodologías ágiles son más modernas y más livianas que cualquiera de las tradicionales. Las metodologías ágiles se deberían aplicar en proyectos donde exista mucha incertidumbre de un entorno volátil, donde los requisitos no se conocen con exactitud, mientras que las metodologías tradicionales de dirección de proyectos obligan al cliente a tomar las decisiones al inicio del proyecto. Como último comentario se puede decir que No existe una metodología universal para hacer frente con éxito a cualquier proyecto de desarrollo de software. Toda metodología debe ser adaptada al contexto del proyecto (recursos técnicos y humanos, tiempo de desarrollo, tipo de sistema, etc.).

22 5. Glosario Scrum RoadMap - (Que podría traducirse como hoja de ruta) es una planificación del desarrollo de un software con los objetivos a corto y largo plazo, y posiblemente incluyendo unos plazos aproximados de consecución de cada uno de estos objetivos Sprint que es la unidad básica, el contenedor del proceso de desarrollo, por lo general tiene una duración de 2 semanas, a veces puede ser 3. Product Owner el director (s) del producto que crea las necesidades de los usuarios. Product Backlog una lista priorizada de las necesidades de los usuarios, generalmente se ordena con base en el valor generado a la empresa. Sprint Planning Meeting (SPM) precede a la Sprint y Sprint se inicia con SPM, donde el propietario del producto presenta. Planning Poker Un juego de la estimación. Para cada caso de usuario una serie de rondas de estimaciones suceda, hasta que sólo queden 2 tarjetas de estimación planteadas. y el valor superior es elegido como el punto de la historia del usuario de que la historia del usuario. Baseline User Story una historia de usuario que se ha seleccionado como línea de base. Otras historias de los usuarios suelen ser evaluados en relación a esta historia de usuario. Siempre es recomendable escoger una historia de usuario con 3 o 5 puntos de la historia de usuario. Spike Una investigación. Algo que no es una historia de usuario, pero tiene una consecuencia. Ejemplo incluye, si una historia de usuario no se puede implementar porque hay ciertas incertidumbres. Entonces Spike se organiza cuando el equipo se ve en eliminar las incertidumbres. Sprint Review Meeting (SRM) La reunión con la que el Sprint concluye. En el SRM el equipo presenta las historias de los usuarios para el propietario (s) del producto. User Story La descripción, por lo general en una frase de lo que el Propietario Usuario / producto quiere lograr, seguido de una lista de criterios de aceptación. También puede incluir imágenes, dibujos. Definition of Done (DoD) Una lista de criterios que las tareas tiene que encajar con el fin de ser marcado como realizadas. Example: User Story Definition of Done - significa las siguientes tareas deben ser realizadas en un caso de usuario: Se cumplen todos los criterios de aceptación Implementación terminado La revisión de código que lleva a cabo Pruebas unitarias escritas La prueba funcional se ha realizado Las pruebas de integración se escriben / realizadas Área Regresión prueba se realiza