Por otro lado, la gente que utiliza PMBOK te dirá que no hay nada como el desarrollo en cascada o Waterfall, con toda la información y requerimientos antes de iniciar el desarrollo, y que Scrum es una perdida de tiempo, sobretodo en España.
Personalmente, creo que todos tienen parte de razón. No hay una opción buena o mala, mejor o peor. Ambas opciones son bien válidas, hay que saber aplicar la metodología adecuada para cada situación.
El objetivo, la fecha, y el entregable
En un mundo ideal, bajo un PMBOK tienes muy claro cual es el objetivo final porque todo el proceso está descrito al detalle, mientras en Scrum tienes la idea del objetivo y el desarrollo se lleva a cabo sobre la marcha.
En un desarrollo en Waterfall tienes una fecha final de desarrollo medianamente realista porque está completamente planificado, teniendo siempre presente que cualquier desvío en las tareas retrasa la salida porque no tienes un producto entregable.
En Scrum te vas acercando poco a poco y de forma incremental a esa idea final, pero siempre acabando el ciclo de la iteración con un producto entregable. Es decir, que una vez llegada una supuesta fecha final, puede que no tengas el proyecto finalizado, pero puedes realizar una entrega totalmente funcional de un porcentaje avanzado del mismo.
Entonces diréis… Scrum es mejor, porque puedes entregar el 80-90% del proyecto en la fecha de entrega. Pero la verdad es que, ¿Cuando os habéis encontrado un proyecto donde os dejen entregar una parte y no os pidan el producto completo? Aunque se puedan fasear cierto aspectos o detalles, la mayoría de las veces os pedirán todo o nada.
Información y elementos disponibles
La diferencia principal entre Scrum y PMBOK es que éste último necesita de una toma de requerimientos previa a la planificación, un análisis tanto funcional como técnico, y una vez todo está firmado y planificado hasta el mínimo detalle, entonces arranca el ciclo de desarrollo.
En cambio Scrum juega con el Caos, es decir, no tiene porque existir un funcional, solo un rol que tenga la idea clara del desarrollo que se encargará de guiar al equipo hacia su objetivo priorizando las tareas y dando feedback continuo. Cada iteración constituye en sí una toma de requerimientos, análisis, planificación, ciclo de desarrollo, y entrega de producto.
Esta es la diferencia que determina el porque Scrum es mas abierto a cambios, porque desarrollar en ciclos cortos permite que una idea pueda ser maleable, mientras en PMBOK cualquier cambio de requerimiento supone para el proyecto, revisar los funcionales, y replanificar. Esto último en el mundo ideal, en el mundo real te comes el cambio y te callas :)
El Equipo
Un equipo en Waterfall sigue unas indicaciones, mientras que en scrum el equipo se auto-organiza en base a unas prioridades. Para llevar a cabo el trabajo Scrum dice que necesita de un equipo maduro.
¿Y eso que significa? Pues que en Scrum se necesita un equipo que haga suyas las tareas y responsabilidades, y se comprometa a cumplirlas en el plazo que el mismo equipo ha considerado. En cierto modo en PMBOK el equipo vive más tranquilo por no ejercer ese conjunto de responsabilidades, aunque se acaba trabajando igual.
Adquirir tanta responsabilidad no es algo que quiera todo miembro de un equipo. Muchas veces te encontrarás que hay gente que necesita que le detalles las cosas, y que prefiere no coger la iniciativa a la hora de resolver los problemas que surjan a lo largo del desarrollo.
Debes estar seguro de que tu equipo está preparado antes de aplicar Scrum. El equipo es fundamental para el éxito en Scrum.
Si pensabas que no afecta al equipo, estabas bien equivocado.
Reuniones y seguimiento
En el caso de PMBOK, se realizan reuniones para el inicio del proyecto, reuniones de seguimiento del proyecto, y reuniones de fin de proyecto con carácter de revisión de errores y aprendizaje de los mismos. Por supuesto, las reuniones están ya fijadas antes de iniciar el ciclo de desarrollo, y según el avance del mismo, se pueden llegar a establecer más reuniones de seguimiento si es necesario.
En el caso de Scrum, es un concepto bastante parecido pero aplicado a la iteración corta y con más seguimiento por la falta de detalle del proyecto. Tenemos las reuniones diarias para revisar en equipo el compromiso de cada uno, las reuniones de planificación, las de review del producto y feedback de Product Owners, y por último las de retrospectiva, también para analizar problemas y errores, y aprender de ellos de cara a la siguiente iteración.
Si quieres saber más, hace un tiempo publique un post sobre Los Scrum Meetings.
Resistencia al cambio
Aquí no vamos a diferenciar entre ambas metodologías, ambas se encuentran con el mismo problema: La resistencia al cambio.
Por una parte PMBOK es muy estricta en cuanto a sus necesidades y organización, pero no encontraras empresas en España (o casi) que cumpla religiosamente con lo que dicta la PMO y la guía de PMBOK. Siempre hay problemas en la toma de requerimientos, no siempre se espera a tenerlos cerrados y firmados para empezar el desarrollo. Por otro lado, cuando no se ha cambiado un requerimiento cuando el desarrollo está en marcha…
En Scrum no es necesario tener un funcional en mente, pero eso no significa que no se deba realizar un esfuerzo de síntesis para tener la idea del proyecto clara con todas las implicaciones posibles. Ese acaba siendo un problema, porque no se realiza ese esfuerzo. Y por otro lado, la gente tiene puestos de trabajo que les mantienen demasiado ocupados como para dar el feedback continuo que requiere un desarrollo incremental sin el nivel de especificación de PMBOK.
La aplicación de cualquier metodología ya sea PMBOK o Scrum no requiere un cambio de chip del equipo de desarrollo y responsables, sino que requiere una implantación y cambio de filosofía que aplica a prácticamente toda la empresa, o por lo menos todas aquellas áreas implicadas en proyectos de desarrollo.
Si esto no se lleva a cabo correctamente y la empresa no se toma en serio la organización y apoyo necesario para su funcionamiento, el fracaso (retraso de fechas, producto erróneo, etc.) está más que asegurado.
¿Alguna conclusión?
Al final, cualquier opción es buena si te ayuda a alcanzan los objetivos marcados.
No te dejes llevar por modas, o influencias. Debes seleccionar como afrontarás el proyecto teniendo en cuenta donde trabajas y como se trabaja, los elementos con los que cuentas, el equipo, y la libertad que te dejarán. Acabas adecuando la metodología a la forma de trabajar de tu empresa. No es obligatorio utilizar una u otra de forma estricta (aunque sería lo ideal), puedes utilizar sus detalles según tus necesidades: desarrollo en ciclos cortos, reuniones diarias, requerimientos funcionales, reviews, dar más responsabilidades al equipo, etc.
Aplicar cualquier metodología de proyectos, ya sea utilizando un clásico Waterfall bajo PMBOK, o bajo el marco Agile como Scrum, y aplicarlo en el desarrollo, puede ser un poco frustrante. Especialmente en España. Lo primero que te puedo aconsejarte es que tengas paciencia, y lo primero que puedo decirte es: Ánimo! :)
Me gusta la filosofía de Scrum, pero en España no es fácil encontrar empresas que realmente se vuelquen en su aplicación, responsables que confíen y tengan la paciencia para llevar a cabo la adaptación, y que además se den las condiciones necesarias. Los casos de éxito son lamentablemente escasos. Ojalá me equivoque y sea cosa mía.
Si consideras que me equivoco en algo, quieres añadir detalles que he omitido, o simplemente quieres compartir tu experiencia, por favor ¡No dudes en hacerlo!
Also published on Medium.
Last December, I started a coaching series, and while I was doing my introspection analyzing…
Today is January 1st. It is time to review what happened last year and set…
This post was originally included in the 24th issue of my weekly newsletter. If you…
I started this post in my newsletter last week, but I decided to move it…
Political and group polarization was the starting topic in my last newsletter (issue number #18).…
I included the topic of introverted leaders in my eighteenth newsletter. This post is based on…
This website uses cookies.
View Comments
Cuando la empresa ya tiene procesos de dirección de proyectos ya definidos y verificados ya sea con CMMI, ISO o MoProSoft (que es el caso de México), es un tanto complicado elegir lo mejor de entre todos los métodos y herramientas.
Sin embargo, sin afectar a esos procesos ya definidos, se pueden agregar, más no quitar, métodos o herramientas que te puedan ayudar al logro de los objetivos, a veces es cosa de las necesidades de negocio o del cliente que quiere ver avances cada semana.
En fin, a mi parecer, por eso somos PROFESIONALES, debemos ser capaces de aplicar aquello que nos va a llevar a lograr los objetivos del proyecto, eso si, asumiendo toda la responsabilidad del éxito o fracaso de lo que apliquemos.
Saludos desde México.
Scrum no le llega ni a los talones al PMBOK... ambos no son lo mismo para la gestión de proyectos... scrum se integra pero dudo que reemplace... ademas para aprender scrum solo necesitas 3 días :s
Estimados, pertenezco al grupo de quienes afirman que los proyectos deben planificarse previo a su ejecución. Hay múltiples estándares predictivos (Plan-Do-Check-ACt) y no solo PMI (IPMA, Prince-2, y más actualmente la norma ISO:21.500:2013).
Me sorprende leer la facilidad con que los cultores de los modelos Agile suelen desacreditar a todos ellos, siempre basados en múltiples lecciones aprendidas y recogiendo las mejores prácticas.
Después de leer este artículo y varios textos al respecto, me he formado una impresión, que equivocada o no, es refrendada por todos quienes dan su opinión y por la descripción formal de Scrum y otros modelos "ágiles".
Si buscan el CHAOS Manifesto 2013 (Standish Chaos Report) podrán ver que los índices de fracaso y fallas en los proyectos tecnológicos se ha mantenido, salvo escasas excepciones, en forma casi inalterable, es decir, no evidencia empírica de un mejoramiento en los KPI de cualquier proyecto, en especial la sitisfacción del cliente (calidad) que sustente que los nuevos modelos hayan aportado "algo nuevo en el horizonte" de los proyectos TI. Consideren que la base de datos de CHAOS es de 50.000 proyectos y que sigue mostrando desviaciones importantes (considerablemente más que en cualquier otra industria) en los conceptos de plazos, costos y alcance.
Reconozco que las TI han revolucionado la forma de mirar el mundo. Soy de los que sostiene que eso lo han logrado sólo dos grandes inventos (imprenta e internet), pero no soy capaz de imaginarme como la falta de visión del todo puede lograrse a través de incrementos no planificados como una parte del total y menos que esto sólo esté en la visión de "unos pocos".
El mayor problema de los proyectos TI sigue siendo la falta de una métrica de avance confiable. Todo esfuerzo por modelar un sistema de medición de avance ha fracasado, pero eso no justifica que debamos olvidarnos del rendimiento de los recursos, comprometer hasta tres o cuatro veces los mismos recursos en distintas propuestas (¿les suena familiar?).
Propongo que antes de seguir buscando soluciones "geniales" se discuta detenidamente sobre las causas de fracaso en los proyectos TI, especialmente en lo referido a la falta de definición y claridad del alcance del proyecto y de su producto, aspecto repetido en toda encuesta disponible y que Ágile desestima. Cualquier modelo no predictivo termina siempre en un "nunca termina". Su cliente sigue pensando que lo puede cambiar todo, con o sin Scrum, y de facto sigue haciéndolo.
En mi opinión, la base del éxito sigue estando, como en cualquier otra industria, en la asertiva gestión de requerimientos y la de los cambios solicitados (formulación, entendimiento común, trazabilidad con los objetivos, verificación y validación de requerimientos).
Sin duda, estoy abierto al debate de las ideas.
Saludos desde Chile.
Edgardo
Hola, me he encontrado con personas que por alguna razón comparan PMI con SCRUM... y lo encontré un disparate, sin embargo antes de desestimar por completo si quiera investigar "el por que" de tal confusión, quise revisar en Google para encontrar algún enfoque que apoye esa idea... y bang¡¡ efectivamente hay más gente de lo que pensé que tiene esa idea... Por cierto el origen de todo, como casi siempre, es el no investigar lo suficiente y quedarse con las escuetas definiciones de Wikipedia. Para no repetir, adhiero completamente a lo indicado por Edgardo. PMI no es una método para proyectos de Desarrollo, es un compendio de buenas prácticas que modela una serie de procesos, que en su conjunto aportan para un buena administración de Proyectos de Cualquier tipo y alcance. Es muy probable que un proyecto requiera montar su solución de Software sobre una plataforma física, que tenga que gestionar accesos de red, seguridad, compras de hardware, implementación de esta plataforma física en 2 sites de dos proveedores distintos. Por tanto se gestionarán diversos recursos, varias empresas, Cliente y Proveedores. En fin, y solo estoy mencionando un proyecto más bien pequeño. Alguien puede decir que con Scrum puedo gestionar este nivel de elementos?. Está claro que no, y la respuesta es bastante sencilla, y está en la definición misma de lo que es SCRUM y su alcance. No hay lugar a dudas de que Scrum es un complemento perfecto para la Administración de Proyectos bajo los estándares buena práctica del PMI.
Ahora entiendo porque el desarrollo de software falla cuando existe el problema de la aceptación y adaptación del cambio, más cuando existen la desinformación y aun así hablamos solo por hablar. Me sorprende leer aquí el que se diga que Agile no tiene una fecha de entrega definida, o que por que existen procesos como CMMI, ISO o MoProSoft es complicado elegir otro, para empezar son metodologías, al igual que agile, lo que significa que podemos adapartarlas al entorno en que estemos, mucho más podemos combinar ambas.
Agile no se aprende en un día, para los de PMO, Agile va mas allá de lo que creen, ya que antepone la calidad del producto antes de que llegue la fecha de entrega, inmiscuye al cliente en todo el proceso lo cual no hacen los métodos de la PMO, Agile es TDD, CMDB, TEST, QA, XP, etc.
Si no se ha trabajado en conjunto con PMO y Agile, lo mejor sería no opinar.