Hola a todos, aquí vuelvo a la carga con un nuevo post para desgracia de mis minoritarios lectores. El tema de los proyectos cerrados ya lo traté en otro post, explicando que en realidad el pensar que un proyecto está cerrado en alcance, tiempo y recursos es algo totalmente utópico. Sin embargo debido al ambiente de desconfianza que existe en nuestro sector entre clientes y proveedores, surgió esa mala bestia, el contrato cerrado, causante de tantos entuertos en nuestra profesión. Dado que ejercemos nuestra profesión en un ambiente hostil, nueve de cada diez veces vamos a encontrarnos en un proyecto con contrato cerrado. Los proyectos con contratos cerrados se han puesto siempre como ejemplo prototípico de un entorno donde Scrum y otras metodologías ágiles no podrían funcionar. Como este tipo de proyectos son los más comunes, muchos han usado esta aseveración para defender la postura de que trabajar en modo ágil es imposible en España (y alrededores). Yo no estoy para nada de acuerdo con esto, la verdad es que lo considero totalmente desacertado y un síntoma de lo mal que se está entendiendo el movimiento ágil. De hecho mi postura es radicalmente opuesta: los proyectos cerrados constituyen nuestro mejor aliado para implantar el modelo ágil en la empresa. O sea, no solo no pienso que el proyecto cerrado impida la gestión ágil, sino que es un aliado a la hora de hacer ver a nuestro entorno lo positivo que es Scrum. Todo pasa por una pequeña revelación: scrum es más eficiente que la cascada, sobre todo en proyectos cerrados. Aunque ya comenté algo al respecto en mi post anterior, quiero dar más detalle sobre mi postura a este respecto. Lo veremos a lo largo de este post, pero no os preocupéis, si se hace muy largo pienso dividirlo.
Como sabréis Scrum es un proceso iterativo, que al igual que cualquier otra metodología iterativa, divide la gestión y control del proyecto en pequeñas fases o iteraciones (sprints en scrum). Al final de cada pequeña fase se inspecciona el progreso del proyecto y se ajustan las planificaciones y la estrategia de desarrollo. El modelo clásico de cascada no es iterativo y se basa en una planificación y diseño detallado, tras la cual se realiza la construcción, y el producto no es inspeccionado y revisado por el cliente hasta el final. Obviamente el realizar la planificación y diseño detallado al principio es un error tremendo, ya que es cuando menos información tenemos, los requisitos están menos claros y la incertidumbre es mayor, con lo que seguro que nos vamos a equivocar en la planificación, y por mucho.
Es obvio, que una metodología iterativa es más eficiente que la cascada. En el caso de un contrato cerrado nadie nos libra de un análisis de requisitos con cierto detalle y una estimación afinada en la fase de preventa. Esto es intrínseco al modelo de contrato cerrado y concurso, necesitamos saber si podemos ir o no a presentarnos al proyecto y por cuánto dinero. Ya dije que esto es lo peor que podemos hacer, entonces, ¿de qué nos valen las iteraciones en un contrato cerrado? Simplemente para tener feedback frecuente. Esto redunda en un mayor control, por ejemplo:
- Si el proyecto va muy mal, se puede detectar pronto, y cancelarlo con el menor coste para ambas partes. Algunos clientes (no todos) os agradecerán esta sinceridad e interés por no hacerle perder más dinero y tiempo.
- Si el proyecto va muy mal, no se puede cancelar pero se puede retrasar, tal vez podáis negociar con el cliente un plazo extra de tiempo. Sí, sí, es contrato cerrado, pero el proyecto real no, en la práctica si el time-to-market no es muy crítico se puede negociar un retraso (aunque no te lo paguen).
- Si el proyecto va muy mal, pero ni se puede cancelar ni retrasar, tendréis que usar la técnica de «más madera». Si el cliente es bondadoso, podéis pactar un coste extra, aunque sea un contrato cerrado.
- Si el proyecto va mal, pero se puede salvar, tomar las medidas correctoras pertinentes.
- Si alguna circunstancia o requisito cambia os podéis enterar y aceptar el cambio de forma controlada. Sí, el contrato es cerrado, pero si el cliente decide cambiar un requisito o simplemente hubo un malentendido, lo correcto es aceptar el cambio de forma negociada. En caso contrario correis el riesgo de acabar el proyecto con éxito pero que no haga lo que quiere el cliente, y perder a éste de cara a futuros proyectos. Además, también las circunstancias y contexto del negocio cambia y no se pueden controlar, sería absurdo ponernos la venda en los ojos y pensar lo contrario.
O sea, que al planificar y cerrar la cosas al principio (contrato cerrado) estamos condenados a fallar. Pero usando una metodología iterativa podemos fallar por menos al controlar mejor el proyecto, e incluso aceptar cambios en el alcance si fuera necesario (aunque el contrato sea cerrado). También evita que andemos a ciegas hacia nuestra perdición. Estas ventajas están claras incluso en clientes muy tradicionales. La mayoría de ellos ya usan esquemas de trabajo iterativos, ya sea de forma explícita o implícita. En el último caso se suele tener un plan waterfall, pero muchas reuniones de seguimiento e hitos a intervalos regulares que implementan de facto un sistema iterativo. Otra variante se produce cuando el cliente divide un proyecto grande en múltiples fases, cada una de menos de tres meses, e intenta realizarlas de una a una en formato contrato cerrado. Desde el punto de vista del cliente esto es un ciclo de vida iterativo, desde el punto de vista del proveedor es simplemente una sucesión de concursos y contratos cerrados waterfall. Esta última forma de trabajar es bastante perversa, ya que no asegura al proveedor que realiza una fase del proyecto su participación en la siguiente, con lo que el incentivo por parte del proveedor para invertir en calidad disminuye, al no saber si se encargará de la evolución o mantenimiento prevista en la siguiente fase.
Como vemos el ciclo de vida iterativo es una mejora en proyectos cerrados, pero no es suficiente. Afortunadamente scrum no es sólo iterativo, sino incremental. En un proceso iterativo e incremental, al final de cada iteración no sólo se obtiene feedback de la marcha del proyecto, sino que se realiza una entrega parcial, que representa un incremento del grado de avance del proyecto. Existen varios procesos de desarrollo iterativos e incrementales, pero no todos ellos son ágiles. Los procesos iterativos e incrementales ágiles, como Scrum, entregan incrementos de funcionalidad, mientras que los demás entregan incrementos de construcción.
Un incremento de funcionalidad consiste en añadir nueva funcionalidad al sistema, que sea directamente útil al usuario, y que esté lista para entrar en producción, al final de cada iteración. Scrum sigue esta filosofía. El objetivo de cada sprint es entregar valor adicional al cliente, en forma de Product Backlog Items (PBIs) implementados y listos para entrar en producción. Por valor entendemos la utilidad, funcionalidad y/o rentabilidad de cada funcionalidad entregada. Los PBIs son unidades de funcionalidad, convenientemente analizadas y con una estimación de valor y coste. Pueden tener forma de historias de usuario o de casos de uso, según lo que se prefiera, pero eso no es lo importante. La estrategia de Scrum consiste no sólo en entregar valor al final de cada sprint, sino ir implementando los PBIs por prioridad, de forma que se entreguen primero los más importantes. La prioridad se calcula equilibrando el valor con el coste de cada PBI, de forma que dado el mismo coste se entreguen primero las de mayor valor.
La mayoría de las metodologías iterativas que se usan en el mundo empresarial no entregan incrementos de funcionalidad, sino incrementos de construcción. Un incremento de construcción consiste en entregar uno o más artefactos del proyecto al finalizar cada iteración. Ejemplo de tales artefactos son: documentos de diseño, esquema de BBDD, scripts de carga, capa de persistencia, pantallas. Estos artefactos, aunque necesarios para completar el proyecto, no aportan funcionalidad por si mismos. Estamos acostumbrados a que en cada hito, tengamos que entregar el documento de análisis, el de diseño, las tablas, etc. En el fondo esta forma de trabajar no es más que añadir un control iterativo a un ciclo de vida de cascada, de forma que cada iteración haga énfasis en una única fase de la cascada.
Otra diferencia importante entre los dos enfoques incrementales es en las reviews. En Scrum en cada sprint review se interactúa con el cliente, usuario y/o representante ya que vamos a enseñar funcionalidad. En esta reunión el cliente acepta o rechaza la nueva funcionalidad y nos proporciona un feedback de calidad sobre la funcionalidad del sistema. En el enfoque de entrega de incrementos de construcción no es posible interactuar con el usuario ni realizar aceptaciones de funcionalidad, ya que se entregan artefactos técnicos que son revisados por técnicos del cliente. En vez de aceptaciones de funcionalidad, se realizan aceptaciones de componentes tecnológicos. En este sentido no podemos tener feedback sobre la funcionalidad del sistema hasta bien tarde en el ciclo de vida de la aplicación (pruebas). Esto es totalmente ineficiente ya que el peor momento para detectar un error es al final, que es cuanto más caro es repararlo. También es bastante malo desde el punto de vista de la transparencia, ya que el usuario real no ve el sistema funcionando hasta el final. En realidad un enfoque iterativo incremental tradicional sigue siendo tan opaco para los usuarios como una cascada, ya que éste no puede interactuar con el sistema hasta el final. Esta forma de trabajar es un poco perversa, ya que al fin y al cabo, lo que el cliente conoce bien es la funcionalidad, y nos ha contratado porque sabemos de cosas técnicas. Lo lógico es que el cliente revise la funcionalidad, que es de lo que sabe y lo que le interesa, y que confíe en nuestro saber hacer. Tal vez esa confianza en nuestro saber hacer se ha visto envenenada por la moda de contratar «personal poco cualificado» y ofertar muy barato. Dicho todo esto, es obvio que Scrum proporciona una mayor transparencia y detecta los errores antes que una metodología iterativa incremental tradicional. Además proporciona resultados tangibles antes que un enfoque tradicional.
Como resumen, el hecho de aceptar un proyecto cerrado siempre conlleva un alto riesgo de no cumplir con las expectativas del cliente. Sin embargo scrum hace una mejor gestión que la cascada y otras metodologías no ágiles, al permitirnos:
- Mitigar el riesgo de la estimación errónea. Si nos pasamos en la estimación al menos habremos entregado resultados tangibles y no artefactos «tecnológicos».
- Mitigar el riesgo de un lanzamiento prematuro debido a presiones de mercado. Si nuestros competidores lanzan su producto antes que nosotros, podemos ir a producción antes de lo esperado, ya que al menos tenemos algo con lo que ir a producción, en vez de documentos «técnicos».
- Ayudarnos a estimar mejor, al refinar mediante mejora continua nuestros procesos y usar timeboxing para que el proceso sea más predecible.
- Ayudarnos a dar un precio más competitivo. De nuevo el timebox nos ayuda a enfocar nuestros esfuerzos y la mejora continua a aprender ser cada vez más productivos.
- Mostrar al cliente el estado real del proyecto y entregarle valor de forma continua de forma que éste pueda empezar a confiar en nosotros. Tal vez el siguiente proyecto no sea tan cerrado…
- Mitigar el riesgo/coste de cometer un error en el análisis funcional o aceptar un cambio. Detectar los errores cuanto antes es la forma más barata de solucionarlos, aceptar cambios de nuestros clientes es vital. Todo esto es posible ya que al final de cada sprint se puede mostrar funcionalidad, no tecnología, y por tanto recibir feedback del usuario.
En definitiva scrum falla mejor que otras metodologías a la hora de gestionar un proyecto cerrado. Los puntos claves que aporta scrum para conseguir todo esto son: transparencia con el cliente, mejora continua, iteraciones (sprints) y entrega incremental de funcionalidad real (valor).
Simplemente probad a gestionar vuestros proyectos cerrados con Scrum o similar, no es necesario que el cliente lo sepa de forma explícita. Seguro que la vais a pifiar (es un proyecto cerrado al fin y al cabo) pero lo haréis mejor que si hubierais usado la metodología «de toda la vida», y vuestro cliente se sentirá mejor tratado y más satisfecho (pero no del todo). Construyendo pequeños éxitos, y poco a poco, vuestro cliente ganará confianza y podréis ir planteando otro tipo de relación, basada en la colaboración. Con el tiempo llegará el día que le podáis contar que usáis una cosa llama «agilismo»…
Ahora ya lo sabéis, no tenéis excusa, el agilismo va a llegar… incluso a los proyectos cerrados.
P.S. Uff, se ha terminado mi timebox de 2000 palabras, suficiente por hoy. En el siguiente post más sobre este tema, esta vez con dibujitos…
[…] This post was mentioned on Twitter by Enrique Amodeo Rubio and Jose Ramon, Álvaro Garcia Loaisa. Álvaro Garcia Loaisa said: ¿Proyecto cerrado? Que sea con Scrum por favor: http://t.co/IGw5Ood […]
Lo siento pero no estoy deacuerdo. No sé los proyectos cerrados con los que has trabajado, pero los que yo conozco no sólo son cerrados en requisitos… si no que se acompañan de penalizaciones por retraso (pasta) por eso no se puede jugar con algo tan bonito como iterar y hacer ver al usuario que las cosas no son así, y que podemos negociar, y que el cliente es guay, y que viene con nosotros, etc. Eso es el mundo maravilla
Cuando un cliente saca un proyecto cerrado es para cargarte los retrasos, por eso no los acepta y los penaliza economicamente, y por eso tienes que cerrar cada fase con el, y cubrirte las espaldas
La realidad no es así, la realidad es que en un proyecto cerrado todo lo que pase despues del arranque es tu problema.
En un post anterior hablo sobre esto.
Lo que comentas es para discutir, y no te falta razón. Como digo en el post, los proyectos cerrados están condenados a fracasar, con lo que te vas a comer una penalización casi seguro. Sin entrar en polémica, suponiendo que lleves razón al 100%, ¿cómo te ayuda una metodología tradicional en el mundo que planteas? El hecho de que el peor momento para estimar y planificar es en la fase de la preventa es independiente de que metodología uses ¿Cómo te ayuda la cascada a estimar mejor? Desde este punto de vista, ¿no crees que es mejor revisar frecuentemente junto al cliente la marcha del proyecto para buscar soluciones? ¿No crees que el revisar muchas veces si tus estimaciones fueron buenas o no, te ayuda a mejorar tus estimaciones en el futuro?
Sí, de nuevo como decía en mi anterior post, las penalizaciones son muy frecuentes. Pero como insisto en este post, y en este comentario, con Scrum se falla mejor, es decir, habrás terminado más cantidad de proyecto, que si hubieras usado una cascada. El entregar frecuentemente funcionalidad y obtener feedback del cliente hace que seas más productivo. Obviamente te vas a comer una penalización, pero va a ser más pequeña que si lo hubiera hechos con la cascada. Yo puestos a pagar una penalización, prefiero que sea pequeña. Además te aseguro que el cliente se cabrea mucho menos si le vas enseñando progresos reales (aunque sean insuficientes) durante todo el proyecto.
Sí, te vas a comer la penalización, ¿pero no crees que con Scrum tu imagen ante el cliente se deteriora menos que con la cascada?
Resumiendo mi postura: Los proyectos cerrados generan que entregues mierda, pero no todas las mierdas son igual de grandes e igual de apestosas ¿Qué mierda es peor, Scrum o la cascada? Para mí, la cascada.
Por cierto, que conste que estoy totalmente de acuerdo contigo. Lo normal es que el cliente sea «hostil» e imponga penalizaciones. Pero eso es debido al clima de desconfianza que se ha generado en el sector, tenemos que ir regenerando la confianza poco a poco.
Magnifico Post!
Estoy totalmente de acuerdo contigo, en proyectos cerrados, casi se está abocado al fracaso, ya que la complicación del desarrollo de software con requisitos emergentes es imprevisible. Solo lo veo tangible en proyectos muy muy parecidos a los ya realizados o proyectos simples.
Saludos!
Jefry, el tema de las penalizaciones es muy relativo. Hay que tener en cuenta que sí un proyecto se retrasa el primero que pierde es el cliente, que no puede disponer de un sistema que necesita en el momento que lo necesita. Ese es el origen de las penalizaciones y Slas.
Sin embargo, también es cierto que muchas veces no se aplican. Todo depende de la relación cliente-proveedor y del tipo de proveedor y de la causa de los retrasos.
Muchas veces se tiene la mala costumbre de ocultar la realidad de los proyectos a los clientes, desenmascarando el retraso al final de la cascada, sembrando la desconfianza y echandonos mierda encima al entregar con pinzas o con un lacito algo que no hay por donde cogerlo.
No estoy totalmente seguro de qué metodología es mejor, pero sí con una puedo ir viendo cosas que necesito en base a mi prioridad de forma reiterada, yo preferiría esa opción porque incluso podría ir usando el sistema mientras se desarrolla.
Un saludo
Muy bueno, como voy con retraso ahora me leo el 2 🙂
aprendo aprendo aprendo
La frase clave para mi: «En definitiva scrum falla mejor que otras metodologías a la hora de gestionar un proyecto cerrado. »
Un gran post Enrique!
Buenas, mi experiencia vivida en lo que llevo de proyectos aplicando metodología Scrum, es que el cliente se va volviendo vago a la hora de definir las cosas, con eso de que somos «ágiles» se le ha quedado la idea de que cambiar continuamente las cosas, definirlas así por encima o que empecemos a lanzar código incluso en peticiones que no han terminado de definirse correctamente, porque lo importante es que al final del sprint vean cosas (aunque todo tu trabajo sea relativo a cosas internas que no tienen una representación visual como tal, pero tienes la presión de presentar algo que se vea y le dé la sensación al cliente de que ha avanzado respecto al anterior sprint, aunque eso implique muchas veces presentarle cartón piedra -con el tiempo perdido en hacerlo-).
El resultado es que al final también hay retrasos, sólo que quedan enmascarados por las iteraciones, y que en los últimos dos años he hecho y deshecho y vuelto a hacer más código que en toda mi vida laboral. Y parece que se da prioridad a entregar cosas en los sprints, en lugar de a entregar cosas bien hechas.
No sé si es que se está aplicando mal Scrum en los proyectos por los que he pasado, si es que es un efecto colateral que estas metodologías facilitan que se dé si no se tiene cuidado, o qué, pero personalmente, a nivel laboral, ha convertido mi trabajo en el puñetero infierno en la Tierra y ha aniquilado mi motivación para trabajar, y poco a poco va a haciendo lo mismo con la de mis compañeros.
Hacer y deshacer trabajo es muy desmotivante, al igual que trabajar con especificaciones vagamente definidas y sin saber lo que viene después porque no está definido, el no saber qué planteamiento aplicar que te pueda servir para lo que viene después… Creo que la frase «es que si hubiera sabido que luego venía eso, lo habría planteado de otra manera» es la que más veces he dicho y oído desde que aplicamos Scrum.
Al principio pensaba que simplemente era un problema del primer proyecto en el que estuve y en el que decidieron aplicar Scrum, pero después de haber pasado por tres proyectos diferentes con Scrum y en los tres haber vivido los mismos problemas (y las mismas consecuencias), empiezo a pensar que son consecuencias implícitas o explícitas de la metodología y no problemas concretos del proyecto.
Estoy deseando participar en un proyecto que la aplique y que realmente me aporte todo eso que sobre la teoría es tan interesante (de verdad, me encantaría poder trabajar en un proyecto así porque sobre el papel todo me parecen ventajas, pero luego puesta en marcha, me está resultando la experiencia contraria).
Scherzo.