El problema de la agilidad es que no vamos a saber cuándo se termina el proyecto (y la típica solución al anterior problema)

Mira que habré dado cursos y charlas sobre agilidad, sobre las ventajas de un ciclo de vida iterativo – incremental frente a uno en cascada, etc., y no falla, siempre, pero siempre, hay alguien que me pregunta, o que objeta: El problema de un ciclo de vida iterativo, o de la agilidad, es que no vamos a saber cuándo se termina el proyecto, con el cascada si lo sabemos.
Te pongo en contexto. Como ya hablamos más despacio en aquel post de el ciclo de vida iterativo e incremental y el riesgo de olvidarse del iterativo y quedarse solo con el incremental, en un ciclo de vida en cascada las fases del ciclo de vida (requisitos, análisis, diseño, etc.) se realizan (en teoría) una única vez y el inicio de una fase no comienza hasta que termina la fase que le precede.
Por otro lado, en un ciclo de vida iterativo e incremental se van liberando partes del producto (prototipos) periódicamente, en cada iteración, y cada nueva versión, normalmente, aumenta la funcionalidad y mejora en calidad respecto a la anterior. El ciclo de vida iterativo e incremental es una de las bases de un proyecto ágil, más concretamente, con iteraciones cortas en tiempo, de pocas semanas, normalmente un mes y raramente más de dos.

Del cascada vamos normalmente, y directamente, al proyecto cerrado

El proyecto cerrado lleva al cascada, el cascada lleva a cerrar los requisitos, cerrar los requisitos lleva al sufrimiento. Percibo mucho miedo en ti. (Que hubiera dicho Yoda)
Como también mencionamos en su momento, en aquello de contrato cerrado, ¿el peor enemigo del software o mal necesario? (esto te interesa mucho, más que cualquier cosa en la ingeniería software), el ciclo de vida en cascada es la base del mortal proyecto cerrado, es este último su manera más usual de establecer una relación económica entre el cliente y el proveedor.
El contrato cerrado, o “llave en mano”, consiste, básicamente, en aplicar el cascada, el cliente redacta, siempre antes de comenzar el proyecto, un documento llamado “pliego de condiciones” que, principalmente, contiene los requisitos que debe implementar el software, o el sistema de información. Las empresas candidatas a llevarse el proyecto toman como base esos requisitos, le dicen al cliente por cuánto tiempo y cuanto dinero será el proyecto.
Es decir, se cierra desde el principio el presupuesto, el tiempo y los requisitos.

La teoría de que con el cascada, al empezar el proyecto, sé cuando durará y cuanto me costará

Según lo anterior, aparentemente, en un ciclo de vida en cascada, al comenzar, se tiene una estimación del tiempo, requisitos y el presupuesto del proyecto. Y esto, en muchas empresas que trabajan por presupuestos cerrados (normalmente todas las grandes), es una manera de trabajar ineludible, que hace muy difícil escapar de las garras del proyecto cerrado y del ciclo de vida en cascada.
Pero la realidad dice que esto genera en el día a día muchos, pero muchos, problemas (sólo hay que salir “a la calle” para verlo).
La mayoría de los problemas vienen de que pocas veces los requisitos están realmente cerrados al principio. El cliente, no siempre, pero si la mayoría de veces, redacta unos requisitos demasiado pronto, escribe ideas poco concretas e incompletas de lo que se supone necesita que haga el software. Y, normalmente, cuando avanza el proyecto, esos requisitos difieren de lo que realmente él necesitaba, lo cual acaba sabiendo cuando recibe la primera entrega.
Y la realidad también dice que el proveedor, en base a esos requisitos (la mayoría de las veces poco concretos, o que difieren de lo que realmente se necesita) hace una estimación del tiempo basada en “estimación dirigida por lo que el cliente quiere oír”, es decir, bajando al máximo los tiempos, porque sino no se lleva el proyecto.
Los anteriores forman el coctel explosivo del día a día de los grandes desarrollos, los conflictos, atajos, los saltos de calidad para hacer entregas, las recopilaciones de correos electrónicos para justificar el “yo te lo dije”, etc., están servidos, más aún si hay penalizaciones económicas por retrasos en las entregas.

Los riesgos que corres en un proyecto en cascada: comprar algo, sabiendo el precio, pero que luego no te vale

