ISSN 0798 1015
ISSN 0798 1015
Vol. 40 (Nº 11) Año 2019. Pág. 4
RESTREPO PÉREZ, Marisella 1; REYES GAMBOA, Adriana X. 2
Recibido: 18/11/2018 • Aprobado: 17/02/2019 • Publicado 08/04/2019
RESUMEN: Los gerentes y patrocinadores han encontrado falencias en el seguimiento y control de los proyectos que gestionan con SCRUM dado que no les es fácil conocer el estado en el que se encuentran. En este artículo se propone un modelo que integre las diferentes herramientas y técnicas utilizadas en el PMBOK con la metodología SCRUM, buscando de esta manera que SCRUM cubra las necesidades de conocer el avance del proyecto en las áreas de tiempo, costos y recursos. |
ABSTRACT: Managers and sponsors have found weaknesses in the monitoring and control of the projects they manage with SCRUM given that it is not easy to know the state in which they are. This article proposes a model that integrates the different tools and techniques used in the PMBOK with the SCRUM methodology, seeking in this way that SCRUM covers the needs to know the progress of the project in the areas of time, costs and resources. |
SCRUM es una metodología para gestión, mejora y mantenimiento de un sistema nuevo o existente, se concentra en cómo los miembros del equipo deberían funcionar a fin de producir un sistema flexible en un entorno que cambia constantemente (Beck, Kent, et al., 2016). Un principio clave de SCRUM es el reconocimiento de que durante un proyecto los participantes pueden cambiar de idea sobre lo que quieren y necesitan, y que los desafíos impredecibles no pueden ser fácilmente enfrentados de una forma predictiva y planificada. Por lo tanto, SCRUM adopta una aproximación pragmática, aceptando que el problema no puede ser completamente entendido o definido (Schwaber, 2004). En contra parte, la gestión de proyectos se enfoca en la planeación, definición del alcance y el seguimiento y control constante de los proyectos, teniendo un porcentaje de flexibilidad e incertidumbre muy bajo (Project Management Institute, 2013).
En todos los proyectos independientemente de la metodología utilizada para desarrollarlos, existen unos patrocinadores y gerentes que requieren conocer unas variables principales tales como el tiempo, los costos, recursos, alcance, que le ayudan a determinar el estado del proyecto y para alinearlo con la estrategia organizacional, pero específicamente en muchos proyectos desarrollados con SCRUM, no se tienen en cuenta dichos ítems para controlar el trabajo a asignar a los miembros del equipo, puesto que es el equipo de desarrollo quienes estiman y adquieren el compromiso a adquirir acorde a su capacidad.
En este artículo se propone incluir las técnicas y herramientas utilizadas en la gestión de proyectos según el PMBOK en el marco de trabajo SCRUM, buscando incorporar al marco los elementos que sean necesarios para cubrir las necesidades que tienen los patrocinadores de conocer el progreso de los proyectos que gestionan con SCRUM. Este artículo se encuentra organizado en cuatro secciones, la primera presenta la introducción al artículo, la segunda corresponde al marco conceptual que presenta el área de investigación que abarca este trabajo y la revisión de literatura, la tercera presenta los resultados de la investigación, y por último se presentan las conclusiones de este trabajo.
2.1.1. Gestión de Proyectos: La gestión de proyectos es el uso de conocimientos, habilidades y técnicas para ejecutar proyectos de manera eficaz y eficiente. Se trata de una competencia estratégica para organizaciones, que les permite vincular los resultados de un proyecto con las metas comerciales para posicionarse mejor en el mercado. La mayoría de los autores de literatura de gestión de proyecto concuerdan en que la gestión de proyecto se trata de establecer y, después, alcanzar (o superar) objetivos de tiempo, costo y desempeño (calidad). Por lo que una definición posible sería: Las habilidades y los procesos de planificación y control necesario para finalizar un proyecto con recursos del proyecto respetando o mejorando los límites de tiempo, costo, calidad y seguridad a un nivel de riesgo aceptable (Wallace, 2014).
Es un marco de trabajo por el cual las personas pueden abordar problemas complejos adaptativos, a la vez que entregar productos del máximo valor posible productiva y creativamente. Scrum es:
Scrum es un marco de trabajo de procesos que ha sido usado para gestionar el desarrollo de productos complejos desde principios de los años 90. No es un proceso o una técnica para construir productos; en lugar de eso, es un marco de trabajo dentro del cual se pueden emplear varios procesos y técnicas. Scrum muestra la eficacia relativa de las prácticas de gestión de producto y las prácticas de desarrollo de modo que podamos mejorar. El marco de trabajo Scrum consiste en los Equipos Scrum y 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. Las reglas de Scrum relacionan los eventos, roles y artefactos, gobernando las relaciones e interacciones entre ellos (Schwaber & Sutherland, 2013).
A continuación se nombran algunos artículos referentes a la integración de la gestión de proyectos PMBOK con SCRUM:
Dentro de la literatura analizada se destacan las investigaciones realizadas por el autor Ghosh (2012) quien propone la mejora del PMBOK al compararlo con los estándares de gestión de proyectos de las metodologías ágiles P2M, ICB, PRINCE2, APM y SCRUM. P. Fitsilis (2008) compara un conjunto genérico de procesos utilizados en el PMBOK con una serie de procesos que se tienen en cuenta en la gestión de proyectos ágiles. El resultado es que las metodologías ágiles de gestión de proyectos no pueden considerarse completas, desde el punto de vista de gestión de proyectos tradicional, puesto que faltan varios procesos o no se describen explícitamente. Díaz et al. (2017) realizan el estudio de las diferentes metodologías tradicionales y ágiles para determinar cuál es la más apropiada en la gestión de los proyectos desarrollados por la empresa VoiceCenter que implementa soluciones integrales de software y hardware para la gestión telefónica de contactos y transacciones telefónicas mediante la respuesta de voz interactiva, determinando finalmente que la metodología SCRUM es la que más se acopla a las necesidades y reglas de negocio de dicha empresa. Medina (2017) integra los distintos conceptos metodológicos y buenas prácticas propuestas por el Project Managemet Institute (PMI) a través de su guía PMBOK 5ta Edición y el marco de trabajo SCRUM para la Gestión de Proyectos dentro de una Empresa de Base Innovadora y Tecnológica (EBIT). Concluye que estos marcos no son excluyentes, por el contrario se complementan y que la efectividad de cada una depende de la adaptación de sus procesos a las necesidades de los diferentes tipo de empresas. Alfonzo et al. (2012) exponen una propuesta generada como superación de una diseñada ad-hoc probada previamente, para ser tratada a través de las prácticas y actividades de una metodología ágil como SCRUM. Se describen las diferentes fases de las dos metodologías con el fin de gestionar y controlar el proceso de desarrollo de software. Godoy (2014) presenta el subsistema de gestión de tareas como parte de un “Modelo de Simulación Dinámico de Gestión de Proyectos de Desarrollo de Software Bajo SCRUM”, el cual puede ser utilizado como herramienta para evaluar el impacto de políticas alternativas de gestión y la detección de cuellos de botella. Nazareno et al. (2016) propone un modelo de trazabilidad basado en las prácticas de SCRUM, que permitió representar las trazas existentes entre los artefactos generados durante procesos SCRUM. Godoy et al. (2014), presenta un ejemplo de la utilización de un Modelo Dinámico de Simulación como herramienta de ayuda en la gestión de proyectos de desarrollo de software llevados a cabo con la metodología SCRUM. El modelo permite a los SCRUM Masters y el Team analizar el efecto del uso conjunto de la metodología SCRUM, Bloques de Tiempo, Artefactos y Reglas en la gestión de los mismos en diferentes escenarios. Cortes (2017) propone integrar algunas de las buenas prácticas de la metodología PMI en el desarrollo de los proyectos de la fábrica de software y recurrir a fortalecer la dinámica de trabajo con las recomendaciones de la metodología SCRUM en el desarrollo del producto, para la Fábrica de Software de la Fundación Cardiovascular de Colombia (FCV). Como trabajo futuro, se propone la estrategia de tener un perfil o rol dentro de la Fábrica de Software, como Gestor de Proyectos de Software. Velásquez et al. (2017) seleccionan a la empresa Greensqa para realizar la identificación y análisis de riesgos, a través de la metodología ágil SCRUM, debido a que metodologías como la propuestas en el PMBOK implican realizar una planificación detallada, en la cual se identifican los riesgos, se realiza un análisis cualitativo y cuantitativo y se utilizan una serie de diferentes técnicas y herramientas, con el fin de generar un plan de respuesta a los riesgos, con el objetivo de poderlos controlar. A través del modelo se mejora la gestión de riesgos en proyectos de pruebas de Software, específicamente en los componentes de tiempo, presupuesto, comunicación y herramientas metodológicas empleadas. Guzmán et al. (2016), desarrollan una propuesta metodológica de gestión de proyectos basada en las buenas prácticas de SCRUM y el PMBOK, como una guía para la gestión de proyectos reduciendo la probabilidad de fracaso de los proyectos. Concluyen que la metodología de gestión de proyectos propuesta y ninguna otra metodología aseguran el éxito de un proyecto, ya que implica mucho en la habilidad del Jefe de Proyecto, el compromiso y respaldo de la alta dirección y la respuesta al cambio organizacional que generará al adoptarse esta metodología. Villalta (2018) realiza una guía de procedimientos encaminados a la toma de decisiones en dirección a la gestión de los recursos humanos y económicos; además se elaboró una lista o matriz implícita en donde se identificaron los riesgos ocurridos en esta fase. Está metodología fue aplicada a través de técnicas prácticas tales como reuniones diarias, asignación de roles otorgando responsabilidad a un integrante de cada módulo, constante comunicación, capacitaciones, entre otros, logrando así gestionar a los recursos de forma ágil y ordenada. Rodríguez et al. (2018) analizan algunas de las metodologías ágiles más usadas: Kanban, Lean Project Management, Scrum, XP y Canvas, definiendo el funcionamiento de cada una, y analizando su capacidad de integración en procesos específicos del PMBOK. El análisis permitió explorar la utilidad de los métodos ágiles dentro de diferentes procesos y áreas de conocimiento, detectándose una alta dependencia del nivel de integración con el tipo de proyecto y su nivel de incertidumbre, definida en términos genéricos en una elevada utilidad en proyectos expuestos a cambios durante su desarrollo, pero presentando riesgos de déficit de documentación e información en proyectos de grandes dimensiones. Uribe (2018) establece un enfoque holístico para vincular las mejores técnicas, herramientas, procedimientos y normas del Project Management Institute (PMBOK), con las metodologías ágiles de desarrollo de software, para mayor eficiencia en la gestión de proyectos. En este sentido, el aporte científico de la investigación está precisamente, en la propuesta de un modelo para la integración del PMBOK a las metodologías ágiles como apoyo a la dirección de proyectos de desarrollo de software, realizando el análisis de la situación actual, el estudio teórico conceptual de la guía del PMBOK y los métodos ágiles, así como el análisis de los criterios de selección de las metodologías. La propuesta se comprueba al implementarse en un proceso de gestión de proyectos si se considera que como resultados esperados, la gestión de proyectos debe ser estructurada, planificada en base a la optimización de tiempos y recursos. Palacios (2014) crea una guía de fundamentos para la dirección de proyectos de desarrollo de software para la empresa SiaciSolutions S.A., la cual dará solución a los problemas de la empresa al momento de elaborar proyectos para sus clientes. Se analizaron casos de estudio y de éxito que permitieron conocer las buenas prácticas y metodologías de dirección de proyectos mundialmente utilizadas en los últimos tiempos. Además, debido a los buenos resultados y la gran acogida que han tenido por su flexibilidad y facilidad de uso, se analizaron la Guía de fundamentos de proyectos del Project Management Institute: PMBOK 5TA Edición, y la metodología ágil híbrida SCRUM/XP. A continuación, se formularon y aplicaron encuestas de opinión dirigidas al personal técnico y directores de proyectos de la empresa. Con los resultados obtenidos se pudo corroborar la presencia del problema, las brechas existentes y las necesidades de mejora de la dirección de proyectos per se; los mismos que han permitido desarrollar la guía de fundamentos para la gestión de proyectos de desarrollo de software dentro de las restricciones de alcance, tiempo, costo, calidad, riesgos y recursos humanos; facilitándole a la empresa la obtención de altos niveles de satisfacción para sus clientes. Jiménez (2016) construye un producto generalizado de fácil entendimiento, para comercializar en organizaciones o centros académicos donde exista un interés en entrenar o adelantar proyectos maduros y profesionales de manera ágil en entornos digitales, dicho producto unificó los elementos claves tanto del marco de referencia provisto por el PMI como de la metodología ágil para desarrollo de software Scrum, bajo una dinámica interactiva con aplicación para entornos digitales, en términos de su contenido, sus convenciones y sus reglas. Cabe destacar que el análisis no sugiere cambios en la base común del marco de referencia del PMI, como tampoco de la metodología Scrum, y tampoco pretende emitir juicios asociados a la gerencia de proyectos, sobre las prácticas actuales utilizadas en las organizaciones, desde las perspectivas tradicionales y ágiles en entornos digitales.
En la figura 1 se presentan las diferentes etapas que se deberán seguir para la construcción del modelo de seguimiento y control propuesto:
Figura 1
Etapas del modelo propuesto
Fuente: Elaboración propia
La Guía del PMBOK® describe la naturaleza de los procesos de la gestión de proyectos en términos de la integración entre los procesos, de sus interacciones y de los propósitos a los que responden. Los procesos de la dirección de proyectos se agrupan en cinco fases: Inicio, Planificación, Ejecución, Monitoreo y Control y Cierre. Los 47 procesos de la dirección de proyectos se agrupan a su vez en diez Áreas de Conocimiento: 4. Gestión de la Integración del Proyecto, 5. Gestión del Alcance del Proyecto, 6. Gestión del Tiempo del Proyecto, 7. Gestión de los Costos del Proyecto, 8. Gestión de la Calidad del Proyecto, 9. Gestión de los Recursos Humanos del Proyecto, 10. Gestión de las Comunicaciones del Proyecto, 11. Gestión de los Riesgos del Proyecto, 12. Gestión de las Adquisiciones del Proyecto y 13. Gestión de los Interesados del Proyecto. Los procesos fueron numerados en este artículo acorde como se encuentran numerados en la Guía del PMBOK® — Quinta edición.
El objetivo de esta etapa es determinar cuáles procesos, prácticas y herramientas del PMBOK se acoplan al marco SCRUM. En la tabla 1 se presentan los procesos elegidos agrupados por fases, los cuales se seleccionaron con base en el análisis de 8 trabajos presentes en la revisión de la literatura que tenían como objetivo integrar prácticas del PMBOK al marco SCRUM, se tendrán en cuenta los procesos que coincidieron en 3 o más trabajos. Cabe notar que después de elegir los procesos a aplicar, no ha quedado ninguno del área de conocimiento de gestión de las adquisiciones. A pesar de que solo 2 autores tuvieron en cuenta los procesos de controlar el cronograma y los costos, en este artículo si se anexarán, puesto que se considera de acuerdo a la revisión literaria que son dos ítems requeridos para la consecución exitosa de un proyecto. Se pasa de tener 47 procesos en el PMBOK a seleccionar 22 para integrar al marco SCRUM.
Tabla 1
Procesos de PMBOK seleccionados para integrar a SCRUM
Fuente: Elaboración propia
Después de elegir los procesos, actividades y herramientas que generen valor en el marco SCRUM se procede a establecer las actividades del PMBOK dentro del marco de manera que fluyan de forma ágil en las actividades ya conocidas en SCRUM. Es decir, se incorporan en las fases y ceremonias existentes en SCRUM (Inception, Refinamiento, Planning, Review, Sprint, Retrospectiva), los diferentes procesos elegidos del PMBOK para permitirle a los gerentes visualizar el estado en el que se encuentra el proyecto. En la figura 2 se presenta el resultado de la integración de los procesos del PMBOK en las fases de SCRUM. Se agregan en el modelo las actividades propias de SCRUM, las cuales estarán marcadas con un “*” y los procesos seleccionados, quedando en total 30 actividades a desarrollar divididas dentro de las fases mencionadas.
Figura 2
Modelo propuesto
Fuente: Elaboración propia
Se tomó como base el proceso iterativo e incremental planteado en SCRUM, pero tomando los procesos que se definen en el PMBOK igualándolo a las fases del marco ágil, con el fin de lograr un marco efectivo que continúe otorgando entregas tempranas de valor a los interesados del proyecto y que ayude a los gerentes a visualizar el progreso de los proyectos para lograr que sean alineados a las estrategias organizacionales, además de que le ayudará a los gerentes a involucrarse más con los riesgos, que en SCRUM son llamados impedimentos y que muchas veces deben ser solucionados por el equipo del proyecto y en caso de que el equipo no lo logre, por el SCRUM Master. El modelo propuesto presenta las fases descritas en la figura anterior, el cual integra procesos existentes en el PMBOK con el marco SCRUM, dentro del modelo se decide continuar manejando las fases de SCRUM y allí anexar los procesos elegidos manteniendo la identidad del marco: Inception, Refinamiento, Planning, Review, Sprint, Retrospectiva.
El objetivo del modelo propuesto es evitar la informalidad manejada actualmente en los proyectos gestionados con SCRUM. De esta manera se logrará alinear a los equipos de desarrollo ágil con las necesidades de los gerentes y patrocinadores y por ende a la estrategia organizacional de las compañías. A continuación, se presentan entonces los procedimientos a seguir en cada una de las fases de SCRUM con los nuevos procesos sugeridos a llevar a cabo dentro de cada una de ellas. Dichas fases son llamadas dentro del marco como ceremonias, por lo que se continuarán llamando de esa manera. Los roles que se manejarán dentro del modelo son los siguientes:
Realizar el acta de constitución del proyecto es una tarea fundamental tanto en el marco SCRUM como en el PMBOK, sin embargo, para SCRUM es determinante que dicha acta sea realizada por todos los miembros del equipo, para ello se crea la ceremonia del inception, en la que es presentado el objetivo del proyecto a todos los miembros que ejecutarán el mismo. Antes de dicha ceremonia deberán estar definidas las historias de usuario que ingresarán al product backlog, la arquitectura del proyecto, el equipo de trabajo, los interesados del proyecto. Para ello antes de dar inicio a la ceremonia para presentarle al equipo el proyecto, se deberán reunir los miembros del equipo de producto para determinar cómo se planteará el proyecto, cuál será el alcance, qué definiciones tendrá, cuál será el producto mínimo viable y qué historias de usuario épicas desarrollará el equipo SCRUM. Estando en la ceremonia, el product owner procede a explicarle al equipo el alcance del proyecto, mostrará las historias de usuario propuestas y el equipo comenzará a revisarlas para dar una estimación a alto nivel sobre cuántos sprints podría tomarle finalizar los incrementales para entregar el producto mínimo viable definido por todos los asistentes a la reunión. También se realizará una actividad llamada el vecindario en la que se determina cuáles otros interesados además de los asistentes a la reunión están implicados en el proyecto y cómo se llevarán a cabo las comunicaciones en el transcurso del proyecto, quienes asistirán a las ceremonias, quienes deberán estar informados en los diferentes temas del proyecto etc., se determinarán los riesgos en conjunto, los cuales serán gestionados durante el transcurso del proyecto y estarán cambiando constantemente en las reuniones diarias. Al finalizar la ceremonia se realizará un entregable llamado la definición de terminado del inception en el cual se determine el cierre del inception, en el que el objetivo es que se determine cuántos sprints tomará la finalización del producto mínimo viable, hasta que no se finalicen todas las actividades del inception, este no podrá darse por terminado y no se podrá dar inicio a la planeación del sprint. En dicho entregable se entregarán la arquitectura del proyecto, los riesgos identificados, los interesados, las historias épicas y el producto mínimo viable, con este documento se da inicio a la fase de planeación del sprint. Además, el gerente tendrá como insumo la estimación a alto nivel otorgada por el equipo y las historias de usuario generadas por el product owner para definir el cronograma del proyecto y los costos del mismo para su posterior monitoreo y control, dicha información quedará consignada en el acta de constitución del proyecto y en el plan para la dirección del proyecto, será información que tendrá el gerente para la toma de decisiones y para generar un monitoreo y control de dichos ítems en las siguientes ceremonias. En la figura 3 se presentan los procesos a desarrollar en el inception catalogados por el responsable de desarrollarlos:
Figura 3
Procesos del inception
Fuente: Elaboración propia
Después de darse por finalizado el inception, se procederá a realizar la ceremonia de refinamiento, en la que el product owner lleva las historias de usuario a desarrollarse en el siguiente sprint. Las historias de usuario serán leídas al equipo de desarrollo quién determinará si cumplen con el principio INVEST (Independiente, Negociable, Valiosa, Estimable, Pequeña, Testeable), en caso de que no lo cumplan, se deberán organizar las historias para presentarlas en la ceremonia de planning. A esta ceremonia deberán asistir el equipo SCRUM y el equipo de producto. Toda persona que requiera que el equipo de desarrollo genere una tarea deberá asistir al refinamiento para que sus historias de usuario sean ingresadas en el planning, de lo contrario el equipo de desarrollo no podrá ejecutar tareas externas a los compromisos adquiridos dentro del planning. En esta ceremonia el gerente de proyecto deberá velar porque en el siguiente sprint ingresen las historias de usuario planeadas en el inception, de lo contrario la planeación en cuanto a costos y cronograma realizada por él en la ceremonia anterior se comenzará a desplazar en el tiempo y en dinero, los cuales son ítems vitales para el desarrollo del proyecto, cabe aclarar que el gerente siempre debe estimar tiempos y costos con una holgura, teniendo en cuenta la flexibilidad en cuanto a cambios permitida en este marco de trabajo. El gerente también deberá estar al tanto de los cambios solicitados por el product owner y usuarios, puesto que no se deberán desviar del objetivo principal que es la implementación del producto mínimo viable, en esta revisión se deberá apoyar del SCRUM Master y equipo del proyecto. En la figura 4 se presentan los procesos a llevarse a cabo en la ceremonia de refinamiento:
Figura 4
Procesos del refinamiento
Fuente: Elaboración propia
En la fase de planeación se encuentra una de las mayores diferencias entre el marco SCRUM y el PMBOK, puesto que mientras en la primera quien define las actividades que va a desarrollar es el equipo de desarrollo, en la segunda es el gerente del proyecto quien después de definirlas le asignará a cada recurso la actividad a implementar y el tiempo destinado que tiene para la misma. En este modelo el equipo de desarrollo continuará seleccionando las historias de usuario que ingresarán dentro del sprint, se resalta la importancia de que sea el mismo equipo quien defina a cuáles historias de usuario se compromete cumplir, teniendo en cuenta que son las mismas personas las que estiman y las que ejecutarán las tareas. Está ceremonia se divide en dos, en la primera parte el product owner se encargará de entregarle al equipo las historias de usuario priorizadas, las cuales fueron revisadas en la ceremonia anterior. En este punto el equipo de desarrollo se encargará de seleccionar las historias de usuario a las que se podrá comprometer, teniendo en cuenta la prioridad otorgada por el product owner; en la segunda parte de la ceremonia el equipo tendrá que desglosar las tareas requeridas para cumplir cada historia y posteriormente realizará la estimación para cada historia, contando con la incertidumbre que se tiene para cumplirla, el tiempo, los recursos involucrados y la complejidad de la misma. De igual manera el product owner define los criterios de aceptación de la historia de usuario los cuales serán insumos necesarios para plantear las pruebas a realizarle a la misma, cumpliendo con el criterio INVEST de que la historia deberá ser Testeable, de esta manera en esta ceremonia se acuerda el alcance a darle a las pruebas del incremento del producto. Tener en cuenta que el compromiso adquirido por el equipo tendrá las fases de diseño, desarrollo y pruebas, por lo que las historias de usuario deberán tener un alcance tan pequeño para cumplir en el mismo sprint con dichas fases de desarrollo. En la figura 5 se describen los procesos a seguir para la ceremonia del planning:
Figura 5
Procesos del planning
Fuente: Elaboración propia
El sprint es el periodo de tiempo en el que el equipo debe desarrollar las historias de usuario comprometidas dentro del planning, este tiempo puede estar entre 2 a 4 semanas y es estándar, es decir en el inception se acuerda el periodo de tiempo en el que se generará el sprint y este tiempo será el establecido hasta finalizar el proyecto. Dentro de este tiempo el equipo estará ejecutando las tareas determinadas en el planning y se realizará la ceremonia del daily en la cual cada miembro del equipo le contará a sus compañeros las actividades realizadas el día anterior y las que implementará en el presente día, el equipo de desarrollo será el responsable de estar controlando y monitoreando el progreso del sprint con el fin de determinar cualquier alerta en caso de generarse algún riesgo que impida cumplir con el compromiso. El equipo presentará los impedimentos que tiene para el desarrollo de cualquier actividad que afecte el cumplimiento de las historias de usuario dentro del sprint, estos impedimentos deberán ser escalados al SCRUM Master quien deberá removerlos para que el equipo continúe con sus labores. En este modelo se propone que no sólo sea el SCRUM Master quien remueve impedimentos sino que también el gerente del proyecto esté enterado de los mismos y de igual manera sea quien le ayude al equipo a removerlos. El SCRUM Master le ayudará al equipo a desarrollarse con el fin de crear equipos de alto desempeño que sean auto gestionados y auto organizados. A continuación, en la figura 6 se muestran los procesos referentes a la fase del sprint:
Figura 6
Procesos del Sprint
Fuente: Elaboración propia
3.4.5. Procesos de la review
En la ceremonia de review el equipo de desarrollo le hace entrega al product owner, gerente e interesados, el incremento del producto, el cual deberá ser funcional, el ideal es que este incremento sea entregado en un ambiente productivo, pero teniendo en cuenta varias restricciones en cuanto a procesos organizacionales para la gestión de un paso a producción, este incremento se podrá entregar en un ambiente de calidad, siempre y cuando tenga las pruebas necesarias. De esta manera el product owner recibirá el incremento y revisará que cumpla con los criterios de aceptación presentes en la historia de usuario, cumpliendo así con el proceso de controlar la calidad. Está ceremonia será facilitada por el SCRUM Master quien deberá garantizar que todos los interesados asistan a ella cumpliendo con los procesos de controlar las comunicaciones, generando una comunicación cara a cara al estar presentes todos los interesados en la reunión.
En este modelo se propone la participación activa del gerente del proyecto en la ceremonia de review y que sea responsable de los procesos de controlar el alcance, el cronograma y los costos validando que la entrega del incremento cumpla con lo planeado en el inception y en caso de que no, advertir al product owner de que está agregando al sprint historias de usuario que no aplican para la consecución del objetivo que es llegar al producto mínimo viable en el tiempo y con los costos establecidos. De igual manera, el gerente deberá revisar si se está finalizando el presupuesto para solicitar más con los patrocinadores, teniendo en cuenta las retribuciones de dinero por las entregas de valor tempranas que ha generado el equipo. En la figura 7 se presentan los procesos a implementar en la review:
Figura 7
Procesos de la review
Fuente: Elaboración propia
La ceremonia de retrospectiva se realiza una vez finalizada cada iteración para revisar cómo se sintió el equipo y que ítems identifica que debe mejorar, el SCRUM Master se encargará de llevarle al gerente, product owner e interesados los puntos de mejora identificados por el equipo, los cuales serán trabajados en el siguiente sprint como parte del desarrollo y la mejora continua del equipo. En la última iteración del proyecto se entregará el producto final al cliente y se dará el cierre administrativo del proyecto, la última retrospectiva del proyecto se lleva a cabo para documentar y analizar las lecciones aprendidas y sugerencias para la mejora de los productos y procesos. Para iniciar el cierre es necesario disponer de los productos del proyecto, su documentación, entregas a las áreas de soporte y la firma de conformidad del destinatario, si es el caso. En la figura 8 se describe el proceso final del cierre del proyecto:
Figura 8
Procesos de la retrospectiva
Fuente: Elaboración propia
Los proyectos siempre deben ser controlados por los gerentes de proyectos para lograr que estos estén alineados con la estrategia organizacional de las empresas de desarrollo de software.
Con el modelo diseñado en este artículo, los gerentes y patrocinadores de los proyectos SCRUM, pueden visualizar el progreso de los proyectos que tienen a cargo y de esta manera tomar decisiones oportunas en cuanto a los ítems principales de la gerencia de proyectos, costos, tiempo y recursos.
Incorporar técnicas y herramientas de seguimiento y control del PMBOK en el marco de trabajo SCRUM permite mejorar el cumplimiento de las necesidades de tiempo y costo que tienen los gerentes y patrocinadores de los proyectos que se gestionan con SCRUM.
Como trabajo futuro se propone la implementación del modelo realizado en este artículo, dentro de una organización que tenga como metodología principal SCRUM y que sea validado por personas expertas tanto en la metodología SCRUM como en PMBOK para definir con el criterio adecuado si el modelo aplica y mejora la gestión de proyectos de software que se trabajan con la metodología SCRUM.
Alfonzo, P. L., Mariño, S., & Godoy, M. V. (2012). Propuesta metodológica para la gestión de proyecto de software ágil basado en la Web. Multiciencias, 11(4).
Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., ... & Kern, J. (2001). Manifesto for agile software development. Recuperado de: https://moodle2016-17.ua.es/moodle/pluginfile.php/80324/mod_resource/content/2/agile-manifesto.pdf
Cortes Pabón, Á. M. Lineamientos para la planeación y estimación de actividades en el marco de la Fábrica de Software de la Fundación Cardiovascular de Colombia (FCV) basados en metodología SCRUM y PMI.
Díaz, C., & Enrique, L. (2017). Propuesta metodológica para gestión de proyectos de desarrollo de software personalizado y marco de trabajo para soporte técnico de la empresa Voicecenter que presta soluciones de sistemas de Call Center(Master's thesis, Quito: Universidad de las Américas, 2017).
Fitsilis, P. (2008). Comparing PMBOK and Agile Project Management software development processes. In Advances in Computer and Information Sciences and Engineering (pp. 378-383). Springer, Dordrecht.
Ghosh, S., Forrest, D., DiNetta, T., Wolfe, B., & Lambert, D. C. (2012). Enhance PMBOK® by comparing it with P2M, ICB, PRINCE2, APM and Scrum project management standards. PM World Today, 14(1), 1-77.
Godoy, D. A., Belloni, E. A., Sosa, E. O., Kotynski, H., & Benítez, J. D. D. (2014). Evaluación de alternativas de gestión en proyectos de software desarrollados con scrum utilizando dinámica de sistemas. In XX Congreso Argentino de Ciencias de la Computación (Buenos Aires, 2014).
Godoy, D. A., Sosa, E. O., Belloni, E., & Kotinski, H. (2014). Simulación Dinámica de Gestión de Tareas en Proyectos Desarrollados Con Scrum. In II Congreso Nacional de ingenieria informatica/ingenieria de sistemas (CoNaIISI), Universidad Nacional de San Luis, San Luis (Vol. 2014).
Guzman Baños, E. V. (2016). Propuesta Metodológica usando SCRUM y PMBOK, para la gestión de proyectos de TI de la Jefatura de Informática de una Unidad Ejecutora del Sector Transportes.
Jiménez Pulido, J. F. (2016). Framework para consolidar las mejores prácticas al nivel de gerencia de proyectos en entornos digitales (Master's thesis, Universidad EAFIT).
Medina, R. (2017) Diseño de marco ágil para la dirección de proyectos de desarrollo de producto en una ebit integrando las mejores prácticas de Pmbok y Scrum. (Tesis de especialización) Universidad Militar Nueva Granada. Bogotá.
Nazareno, R., Bollati, V. A., Leone, H., & Gonnet, S. (2016). Modelo para la Automatización de Relaciones de Trazabilidad en Procesos Scrum.
Palacios, A., & Merchán, V. (2014). Guía de fundamentos para la dirección de proyectos de desarrollo de software con enfoque pmi y los métodos ágiles. Ecuador, Quito. Universidad de las Fuerzas Armadas ESPE.
Project Management Institute. (2013). Guía de los Fundamentos Para la Dirección de Proyectos (Guía del PMBOK®)-Quinta Edición (SPANISH). Project Management Institute.
Rodríguez Vázquez, E., & Diaz Varela, E. R. (2018). Integración de metodologías ágiles en la gestión del alcance y otras áreas de conocimiento de la dirección de proyectos.
Schwaber, K. (2004). Agile project management with Scrum. Microsoft press.
Schwaber, K., & Sutherland, J. (2013). La guía de scrum: La guía definitiva de scrum, las reglas del juego. Recuperado de http://www. scrumguides. org/docs/scrumguide/v1/Scrum-Guide-ES. pdf.
Uribe Campaña, L. M. (2018). Modelo de Integración del Project Management Body of Knowledge con las Metodologías Ágiles de Desarrollo de Software (Master's thesis, Pontificia Universidad Católica del Ecuador).
Velásquez, B., Camilo, S., Mora Castillo, A. M., Talero Niño, Á. H., & Valencia Ardila, O. R. (2017). Identificación y análisis de riesgos con metodología ágil Scrum, en la dirección de proyectos de pruebas de software en Bogotá, aplicado a la empresa Greensqa.
Villalta Andrade, S. M. (2018). Plataforma Tecnológica Para Contribuir A La Planeación Urbana En La Ciudad De Guayaquil Dirigido A La Transportación, Enfocado A La Gestión Del Recurso Humano Y Económico Del Proyecto Para La Gestión De Riesgos, Aplicando La Metodología Scrum (Doctoral dissertation, Universidad de Guayaquil. Facultad de Ciencias Matemáticas y Físicas. Carrera de Ingeniería En Sistemas Computacionales).
Wallace, W. (2014). Gestión de proyectos. Reino Unido.
1. Departamento de Ingeniería. Politécnico Colombiano Jaime Isaza Cadavid. Aspirante a Magister en ingeniería con énfasis en gestión de proyectos. marisella_restrepo82103@elpoli.edu.co
2. Departamento de Ingeniería. Politécnico Colombiano Jaime Isaza Cadavid. PhD. axreyes@elpoli.edu.co