- Alphadi Deutschland GmbH
- +49 561 949 189 0
- info@alphadi.org
La gestión clásica de proyectos (PMI) se orienta por fases, siguiendo planes fijos, lo que la hace ideal para proyectos estables. La gestión ágil, como SCRUM, trabaja de forma iterativa en sprints cortos, adaptándose continuamente a los nuevos requisitos. Mientras que PMI se centra en la estabilidad, SCRUM ofrece flexibilidad para proyectos dinámicos.
«A continuación encontrará un extracto de nuestro Blue Book, páginas 60-73 (PMI) y 174-186 (SCRUM)».
Un proyecto es una empresa única y limitada en el tiempo para producir un producto, servicio o resultado. Existen varios métodos de gestión de proyectos para llevarlos a cabo. A grandes rasgos, pueden dividirse en ágiles y clásicos.
Las razones para llevar a cabo un proyecto pueden ser muy diversas. Uno de los principales es crear valor empresarial. Un proyecto se lleva a cabo para cerrar una brecha. Por ejemplo, puede tratarse de problemas de calidad, de plazos o de la necesidad de nuevas innovaciones.
Se pueden gestionar proyectos que se influyen mutuamente como un programa y obtener beneficios mediante la coordinación conjunta. Así pues, un programa consta de varios proyectos interrelacionados. Una cartera es una colección de proyectos, programas y carteras individuales que son necesarios para alcanzar objetivos estratégicos. Los proyectos y programas individuales de una cartera no tienen por qué estar conectados entre sí. En una cartera más amplia, los proyectos, programas y carteras se gestionan conjuntamente.
Un proyecto puede ser realizado por una sola persona, pero también por un equipo. En proyectos complejos, trabajar en equipo es esencial, ya que más miembros del equipo tienen más competencias.
El director del proyecto es responsable de alcanzar los objetivos del proyecto y de dirigir al equipo. La organización designa a una persona como gestor del proyecto. El gestor del proyecto debe tener competencias en liderazgo, métodos de gestión de proyectos y habilidades de gestión estratégica/empresarial.
Aparte de los conocimientos y las capacidades blandas y duras, cada persona debe demostrar también un comportamiento adecuado. Los valores más importantes son:
Los directores de proyecto certificados por el PMI que no se adhieran a este código pueden ser denunciados. El Project Management Institute verifica el comportamiento sometiendo a la persona a un proceso disciplinario.
En los métodos de gestión de proyectos se distingue a grandes rasgos entre gestión de proyectos clásica y ágil. La gestión de proyectos clásica divide los procesos del proyecto en varias fases que se construyen unas sobre otras, es decir, una vez completada la primera fase, puede iniciarse la siguiente. Una fase es un conjunto de varias actividades que encajan lógicamente entre sí. Entre una fase y otra suelen tener lugar las «puertas de entrada» o «revisiones de puerta». En ellas se revisan los resultados de la fase. En la gestión ágil de proyectos, se procede de forma iterativa, es decir, se ejecutan varios bucles de iteración en los que cada vez se está un poco más cerca del objetivo del proyecto. Las iteraciones deben ser independientes entre sí, de modo que puedan llevarse a cabo en un orden variable, es decir, se intenta producir un producto parcial útil después de cada iteración.
El triángulo mágico muestra que el alcance (requisitos), los recursos y el tiempo de un proyecto dependen unos de otros y, por tanto, deben coordinarse. En los proyectos clásicos se dice que el alcance es fijo y en función de él se determinan los recursos y el tiempo. La mayoría de la gente se opondría a esto, porque a menudo el presupuesto y el tiempo de un proyecto se determinan primero. En un enfoque ágil, el alcance es variable. Ahora se puede debatir cómo es con el tiempo y los recursos: en SCRUM, el tiempo de un sprint es fijo. Debido al hecho de que las personas son principalmente necesarias como recursos (atención: esto se aplica especialmente en el desarrollo de software), estos también son fijos. O se puede argumentar que el número de sprints no es fijo, por lo que el tiempo no es fijo y, en consecuencia, los costes tampoco lo son. En los proyectos clásicos, el alcance del proyecto se define al principio, mientras que en los proyectos ágiles no.
Los proyectos se llevan a cabo en un entorno corporativo. Dado que cada empresa es diferente, la gestión de proyectos debe adaptarse a las circunstancias.
FEE son las siglas de «Factores del Entorno Empresarial». Se trata de condiciones del entorno interno y externo en las que no puede influir directamente el equipo del proyecto, pero que, a la inversa, repercuten en él.
Ejemplos de FEE internos:
Ejemplos de FEE externos:
OPA son las siglas de «Organizational Process Assets» (activos de procesos organizativos). Los activos de proceso de la organización describen los planes, procesos, políticas y procedimientos específicos de la empresa. Hay que tenerlos en cuenta a la hora de ejecutar proyectos.
Ejemplos:
La Oficina de Gestión de Proyectos (PMO) es una estructura organizativa que estandariza la ejecución de proyectos en términos de herramientas, procesos, procedimientos y liderazgo. La PMO puede ser un departamento o un individuo. La influencia de la PMO en la ejecución del proyecto puede adoptar diferentes formas. La PMO puede apoyar, controlar o instruir al director del proyecto.
Oficialmente, un proyecto suele comenzar con la orden de proyecto. Antes de que se firme la orden de proyecto, ya se está elaborando la información inicial, como los costes y beneficios del proyecto.
El fin natural de un proyecto es la consecución del objetivo del mismo, como la finalización de una casa. Pero también hay proyectos que nunca se terminan porque ya no hay recursos financieros disponibles, el resultado ya no es necesario, faltan los recursos o porque el objetivo del proyecto está legalmente obsoleto.
Podemos dividir los pasos necesarios durante un proyecto en cinco grupos de procesos: el grupo de procesos de inicio, el grupo de procesos de planificación, el grupo de procesos de ejecución, el grupo de procesos de seguimiento y control y el grupo de procesos de cierre. Estos grupos de procesos no se ejecutan consecutivamente, sino en paralelo. Dependiendo del momento del proyecto, hay más o menos tareas en los distintos grupos de procesos.
En este diagrama se puede ver la progresión en el tiempo y la magnitud del esfuerzo en distintos momentos. Al principio de un proyecto, hay muchas tareas en el grupo de procesos de iniciación y en el grupo de procesos de planificación. En las páginas siguientes, los grupos de procesos se revisan uno tras otro, aunque a menudo se ejecutan simultáneamente durante un proyecto.
SCRUM es un método ágil de gestión de proyectos. El origen de SCRUM se encuentra en el desarrollo de software. Los dos fundadores, Jeff Sutherland y Ken Schwaber, están detrás de SCRUM y de la Guía SCRUM, que describe qué es SCRUM exactamente. SCRUM se desarrolla continuamente. Los cambios se pueden ver en la última Guía SCRUM, que se puede encontrar gratuitamente en Internet.
SCRUM es un marco sencillo basado en los siguientes elementos:
La idea de SCRUM es desarrollar un producto en varios bucles temporales (iteraciones o sprints). Para ello, primero se recopilan los requisitos conocidos del producto en una lista, el backlog del producto. De la lista se seleccionan los elementos que pueden realizarse en el siguiente sprint o iteración. Durante el sprint, los requisitos se implementan de modo que al final se crea un producto parcial. Este se examina para identificar mejoras. El siguiente sprint comienza de nuevo con la selección de requisitos.
Aunque SCRUM tiene sus orígenes en el desarrollo de software, también puede aplicarse bien en otros ámbitos.
Un equipo SCRUM suele estar formado por diez personas o menos. En SCRUM se distinguen tres roles con distintas responsabilidades: el SCRUM Master, el Product Owner y los Developers. En cada equipo SCRUM hay un SCRUM Master, un Product Owner y varios Developers. También puede haber una doble asignación, por ejemplo, que el SCRUM Master sea también un Desarrollador. Sin embargo, esto no suele ser recomendable, ya que puede dar lugar a un conflicto de roles.
Un proyecto SCRUM consta de varios sprints. A menudo, el número de sprints necesarios para completar el proyecto no se conoce al principio del mismo. Esto se debe a que en algunos proyectos los requisitos no se conocen totalmente al principio. No conocer todos los requisitos suele acarrear problemas cuando se ejecutan proyectos con métodos clásicos de gestión de proyectos, como el modelo de cascada. Aquí es donde SCRUM ofrece una solución.
En SCRUM, hay cinco eventos: el Sprint, la Planificación del Sprint, el SCRUM Diario, la Revisión del Sprint y la Retrospectiva del Sprint. El propio Sprint es un contenedor y alberga los demás eventos. Un Sprint tiene un periodo de tiempo fijo con un máximo de 4 semanas. Durante el sprint, los desarrolladores producen un incremento del producto acabado. Un Sprint comienza con la Reunión de Planificación del Sprint, en la que se planifica el Sprint que acaba de comenzar. Tras la planificación tiene lugar la implementación. Durante esta fase, el SCRUM diario tiene lugar todos los días. Poco antes del final del Sprint, el incremento del producto se examina en la Revisión del Sprint para identificar las mejoras y las funciones que faltan. Tras la Revisión del Sprint, tiene lugar la Retrospectiva del Sprint. El objetivo es identificar el potencial para mejorar la colaboración y la eficiencia. El Sprint termina cuando finaliza el plazo. Entonces comienza el siguiente Sprint.
Un sprint puede cancelarse si el objetivo del sprint queda obsoleto. La cancelación del sprint solo puede iniciarla el propietario del producto.
En SCRUM, todos los eventos tienen una duración determinada. La duración máxima de los eventos se establece en 4 semanas para el Sprint, 8 horas para la Planificación del Sprint (para un Sprint de 4 semanas, de lo contrario normalmente más corto), 15 minutos para el SCRUM Diario (siempre), 4 horas para la Revisión del Sprint (para un Sprint de 4 semanas, de lo contrario normalmente más corto) y 3 horas para la Retrospectiva del Sprint (para un Sprint de 4 semanas, de lo contrario normalmente más corto). Excepto el Sprint, todos los demás eventos pueden terminar antes de tiempo si han cumplido su propósito. La duración de la Planificación del Sprint, la Revisión del Sprint y la Retrospectiva del Sprint suele ajustarse a la duración del Sprint.
El Sprint comienza con la Reunión de Planificación del Sprint. La Planificación del Sprint es una reunión en la que todo el equipo SCRUM se reúne para planificar el Sprint que acaba de comenzar. Para un Sprint de 4 semanas de duración, se dispone de un tiempo máximo de 8 horas para este evento. Si se eligen sprints más cortos, el tiempo suele reducirse. Como regla general, debería planificar unas 2 horas por semana de sprint para la reunión de planificación del sprint. Durante este evento, el equipo define conjuntamente el objetivo del sprint. Los desarrolladores seleccionan las entradas del backlog del producto que pueden completar en este sprint y crean un plan de implementación para las entradas seleccionadas.
El SCRUM diario tiene lugar cada día del sprint. Tiene una duración de 15 minutos, independientemente del número de desarrolladores que trabajen en el proyecto y de la duración del sprint seleccionada. El SCRUM diario siempre tiene lugar en el mismo lugar a la misma hora y es una reunión para los desarrolladores. El SCRUM Master y el Product Owner no tienen que participar en el Daily SCRUM. Durante el SCRUM Diario, los Desarrolladores comprueban si el progreso en el Sprint es el adecuado (por ejemplo, con el gráfico de burn-bown) y discuten la distribución de tareas para las próximas 24 horas. Durante este proceso, se ajusta el Sprint Backlog, también llamado SCRUM Board.
La Revisión del Sprint ofrece una oportunidad formal para que el equipo SCRUM se reúna con las principales partes interesadas para discutir el producto. El objetivo no es aprobar el incremento, sino trabajar juntos para encontrar posibles mejoras y debatir los siguientes pasos.
La Retrospectiva del Sprint es una reunión de lecciones aprendidas para todo el equipo SCRUM. Durante la reunión, se recopilan, seleccionan y, si es posible, se implementan inmediatamente mejoras para la calidad y la velocidad del equipo SCRUM. Durante la retrospectiva, la atención se centra en la colaboración del equipo, las técnicas empleadas y los documentos utilizados, como la «Definición de Hecho». Los problemas que se produjeron en el último sprint proporcionan una buena indicación para las mejoras.
Con más de 4.000 proyectos y estudios de casos, Alphadi es líder en el campo de Lean Six Sigma e Sales Process Engineering. Le asesoramos de forma integral para que sus objetivos se alcancen de forma sostenible y a largo plazo.
2024 © All Rights Reserved.
