GESTIÓN ÁGIL DE PROYECTOS

12
 Gestión Ágil de Proyectos

John Javier Gutiérrez

Héctor Onel Beltrán

U de Cataluña

Diplomado en Gerencia de Proyectos bajo lineamientos del PMBOK® del PMI®

12
TABLA DE CONTENIDO

INTRODUCCIÓN...........................................................................................................................5

Gestión Ágil de los proyectos......................................................................................................5

Capítulo 1 El manifiesto Ágil........................................................................................................10

Capítulo 2 Aplicando el manifiesto Ágil.......................................................................................13

Capítulo 3 Enfoque Predictivo/Tradicional/Waterfall...................................................................15

Enfoque Adaptativo/Ágil...........................................................................................................19

Cómo funcionan los proyectos ágiles....................................................................................19

¿Por qué los proyectos ágiles funcionan mejor?........................................................................20

Bibliografía....................................................................................................................................22

12
TABLA DE ILUSTRACIONES

Ilustración 1 Línea de Tiempo Gestión de Proyectos Agiles...........................................................7

Ilustración 2 Tareas de la Gestión de la Integración del Proyecto.................................................16

Ilustración 4 Cascada Vs. Ágil......................................................................................................20

12
 INTRODUCCIÓN

Gestión Ágil de los proyectos

La gestión ágil de proyectos es un estilo de gestión de proyectos que se centra en la entrega

temprana del valor comercial, la mejora continua del producto y procesos del proyecto,

flexibilidad del alcance, aportes del equipo y entregando productos bien probados que reflejan

las necesidades del cliente.

En esta parte se explicará por qué los procesos ágiles surgieron como un enfoque a la gestión de

proyectos de desarrollo de software a mediados de la década de 1990 y por qué las metodologías

ágiles han llamado la atención de los gerentes de proyecto, clientes que invierten en el desarrollo

de nuevo software y ejecutivos cuyas empresas financian departamentos de desarrollo de

software. También se explica las ventajas de las metodologías ágiles sobre las de enfoque

tradicional para la gestión de proyectos.

La gestión de proyectos necesitaba un cambio de imagen

Un proyecto es un programa de trabajo planificado que requiere una cantidad definitiva de

tiempo, esfuerzo y planificación para completarse. Los proyectos tienen metas y objetivos y a

menudo deben completarse en un período de tiempo fijo y dentro de un presupuesto

determinado.

Es probable que sea un gerente de proyecto o alguien que inicia proyectos, trabaja en proyectos o

se ve afectado por los proyectos de alguna manera.

Los enfoques ágiles son una respuesta a la necesidad de modernizar la administración del

Proyecto.

12
Para comprender cómo los enfoques ágiles están revolucionando los proyectos, es útil conocer

un poco sobre la historia y el propósito de la gestión de proyectos y los problemas que enfrentan

los proyectos en la actualidad.

Los orígenes de la gestión moderna de proyectos.

Los proyectos han existido desde la antigüedad. Desde la Gran Muralla China hasta las

pirámides mayas de Tikal, desde la invención de la imprenta hasta la invención de Internet, las

personas han realizado grandes y pequeños proyectos.

Como disciplina formal, la gestión de proyectos tal como la conocemos solo ha existido desde

mediados del siglo XX. En la época de la Segunda Guerra Mundial, los investigadores de todo el

mundo estaban haciendo grandes avances en la construcción y programación de computadoras,

principalmente para el ejército de los Estados Unidos. Para completar esos proyectos,

comenzaron a crear procesos formales de gestión de proyectos. Los primeros procesos se basaron

en modelos de fabricación paso a paso que el ejército de los Estados Unidos utilizó durante la

Segunda Guerra Mundial.

Las personas en el campo de la computación adoptaron estos procesos de fabricación basados en

pasos porque los primeros proyectos relacionados con la computadora dependían en gran medida

del hardware, con computadoras que llenaban habitaciones enteras. El software, por el contrario,

