Una reflexión recurrente en la literatura ágil se refiere a que en un enfoque tradicional se fija el alcance y según esto se determinan los plazos y costos, mientras que en un enfoque ágil se fijan los plazos y costes y según esto se implementa el máximo alcance posible. Esto se ilustra en la siguiente figura (una adaptación de una imagen atribuida al método ágil DSDM).
Inmediatamente pensaríamos: ¿qué contrato se adapta mejor cada situación?. Si bien hay variadas alternativas (ver "Contratos Ágiles": Parte 1 y Parte 2), el caso tradicional suele coincidir más con contratos de tipo "Precio Fijo /Alcance Fijo" y el caso ágil, a priori, podría ser más cercano al contrato de tipo "Tiempo y Materiales", aunque en ambos tipos de contratos se presentan ventajas e inconvenientes para el proveedor y para el cliente.
A partir de este punto presentaré mi visión ágil y pragmática respecto de cómo conseguir el éxito en un proyecto gestionando Alcance, Tiempo y Costo. Con "pragmática" me refiero a que siendo realista, en muchas situaciones será muy difícil cambiar el tipo de contrato, es decir, no convenceremos al cliente para establecer un contrato que se acerque hacia alguna variación de tipo "Tiempo y Materiales". ¿Puede entonces un contrato no ideal para el agilismo hacernos renunciar a la aplicación de prácticas ágiles? ¿se puede trabajar de forma ágil en un contexto de Alcance, Tiempo y Costo prefijados? Mi respuesta es sí, pero requiere una explicación.
Un contrato puede obligarnos a identificar los requisitos y estimarlos para establecer un compromiso coherente en cuanto a alcance-plazos-costo. Sin embargo, dicha identificación no tiene por qué implicar una definición detallada (y temprana) de todos los requisitos. Hay requisitos que sólo con un nombre pueden ser estimados, para otros quizás sea necesario hacer algún boceto o prototipo, y para algunos pocos quizás sería conveniente dedicar más esfuerzo para conseguir una definición y validación detallada. Además, normalmente dicha necesidad de especificación detallada está correlacionada directamente con el valor del requisito en el contexto global del producto, es decir, los requisitos de mayor valor son los que incuestionablemente estarán en el producto resultante, y además, deberían ser abordados cuanto antes (implementar lo más importante primero, así cuánto antes podremos confirmar que el producto está bien encaminado).
Con lo anterior estamos haciendo una discriminación entre los requisitos respecto de su nivel de especificación y validación. Obviamente, un factor importante asociado a la necesidad de especificar en detalle (para conseguir una estimación razonablemente certera) depende de la experiencia del equipo de desarrollo en el ámbito tecnológico y del dominio del problema. Pero de todas formas, siempre será posible en cierta medida conseguir la deseada estimación temprana, necesaria para el compromiso contractual, y al mismo tiempo no caer en una "fase de análisis" que nos obligue a hacer una inversión muy significativa al comienzo del proyecto (incluso antes de cerrar el contrato) y que luego, veamos con frustración que no se ha rentabilizado a lo largo del proyecto.
Lean Development menciona en uno de sus Mudas (fuentes de desperdicio) la sobreproducción o producción con demasiada anticipación. Especificar tempranamente y en detalle los requisitos puede derivar en este Muda cuando las especificaciones de requisitos quedan obsoletas antes de su implementación o incluso cuando, por cambios en la orientación del proyecto, ciertos requisitos ni siquiera llegan a implementarse. De esta forma, por ejemplo, si se añade un nuevo requisito podríamos intercambiarlo por requisitos previstos y no implementados (que supongan un esfuerzo de implementación equivalente), sin que esto tenga que suponer siempre un desperdicio de esfuerzo en especificación y validación de los requisitos descartados. Lectura recomendada: "Gestión ágil de requisitos o ¿cuál y cuánta documentación/especificación es suficiente?".
En un contexto ágil, la planificación (y re-planificación) y el seguimiento continuo son actividades muy presentes en el día a día del equipo. Esto se ve apoyado/alineado con el hábito de generar versiones frecuentes con nuevos requisitos implementados. El contrato asociado al proyecto puede tener una duración de, por ejemplo, 6 meses, pero la dinámica interna del proyecto puede estar basada en sprints de, por ejemplo, un mes cada uno. Aunque en el contrato se haya establecido un Alcance, Plazo y Costo fijo, soportados por estimaciones de esfuerzo, basta con disponer con un margen de flexibilidad y capacidad de respuesta ante cambios, especialmente respecto de requisitos que aún no han sido implementados (y en los cuales aún no se ha invertido ni siquiera en su especificación y validación detallada).
Alguien podría mirar estos planteamientos con escepticismo desde una perspectiva de Gestión del Alcance de un proyecto. El éxito de un proyecto se basa en que se satisfagan las expectativas del cliente, pero esto se puede conseguir incluso si dichas expectativas no son las mismas que en el comienzo del proyecto. La clave es que dichas expectativas estén siempre actualizadas. Lecturas recomendadas: "Gestión del alcance en un proyecto ágil" y "7 diferencia entre una planificación tradicional y una ágil". Así pues, aunque se introduzcan cambios en los requisitos, si dichos cambios no generan "desperdicios" significativos de esfuerzo (porque no se ha invertido tiempo su definición ni implementación) no deberían afectar negativamente al proyecto. Solo en el caso que los cambios conlleven desperdicio significativo de esfuerzo habría que evaluar con el cliente el alcance, costo y plazos para mantener actualizadas las expectativas.
Por otra parte, un requisito siempre ofrece un rango bastante amplio de alternativas en su implementación, todas ellas cumpliendo con su definición y aceptación del cliente. No me refiero solo a alternativas de tecnología, diseño y/o arquitectura interna del producto, sino a las alternativas negociables con el cliente, aquellas que se refieren al diseño de interfaz y experiencia de usuario, al nivel de automatización de ciertas funcionalidades, a la posible opcionalidad de ciertas operaciones complementarias a la funcionalidad esencial. Me gusta referirme a esto como "Sofisticación" (de la implementación de cada requisito) como otro aspecto que en un contexto ágil puede ayudar a resolver el desafío Alcance-Tiempo-Costo. Sí, esto podría verse como una rebaja en la calidad del producto, pero de aquella calidad "prescindible", la cual es necesario detectarla y negociarla abiertamente con el cliente. Debería ser un acuerdo Win-Win entre cliente y desarrolladores que establezca dicho nivel de sofisticación para cada requisito, sin renunciar a la esencia del requisito, y obviamente, dejando abierta la posibilidad para que en una futura entrega (por ejemplo en otro contrato) pueda elevarse el nivel de sofisticación de un requisito. De esta forma, tal como se ilustra en la siguiente figura, cada requisito incluido en el alcance puede además evaluarse en cuanto a su sofisticación, para así ayudar a lograr un equilibrio y consistencia con el tiempo y recursos del proyecto.
Finalmente, volviendo al título de este post, ¿es posible conseguir un "Bueno, bonito y barato" aplicando un enfoque ágil?. Según lo ya comentado mi respuesta es "sí, se puede", pero como habréis visto, requiere de un cambio de chip importante en el desarrollo del proyecto. No se trata de trabajar más por menos como sostienen algunos "genios" de la competividad, se trata de hacer lo que estratégicamente es más apreciado por el cliente (lo que más valor le aportará), de dosificar y negociar el nivel de sofisticación en la implementación de cada requisito, y de gestionar los cambios, manteniendo siempre actualizadas las expectativas del cliente.
