Sunday, 19 November 2017

Cómo ser ágiles en proyectos a precio cerrado

La mayor parte de mi vida profesional, como muchos otros, la he vivido trabajando en proyectos a precio cerrado (fixed price) en concreto trabajando para administraciones públicas en las que el alcance del proyecto venía prefijado de antemano en pliegos de condiciones administrativas y claúsulas técnicas.

En este tipo de proyectos tienes que presentar una propuesta económica, de recursos y de tiempo a la administración pública que valorará cuál es la mejor de las ofertas presentadas, normalmente la de presupuesto económico más bajo, decidiendo luego qué proveedor será el adjudicatario. Por tanto, desde antes de iniciar el proyecto, tendrás que estudiar las condiciones y el alcance fijados en los pliegos y hacer una arriesgada estimación de cada una de las tareas o módulos que se requiere desarrollar y lanzar tu oferta.

¿Se puede ser ágil en proyectos en los que el costo, el alcance y a veces la fecha de entrega están cerrados desde el inicio? Yo pienso que sí, veamos cómo.

¿Qué hacer con el coste?

Este es el lado más arriesgado de este triángulo de hierro. Hemos hecho una estimación basada en lo que ponía en los pliegos de contratación pero estos contienen en la mayor parte de las ocasiones una descripción genérica de las tareas a realizar que luego se concretará a medida que se avanza en el proyecto o se analiza con las partes interesadas. Más que una oferta hemos hecho una apuesta que no sabemos si nos saldrá bien.

Tendremos que confiar en haber hecho una buena estimación. Por naturaleza todos tendemos a ser demasiado optimistas teniendo en cuenta sólo los escenarios en los que todo marcha bien. Sólo cuando usamos estimaciones tipo PERT en la que se nos obliga a ponernos también en el peor caso nos paramos a pensar en esos grandes imprevistos que siempre pueden pasar (como se dice en inglés, shit happens). A partir de aquí nos basaremos en las mejoras de eficacia que proporciona la agilidad.

En Scrum y otros frameworks iremos entregando cada poco tiempo una parte del alcance prometido lo que permitirá ir enseñando nuestros trabajo, haciendo correcciones y aprendiendo de lo que ya hemos hecho. En los proyectos en cascada también hay fases: Análisis, Diseño, Construcción y Testeo pero al final de las primeras sólo entregamos unos documentos sobre lo que se va a construir. Sería como analizar, diseñar un nuevo prototipo de móvil y esperar a construir 10.000 unidades para luego comenzar a venderlo y ver si le gusta a los usuarios que lo han comprado o no.

Incluir los tests y planes de aseguramiento de la calidad en cada sprint nos permitirá construir bien desde el inicio y con menos costes. Es mucho más fácil corregir los problemas de cobertura de un móvil cuando se está desarrollando y diseñando la antena en los primeros modelos que cuando ésta ya ha llegado a la línea de ensamblaje para la producción en masa.

¿Qué hacer con el alcance?

A medida que avanza el proyecto es habitual que el cliente se dé cuenta de que necesita cosas que no están incluidas en el contrato inicial. Elaboró los pliegos con el conocimiento que tenía en ese momento pero según se adquiere más experiencia en el proyecto y se va usando la aplicación (recordemos que la vamos entregando poco a poco para que la comiencen a utilizar) se va dando cuenta de que hay partes sin las que el software sería mucho menos provechoso.

En los proyectos ágiles en los que he trabajado admito modificaciones negociadas al alcance. Si se quieren incluir cinco informes nuevos a la aplicación que la harían mucho más útil deberemos acordar qué otras tareas de igual o similar estimación quitamos del alcance del proyecto. Normalmente está tan interesado en incluir las nuevas funcionalidades que no le importa sacar del proyecto otras tareas que ahora no ve tan importantes o que incluso considera que no deben hacerse.

Para la negociación habré presentado al cliente desde el arranque del proyecto una estimación de cada una de las funcionalidades a entregar de forma que sabe cuánto valen para él cada uno de estos puntos si decide quitarlos del alcance. Esta estimación fue realizada al inicio del proyecto y puede que ahora sepamos que hay cosas que son mucho más costosas de realizar de lo que estimamos al inicio, sin embargo, no cambio esta estimación inicial para que el cliente no se sienta engañado. Normalmente las estimaciones que ahora son más costosas son compensadas con otras que ahora sabemos que no lo son tanto y que también quiere que quitemos del proyecto. En cualquier caso, si hemos conseguido que el cliente esté satisfecho con el trabajo que le hemos ido entregando poco a poco y además está contento por las nuevas funcionalidades que va a conseguir, la negociación no debería ser muy dura.

¿Que hacer con el tiempo?

A veces, además de tener un importe económico y un alcance fijos tenemos que cumplir también con unas fechas de entregas inalterables que nos obligarían a aumentar las horas extras, los tiempos dedicados durante el fin de semana y el número de desarrolladores implicados en el proyecto aumentando considerablemente nuestro coste del proyecto.

Si hemos sido ágiles en el proyecto y hemos ido poniendo en producción cada poco tiempo lo que hemos ido desarrollando, el cliente podrá tener ya en uso el día de la fecha de entrega un porcentaje alto de lo que se necesita entregar. Si además hemos priorizado correctamente, desarrollando en primer lugar aquellas funcionalidades que más valor aportan, sólo quedarán fuera aquellas de menor importancia por lo que normalmente pueden entregarse en una segunda fase sin que se altere demasiado el valor del sistema.

