Este es un post con olor retro, vintage. Empezando por haber usado la palabra «proyecto» junto a la palabra ágil, palabra que, en tiempos, yo he usado mucho, al igual que el PowerPoint, pero de la que me llevo quitando desde hace años, ya estoy prácticamente limpio, por el dudoso bien que una gestión de «proyectos» puede hacerle a la creación de productos y servicios y su también dudosa aplicación a la gestión ágil.
Pero hoy el tema no es meterse con los proyectos, ya ha habido muchos post y charlas sobre ello (te dejo una lista de algunos de ellos al final de post), hoy el tema es esa pregunta tan vintage, que he querido dejar literal, con la palabra proyecto incluida, que tanta gente que llega de nuevas al mundo ágil te hace de… ¿Y cómo se calcula el avance de un «proyecto» ágil?
La pregunta suele venir cuando alguien que sigue trabajando en gestión clásica, se acerca a la gestión ágil y se le caen dos piezas fundamentales de la misma: la gestión de avance por horas y la fecha fin de proyecto.
La gestión de avance por horas, aquella que es de los tiempos de la Tierra Media, se basaba en tener una fecha fin de entrega de algo, y contar de alguna manera las horas, o días, que hay desde el comienzo hasta esa fecha fin y luego, según la fecha en la que estamos, hacer un porcentaje de horas para «saber» como vamos (mientras escribía este párrafo un sudor frío ha caído por mi frente).
No dejo de pensar mientras escribo, como puedo estar haciendo un post sobre esto en el año 2018. Y el problema no está en lo duro de escribir este post, está en que aún, en 2018, tenga que convencer a gente de que la gestión de avance por horas es un error.
En una gestión ágil (e incluso sin ser ágil) este modo de calcular el avance, en función de horas transcurridas, no tiene sentido por…
a) Es absurdo por naturaleza, horas transcurridas no es trabajo terminado y menos aún… valor aportado (va post… horas en la oficina vs ideas y conocimiento aportado)
b) En un ciclo de vida ágil no se trabaja con fechas fin, más bien con entrega continua.
c) A diferencia de la gestión de proyectos, no hay un alcance cerrado (la antigua especificación de requisitos), por lo que no sabes «lo que te queda», lo cual es real como al vida misma, a un servicio o producto de base tecnológica siempre se le están añadiendo cosas.
Entre que medir horas es absurdo (estar sentado suma horas y no necesariamente añade valor a un producto o servicio) y entre que no sabes cuanto te queda hasta llegar a una fecha fin que no hay (hay entregas continuas) o completar una antigua especificación de requisitos… ¿qué nos queda para ver cómo vamos?
Pues por ahora, hasta que alguien descubra otra cosa, te quedan las siguientes estrategias (hay alguna más pero no quiero hacer más complicado el post y me quedo con las más típicas), que realmente no son un cálculo de avance como tal (para saber el avance habría que conocer el fin), más bien son un «cómo vamos»:
– Con lo que viene a llamarse velocidad, que es cuánto trabajo se ha completado en un intervalo de tiempo, típicamente un Sprint. Esto se suele medir, si no hay más remedio, en Puntos Historia, o, idealmente, en items o Historias de Usuario terminadas. Y esta estrategia vale si esos items a contar son verdaderamente cosas terminadas (en tecnología cosas que han pasado a producción o pre-producción), no documentos o pantallas vacías.
– Con algo más profundo, complementario a lo anterior, y que incluso puede llegar a sustituirlo… el valor aportado. Una cosa es terminar items y otra que valgan para algo (esto requiere dedicarle un tiempo, no es trivial entenderlo si es la primera vez que lo escuchas, te dejo un post Hypothesis-Based Development, desarrollo basado en Hipótesis)
Antes de terminar, y por no dejarlo sin citar, recuerda que la hora como tal no está eliminada de la gestión ágil 8tampoco es que sea obligatorio usarla), pero una cosa es usarla para «cuánto tardamos» y otra para «cuánto llevamos», pero esto para otro post. En cualquier caso, olvida la hora como medida del avance, y olvida la idea de proyecto.
Más allá del concepto “proyecto” en tecnología #noprojects #beyondproject
6 peligros de pensar en proyectos
En vídeo y dibujando… Gestión de Proyectos vs Equipos
Gestión orientada a proyectos vs orientada a equipos (llámala ágil)
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Uno de los principales problemas para cambiar una metodología basada en horas a otra ágil es encontrar una manera sencilla de facturar esto último. En una metodología basada en horas esto se hace con una simple multiplicación. Horas imputadas al proyecto por precio por hora. ¿Cómo se facturaría mensualmente un trabajo realizado con metodologías ágiles?
Llámale proyecto o llámale «llegar a un punto». Cuando el CEO viene y te pregunta: «Cuando tendremos el nuevo site funcionando?» necesita una estimación. Y no le puedes venir con que somos ágiles y que no tiene sentido en el mundo ágil hablar de estimaciones de futuro.
Es muy cómodo decir, «no se puede». Pero la realidad es que negocio «necesita» esa estimación.
Alberto: puedes facturar igual. Nosotros lo hacemos así. Entregas valor y facturas las horas que te ha costado entregarlo.
Jose Huerta: si necesitas estimar, tienes que hacerlo. Si necesitas dar una fecha de compromiso igual. Pero no es muy razonable calcular el avance en base a las horas que llevas echadas. Calculas el avance en base al valor (funcionalidades) entregado.
Al site le faltan las funcionalidades X y Z. X lo tenemos estimado en N días y Z en M. Nos comprometemos a tenerlo antes del día D. Estoy obviando terminos scrumnianos aposta.
No tener los cojones para predecir el faltante o atraso de un proyecto es una excusa para decir que el proyecto es ágil y todo es paz y amor. Los recursos de dinero no son ilimitados por lo cual se puede se debe poder establecer cuánto falta de un proyecto y hacer una visión del mismo.