era una parte más pequeña de los proyectos informáticos. En las décadas de 1940 y 1950, las

computadoras podían tener miles de tubos de vacío físicos, pero menos de 30 líneas de código de

programación. El proceso de fabricación de 1940 utilizado en estas computadoras iniciales es la

base de la metodología de gestión de proyectos conocida como cascada.

En 1970, un informático llamado Winston Royce escribió "Gestión del desarrollo de grandes

sistemas de software", un artículo para la IEEE (Instituto de Ingeniería Eléctrica y Electrónica)

que describía las fases en la metodología de cascada (Waterfall). El término Cascada se selló más

12
tarde, pero las fases, incluso si a veces se titulan de manera diferente, son esencialmente las

mismas que definió originalmente Royce:

1. Requisitos

2. Diseño

3. Desarrollo

4. Integración

5. Prueba

6. Despliegue

En los proyectos en cascada, pasa a la siguiente fase solo cuando se completa la anterior, de ahí

el nombre de cascada.

La metodología de cascada fue el enfoque de gestión de proyectos más común en el desarrollo de

software hasta que fue superada por enfoques mejorados basados en técnicas ágiles alrededor de

2008.

Introducción a la gestión ágil de proyectos

Las semillas para las técnicas ágiles han existido durante mucho tiempo. De hecho, los valores,

principios y prácticas ágiles son simplemente una codificación del sentido común. La Ilustración

1 muestra una historia rápida de la gestión ágil de proyectos, que data de la década de 1930 con

el enfoque Planificar-Hacer-Estudiar-Actuar (PDSA) de Walter Sherwart para la calidad del

proyecto.

12
 Ilustración 1 Línea de Tiempo Gestión de Proyectos Agiles.

En 1986, Hirotaka Takeuchi e Ikujiro Nonaka publicaron un artículo llamado "Nuevo juego de

desarrollo de nuevos productos" en Harvard Business Review.

El artículo de Takeuchi y Nonaka describió una estrategia de desarrollo rápida y flexible para

satisfacer las demandas de productos de ritmo rápido. Este artículo emparejó primero el término

scrum con el desarrollo de productos (Scrum originalmente se refería a una formación de

jugadores en Rugby.) Scrum finalmente se convirtió en uno de los marcos de gestión de

proyectos ágiles más populares.

En 2001, un grupo de expertos en software y proyectos se reunieron para hablar sobre lo que sus

proyectos exitosos tenían en común. Este grupo creó el Manifiesto Ágil, una declaración de

valores para el desarrollo exitoso de software:

Manifiesto para el desarrollo de software ágil *

Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a

hacerlo. A través de este trabajo hemos llegado a valorar:

 Individuos e interacciones sobre procesos y herramientas

 Trabajo de Software sobre documentación completa

12
  Colaboración del cliente sobre negociación de contratos

 Responder al cambio sobre seguir un plan

Es decir, si bien hay valor en los artículos de la derecha, valoramos más los artículos de la

izquierda.

* Agile Manifesto Copyright © 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair

Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt,

Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff

Sutherland, Dave Thomas.

This declaration may be freely copied in any form, but only in its entirety through this notice.

Estos expertos también crearon los Principios detrás del Manifiesto Ágil, 12 prácticas que

ayudan a respaldar los valores en el Manifiesto Ágil.

Agile, en términos de desarrollo de productos, es un descriptor para los enfoques de gestión de

proyectos que se centra en las personas, las comunicaciones, el producto y la flexibilidad. Si está

buscando la metodología ágil, no la encontrará. Sin embargo, marcos (por ejemplo, Scrum),

técnicas (por ejemplo, requisitos de historias de usuarios) tienen una cosa en común: la adhesión

al Manifiesto Ágil y los 12 principios ágiles.

12
 Capítulo 1

El manifiesto Ágil

La investigación y la experiencia ilustran por qué los valores ágiles son tan importantes para:

Individuos e interacciones sobre procesos y herramientas: ¿Por qué?

