Este artículo es una colaboración de José Huerta (www.josehuerta.es). Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. En su blog, que recomiendo sinceramente, publica artículos excelentes sobre gestión de proyectos de desarrollo software y gestión de equipos de trabajo, entre otros temas que os invito a conocer.
¿Es PMBOK sinónimo de desarrollo en cascada?
- En cascada: Primero se miran los requisitos. Luego se analizan. Luego se hace el diseño. Se programa, se testea, se pone en producción y se cierra el proyecto.
- De forma ágil: Se hace una pequeña funcionalidad, se pone en producción. Se añade otra, se pone en producción, etc.
Por hacer una comparación con la construcción (aunque la metáfora puede tener pegas importantes) en cascada sería lo habitual: hablar con el cliente, hacer los primeros esbozos, hacer el proyecto de arquitectura, construir, comprobar y entregar. Mientras que el desarrollo ágil sería, ahora te hago la planta baja. Ya te dejo que entres a vivir, mientras construyo la siguiente planta. Viendo como ha quedado la primera, a lo mejor tomas decisiones nuevas sobre las siguientes plantas. Francisco os da una versión más desarrollada y formal en su artículo gestión ágil de proyectos.
Dicho esto, existe una «moda» emergente en el que el desarrollo informático tiene que ser ágil y no en cascada. Y yo estoy de acuerdo con esta moda. Más que moda, es que el sector ha evolucionado.
Conjuntamente con esta forma de desarrollar de forma ágil, se han creado nuevas metodologías para «ordenar» este desarrollo. Y ha pasado algo curioso: la gestión de proyectos como tal se ha relacionado con «Desarrollo en cascada».
Esta visión está completamente equivocada. Pensar en proyectos no es más que ordenar el trabajo para conseguir un objetivo. Da igual si pensamos en que las fases del proyecto serán en cascada o serán iterativas. De hecho el PMBOK contempla esta posible iteración en las fases del proyecto.
PMBOK no implica desarrollo en cascada, ni de ninguna otra manera. De hecho si comparamos con SCRUM, que es quizás la más famosa metodología ágil (y que debes conocer si quieres certificarte como ACP), como el PMBOK veremos muchísimos paralelismos. El Sprint Planning comprende el Project Charter y los procesos de planificación. En unas horas se los cepillan todos. El Sprint Review y las lecciones aprendidas son prácticamente lo mismo. E incluso hay un proceso de gestión de cambios, centrado en el PO, y que se revisa diariamente en el Daily Scrum.
No hay que perder de vista que hablamos de fases de proyecto muy cortas, típicamente de 2 semanas. En 2 semanas hay que iniciar, planificar, ejecutar, controlar y cerrar el proyecto. Así muchos procesos duran minutos. Os recomiendo leer un artículo que escribí hace tiempo sobre como aplicar PMBOK en proyectos pequeños.
Él cambio radical que vivimos en desarrollo hoy en día es que la responsabilidad de project manager se diluye entre varias personas. Pero teniendo en cuenta que el PMBOK no acaba de centrar lo que debería hacer un PM, ya que hay PM expeditivos, con poder, etc., no veo que el tener las responsabilidades de PM distribuidas en el equipo suponga un gran cambio.
Resumiendo, y sacando conclusiones: Se puede ser ágil y aplicar muchas de las recomendaciones del PMBOK. No son excluyentes.
