Parafraseando un concepto bien conocido en la gestión de proyectos, uno podría decir: «La planificación es indispensable, pero los planes son inútiles. Por lo tanto, inspeccione y adáptese.»
Los planes tradicionales se rigen por fechas, lo más probable es que la fecha de finalización sea el principal factor impulsor. En la gestión de proyectos tradicional, usted reúne los requisitos de sus partes interesadas, construye el alcance del proyecto y divide el proyecto en piezas de trabajo manejables. Esto, a su vez, crea una estructura de desglose del trabajo (WBS). A continuación, el nivel más bajo de WBS, es decir, los paquetes de trabajo, se descomponen en actividades. Las actividades se vinculan con dependencias, y los recursos se estiman y aplican a las actividades para crear un cronograma de extremo a extremo para el proyecto. Este cronograma se supervisa y controla con la ayuda de un plan de gestión de cronogramas, que generalmente es un plan subsidiario del plan de gestión de proyectos consolidado.
Pero, ¿cuántas veces sucede que lo que usted ha planeado y lo que realmente sucedió en el suelo, emparejados? ¡Ya sabes la respuesta! La cita de apertura significa que la planificación es esencial,pero esperar que podamos seguir el plan exactamente no es una cosa sabia. Cuando hay grandes cambios en los requisitos y una gran incertidumbre en la tecnología o la plataforma, el PMs suele ir con ciclos de vida adaptativos (o ágiles).
De hecho, el cuarto valor del Manifiesto Ágil dice: «Responder al cambio siguiendo un plan.»La agilidad está impulsada por el cambio, y lo más probable es que estos cambios sean impulsados por los clientes. Esto lleva a un concepto llamado Agile Release Planning.
La planificación de versiones es diferente a la planificación tradicional, donde el plan completo se considera por adelantado, se elabora en detalle y solo se puede cambiar con solicitudes de cambio formales. Un plan de lanzamiento se puede actualizar muchas veces en función de los comentarios de iteraciones anteriores.
Debido a que los ciclos de vida adaptativos son de naturaleza incremental, las organizaciones pueden lanzarse al final de cada iteración. También pueden optar por lanzar después de unas cuantas iteraciones o incluso de forma continua. Esto requiere una planificación a más largo plazo, pero se puede facilitar de manera efectiva utilizando la técnica de planificación de lanzamientos, que se introdujo recientemente en la 6a edición de la Guía PMBOK.
Para aspirantes a Profesionales de Gestión de Proyectos (PMP) y Asociados Certificados en Gestión de Proyectos (CAPM) , la Planificación Ágil de Versiones es un concepto clave que debe conocer. La 6a edición de la Guía PMBOK ha introducido consideraciones ágiles para cada área de conocimiento. Esto también es útil para los aspirantes a Profesionales Certificados Ágiles (ACP).
A medida que profundizamos en esto, primero veamos cómo se desarrollan los planes de lanzamiento a un alto nivel.
De la Visión a la Hoja de ruta para Lanzar Planes
En proyectos ágiles, el trabajo comienza con una visión de producto. La visión se traduce en una hoja de ruta del producto. La hoja de ruta contiene las características que se desarrollarán durante un período de tiempo. También puede decir que una hoja de ruta representa el alcance del producto, que se entrega en varias versiones. Esto conduce a los planes de lanzamiento y se muestra en la figura a continuación.
Hoja de ruta y Acumulación de productos
Un componente de la secuencia anterior es la hoja de ruta del producto, y para comprender la hoja de ruta del producto, primero necesitamos comprender la acumulación de productos. En los enfoques ágiles, todos los requisitos, tanto los requisitos del proyecto como los requisitos del producto, forman parte del backlog de productos (PB). Cada elemento del backlog de productos se denomina product backlog item (o PBI). Aparte de las características (requisitos), un elemento de acumulación de productos puede ser una solicitud de cambio, un defecto, un error, un problema o incluso un trabajo técnico específico.
Como sabemos, en los proyectos ágiles, los requisitos evolucionan continuamente y hay incertidumbres/riesgos significativos. Como resultado, generalmente priorizamos los PBIs. Las PBIS priorizadas se toman de la parte superior del backlog y se entregan al cliente(s). Los temas de alta prioridad siguen estando en la parte superior del atraso y son de grano fino, mientras que los temas de baja prioridad se encuentran en la parte inferior del atraso y son de grano grueso. La priorización de los elementos en el PB determina el nivel de detalle de ese elemento en el backlog de productos. Esto se muestra en la siguiente figura.
Si utiliza herramientas ágiles como Microsoft Project, puede desarrollar el backlog de productos rápidamente. A continuación se muestra un ejemplo de backlog de productos, dibujado con MS Project.
Aquí, tenemos un backlog de productos que muestra los artículos de backlog de productos (PBIs) de «Crear un nuevo usuario», «Iniciar sesión en el sistema de comercio en línea», «Transferir una acción», etc. Si desea agregar cualquier otro elemento de backlog, solo tendrá que hacer clic en el icono «+» del cuadro de comandos «Nueva tarea».
Los elementos de nivel superior en el backlog de productos se pueden escribir en historias de usuario, que se estiman en puntos de historia, una medida relativa sin unidades.
Ahora, al llegar a la hoja de ruta del producto, simplemente puede decir que es un backlog de productos con un cronograma. Una hoja de ruta representa el futuro planificado del proyecto (es decir, lanzamientos de productos planificados y/o propuestos) o temas de lanzamiento, enumerando las funcionalidades de alto nivel del producto. La hoja de ruta dice qué características o épicas (una épica, en pocas palabras, es una gran historia de usuario) se entregarán en cada versión.
Plan de lanzamiento
La hoja de ruta del producto impulsa los planes de lanzamiento. Un plan de lanzamiento da el cronograma de lanzamiento, cada lanzamiento suele ser de tres a seis meses. Una versión contiene muchas iteraciones, desde la Iteración 0 (iteración cero) hasta la Iteración N. La iteración 0 se puede utilizar para la aprobación de proyectos, la configuración del entorno para el proyecto, la descripción inicial y las discusiones de diseño, etc. Algunos profesionales ágiles usan Iteración-H (iteración de endurecimiento), que es la iteración final al final de la versión para prepararse para la entrega. Esta iteración puede incluir elementos de trabajo finales, como materiales de capacitación y marketing, notas finales de la versión, guías de instalación, guías de sistema/usuario, etc. Esto se muestra a continuación.
Como se muestra, el plan de lanzamiento tiene iteraciones, de «Iteración-0» a «Iteración – N». Puede decidir tener una versión después de unas cuantas iteraciones y/o una versión final después de la última iteración.
El plan de lanzamiento presenta una hoja de ruta de cómo el equipo pretende lograr la visión del proyecto dentro del alcance de los objetivos y limitaciones del proyecto. Ayuda al propietario del producto y a todo el equipo a decidir cuánto se debe desarrollar y cuánto tiempo se tardará en tener un producto liberable. Transmite expectativas sobre lo que es probable que se desarrolle y en qué plazo. El plan de lanzamiento también puede servir de guía hacia el cual el equipo puede avanzar. El plan de lanzamiento se puede actualizar al final de una iteración y refleja las expectativas actuales que se incluirán, para que puedan entregarse en iteraciones posteriores.
Planificación de lanzamientos con Backlog de productos
Para tener una mejor comprensión de la planificación de lanzamientos, puede visualizar los planes de lanzamiento con la ayuda de backlog de productos.
Ya sabemos que los artículos en el backlog de productos están clasificados u ordenados, según su prioridad. Los artículos de nivel superior que son de grano fino, estarán listos para el consumo en la próxima iteración (en la próxima versión inmediata). El backlog priorizado, con características y otros elementos, se muestra en el lado izquierdo de la figura a continuación.
 |
 |