Porque la investigación muestra un aumento de 50 veces en el rendimiento cuando acertamos

con las personas y las interacciones. Una de las formas en que lo hacemos bien es mediante la

colocación de un equipo de desarrollo con un propietario de producto capacitado.

Trabajando Software sobre documentación completa: ¿por qué?

No realizar pruebas y corregir defectos durante el sprint puede tomar hasta 24 veces más

esfuerzo y costo en el próximo sprint. Y después de implementar la funcionalidad en el mercado,

si un equipo de soporte de producción que no participó en el desarrollo del producto realiza las

pruebas y la reparación, el costo es hasta 100 veces más.

Colaboración del cliente sobre la negociación del contrato: ¿Por qué?

Un propietario de producto dedicado y accesible puede generar un aumento cuádruple en la

productividad al proporcionar una aclaración en el momento al equipo de desarrollo, alineando

las prioridades del cliente con el trabajo que se realiza.

Respondiendo al cambio después de seguir un plan: ¿Por qué?

Comenzar con un plan es vital, pero es cuando menos sabemos. Los equipos ágiles no planean

menos que los equipos en cascada: planean tanto o más. Sin embargo, los equipos ágiles adoptan

un enfoque justo a tiempo, planificando lo suficiente cuando sea necesario. La adaptación del

12
plan a las realidades en el camino es cómo los equipos ágiles entregan productos que deleitan a

los clientes.

Los creadores del Manifiesto Ágil se centraron originalmente en el desarrollo de software porque

trabajaban en la industria de TI. Sin embargo, las técnicas ágiles de gestión de proyectos se han

extendido más allá del desarrollo de software e incluso productos externos relacionados con la

computadora. Hoy en día, las personas utilizan enfoques ágiles para crear productos en una

variedad de industrias, incluyendo biotecnología, manufactura, aeroespacial, ingeniería,

mercadeo, trabajo sin fines de lucro e incluso construcción de edificios. Si desea comentarios

empíricos tempranos sobre el producto o servicio que está brindando, puede beneficiarse de los

métodos ágiles.

Se siguen estos doce (12) principios:

1. Nuestra máxima prioridad es satisfacer al cliente a través de la entrega temprana y

continua de software valioso.

2. Bienvenido a los requisitos cambiantes, incluso al final del desarrollo. Los procesos

ágiles aprovechan el cambio para la ventaja competitiva del cliente.

3. Entregue software de trabajo con frecuencia, desde un par de semanas hasta un par de

meses, con preferencia al menor tiempo.

4. La gente de negocios y los desarrolladores deben trabajar juntos a diario durante todo

el proyecto.

5. Desarrollar proyectos en torno a individuos motivados. Bríndeles el entorno y el

apoyo que necesitan, y confíe en ellos para hacer el trabajo.

6. El método más eficiente y efectivo para transmitir información a un equipo de

desarrollo y dentro de él es la conversación cara a cara.

7. El trabajo en el Software de trabajo es la medida principal del progreso.

12
8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores,

desarrolladores y usuarios deberían ser capaces de mantener un ritmo constante

indefinidamente.

9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.

10. La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.

11. Las mejores arquitecturas, requisitos y diseños surgen de equipos auto organizados.

12. A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo, luego ajusta

y perfecciona su comportamiento en consecuencia.

12
 Capítulo 2

Aplicando el manifiesto Ágil

A mediados de la década de 1990, Internet estaba cambiando el mundo ante nuestros ojos. Las

personas que trabajan en la floreciente industria de las puntocom estaban bajo constante presión

para ser las primeras en comercializar con tecnologías de rápido cambio.

Los equipos de desarrollo trabajaron día y noche, luchando por entregar nuevos lanzamientos de

software antes de que los competidores volvieran obsoletas sus empresas. La industria de la

tecnología de la información (TI) se reinventó por completo en unos pocos días.

Dado el ritmo de cambio en ese momento, inevitablemente aparecieron grietas en prácticas

