archivo

Archivo de la etiqueta: agilismo

Tom DeMarco realizó la siguiente reflexión en su libro “The Deadline: A Novel About Project Management” (1997): “El problema de los procesos estándar es que la gente pierde la oportunidad de tomar importantes atajos”.

Cuando los procesos son tan rígidos y parece que lo único importante es cumplir con ellos se pierde la visión de que no se trabaja para el proceso sino para realizar un software de calidad.

Esta visión negativa del autor de lo que supone una gestión balanceada hacia el proceso donde las personas pasan a ser algo con menos importancia ha sido una constante en DeMarco desde que en el año 1987 publicase junto a Timothy Lister el libro “Peopleware: Productive Projects and Teams” que extendió precisamente el concepto de Peopleware en el que sitúa a las personas como elemento principal en el desarrollo de software (el concepto fue utilizado inicialmente por otros autores, datándose su origen en el año 1977).

Es bien sabido que los fundamentos del Manifiesto Ágil son anteriores a su publicación, en el caso de la publicación indicada nos encontramos catorce años antes (y veinticuatro si consideramos el origen del concepto).

Es normal que entonces se tuviera problemas con una orientación a procesos descompensada y desgraciadamente sigue siendo normal ahora, entre otras cosas por la dificultad que tenemos los seres humanos de aprender de nuestros errores y porque en entornos académicos durante muchos años se ha hablado mucho de procesos y poco o nada de las personas.

El proceso debe establecer un marco general de trabajo con la suficiente flexibilidad para permitir una adaptación a los diferentes contexto que nos encontramos en los proyectos de desarrollo de software y a los cambios que se producen en los mismos y se tienen que definir con la finalidad de cumplir una serie de objetivos establecidos por la organización, entre los que nunca estará el propio proceso en sí.

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.

Yo estoy plenamente convencido de que para que un proyecto de desarrollo de software tenga posibilidades de tener éxito es fundamental que las interrelaciones personales entre los miembros del equipo de proyecto y entre los stakeholders deben funcionar. No hablo de amistad, hablo de profesionalidad y confianza.

Cuando nos enfrentamos a un problema en el proceso de desarrollo, muchas veces se trata de un duelo entre nosotros y el problema, por ejemplo si hay que programar un componente es un duelo intelectual entre nosotros y el algoritmo o algoritmos necesarios para llevarlo a cabo. Por muy difícil que sea ese duelo, lo normal es que sean mucho más fáciles de tratar que cualquier contingencia en la que se vean involucradas personas.

Cada uno de nosotros es un mundo, con nuestros propios intereses personales y profesionales y en donde nuestro estado de ánimo puede ser diferente de un día para otro.

Por este motivo, saber gestionar situaciones en las que están involucradas personas es muy importante dentro del proceso de desarrollo de software.

Una mala gestión de esas situaciones puede acabar con el proyecto o poner una resistencia que dificulte en gran medida la consecución de los objetivos, requiriéndose un mayor esfuerzo que tendrá un impacto en la materialización en el producto de las expectativas de los usuarios (si se pierde el enfoque en los objetivos y se desvía atención a problemas entre equipos o en el seno de un equipo)y también en aspectos presupuestarios porque el avance en el proyecto será más desordenado y en cada iteración o evolución perderá fuerza la intención como consecuencia de una menor atención por parte de la mayoría de las personas y equipos involucrados en el proyecto.

La siguiente cita de Alistair Cockburn resume perfectamente esta situación (traducción libre): “El fondo real del término ágil no se ha alcanzado todavía porque la gente todavía desvía su atención a la religión del proceso o al sueño de las matemáticas y olvida que nuestra industria está construida sobre personas que trabajan juntas, inventando y decidiendo sobre la marcha. Lo repito una y otra vez, lo importante son las personas, los seres humanos, con todos sus defectos. Las matemáticas y los procesos son relevantes, pero muchos más fáciles de gestionar que tratar con las personas reales que están delante nuestra”.

Hace poco descubrí la siguiente cita de Alistair Cockburn que refleja a la perfección mi sentimiento sobre el concepto de ser ágil: “Ser ágil … es una actitud, no una técnica con sus limitaciones. Una actitud no tiene fronteras, por lo que el enfoque no es preguntarse ¿puedo ser ágil aquí? sino ¿cómo voy a actuar de forma ágil aquí? o ¿cómo podemos ser ágiles aquí?”.