Dentro de MS Project, simplemente tiene que seleccionar, arrastrar y soltar elementos atrasados y organizarlos según su necesidad de priorizarlos. Esto se muestra en el lado derecho de la figura de arriba. Teniendo en cuenta el ejemplo anterior que muestra la acumulación de productos dentro de MS Project, tenemos esta clasificación relativa: primero «Inicie sesión en el sistema de comercio en línea», luego «Cree un nuevo usuario», luego «Compre una acción», etc.
Como se muestra arriba, he seleccionado y arrastrado el elemento de característica «Iniciar sesión en el sistema de comercio en línea» y lo he soltado antes del elemento de característica anterior «Crear un nuevo usuario».»El elemento seleccionado estaba ligeramente gris cuando lo arrastré y lo dejé caer.
Con el backlog, puede decidir cuáles de los elementos de backlog se deben entregar en las próximas versiones. A continuación, vemos que los elementos de la próxima versión (es decir, la versión 1) se priorizan en su mayoría. Los elementos de la versión 2 también pueden tener prioridad, pero vemos que los elementos de la versión 3 no tienen prioridad, ya que son elementos de baja prioridad.
También puede visualizar la planificación de esta versión con MS Project. Mira la figura de abajo. Se ha demostrado que se toman PBIS en varias liberaciones. ¿Recuerdas que una versión contiene iteraciones? En nuestro caso, para la primera versión, tenemos tres iteraciones, y se espera que todos los artículos se entreguen en estas iteraciones. Una iteración se llama sprint en el marco Scrum, que es un marco popular utilizado por Agile PMs. Para las próximas dos versiones (es decir, la Versión 2 y la Versión 3), tenemos las PBIs, pero aún no hemos decidido las iteraciones (o sprints).
Planificación de iteraciones
Si ha seguido, el plan de lanzamiento consta de Iteración 0 a Iteración N y podemos decidir lanzar al final de cada pocas iteraciones o cada iteración. Pero, ¿qué sucede dentro de una iteración? En pocas palabras, el alcance de un conjunto de características dentro de la iteración se confirma al principio de la iteración y se entrega al final de la iteración.
Las funciones que se confirman y se toman para la iteración se desglosan en tareas (o actividades) y los miembros del equipo las estiman en horas. La secuencia de pasos desde la hoja de ruta del producto hasta el plan de lanzamiento y el plan de iteración se muestra en el diagrama a continuación.
Resumiendo la figura de arriba, estos serán los puntos clave:
- La visión del producto impulsa la hoja de ruta del producto
- La hoja de ruta del producto impulsa los planes de lanzamiento
- Un plan de lanzamiento tendrá iteraciones
- Las características, que se estiman en puntos de historia, se desarrollan en una iteración
- Las características se desglosan en tareas, que se estiman en horas
Con MS Project 2016, puede crear un plan de lanzamiento rápidamente. Teniendo en cuenta nuestro ejemplo anterior de backlog, tenemos tres iteraciones/sprints para la primera versión (es decir, Sprint 1, Sprint 2 y Sprint 3). Cada sprint tiene un conjunto de funciones que entregar. Esto se muestra a continuación en la vista «Tablero de Planificación de Sprint».
También puede profundizar para ver qué sucede en el nivel de iteración / sprint y averiguar en qué PBIs se está trabajando. MS Project muestra esto en la vista «Tablero de velocidad actual». Vea la figura a continuación.
Para Sprint 1, tenemos que entregar tres artículos: «Inicie sesión en el sistema de comercio en línea», «Cree un nuevo usuario» y «Compre una acción.»Estos están pasando por tres estados de flujo de trabajo: «Siguiente»,» En progreso «y » Listo».»Por supuesto, puede agregar, eliminar o personalizar estos estados de flujo de trabajo según sus necesidades.
Plan de Lanzamiento Vs. Plan de Iteración
Si está tomando el examen, también debe conocer las diferencias entre el Plan de Lanzamiento y el Plan de Iteración. Se indican en el cuadro que figura a continuación. Por lo general, las iteraciones se programan de dos a cuatro semanas. Sin embargo, en algunos casos, como XP (otro marco Ágil), las iteraciones pueden durar una semana.
Guía de Cuerpo de Conocimiento de Gestión de Proyectos (PMBOK), 6a Edición, por Project Management Institute (PMI)
Quiero Ser Un PMP: La Forma Sencilla y Sencilla De Ser un PMP, 2a edición, por Satya Narayan Dash
Quiero Ser un ACP: La Forma Sencilla y Sencilla De Ser un ACP, por Satya Narayan Dash
Lecciones en vivo de Microsoft Project 2016, por Satya Narayan Dash
Guía de Práctica Ágil, por Project Management Institute (PMI)