convencionales de gestión de proyectos. El uso de metodologías tradicionales como la cascada,

que se discute en la lección 1, no permitió a los desarrolladores responder lo suficiente a la

naturaleza dinámica del mercado y a los nuevos enfoques comerciales emergentes. Los equipos

de desarrollo comenzaron a explorar alternativas a estos enfoques obsoletos para la gestión de

proyectos. Al hacerlo, notaron algunos temas comunes que produjeron mejores resultados.

En febrero de 2001, 17 de estos nuevos pioneros de la metodología se reunieron en Snowbird,

Utah, para compartir sus experiencias, ideas y prácticas; para discutir la mejor manera de

expresarlos; y sugerir formas de mejorar el mundo del desarrollo de software. No podrían haber

imaginado el efecto que tendría su reunión en el futuro de la gestión de proyectos. La

simplicidad y claridad del manifiesto que produjeron y los principios posteriores que

transformaron el mundo de la tecnología de la información y continúan revolucionando la

gestión de proyectos en todas las industrias, no solo en el desarrollo de software.

Durante los próximos meses, estos líderes construyeron lo siguiente:

El Manifiesto Ágil: una expresión intencionalmente racionalizada de los valores centrales del

desarrollo.

12
Los principios ágiles: un conjunto de 12 conceptos rectores que apoyan a los equipos ágiles de

proyectos en la implementación de técnicas ágiles y en el camino.

El Ágil Alliance: una organización de desarrollo comunitario enfocada en apoyar a individuos y

organizaciones que están aplicando principios y prácticas ágiles.

El trabajo del grupo estaba destinado a hacer que la industria del software sea más productiva,

más humana y más sostenible.

Nadie puede negar que el Manifiesto Ágil es una declaración concisa y autorizada. Mientras que

los enfoques tradicionales enfatizan un plan rígido, evitan el cambio, documentan todo y alientan

el control basado en la jerarquía, el manifiesto se centra en:

• Personas

• Comunicaciones

• El producto

• Flexibilidad

El Manifiesto Ágil representa un gran cambio en el enfoque de cómo se conciben, conducen y

gestionan los proyectos. Si leemos solo los elementos de la izquierda, entendemos el nuevo

paradigma que los firmantes del manifiesto imaginaron.

Descubrieron que, al centrar más la atención en las personas y las interacciones, los equipos

producirían de manera más eficaz software de trabajo a través de una valiosa colaboración con el

cliente y respondiendo bien al cambio. Por el contrario, el enfoque principal tradicional en los

procesos y las herramientas a menudo produce documentación exhaustiva o excesiva para

cumplir con las negociaciones del contrato y seguir un plan inmutable.

12
 Capítulo 3

Enfoque Predictivo/Tradicional/Waterfall

 Implica tomar decisiones respecto a dónde concentrar los recursos y esfuerzos.

 Permite anticiparse a posibles polémicas, de forma que puedan ser tratadas antes de que

se conviertan en problemas críticos.

 Consiste en coordinar el trabajo para el éxito del proyecto en general.

 Incluye hacer concesiones entre objetivos y alternativas en competencia.

 Identificar riesgos en los procesos y precisar los procesos asociados.

No hay una única manera de gestionar un proyecto, implica la aplicación de

conocimientos, habilidades y procesos de la gestión de proyectos en diferentes órdenes y grados

de rigor para alcanzar el rendimiento esperado.

La percepción de que un proceso no aplica, no significa que no deba ser tratado. Es

responsabilidad del director del proyecto y el equipo, tratar los procesos y decidir cuáles aplican

y su grado de implementación.

Las tareas propias de Gestión de la Integración del Proyecto están estrechamente

relacionadas con su ciclo de vida, tal como se describe en la Ilustración 2.

12
 Ilustración 2 Tareas de la Gestión de la Integración del Proyecto

La gestión de la integración del proyecto implica tomar decisiones en cuanto a la asignación