Siendo pragmáticos, si trabajas en cascada corres un alto riesgo de tener un presupuesto cerrado para desarrollar un producto software que finalmente, o en gran parte, no te sirva.
Es decir, que salvo que tengas bien claros los requisitos, cuales son y cuales serán, que sean los que has escrito al principio los que realmente necesitas, que sean esos los que necesitas y que no vayan a cambiar a lo largo del proyecto, salvo que se den los anteriores (y hay proyectos donde SI se dan estos condicionantes, pero no son muchos)… el cascada es un riesgo en la práctica.
Sí, tendrás claro el presupuesto… pero comprarás algo que no te vale.

¿Qué pasa en agilidad?

En agilidad el cambio (por ejemplo, y principalmente, en los requisitos) es bien venido. La idea es sacar un producto que cumpla las expectativas reales de aquellos que lo van a usar, expectativas que pudieran no conocerse al principio.
Al subcontratar un proyecto ágil, lo más idóneo es el pago por iteración, por tiempo, por historia de usuario añadida al prototipo o por puntos historia.
Pero sería ingenuo negar que la gran mayoría de las grandes empresas no están preparadas para trabajar con este modelo de facturación… y que aún les queda mucho para cambiar esa manera de relacionarse con los proveedores.

Pero la vida es dura… la solución de compromiso, empezar con un cascada “light” y continuar con agilidad o iteraciones

Nos quedan muchos años para que los proyectos cerrados dejen de ser la principal manera de trabajar entre grandes empresas, clientes y proveedores. Nos guste o no (y no nos gusta).
Por ello, una solución alternativa típica es buscar un punto intermedio, que pasa normalmente por hacer proyectos ágiles en el contexto de releases o agrupando topes de varias iteraciones o Sprints.
Es decir, para evitar el temeroso horizonte de “cuándo terminarán las iteraciones” cerrar un primer grupo de ellas (por ejemplo 6), hacer una primera aproximación a los requisitos a cumplir al final de las mismas (por ejemplo, el product backlog, por cierto te dejo lo de cómo mejorar la estimación y preparación del product backlog: reuniones de refinamiento o Backlog Grooming las historias de usuario a cubrir en esas 6 iteraciones), hacer una estimación económica de esas primeras iteraciones y empezar a hacer desarrollo basado en un ciclo de vida iterativo e incremental.
Vamos un poco de cascada “light” al principio y agilidad para desarrollar, pero asumiendo holgura por ambas partes (cliente – proveedor) a la hora de cambiar requisitos al final de cada iteración.

Para ampliar todo esto…

Si continúo con el post escribo un libro, así que, en vez de ello, te dejo el libro que ya escribí y en el que puedes ampliar mucho de lo aquí dicho (aquí lo puedes encontrar)…
libro-gestion-agil

