¡Hola!

Atendiendo a la sugerencia de la Profe María Esther en la “Pizarra Interactiva”, y

complementando sus entradas sobre los fundamentos de la Gestión de Proyectos,
orientándonos ya hacia los proyectos de desarrollo de software, quise traer a colación
algunos elementos que han generado interesantes debates desde hace ya algunos
años.

Como seguramente vieron, en el Drive que la profesora nos ha compartido con

excelente material, se encuentra la última edición del “Cuerpo de Conocimientos de la
Gerencia de Proyectos (Project Management Body of Knowledge o PMBOK 6ta ed.). En
éste se incorpora un apéndice completo sobre agilidad (Apéndice X3 ENTORNOS DE
PROYECTOS ÁGILES, ITERATIVOS, ADAPTATIVOS E HÍBRIDOS)
Si bien, todavía hay mucho camino por recorrer para hacer un mapa 100% preciso, si
es que esto es posible, entre el esquema de gestión “tradicional” de proyectos y el
esquema planteado por organizaciones como Agile Alliance (Enlaces a un sitio
externo.) y Scrum Alliance (Enlaces a un sitio externo.) (que han trabajado en los
últimos años muy de la mano con el PMI) les dejo algunas reflexiones que
seguramente nos servirán a lo largo del desarrollo de este curso.

Lo primero que se debe comprender es el ciclo de vida de un proyecto. Bajo el

esquema "tradicional", un proyecto tiene un ciclo de vida predictivo.

A lo largo de los últimos 35 años, la forma de desarrollar un producto de software (p.

ej. un sistema de información) ha ido evolucionando, en conjunto con la manera en
cómo se concibe y gestiona el proyecto para su diseño, construcción y puesta en
producción (ciclo de vida de desarrollo de software).

Lo anterior se debe, principalmente a que el proceso de desarrollo de

software (particularmente las etapas de diseño y construcción) se pueden expresar
como procesos de transformación de conocimiento. Es decir, a diferencia de un
producto "tangible" como una botella de refresco, un par de zapatos, etc. el producto
de software no tiene materias primas asociadas: es una materialización de los
conocimientos que el equipo de diseñadores, analistas y codificadores tienen en un
momento particular.

Entendiendo eso, se puede ver que el enfoque "tradicional" predictivo pueda que no se
adapte totalmente a la generación de un producto de software, ya que:

 Los requisitos, si bien pueden definirse por adelantado, antes de comenzar el

desarrollo, van experimentando modificaciones entre las entregas planificadas, por
lo que una metodología iterativa e incremental, se adapta más, pero no es
suficiente: los requisitos son modificados por los interesados durante la
propia entrega.
 Los planes realizados para un entregable, para posteriormente entregar un
único producto final al cerrar el proyecto, tienden a quedar obsoletos a lo largo
de esa "transformación del conocimiento" (los interesados realizan cambios
"menores" en las especificaciones no sólo en la etapa e planificación, sino en la de
ejecución).
 En la gestión "tradicional" se intentan restringir o minimizar esos cambios lo más
posible. A lo largo del tiempo se ha evidenciado que en los procesos de
construcción de software lo único constante son los cambios. Por tanto, cambiando
este enfoque y permitiendo la incorporación de cambios durante la entrega,
es posible tener mejores resultados.
 Para el enfoque predictivo o "tradicional", los interesados clave se involucran en
momentos o hitos específicos. Sin embargo, las metodologías iterativas /
incrementales para el desarrollo de software plantean que los interesados sean
involucrados periódicamente. Ahora bien, las evidencias empíricas señalan que si
esos interesados son involucrados continuamente, no sólo al finalizar la
entrega (ni del producto final, como el enfoque predictivo establece), ni al finalizar
una iteración, sino durante la iteración, la aceptación de ese producto o
subproducto es más frecuente.
 Según los enfoques "tradicionales" predictivos, los riesgos y costos son controlados
a través de una planificación detallada de aquellos elementos que se conocen y
pueden ser controlados. Pero, si se habla que se está trabajando con el
"conocimiento como materia prima", esos riesgos y costos son muy difíciles de
estimar a priori (p. ej. si el producto final es un edificio, se pueden hacer compras
adelantadas de los materiales necesarios para su construcción. Si el producto final
es un sistema de información, de manera real y sensata ¿qué compra se puede
hacer por adelantado, más allá del hardware y obras de infraestructura necesarias
para soportar ese sistema? Es decir, la ecuación siempre tendra variables con
elevada incertidumbre). Por tanto, un enfoque que vaya más allá de lo iterativo e
incremental, donde el riesgo y los costos sean controlados a medida que
surgen los requisitos y las limitaciones, permitirían "aceptar la realidad sin
«estropear» ningún plan" puesto que el plan más bien se concentra en adaptarse a
los cambios y al contexto, a través de pequeñas entregas que aporten valor a los
interesados.

Con lo anterior, y habiéndome extendido un poco más de lo planificado, se sientan las