de recursos, balancear objetivos y alternativas contrapuestas y manejar las interdependencias

entre las áreas de conocimiento de la dirección de proyectos.

12
Los procesos de dirección de proyectos son normalmente presentados como procesos

diferenciados con interfaces definidas, aunque en la práctica se superponen e interactúan de

formas que no pueden detallarse totalmente.

En los casos de interacción de procesos individuales, la necesidad de una gestión de la

integración del proyecto se torna evidente. Por ejemplo, una estimación de costos necesaria

para un plan de contingencias implica la integración de los procesos en las áreas de conocimiento

relativas al costo, al tiempo y a los riesgos.

La identificación de riesgos adicionales asociados a diversas alternativas de adquisición de

personal, puede generar la necesidad de reconsiderar uno o varios de estos procesos. También

puede ser necesario integrar los entregables del proyecto a las operaciones en curso, ya sea por

parte de la organización ejecutante o la organización del cliente, o a la planificación estratégica a

largo plazo que toma en cuenta los problemas y oportunidades futuras.

La gestión de la integración del proyecto también abarca las actividades necesarias para

gestionar los documentos del proyecto, para asegurar la coherencia con el plan para la dirección

del proyecto y los entregables del producto.

La mayoría de los profesionales con experiencia en dirección de proyectos reconocen que no

existe una manera única de dirigir los proyectos. Aplican sus conocimientos y sus habilidades, e

implementan los procesos necesarios de dirección de proyectos en diferente orden y de

acuerdo a niveles de rigor variables para conseguir el desempeño esperado del proyecto. No

obstante, la percepción de que un determinado proceso no es necesario no significa que no deba

ser considerado. El director del proyecto y su equipo deben estudiar cada proceso para establecer

12
el nivel de implementación de cada uno de ellos para cada proyecto. Cuando un proyecto tiene

más de una fase, debe aplicarse el mismo nivel de rigor en los procesos que integran cada fase

del proyecto.

Es posible comprender la naturaleza integradora de los proyectos y de la dirección de proyectos

si se consideran los otros tipos de actividades realizadas durante su ejecución. Los siguientes son

algunos ejemplos de las actividades llevadas a cabo por el equipo de dirección del proyecto

descritos en la Guía de los Fundamentos para la Dirección de Proyectos - PMBOK®:

 “Analizar y comprender el alcance. Esto abarca los requisitos del proyecto y del

producto, criterios, supuestos, restricciones y otras influencias relativas a un proyecto y

el modo en que ellas se gestionarán o abordarán dentro del proyecto.

 Entender de qué manera utilizar la información identificada y transformarla luego en un

plan para la dirección del proyecto con un enfoque estructurado.

 Realizar actividades para producir los entregables del proyecto.

 Medir y monitorear todos los aspectos del avance del proyecto y realizar las acciones

apropiadas para cumplir con los objetivos del mismo”.

Los procesos que componen los grupos de procesos de un proyecto frecuentemente son

retroalimentados constantemente. Por ejemplo, el Grupo de Proceso de Planificación

proporciona al Grupo de Proceso de Ejecución un plan documentado para la dirección y

ejecución del proyecto en una de las etapas iniciales del proyecto; sin embargo, puede proveer

actualizaciones al plan en cuestión si se producen cambios en el avance el proyecto.

12
Enfoque Adaptativo/Ágil

Cómo funcionan los proyectos ágiles

Los enfoques ágiles se basan en un método de control empírico, un proceso de toma de

decisiones basado en las realidades observadas en el proyecto. En el contexto de las

metodologías de desarrollo de software, un enfoque empírico puede ser efectivo tanto en el

desarrollo de nuevos productos como en proyectos de mejora y actualización. Al utilizar

inspecciones frecuentes y de primera mano del trabajo hasta la fecha, puede realizar ajustes

inmediatos, si es necesario. El control empírico requiere:

Transparencia sin restricciones: todos los involucrados en un proyecto ágil saben lo que está

