Javier Moya
Desde hace algún tiempo a esta parte los que nos movemos en el mundillo de la gestión de proyectos no cesamos de escuchar nuevos “palabros” como SCRUM, Agile, PMP, PRINCE2… y cuando preguntas por uno de ellos (o tal vez por todos) pareces desactualizado, un bicho raro, estás fuera de onda. Cuántas veces habré escuchado “¡¿Cómo es posible que no sepas que es SCRUM!? ¡Si yo lo utilizo desde hace mil años!” Cuando en realidad este erudito se leyó ayer un artículo que rezaba sobre el tema, y hasta hace dos días pensaba que “Agile” era moverse más rápido por la oficina; ¿Pero este compañero sabelotodo está necesariamente mintiendo? Pues mire usted, no tiene por qué. Es posible que, sin saberlo, usted mismo haya estado aplicando parte de todas las metodologías anteriormente nombradas… sin conocimiento de causa.
Principales características de las metodologías más usadas
Empezaremos definiendo, o al menos dando algunas pinceladas, de las principales características de las metodologías más usadas. Para empezar, las agruparemos en dos grandes grupos, la metodología tradicional y la metodología ágil.
Dentro de la metodología tradicional podemos hablar de dos grandes pilares, PMP y PRINCE-2. ¿La principal diferencia? La primera es de EE.UU. y la segunda de UK. Pero quedarnos ahí sería cómo hablar de la historia griega y decir que “hacían botijos”. Vamos a indagar un poco más sobre ellas.
La palabra PMP significa “Project Management Profesional”, o lo que es lo mismo, Profesional en la gestión de proyectos. Es un certificado que se consigue a través de un examen del PMI (Project Management Institute) estadounidense. Está basado en La Guía del PMBoK (Project Management Body of Knowledge), libro denso donde los haya, que agrupa una serie de acciones a llevar a cabo dentro de un proyecto y buenas practicas que ayudarán a gestionar y llevar un proyecto a buen puerto. Esta metodología se ha creado tras décadas de recopilar experiencias previas, puliendo detalles, añadiendo lecciones aprendidas. Sin ir más lejos, la sexta edición de La Guía del PMBoK está prevista para 2017. Pero aun estando en constante actualización, los tiempos cambian más rápido de lo que lo puede hacer un libro. Está claro que si ha sobrevivido décadas no ha sido por casualidad, y ahora mismo es (en mi humilde opinión) una de las mejores metodologías para gestionar proyectos. Pero como todas las metodologías no posee la verdad Universal; tiene carencias, por supuesto, y en el caso del PMP es su enfoque “mayorista”. Me explico: Todo el PMBoK y toda la metodología están enfocados a macro-proyectos. Inversiones de millones de euros con un equipo de trabajo de varias decenas de personas, con escenarios de alcance/tiempo/coste realistas en donde los roles están bien definidos, hay siempre una figura de un patrocinador, director de proyecto, equipo de trabajo, stakeholders… Seguro que a estas alturas de artículo muchos de vosotros estaréis pensando que vuestros proyectos no son así. Efectivamente, pero no por ello se acaba el mundo.
Esta metodología está diseñada para poder adaptarla a tus proyectos, no hace falta seguirla al pie de la letra, puedes escoger las partes que aplican a tu proyecto. Para entrar un poco en materia, La Guía del PMBoK se centra en un enfoque proactivo y predictivo, pretende anticiparse a los cambios, definir todo lo definible antes de empezar el proyecto, dar un alcance lo más completo posible, organizar un cronograma y ajustar los costes al céntimo. Prever los riesgos, adquirir el equipo de proyecto antes de arrancarlo, negociar las adquisiciones, establecer las comunicaciones, identificar los interesados y preservar la calidad en todos y cada una de las acciones del proyecto sí como del producto resultante, y todo ello integrado y engrasado por el director de proyectos. Ambicioso, sí, pero a veces, inabordable.
Siguiendo un poco la misma línea se encuentra el PRINCE2 (Projects In Controlled Environments), metodología basada en las cada vez mejores y crecientes prácticas en la gestión de proyectos, sobre todo para el gobierno de Inglaterra. En este caso la certificación es expedida por la compañía inglesa Axelos. Aunque en un principio dicha metodología nació para gestionar proyectos de ámbito privado dentro del gobierno de UK hoy en día se ha universalizado dando soporte tanto al sector privado como público alrededor de todo el globo.
Las semejanzas con la Certificación PMP son papables, ambas son metodologías que ambicionan gestionar un proyecto “en cascada” (en inglés waterfall), o lo que es lo mismo, con etapas bien definidas: primero iniciaremos el proyecto, se planificará, se ejecutará y finalmente se cerrará el proyecto. Su ciclo de vida es lineal y dentro de cada fase anteriormente citada puede (debe) existir otro ciclo de vida igual, iniciación, planificación, ejecución y cierre. Todo ello por supuesto orquestado por la figura del director de proyectos. Ambas se centran en la llamada “triple restricción”, le dan soberana importancia al Alcance-Tiempo-Coste, estableciendo líneas base de las que partir para gestionar el proyecto. Cualquier cambio en el alcance del proyecto, la desviación de un solo día de plazo en lo estimado o un solo céntimo más de presupuesto que tengamos que pedirle al Sponsor, requiere el paso por un comité de control de cambios. ¿En tu empresa existe dicho comité? ¿En todas las empresas del mundo hay comités de control de cambios para todos los proyectos? Como dije antes, proyectos de millones de euros sí.
Diferencias entre la metodología ágil y la tradicional
Pero entonces, si son tan parecidos, ¿son iguales? La respuesta evidentemente es NO. Como mencioné antes, la Certificación PMP tiene a sus espaldas bastantes más años de historia que el PRINCE2, por lo que sus buenas prácticas han sido más pulidas y comprobadas. Por otra parte, mientras el PRINCE2 otorga un papel relevante a la figura de comité para la toma de decisiones, La Guía del PMBoK deposita ese poder en el Project Manager. Podría decirse que la Certificación PMP se centra más en “la forma” de hacer las cosas y el PRINCE2 en “el resultado”. Otra diferencia importante, y que debería llamar la atención del lector, es la forma de conseguir la certificación. El examen del PMP consta de 200 preguntas tipo test con cuatro posibles respuestas de las que sólo una es verdadera, se dispone de 4 horas para realizar el examen y los pre-requisitos para poder realizarlo son varios, como tener un título universitario superior y más de tres años de experiencia en dirección de proyectos (4.500 horas) o más de cinco años de experiencia (7.500 horas) si no se está en posesión de título universitario. Aparte de lo anterior se necesita haber cursado un mínimo de 35 horas de formación específica y, por si fuera poco, alrededor de un 70% de aciertos en el examen. Y si todo esto te parece fácil, de las 200 preguntas hay entre veinte y treinta que son de “control”, es decir, no cuentan para el cómputo global de la nota final tanto como si las aciertas como si las fallas, pero evidentemente, no sabes cuáles son. Por el contrario para adquirir la certificación PRINCE2 no es necesario acumular estudios o experiencia previa, el único requisito para obtener el certificado es aprobar el examen basado en la denominada “Guía de gestión de proyectos exitosos con Prince2”, aunque en realidad no es un examen sino dos. El primero, el PRINCE2 Foundation consta de 75 preguntas de las cuales 5 son consideradas de control, por lo que no cuentan para nota, y se aprueba con un 50% de aciertos; este primer examen mide la capacidad del candidato para desenvolverse como un miembro del equipo de trabajo basado en los principios del PRINCE2. El segundo examen, el PRINCE2 Practitioner, es un poco más complicado, aunque sigue siendo de respuesta múltiple nos encontraremos con entre ocho y diez posibles respuestas por pregunta donde solo una es la correcta. Son dos horas de examen y 80 preguntas de las que tenemos que acertar un mínimo del 55%, es decir, 44 preguntas. En esta ocasión se valorará si los candidatos tienen las habilidades necesarias para aplicar el método PRINCE2 a un proyecto simple en el entorno en el que se desenvuelva.
Pero basta ya de hablar de las metodologías tradicionales y pasemos al mundo ágil y moderno. Hace pocos años se iniciaron unos movimientos novedosos en respuesta a diversos problemas que las metodologías tradicionales no podían solventar, al menos de la manera que requerían los clientes. Los principales problemas vinieron con el tiempo de entrega de los proyectos, el cliente demandaba algo y lo demandaba ya, no quería esperar a que se hicieran todos los planes de proyecto necesarios, ni un estudio de riesgos, no entendía por qué se debía hacer un seguimiento al equipo, solo requería que el producto estuviese en su poder lo antes posible y que fuese de calidad. Su proyecto no era millonario, un simple desarrollo de software que apenas durara un mes se convertía con la metodología tradicional en un proyecto de dos meses. En muchas ocasiones el mundo TIC cambiaba tan rápido que lo que el cliente demandaba el “día uno” difería sustancialmente de lo que demandaba el “día diez”, y radicalmente de lo que necesitaba el “día treinta”. Su alcance no era fijo, sabía lo que quería, pero desconocía lo que necesitaría dentro de “x” días.
Para poder dar respuesta a esto nacieron las metodologías ágiles que, aunque la lista es realmente extensa (XP, ExcelR, RUP, DSDM…), en este artículo nos centraremos en las dos principales y más conocidas. Agile y (aunque sea un framework y no una metodología propiamente dicha) SCRUM.
En qué consisten las metodologías ágiles
Para entrar en materia intentaremos explicar en qué consisten las metodologías ágiles, y lo haremos centrándonos en la primera Agile. Es una metodología basada en el trabajo incremental e iterativo. Su biblia es un manifiesto con unos principios ágiles “Agile Manifesto” que surgió a partir de pequeñas semillas de diferentes líderes en la gestión de proyectos a lo largo de todo el mundo que vieron la necesidad de crear algo nuevo que cubriera mejor sus necesidades que lo que había prestablecido hasta ahora. El movimiento ágil surgió en gran medida para cubrir necesidades de proyectos de desarrollo de software en la que aplicar las metodologías tradicionales se equipararía con matar moscas a cañonazos.
Hay una manera muy sencilla de hacerse una idea de las características de Agile. Pensad en proyectos con requerimientos cambiantes, predispuestos al cambio, flexibles, cuyo desarrollo y mantenimiento se adapten según las necesidades, depositando una gran confianza en los equipos de trabajo suponiendo que son auto-suficientes. Todo ello organizando el trabajo en “Time-Boxes” iterativos. Eso es una metodología ágil. De esta forma lo que se gana es rapidez en la entrega de un producto de calidad aunque sea faseado, es decir, el primer ciclo de trabajo ya produciría un entregable, una versión Beta por así decirlo, que si bien no cumpliría con todas las funcionalidades requeridas por el cliente, podríamos incluso tacharlo de prototipo, permitiría al cliente hacerse una mejor idea de lo que tiene y de las cosas a mejorar; tras esta primera entrega pueden redefinirse requisitos que se traduzcan en requerimientos, y en el segundo ciclo de trabajo el equipo ya no tendría que partir de cero, tendría una base sólida para crear más rápido una nueva versión del producto con nuevas o mejoradas funcionalidades.
Para exponerlo de manera más sencilla, iremos de más a menos; un proyecto Agile se compone de Release, que a “grosso” modo podría definirse como partes del entregable final ya depuradas. Cada Release se compone de varias iteraciones, y cada iteración de trabajos diarios llevados a cabo por el equipo de proyecto, y como último eslabón podríamos decir que los trabajos diarios lo forman las distintas tareas llevadas a cabo por cada miembro del equipo. Aplicando este tratamiento finalmente obtendremos un software (producto) de calidad en un corto espacio de tiempo. Hablo de software como el producto a entregar porque si lo pensáis bien, este tipo de desarrollos no casa demasiado bien con otros proyectos, por ejemplo, ¿os imagináis la construcción de un rascacielos con esta metodología? No creo que fuese una buena idea hacer de prisa y corriendo una primera versión del edificio y después pensar que los aseos es mejor que estén en el ala oeste, o que en lugar de ventanas quieres balcones una vez esté construido, o lo que es peor, una vez visto el prototipo te has percatado de que es mejor usar materiales más resistentes para los cimientos porque no has tenido en cuenta la fuerza que ejerce el viento sobre la estructura. Yo personalmente no me subiría a un edificio construido mediante una metodología ágil.
Aunque hay diversos títulos que acreditan a una persona como experto en metodologías ágiles, uno de los más reconocidos últimamente es el PMI-ACP expedido por el PMI, que también se encarga del PMP. Para conseguir dicha certificación hace falta (como en el PMP) acreditar un mínimo de experiencia gestionando proyectos y ahora, además, un mínimo de experiencia (tres años) gestionando proyectos ágiles, aparte en este caso 21 horas de formación específica. El examen consiste en 120 preguntas a completar en 3 horas con cuatro posibles respuestas de las cuales solo una es la correcta, por supuesto con sus veinte preguntas de control que no computan para nota y la exigencia de conseguir alrededor del 70% de aciertos.
El último “palabro” que más de moda está últimamente es SCRUM. A diferencia de lo que mucha gente cree, no es una metodología como tal, es un framework de trabajo ágil que favorece la creación de valor para un cliente. Como pilares básicos se apoya en la transparencia, inspección constante y adaptación, es muy ligero y fácil de entender. Seguro que quien más quien menos ha visto por su oficina o por internet las reuniones de un equipo de trabajo de pie y un mural con diversos post-it, pues esa gente está aplicando SCRUM. La palabra viene de las “melés” en español que se forman en rugby, ya que el trabajo en equipo es esencial.
El ciclo de vida de un proceso SCRUM consiste en coger un “Product Backlog”, que no es más que un paquete de requisitos del cliente/sponsor, el “Product Owner”, descomponerlo en varios “Sprint Backlog”, paquetes de trabajo más pequeños y manejables de los requisitos, y para realizarlos se iteran distintos “Sprint” de trabajo, que pueden ir desde las 24 horas a 30 días. Finalmente lo que resulta de este proceso es un producto final que se ha ido formando a partir de pequeños incrementos y mejoras constantes. Repitiéndolo para cada “Product Backlog” obtendríamos el producto final. Aquí la principal diferencia con otras metodologías ágiles (y por supuesto con las tradicionales) es la figura del “Scrum Master” que no debe ser confundida con la de “Project Manager”. Su figura es más la de un asistente del proceso que conduce las sesiones, aconseja al “Product Owner” sobre la visión y objetivos finales, y asegura el uso de SCRUM para el proyecto. La otra característica de SCRUM son las reuniones que mantiene todo el equipo. Antes de un Sprint está la “Sprint planning meeting” que puede durar hasta 8 horas, donde se definen el “qué” y el “cómo” se va a elaborar el trabajo, si buscamos una similitud con la metodología tradicional podría equipararse con definir el alcance. Tras esto, cada día que dure el Sprint se realizan “Daily Scrum” de unos 15 minutos, son las reuniones que todos tenemos en la cabeza con post-it en la que se pone en común lo que se hizo desde la anterior Daily, lo que se va a hacer hasta la siguiente y los inconvenientes encontrados. Y por último, la “Sprint Review” al acabar el Sprint en la que se presenta el producto resultante del “Sprint Backlog”. Adicionalmente, al finalizar una serie de Sprint se pueden realizar una retrospectiva, de unas 3 horas de duración, en la que se evalúan más las técnicas y habilidades empleadas para valorar si pueden mejorarse y aplicarse para los siguientes Sprint. Como siempre, mejora continua.
El único punto negativo, mal entendido por los equipos de trabajo, es asociar la metodología ágil con la ausencia de documentación, es cierto que al ser sprint rápidos, ligeros y en constante cambio es complicado realizar una documentación detallada, pero no es excusa para suprimirla totalmente, ya que unos mínimos siempre deben estar presentes en los proyectos, por muy ágiles que sean. Para obtener el título de SCRUM Máster existen multitud de cursos impartidos por expertos que superando un examen final otorgan el título PSM-Profesional Scrum Máster.
Para finalizar, hablando a nivel global, podríamos decir que las metodologías tradicionales se centran en la planificación, mientras que las ágiles ponen su foco en la ejecución. En lo que se refiere al Project Manager, tradicionalmente es una figura que controla el proyecto y dirige a los miembros del equipo, mientras que en el mundo ágil los equipos están auto-organizados y auto-dirigidos. La una posee líneas base de tiempo, coste y alcance, la otra es adaptable al cambio, y su restricción principal es la calidad del producto y la rapidez… No podemos concluir que haya una mejor que otra, simplemente distintas, nacidas para diferentes tipos de proyecto. Quizá no utilices una ni otra y dentro de unos años, tu forma de trabajar, se convierta en otra metodología igualmente válida.