bases para que se pueda crear el puente entre la gestión "tradicional" de proyectos y
la gestión ágil de proyectos, entendiendo que, no puede considerarse una u otra
como buena o mala, sino que se ajustan a proyectos de diversa índole.

En definitiva, para la gestión de proyectos de sistemas de información, que es lo que

nos atañe en este curso, la gestión ágil, luce en la mayoría de los casos más
apropiada, toda vez que el producto final de un proyecto de esta naturaleza es un
software, que, insisto, no es más que el producto de la "transformación de
conocimiento".

Dejo aquí algunos términos que podrían "mapearse" entre la gestión predictiva
planteada por el PMI, con la gestión ágil, inicialmente planteada por comunidades de
desarrolladores, y luego organizaciones e instituciones formales (hasta la 6ta edición
del PMBOK donde se materializa una sinergia entre estas últimas y el PMI):

PMBOK Ágil

4. Gestión de la 4.1. Desarrollar el Project Charter o · Realizar el Release Planning o Planificación

Integración del Acta constitutiva del proyecto
Proyecto
4.2. Desarrollar el plan para la
dirección del proyecto (project
management plan)
de las entregas
· Realizar el refinamiento
del backlog (backlog grooming)

4.3. Dirigir y gestionar el trabajo del · Efectuar la planificación las iteraciones

proyecto (sprint planning)

4.4. Gestionar el conocimiento del · Realizar las “reuniones diarias” (daily

proyecto meeting / daily Scrum / stand-up meeting)

4.5. Monitorear y controlar el trabajo · Realizar las (reuniones de) revisiones y

 del proyecto retrospectivas

4.6. Realizar el control integrado de · Gestionar la visibilidad del burndown

cambios

5. Gestión del 5.1. Planificar la gestión del alcance · Fijar la duración y costos en sprints. Variar y
Alcance del ajustar el alcance entre sprints (mantener una
Proyecto 5.3. Definir el alcance entrega realista). Revisiones de sprintspara
validar el alcance y establecer el control
5.4. Crear de la EDT / WBS

5.5. Validar el alcance

5.6. Controlar el alcance

8. Gestión de la 8.1. Planificar la gestión de la calidad · Desarrollo orientado a pruebas (TDD)

Calidad del
Proyecto 8.2. Gestionar la calidad · Pruebas unitarias automatizadas

8.3. Controlar la calidad · Integración continua

10. Gestión de las 10.1. Planificar la gestión de las · Realizar las “reuniones diarias” (daily
Comunicaciones comunicaciones meeting / daily Scrum / stand-up meeting)
del Proyecto
10.2. Gestionar las comunicaciones · Gestionar los “radiadores de información”
(Kanban Boards, Scrumboards, diagramas
10.3. Monitorear las comunicaciones de burndown)

· Realizar las (reuniones de) revisiones y

retrospectivas

11. Gestión de los 11.2. Identificar los riesgos · Gestión de los Riesgos
Riesgos del
Proyecto
11.3. Realizar el análisis cualitativo de · Frequent/Continuous feedback Loop
riesgos

11.5. Planificar la respuesta a los · Realizar las “reuniones diarias” (daily

riesgos meeting / daily Scrum / stand-up meeting)

11.6. Implementar la respuesta a los · Realizar los diagramas de burndown

riesgos

11.7. Monitorear los riesgos · Realizar las (reuniones de) revisiones y

retrospectivas

Burndown o burn down chart = Diagrama de “quemado”

Feedback Loop (conocido también como el ciclo de retroalimentación continua
o Continuous Feedback Loop) = Ciclo de retroalimentación: 1. Definir > 2. Medir > 3.
Analizar > 4. Mejorar > 5. Controlar > Regresar a 1.

Nota: La gestión de recursos (área de conocimiento 9 en el PMBOK 6ta ed.) también

tiene una relación uno a uno con varios mecanismos de la gestión ágil como
los capacity planning durante la planificación de las entregas, y la gestión de los
recursos humanos, como un valor fundamental (foco en el equipo sobre los recursos
individuales). Otras áreas como la 7. Gestión de los costos y la procura (12. Gestión de
Adquisiciones) se siguen gestionando bajo un enfoque tradicional / predictivo. La 6.
Gestión del cronograma, se realiza a través de las planificaciones de las entregas
(release planning) e iteraciones (sprint planning) aunque a lo externo comúnmente se
apoyan en las oficinas de proyecto (PMO)
Toda esta información pueden conseguirla en la guía PMBOK 6ta edición y el PMI Agile
Book (realmente una valiosa fuente, muy actualizada). Adicionalmente, quisiera
compartir una presentación interesante (Enlaces a un sitio externo.), de la coautora de
un libro que ya es un clásico en lo que se refiere a la comunión entre el enfoque
tradicional PMI con el ágil (The Software Project Manager's Bridge to Agility (Enlaces a
un sitio externo.)), Michelle Sliger, y que brinda más información que permite
"mapear" ambos enfoques de gestión para proyectos de software.
Editado por Rafael A. Lara Campos el 21 abr en 22:12