Normalmente las empresas de desarrollo de software prestan servicios a terceros y el proceso de desarrollo está muy condicionado por los mismos por lo que resultar complicado encontrar contextos en los que se puedan aplicar metodologías ágiles de forma ortodoxa. Habrá veces donde se puede reorientar el contexto o aislar parte del proceso de desarrollo y otras veces no será posible.

Ahora bien, una cosa es eso y otra tener una actitud ágil en el proyecto. Incluso en las circunstancias más adversas podemos tener como background este enfoque pero para ello hay que tener muy asimilado en qué consiste ser ágil y eso va mucho más allá de la teoría e incluso de años de práctica de aplicación de metodologías ágiles (al final una metodología no es más que una receta a seguir, si solo nos hemos limitado a seguirla y no hemos mirado más allá no habremos comprendido su esencia).

El desarrollo de software requiere un orden. Las consecuencias de la falta de orden las conocemos todos: mala calidad de los productos y pérdida de dinero (para todos).

Ese orden se obtiene aplicando un proceso o una metodología de fondo dentro del propio desarrollo y con el resto de procesos de tu departamento u organización.

Ahora bien, el proceso es un instrumento, no un fin. Cuando se convierte en un fin se sitúa en la escala de valores por encima del software, algo que nunca debió suceder y tendrá consecuencias negativas en el proyecto ya que es esfuerzo se enfoca en una dirección equivocada.

Tampoco el proceso puede situarse por encima de los personas, aún siendo importante, así lo dice el Manifiesto Ágil y lo evidencia nuestra experiencia. Cuando se interrumpe o dificulta la interrelación entre personas, se crea distancia entre las mismas, se pierde armonía y la colaboración, algo fundamental para sacar adelante los proyectos, se ve afectada.

La propia naturaleza de las personas requiere que los procesos supongan un instrumento que guía de fondo y que en cualquier caso deben adaptarse a un contexto (en el que están incluidas las propias personas).

Alistair Cockburn dice que: “Las personas son inherentemente no lineales e impredecibles”, cualquiera de nosotros somos el mejor ejemplo para ilustrarlo y si miramos alrededor, en nuestro equipo de proyecto o en nuestro departamento, encontraremos tantas muestras como alcance nuestra vista.

Adaptarse a esta circunstancia requiere importantes habilidades humanas y tener presente que los contextos en los que trabajamos serán distintos, a veces los matices serán pequeños y en otras muy sensibles.

En la confianza se cimentan las relaciones personales, laborales y mercantiles.

Cuando un equipo de proyecto y los stakeholders construyen un ambiente de confianza disminuye la resistencia para conseguir el éxito, es la diferencia entre ir todos a una o encontrar personas o equipos que empujan en direcciones direcciones o sentidos.

Si dos principios del Manifiesto Ágil indican que se valora:

– A los individuos y su interacción, por encima de los procesos y las herramientas.
– La colaboración con el cliente, por encima de la negociación contractual.

La confianza resulta un ingrediente esencial para poder satisfacerlos.

No es condición suficiente la confianza para el éxito del proyecto pero es importante, tampoco es condición necesaria pero resulta poco probable que en este contexto el proyecto tenga un fin acorde a las expectativas.

La confianza no se gana de un día para otro, se requiere tiempo y mucho más que palabras. La confianza se basa en los hechos.

Sin embargo, la confianza se puede perder en un momento. Cuesta mucho ganarla, casi nada perderla.

Brad Appleton, director de ingeniería del software de Motorola, realiza una reflexión con la que estoy de acuerdo: “Lo primero que hay que construir es la confianza”. O por lo menos empezar a construirla ya que, como decía, requerirá tiempo.

Muchas personas contrarias a las metodologías o enfoques ágiles utilizan como argumento que la agilidad es una puerta abierta a la entrega de versiones de productos deficientes bajo el amparo de un enfoque evolutivo del desarrollo de software basado en la aproximación sucesiva a la versión final de producto y el feedback o dicho de otro modo: como vendrán nuevas oportunidades de seguir evolucionando el software no me esfuerzo por entregar un buen producto (ya se arreglará o ya se mejorará).

Pues no, no es así. Quien hace eso yo no lo considero agilista (opinión personal), es más puede que no lo considere incluso un buen profesional.

La agilidad requiere desarrollos con intención. La intención es la aproximación a un objetivo tirando a dar, minimizando la especulación. Un desarrollo con intención no se puede sustentar en entregas de calidad deficiente porque de lo contrario la evolución del producto será muy lenta y la capacidad de adaptación al cambio, por tanto, disminuye.