Si hubiésemos realizado un desarrollo en cascada y estuviésemos retrasados, en la fecha de entrega no tendríamos nada que subir a producción a pesar de que podríamos tener un 80% del trabajo realizado. Durante las últimas semanas del proyecto tendríamos que abusar de las horas extras y del estrés para entregar ese 20% que nos falta pero probablemente sólo consigamos que sufra la calidad del software que entregamos y que se se ignore la fase de tests del desarrollo apareciendo un montón de bugs después de la entrega.

Sunday, 12 November 2017

Cómo ser ágiles en proyectos de mantenimiento

Son habituales en la industria ciertos proyectos, denominados de mantenimiento, en los que el trabajo consiste no en desarrollar nuevas funcionalidades al producto sino en realizar correcciones a bugs o las tareas mínimas para lograr que el sistema esté activo y dando servicio las 24 horas.

Pero a veces la carga de trabajo es tan alta, o la organización del equipo no es todo lo eficiente que debería ser, que no hay tiempo para corregir estos problemas de raíz y en lugar de corregir el código que produce los bugs ponemos parches que dan una patada hacia adelante a los problemas. Tampoco tenemos tiempo para refactorizar el código y aumentarle su calidad de forma que el número de errores tan alto que se come todo el tiempo de desarrollo. El problema llega a ser tan preocupante que, incluso cuando nuestro contrato incluye tareas de mantenimiento evolutivo, la corrección de bugs nos consume todo el tiempo disponible evitando que añadamos más valor a nuestro producto.

Si intentamos usar Scrum para poner orden en esto probablemente no nos vaya a funcionar porque semana tras semana nuevas tareas de corrección de bugs nos asaltan de forma urgente en nuestra planificación del sprint impidiendo que lleguemos nunca a cumplirlo. Retomar el trabajo días después hace que tardemos aún más debido a los cambios de contexto y porque nos vemos asaltados de nuevo por más bugs urgentes. Las planificaciones de los sprints no serán nada fiables, el análisis hecho para las nuevas funcionalidades caducará o habrá que revisarlo y ningún sprint se cumple.

Yo utilizaría Kanban en lugar de Scrum en una primera fase de estos proyectos. El uso de Kanban conlleva un menor cambio cultural en el equipo de trabajo y en los clientes y una menor sobrecarga de reuniones pero sobre todo permite una mayor agilidad para dar entrada a tareas urgentes en medio de la carga de trabajo de la semana.

En este Kanban utilizaría tres códigos de tarjetas de colores: Rojo para las tareas de corrección de bugs, amarillo para las tareas que corrigen deficiencias técnicas y code smells en nuestro código y que están haciendo que el código sea difícilmente mantenible o están produciendo bugs de forma continuada. Por último utilizaría el color verde para las tarjetas que implican el desarrollo de nuevas funcionalidades.

Tampoco separaría el equipo en dos partes, uno para corregir bugs y otro para desarrollar nuevas funcionalidades. Hacer eso está reconocido como una mala práctica debido a que los equipos dedicados a los nuevos desarrollos no aprenden lo que pasa cuando se introducen errores y por otro lado se castiga a los equipos de mantenimiento a que sólo arreglan desaguisados y con prisas y tampoco crean nada nuevo que aporte valor y reconocimiento al equipo.

En un principio nuestro Kanban estará lleno de tarjetas de color rojo pero si logramos introducir nuevas tarjetas de color amarillo y subirles la prioridad a aquellas que solucionan un número alto de bugs, en un periodo prudente de tiempo deberíamos conseguir bajar el número de bugs que se están produciendo obteniendo tiempo así para añadir al Kanban más tarjetas amarillas o incluso verdes.

Con el paso del tiempo, nuestro tablero Kanban deberá mostrar un reportorio más amplio de colores en el que finalmente, con suerte, predominará el color verde. Para esto sirven los tableros visuales Kanban, para dar visibilidad a lo que está sucediendo en nuestros proyectos.

Es en este momento, en el que el equipo realiza sobre todo tareas de mantenimiento evolutivo, cuando podríamos volver a pensar en utilizar Scrum para nuestro proyecto bajando un poco el factor de dedicación para solventar aquellas tareas urgentes que nos llegan ahora con menor asiduidad.



Sunday, 5 November 2017

Error nº 9: Apretar demasiado en el objetivo del sprint

Es el equipo el que decide qué funcionalidades caben en un Sprint y cuáles no. Los miembros del Equipo de Desarrollo son los que mejor saben cómo se hace el trabajo y los que por tanto mejor pueden calcular si en el sprint caben seis u ocho historias de usuario o lo hacen a 10.

Si viene presión de fuera para que metan más cosas en el Sprint y que se comprometan a entregar más trabajo cuando realmente no lo ven factible, esto sólo puede hacer que se acumule el resentimiento o la desconfianza o que se fomente la baja calidad del trabajo para poder entregar a tiempo. Se sabe que cuanto más ridículos son los plazos de entrega más tiempo y dinero se malgastan en intentar conseguirlos.

Cuando se planea la cantidad de trabajo que podemos hacer, se planea un tiempo para las pruebas que necesitamos hacer y asegurarnos de que el trabajo es fiable. Se planifica también una cantidad de tiempo razonable para pensar y estructurar el desarrollo. Si falta tiempo para hacer estas cosas, la calidad del trabajo se resentirá y, más adelante, en próximos sprints o después de finalizado el proyecto, pagaremos esta deuda que hemos dejado atrás con intereses de demora convertidos en bugs que nos asaltarán en los momentos más inoportunos y que reducirán el nivel de satisfacción de nuestros usuarios.

Otra cosa es que el Equipo de Trabajo se sienta retado a conseguir más cosas dentro del Sprint y que se sientan con ánimo de conseguir mucho en poco tiempo. Si conseguimos un ambiente así, en el que los desarrolladores se comprometen por sí sólos al máximo alcanzable por ellos, habremos conseguido un gran objetivo y tendremos un gran equipo.