archivo

Archivos diarios: julio 21, 2012

Para Dave Thomas la calidad y el desarrollo no son elementos que se deban separar: “La calidad es algo que tu haces todo el tiempo mientras está desarrollando”.

Cuando en nuestra cabeza solo existe el deseo o necesidad de seguir ejecutando trabajo ya sea por presiones de nuestros superiores y/o del cliente y/o porque lo queremos es quitarnos cuanto antes las tareas que tenemos asignadas difícilmente conseguiremos un producto final de calidad (en todos los sentidos, tanto en aspectos técnicos como en funcionales).

La verdad es que es complicado salir de la espiral de las presiones y de los plazos pero si no tenemos una plena conciencia de que tenemos que desarrollar, dentro de nuestras posibilidades y del proyecto, un software con la mayor calidad posible siempre encontraremos una excusa, a veces más fundada y otras casi sin argumento, para limitarnos a ejecutar tareas lo más rápido posible sin centrarnos en que lo importante no es la rapidez sino la efectividad y la misma se obtiene a través de la calidad.

El enfoque evolutivo del desarrollo de software desde una perspectiva ágil consiste en ir descubriendo el camino hacia el cumplimiento de las expectativas de usuario a través de la oscuridad de la incertidumbre que rodea a los proyectos, de la resistencia que encontremos y de los cambios de dirección y sentido que provocan los cambios de contexto.

La brújula es el feedback sobre iteraciones del producto teniendo como base nuestro background como desarrolladores de software y la intención con que se afronta cada evolución del sistema (una cosa es tener que descubrir el camino y otra no tener muy claro realmente a dónde se quiere ir) y nuestro motor el funcionamiento real como un equipo de trabajo.

Los enfoques clásicos, predictivos por naturaleza, entienden que desde el principio se sabe cómo llegar al producto que se desea y que en cualquier caso a lo largo del proceso de desarrollo se podrían realizar ligeros ajustes.

La realidad que nos encontramos en los proyectos de desarrollo de software nos indica que en la mayoría de los casos no se sabe qué es lo que se quiere realmente (o por lo menos con la suficiente precisión como para poder plantear un enfoque clásico) y que el camino para llegar a ese objetivo tiene muchas curvas, subidas y bajadas, asfalto de distinta naturaleza y diferentes condiciones climáticas.

Cuando en una organización, departamento o equipo de trabajo no existen objetivos, existiendo no se comunican o existiendo y comunicados son papel mojado porque nadie se encarga de medirlos, de hacer que se cumplan y se ignoran, llega el caos.

En esta situación de caos, cada uno hace la guerra por su cuenta y se deja a voluntad del individuo o de equipos concretos tomar decisiones que no solo puedan ser beneficiosas para un proyecto o tarea concreta sino también para otras personas, equipos y la organización. Es cierto que esa voluntad la tienen muchas personas pero también es cierto que otras muchas solo velarán por sus intereses y no solo relacionados con su rol en la organización, sino por sus propios intereses personales.

En el caos, el esfuerzo se fragmenta en diversas direcciones, en muchos casos opuestas y eso impide el progreso de la organización en su conjunto. Se pueden conseguir victorias individuales, tal vez ganar alguna batalla pero tarde o temprano la guerra se perderá ante rivales más organizados o que incluso teniendo tus mismos problemas sean más poderosos que tu.