¿Proyecto cerrado? Que sea con Scrum por favor (2)

Como el post anterior sobre contratos cerrados me quedó un poco abstracto, en este voy a poner un ejemplo, con el que espero ser capaz de clarificar mi idea. Suponed que existen dos versiones de vosotros en dos mundos paralelos. En un mundo, el mundo verde, usáis scrum, y tratais de entregar funcionalidad real al final de cada sprint. En el otro mundo, el mundo rojo, usáis una metodología iterativa tradicional, donde al final de cada iteración entregais artefactos correspondientes a entregables de la cascada (diseño, análisis, capa de persistencia, etc). En ambos mundos el cliente os contrata para hacer el mismo proyecto, bajo contrato cerrado y con las mismas condiciones.

La siguiente figura ilustra lo que ocurre si aprovechando vuestras capacidades CMMI5, conseguís hacer una planificación perfecta durante la preventa y terminais el proyecto en tiempo, dinero y alcance según lo planificado en el contrato cerrado. Podéis observar que aunque en ambos proyectos se ha tenido un éxito rotundo, en el mundo verde se ha ido entregando funcionalidad desde antes. Pero, como el proyecto ha sido exitoso eso sólo son detalles que le importan a los frikies.

Proyecto exitoso (un mundo perfecto)

En el gráfico anterior, se ha medido la entrega de funcionalidad con respecto al paso del tiempo. Sin embargo no todas las funcionalidades son igual de importantes para el cliente. A la importancia de una funcionalidad en concreto lo llamamos valor. En scrum la funcionalidad se entrega por orden de ROI. El ROI es el balance entre el valor de una funcionalidad y su coste estimado. Cuanto más valor más ROI; cuanto menos coste más ROI. Sin embargo, en la práctica, las diferentes funcionalidades se van analizando, refinando y subdividiendo, hasta que éstas tienen un tamaño tal que nos permite, de forma razonable, implementarlas en un único sprint. Debido a esto las funcionalidades que se entregan al final de cada sprint tienen un tamaño similar. En este sentido, y de forma grosera, podemos tratar el factor coste dentro del ROI como una constante. Por lo tanto, de forma aproximada, Scrum entrega las funcionalidades con mayor valor primero, maximizando así el flujo de entrega de valor. Sin embargo en el mundo rojo la funcionalidad se entrega en cuanto se puede. El orden de entrega lo define, no el valor, sino el orden en el que se planificó (cascada) la entrega de todos los artefactos que componen una funcionalidad dada. En este sentido el mundo rojo entrega funcionalidad sin atender al valor, con lo cual el valor de cada entrega será «aleatorio». Si en vez de medir funcionalidad entregada, medimos valor o utilidad entregada, el gráfico anterior se transforma en el siguiente:

Valor entregado en un proyecto exitoso (un mundo perfecto)

De nuevo ambos proyectos tienen éxito, pero en el segundo gráfico se detecta una diferencia aun mayor de entrega de valor entre los dos mundos. De nuevo esto es una curiosidad frikie.

Sin embargo podría haber ocurrido otra cosa. Ciertamente usando CMMI5 y nuestros mejores algoritmos de planificación y estimación, nuestro plan para el contrato cerrado es impecable y perfecto. Sin embargo el mundo es muy cruel, y el rival de nuestro cliente se adelanta y saca antes que nosotros un producto que es directa competencia del nuestro. El cliente desesperado decide salir a producción cuanto antes, con lo que haya, para minimizar perdidas debido a un «time to market» tardío. Lo siento chic@s, el negocio manda. Supongamos que esto ocurre en la iteración 7, veamos el gráfico.

La competencia se nos adelantó (esto es más realista)

¡ Oh, qué pena ! Si la competencia hubiera tardado una iteración más, el mundo rojo hubiera podido entregar un 65% de valor. Desgraciadamente los muy desalmados decidieron sacar el producto a mitad de la iteración 7 y pilló al equipo del mundo rojo integrando la capa de persistencia con el gestor transaccional y haciendo el «documento de diseño de algoritmos concurrentes» de entrega obligatoria en esa fase de la cascada. Sólo pudieron entregar un 10%. En el mundo verde también hemos fracasado, pero al menos conseguimos entregar un 70% de funcionalidad. Desgraciadamente el «documento de diseño de algoritmos concurrentes» está en blanco y no tiene ni índice, que pena más grande, el señor auditor de calidad y responsable de metodología nos va a reñir.

Olvidémonos ahora de la competencia, supongamos que todo lo anterior fue una pesadilla y que realmente tenemos todo el tiempo acordado para entrar en producción, al fin y al cabo, es un contrato cerrado, ¿no? Lo que nos ocurre ahora es que le mentimos al cliente, para ganar el proyecto tiramos los precios y nuestros recursos no son tanto como los que dijimos. O tal vez no, tal vez simplemente no comprendimos tan bien los requisitos como pensamos y estimamos mal. O quizás el tiempo y el precio nos venían impuestos y pensamos que eran asumibles, pero no lo pensamos mucho. Estos escenarios, donde la planificación y estimación inicial no se corresponden con la realidad es el caso más común. Desafortunadamente el contrato cerrado nos impide renegociar tiempo y dinero y por eso constituyen un riesgo tanto para el cliente como para nosotros.

El siguiente gráfico ilustra una situación parecida:

Nos hemos colado en la planificación (como siempre)

De nuevo scrum se centra en maximizar el flujo de valor entregado, con lo que conseguimos en este ejemplo un 60% de valor. El mundo rojo no se centra en el valor sino en artefactos con lo que el valor entregado es sólo el 35%. La hemos pifiado en los dos mundos, pero de nuevo insisto, scrum falla mejor.

A qué mundo preferís pertenecer, ¿al verde o al rojo? Espero haber dejado clara mi postura. Por supuesto los gráficos son ficticios.

Pero no cantéis victoria. Scrum sólo os dice que tenéis que entregar valor y funcionalidad al final de cada sprint, pero no cómo. El cómo conseguir esto es algo muy duro y complicado, y Scrum no te ayuda en nada en este aspecto. Necesitareis un equipo con talento y que sepa construir software de manera ágil. Esto parece material para otro post.

Read Full Post »

¿Proyecto cerrado? Que sea con Scrum por favor (1)

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…

Read Full Post »