8 comentarios en “El problema de la agilidad es que no vamos a saber cuándo se termina el proyecto (y la típica solución al anterior problema)”

  1. Hola Javier, el problema está que los que dirigen las empresas no son informáticos son «contables» y sólo entienden de partidas presupuestarias, balances, cuentas de beneficios, control financiero, etc. A un informático le puede cambiar la forma de pensar y convencerle del agilismo, pero a un «contable» no, deben tratar a todas las áreas de la empresa igual.
    La única forma de realizar estimaciones correctas es basandote en los requisitos inciales y fijar en la propia oferta la forma de «pagar» los cambios en los requisitos, por ejemplo calculando los PF extras y a tanto el PF. Saludos.

  2. Hola Javier,
    Gran calidad, como siempre, de tus artículos. Coincido contigo en numerosas afirmaciones (y entre las que más me duelen, esas en las que tenemos que llevarnos las manos a la cabeza y asumir aún que el modelo en cascada está muy arraigado en muchos sitios); sin embargo, después de leer completamente el artículo, me sigue surgiendo una duda…
    Por simplificar la idea, mencionas que se puede adoptar un punto intermedio (como en otros tantos aspectos de la vida) y te cito textualmente, «[…] proyectos ágiles en el contexto de releases o agrupando topes de varias iteraciones o Sprints […]». A pesar de ello, creo que se pierde esa visibilidad a largo plazo: se podrá trabajar por sprints, se podrá tener una alta capacidad de reacción ante cambios de requisitos o de alcance, se podrán mitigar o minimizar riesgos… pero en mi opinión, el final lo seguiría viendo difuminado o borroso, máxime, cuando muchas veces necesitas de esas «fecha inicio – fecha fin – coste» para una RFP, concursos públicos, etc.
    Aún trabajando de la mano del cliente más ágil que podamos encontrar, en el fondo, como ente pagador querrá saber cuándo estará todo su producto pagado (obviemos que desde los primeros sprints dispondrá de las funcionalidad más críticas para su negocio, pero al final, un sistema es un conjunto de funcionalidades, más y menos importantes que el cliente solicita), el tiempo que le llevará o el tiempo que un proveedor por contrato trabajará para él (sea haciendo un desarrollo o un mantenimiento).
    Es en ese caso (me quedo quizás con uno de los casos más peliagudos, los concursos del sector público), ¿te empiezas a dibujar un diagrama de Gantt aunque luego lo gestiones de forma ágil? En caso de cambios de alcance, ¿te modificarías ese diagrama -que sólo tu guardas celosamente porque eso no es ágil XD- y te replanificarías la fecha estimada de fin?
    Por ir terminando, y si durante mi redacción del mismo se ha perdido la idea debido a su extensión, concluyo de manera breve: si el proyecto necesita de un backlog de X historias de usuario, estimas que se puedan añadir N historias nuevas que aún no están claras por parte del cliente y tienes R recursos para su desarrollo, ¿cómo estimarías la duración o tiempo T que estarán asignados a ese proyecto los recursos (hablando de cara a estimaciones, reporting a áreas de staff/RRHH, gestión presupuestaria, de necesidades de ubicación para el equipo, etc.)? ¿Qué mecanismo utilizarías para ir teniendo definido ese fin y cierre de proyecto?
    Muchas gracias por tu tiempo.
    Saludos.

  3. Sobre cómo gestionar y estimar un proyecto ágil, que no un sprint, existe un libro genial: Agile Estimating and Planning de Mike Cohn. Donde se describe cómo realizar una planificación a largo plazo e incluso un presupuesto para proyectos ágiles.
    http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415
    Es cierto que mucha gente «ágil» te dice que no hay que estimar, no hay que planificar, que eso no es ágil. Pero para mi esto es un error. Por supuesto que se puede estimar y se puede planificar y por tanto presupuestar a la larga. De la pericia del equipo dependerá que estas estimaciones y presupuestos se cumplan en mayor o menor medida.
    Lo de no estimar, no planificar a la larga y no presupuestar está muy bien cuando trabajas en tu proyecto y tienes un presupuesto máximo. De modo que te dedicas a sacar el mejor producto posible y lo antes posible.
    Pero para trabajar con clientes suele ser necesario estimar y presupuestar. No hay que buscar excusas para no hacerlo, sino aprender a hacerlo bien.
    Nos pasamos nuestro día a día estimando desde que ponemos la hora del despertador. Por qué en el desarrollo del software iba a ser diferente?
    El problema es que mucha gente estima mal y usa aún peor estas estimaciones.

    1. Y más cosas. Nosotros cuando estimamos, es cuando dedicamos un momento de reflexión en común para pensar en si realmente todos tenemos clara la complejidad de una tarea, y muchas veces te das cuenta de que no es así, y eso lo vemos a la hora de estimar.

  4. Buenas a todos,
    trabajo con metodología scrum, siguiendo está filososfía.
    Aquí esa ide de lo agil, no se cumple nuca. Hay personas muy capaces, pero este tipo de forma de trabajar me para es mas folosófica que real. De echo hay gente que se ha marchado por eso mismo, al final degenera en caos. Por mi experiencia es fácil de saber, una filosfía prefecta llevada a la practica por seres imperfectos.

  5. Quizá (sólo quizá) estamos asumiendo una base que, en Agile, es insostenible y que no estamos discutiendo: me refiero a que habitualmente los contratos son, por un lado de «Desarrollo de un sistema» (concebido como proyecto cerrado) y por otro, de «Mantenimiento de dicho sistema» (pero en este caso, concebido como servicio, supuestamente renovable). Esto ha sido así históricamente, pero, hoy en día ¿tiene sentido separar ambas cosas? ¿No es mucho más razonable unir ambos contratos en uno sólo, de «Servicio de Desarrollo y Mantenimiento»? ¿No es eso, exactamente lo que Agile facilita? Si erradicamos este tipo de contratos, en beneficio de los de «servicio» (que llevan años ya asumidos por los departamentos financieros) se solucionan algunas trabas de gestión, planificación y delivery, incluso de tipo financiero y presupuestario…

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Share This
Ir arriba