archivo

Archivos diarios: mayo 10, 2011

La Ley de Eagleson viene a decir que (traducción libre): “Cualquier código que hayas desarrollado y que no lo hayas revisado desde hace seis meses o más parecerá que lo hubiera escrito otro”.

Esta situación es muy común y he escuchado distintas versiones de lo mismo a muchos programadores. El motivo generalmente es que conforme se va adquiriendo experiencia y nuevos conocimientos se va mejorando (y cambiando) el estilo de programación.

A esto hay que añadir la aparición de nuevos frameworks, librerías, versiones de las mismas, etc…, la necesidad de adaptarte a los requirimientos técnicos de los distintos proveedores, así como el hecho de trabajar con distintas tecnologías y/o lenguajes de programación.

Tras la revisión del primer y segundo principio o valor del manifiesto ágil, le toca el turno en este artículo al siguiente:

Principio 3: Valorar la colaboración con el cliente, por encima de la negociación contractual.

Quien me conoce sabe que para mi este principio es primordial. Los dos primeros hablan sobre la importancia de las personas que participan en el proyecto y su interacción/comunicación y sobre la importancia de que el software funcione por encima de otros factores, en este caso se trata de dos valores que considero esenciales que no son otros que la colaboración y la confianza.

A lo largo del tiempo que llevo escribiendo en el blog habréis podido comprobar una cierta evolución en mi manera de ver ciertos aspectos del desarrollo de software, pero si hay algo que no ha cambiado ha sido precisamente esto, es decir, la necesidad de que exista colaboración y confianza para que un proyecto de desarrollo de software salga hacia adelante.

Es necesario romper la barrera que separa a clientes y proveedores. Cuando se trabaja en un proyecto es necesario considerar a todas las partes que intervienen como un equipo, en el que todos deben sumar. Si se consigue eso se logrará uno de los objetivos más importantes del trabajo en equipo que no es otro que el hecho de que la suma del bloque sea superior que la suma de las distintas partes individuales.

Por tanto, el equipo de proyecto debe ser uno, en el cual cada uno tiene su rol y tiene que ser respetado. Es lógico que el proveedor defienda determinados intereses (como por ejemplo que el proyecto le sea rentable y/o le sirva de lanzadera para conseguir más negocio) y el cliente los suyos (ha realizado una inversión y quiere obtener resultados), pero siempre dentro del marco de la confianza.

Si se destruye la confianza, se rompe buena parte del espíritu de colaboración y se rompe la unicidad del equipo, cada parte se hará más radical en la defensa de sus intereses y las palabras y la propia negociación del día a día del proyecto serán sustituidas por el contrato que existe entre las partes.

Esto supone un problema para el proyecto, ya que los contratos son objetos predictivos y el desarrollo de software es adaptativo. Cuando se negocia sobre el contrato el proyecto siempre pierde. Pero no es el único, el proveedor también lo hará, ya que difícilmente un contrato será tan cerrado para que no de lugar a interpretaciones y cuando se trata de eso, tiene todas las cartas a su favor el cliente ya que al fin y al cabo es el que tiene la llave de paso del pago de los trabajos.

El cliente también sufre. Si el proyecto pierde en el sentido de que haya funcionalidades que no se implementen y/o de que la calidad se resienta, también pierde el cliente, a lo que hay que sumar el desgaste que individualmente tienen las distintas partes que participan en proyectos de estas características y también en el desgaste de las relaciones centre las partes que pueden dar lugar a que unos u otros terminen buscando otras alternativas.

Continuemos con el análisis de los principios del manifiesto ágil.