AOS2012 Gestión del código heredado

Esta entrada está basada en la charla que sobre este tema tuvo lugar en el Agile Open Space 2012, en Zaragoza, y al que tuve el placer de asistir.

Si queréis leer sobre otras charlas del AOS 2012, he preparado un índice aquí.

Una de las primeras charlas a las que asistí era la de cómo enfrentarnos al código heredado. La verdad es que el propio ponente (Pablo Bouzada), ya se me ha adelantado (claro, para eso es su ponencia), y lo ha dejado todo escrito en su blog. La verdad que fue una gran exposición, y se nota que domina el tema.

De todas formas, me gustaría que:
1º- Leyérais tranquilamente el blog original y
2º - Me permitiérais añadir aquí unos comentarios.

La verdad es que aunque interesante, el fondo del artículo no es nada novedoso. Básicamente nos indica que  todo ha de ser gestionado, y que los riesgos han de gestionarse también. Y en este caso, se trata de gestionar la transición para tomar el control de un proyecto heredado.

Mucho más interesante que el artículo en sí, me interesa el detalle de que si bien hasta ahora éramos simplemente ágiles, y rechazábamos procesos de gestión, nos empezamos a dar cuenta de que realmente la gestión es necesaria. No podemos ser tan ágiles como para decir: "Ok, me acaban de meter en un proyecto con código heredado, y como soy ágil, me pongo a picar y ya está".

Es precisamente el hecho de considerar necesaria la gestión, lo que me sorprende. Por fin somos ágiles...¡y gestionamos! Pues enhorabuena.

Pero no se trata de gestionar al tuntun, ni de meter el mega-proceso de gestión PMBOK que nos permita abordar con el 100% de garantías el proyecto. Se trata simplemente de abordarlo de forma lógica y ordenada, y con el mayor grado de agilidad posible. Aquí es donde Pablo Bouzada tras revisar otros métodos, acaba proponiendo uno más simple:

1. Qué: Identificar qué tengo (a qué me enfrento)
2. Cuánto: identificar el alcance.
3. Cómo: preparar una estrategia para abordarlo, en especial creando una red de seguridad (test funcionales, UAT, unitarios,etc) que me permitan realizar cambios con cierta seguridad. Establecer un límite en dichos test (no se puede cubrir todo), relacionado con el alcance anterior.
4. Cuándo: establecer una priodidad de las tareas, que me permita planificarme.
5. Trabajar, ya por fin, con una cierta seguridad.

Otro punto interesante que surgió en la charla, estaba relacionado con algunos puntos que se producen en el mundo real:

• ANS: ¿Has heredado un proyecto con Acuerdos de Nivel de Servicio? Pues lo tienes muy mal. Primero tienes que atender al contrato con el cliente, y luego, solo luego, podrás atender el proceso descrito. Por supuesto, lo ideal es poder tratar abiertamente esto con el cliente, y convencerle de que nuestra vida se puede volver un infierno si no nos da un período para poder aplicar nuestros 5 puntos anteriores. Sin embargo, el cliente ya tiene un contrato, y nada le obliga a hacer nuestra vida más fácil.
• Compromisos: ¿Y si hay una fecha de entrega asociada al proyecto heredado? Aquí se supone que hemos heredado un proyecto sin entregar. La parte buena, es que al no estar en producción, no tenemos el call-center echando humo con clientes quejándose de incidencias. La parte mala, es que seguramente habrá una fecha en que ese proyecto heredado se deberá entregar. De nuevo, para acometer convenientemente los 5 puntos anteriores, es vital contar con la comprensión y el compromiso del cliente.

Voy a hacer un inciso. Y es que efectivamente, como se comentó en la charla AOS2012 sobre este tema, "el primer interesado en que el proyecto salga bien, es el cliente". Ok. De acuerdo, pero debo apuntar: "el cliente, lo primero en que está interesado es en NO PERDER DINERO". En algún caso, el cliente preferirá denunciarme y no pagarme (al menos no pierde dinero), que concederme de forma gratuita, el tiempo necesario para que usando los 5 pasos anteriores, pueda tomar las riendas del proyecto en condiciones.

¿Cómo? ¿Que el cliente prefiere no tener su producto? Pues no sería la primera vez que se da el caso. Por desgracia, en las metodologías ágiles, damos por sentadas dos premisas que al parecer nadie se detiene a comprobar:

1. El cliente se involucra en el proyecto, y está dispuesto a dedicar el tiempo necesario para lograr el éxito del proyecto.
2. El cliente desea el producto final, y está dispuesto a ese fin, sin escatimar en gastos.

Pues es posible, en algún caso, que no ocurra así. El éxito a cualquier coste, y menos en los tiempos que corren, no se lo pueden permitir todos los clientes. Y hemos de tener en cuenta, que en las empresas, quienes nos contratan han de reportar "hacia arriba" con el avance del proyecto y su coste.

Y no quiero decir, por supuesto, que en el mundo real las metodologías ágiles no sirvan (como parecen afirmar muchos). Lo que simplemente quiero decir, es que NO PODEMOS DAR TODO POR SUPUESTO. Todo tiene un límite, incluso la paciencia y el dinero de nuestro cliente.

Y vuelvo al tema tras el inciso. Los 5 puntos anteriores, el proceso mencionado, hay que aplicarlo. Pero hay que hacerlo dentro de los límites y plazos que tengamos, y haciendo partícipe al cliente. El cliente, debe tener visibilidad de porqué estamos refactorizando, metiendo test unitarios, etc. etc.

Y aquí me permito añadir un problema adicional (es lo que tiene el mundo real, que no es simple y maravilloso, sino retorcidamente complejo):

• ¿Qué ocurre si heredamos el código...no de otra empresa sino de otro empleado? ¿Somos lo bastante honestos para decirle al cliente que necesitamos dedicar tiempo a "protegernos" de la chapuza que le habíamos hecho hasta ahora? Muchos pensarán: "claro que sí, el cliente lo va a entender". Es posible. Otros dirán "No, mejor lo hacemos sin que se entere el cliente, porque seguramente el cliente prefiera no seguir gastando dinero en alguien que ya le ha traicionado en su confianza".

En fin. Disfrutad de este gran artículo original de Pablo Bouzada, y sobre todo...suerte con los proyectos heredados.