sucediendo y cómo está progresando el proyecto.

Inspección frecuente: las personas que invierten en el producto y procesan más regularmente

evalúan el producto y el proceso.

Adaptación inmediata: los ajustes se realizan rápidamente para minimizar los problemas; Si

una inspección muestra que algo debería cambiar, se cambia inmediatamente.

Para acomodar la inspección frecuente y la adaptación inmediata, los proyectos ágiles funcionan

en iteraciones (segmentos más pequeños del proyecto general). Un proyecto ágil implica el

mismo tipo de trabajo que en un proyecto en cascada tradicional: crea requisitos y diseños,

desarrolla el producto, lo documenta y, si es necesario, integra el producto con otros productos.

Usted prueba el producto, soluciona cualquier problema y lo implementa para su uso. Sin

embargo, en lugar de completar estos pasos para todas las características del producto a la vez,

como en un proyecto en cascada, divide el proyecto en iteraciones, también llamadas Sprint.

12
La Ilustración 4 muestra la diferencia entre un proyecto de cascada lineal y un proyecto ágil.

Ilustración 3 Cascada Vs. Ágil

¿Por qué los proyectos ágiles funcionan mejor?

Se verá cómo los proyectos ágiles funcionan mejor que los proyectos tradicionales. Los enfoques

ágiles de gestión de proyectos pueden producir proyectos más exitosos. El estudio de Standish

Group, mencionado en el documento: "Éxito y fracaso de proyectos de software", encontró que,

si bien el 29 por ciento de los proyectos tradicionales fracasaron directamente, ese número se

redujo a solo el 9 por ciento en los proyectos ágiles.

La disminución en el fracaso de los proyectos ágiles es el resultado de que los equipos de

proyectos ágiles hacen adaptaciones inmediatas basadas en inspecciones frecuentes de avance y

satisfacción del cliente.

12
Aquí hay algunas áreas clave donde los enfoques ágiles son superiores a los métodos

tradicionales de gestión de proyectos:

Tasas de éxito del proyecto: descubrirá cómo el riesgo de falla catastrófica del proyecto se

reduce a casi nada en los proyectos ágiles. Los enfoques ágiles de priorización por valor de

negocio y riesgo aseguran el éxito o fracaso temprano. Enfoques ágiles para las pruebas en todo

el proyecto ayudan a asegurar que encuentre problemas temprano, no después de gastar una gran

cantidad de tiempo y dinero.

Corrupción del alcance (Scope Creep): los enfoques ágiles acomodan los cambios a lo largo

de un proyecto, minimizando el desplazamiento del alcance. En proyectos ágiles, puede agregar

nuevos requisitos al comienzo de cada sprint sin interrumpir el flujo de desarrollo. Al desarrollar

completamente las funciones priorizadas primero, evita que el desplazamiento del alcance

amenace la funcionalidad crítica.

Inspección y adaptación: detalles de cómo funcionan las inspecciones regulares y la adaptación

en proyectos ágiles. Los equipos de proyectos ágiles, armados con la retroalimentación frecuente

de los ciclos de desarrollo completos y la funcionalidad de envío, pueden mejorar sus procesos y

sus productos con cada sprint.

Descubrirá cómo obtiene el control del resultado de los proyectos ágiles. Las pruebas tempranas

y frecuentes, el ajuste de prioridades según sea necesario, el uso de mejores técnicas de

comunicación y la demostración y liberación periódica de la funcionalidad del producto le

permiten ajustar su control sobre una amplia variedad de factores en proyectos ágiles.

12
 Bibliografía

Project Management Institute. (2017). Guía de los fundamentos para la Dirección de Proyectos

-PMBOK Project Manajement Body of Knowlegde Sexta Edición. EEUU.

12
 © U de CATALUÑA, 2020
Todos los derechos reservados. Prohibida la reproducción total o parcial sin

permiso o autorización de la Universidad, Bogotá - Colombia.

12