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.

Sunday, 29 October 2017

Error nº 8: El Scrum Master reparte las tareas

Se trata de que los equipos de trabajo sean auto-organizados y se repartan ellos mismos las tareas. Ellos son quienes mejor saben cómo hacer el trabajo y cómo mejor repartírselo entre ellos. Si dejamos que el Scrum Master o el jefe de proyecto reparta el trabajo probablemente no quede balanceado entre todos los miembros del equipo quedando más peso en unos que en otros o se hayan asignado tareas a alguien que no tiene ahora las habilidades técnicas para resolverlo igual que algún otro.

Si dejamos que ellos mismos, los miembros del Equipo de Trabajo, se repartan las tareas a realizar, el trabajo quedará más repartido y ellos tendrán un sentimiento de reparto más justo. Se trata de que levanten la mano y digan ‘Esa tarea la hago yo’ o ‘Creo que quién mejor puede hacerla es Carolina’ a lo que Carolina puede responder ‘Quizás sí, pero ya tengo asignadas las tareas 14 y 16 ¿Qué tal si la hace Fernando? Ya lo hizo una vez y puede ir ganando más experiencia con eso’.

Sunday, 8 October 2017

Error nº 7: Reuniones diarias de Scrum demasiado largas

Esto suele suceder cuando las reuniones de la Daily Scrum se utilizan para resolver los problemas y las dudas que se están teniendo en el trabajo diario. Esta es una reunión que debe mantenerse muy corta y en la que sólo deberemos comentar lo que hicimos ayer, lo que se hará hoy y qué problemas nos estamos encontrando o vamos a necesitar solución.

Es en este último punto cuando todo el mundo tiene una posible solución y la comenta en la reunión por lo que ésta se alarga y alarga con los comentarios sobre un problema que quizás sólo atañe a una o dos personas y a que a las otras no afecta directamente por lo que se aburren y pierden un tiempo en el que podrían estar ya desarrollando.

Aquí el Scrum Master debería mantener bajo control estas reuniones para que no se vayan de tiempo y hagan perder el tiempo a todo el mundo. Siempre que una discusión sobre un problema comience, deberá emplazar esta discusión para otro momento en el que sólo intervengan las personas involucradas y quizás algún tercero que no está en la reunión diaria pero cuya opinión pueda ser importante.

Es esencial también que no olvidemos tener esa otra reunión para resolver el problema ¿Para qué si no se avisó de que había un problema? Si no puede resolverse durante la reunión diaria debe atenderse en algún otro momento del día o días posteriores para ponerle solución.

Sunday, 1 October 2017

Error nº 6: Diseñar todo el proyecto desde el inicio

En Scrum es mejor no diseñar todo el proyecto antes de comenzarlo. Analizarlo todo, diseñarlo todo, construir un gran documento de requisitos de proyecto muy detallado es volver a trabajar como en los clásicos proyectos en cascada. Todas las especificaciones han sido declaradas desde el inicio y no hay posibilidad de cambio.

A estos diseños se les llama big up-front design y no permiten adaptarse a los cambios que pueden verse necesarios a medida que se va construyendo porque todo está ya especificado en un gran diseño antes de comenzar a construir una sola línea de código.

Si tienes una lista de producto pequeña al inicio, que puede ir creciendo a medida que se va avanzando en el proyecto y que se va adaptando a las opiniones y necesidades del Interesado, podrás construir un mejor producto que si haces todo o buena parte del diseño por adelantado. Mientras se va construyendo el proyecto, incluso puede que ya lo estén usando. Alguno de los Interesados puede opinar que es mejor crear una exportación a MS Excel de los informes, y esto es algo en lo que nadie había pensado por lo que no se incluyó en el diseño hecho por adelantado al inicio del proyecto.

Puede también que ya no estén tan interesados en la integración con el sistema de contabilidad Contaplus. Es un desarrollo muy complejo para las ventajas que se obtendrían y corre el rumor por la empresa que el sistema de contabilidad será migrado a SAP antes o después, así que para qué desarrollarlo ¿Qué hacemos ahora con todas las horas que usamos para diseñar esa integración con Contaplus? Puede incluso que ya estén preparadas las clases y los esquemas de base de datos con los campos necesarios para esa integración y ahora ya no van a ser usados.

Sunday, 24 September 2017

No tener reuniones de demo o retrospectiva: Otro error habitual en Scrum

Si no demostramos al cliente lo que hemos hecho en el último Sprint ¿Cómo podemos saber si vamos bien o vamos mal? Podemos seguir avanzando sin que nadie vea nuestro trabajo, tomando suposiciones y huyendo hacia adelante pero cuando llegue el momento de la entrega final en el que el cliente vea todo el proyecto podemos estar en un apuro.

Es mejor que cada poco lo vaya viendo, que dé su opinión, que corrija errores o malentendidos y sobre todo que nos diga qué hicimos bien y podemos dejar cerrado ya para seguir avanzando. Es necesario estar seguros de que el cliente ha aceptado lo que ha visto y que avanzamos sobre estructuras sólidas sobre las que seguir construyendo nuevas funcionalidades.

La demo tiene también el efecto de probar todo en su conjunto para ver que funciona bien. Alguien podría estar trabajando en el backend, otro en el frontend, otro estaría construyendo un servicio web y un cuarto está trabajando en una migración de datos. En la demo vamos a poner cada dos semanas todo esto a trabajar junto. Van a salir las dependencias, los errores por asumir que ciertas interfaces eran de una manera y no de otra y los problemas que se pueden tener al desplegar (redes, certificados de seguridad, diferencias entre los entornos de desarrollo y de demo o pre, etc.).

También es importante que te reúnas con el Equipo de Trabajo después de la reunión de demo para tener una reunión de retrospectiva. Que te cuenten si están bien, si están teniendo problemas o si creen que algo es manifiestamente mejorable. Justo después de la reunión de demo es el momento para confrontarse con la realidad. Se acaba de ver lo que salió bien y lo que salió mal, lo que quedó fuera porque no hubo tiempo y lo que el cliente rechazó porque no se le había entendido bien. Justo ahí todo el mundo tendrá una opinión de lo que es mejorable. Toma buena nota sobre algunos cambios que podrían hacerse, seguramente saldrán buenas ideas de ahí.