archivo

Archivo de la etiqueta: Cockburn

En esta serie de artículos que he publicado en los últimos días que han tenido como hilo conductor una serie de citas de Alistair Cockburn he querido reflejar la visión que tiene este autor y que coincide con la que tengo y que no es otra que el software por encima de todo es el resultado de la colaboración entre personas y que como consecuencia de eso si esa cooperación no funciona o no existe el proyecto se verá afectado.

Por ese motivo es fundamental consolidar un contexto en que las personas cooperen y puedan sacar el máximo partido a su talento. No hay reglas, más allá de determinadas buenas prácticas o la experiencia individual del gestor que permitan llegar a ese caldo de cultivo, entre otras cosas porque no solo va a depender de él y porque las personas somos complicadas de gestionar por naturaleza y más cuando trabajamos en grupos (visiones distintas y objetivos personales y profesionales dispares).

Que sea complicado no quiere decir que se deba dejar en un segundo plano, antes al contrario. Se ha avanzado mucho en la tecnologías y en metodologías, pero tal vez no tanto, en la gestión de las personas en los proyectos de desarrollo de software, de hecho, echando la vista atrás, no creo que se haya dedicado ni una hora de clase en mi etapa universitaria a tratar el factor humano en los proyectos (fruto tal vez de una visión demasiado teórica de lo que es el desarrollo de software).

Alistair Cockburn piensa que al tratarse un factor decisivo en los proyecto de desarrollo de software debe tratarse como tal (traducción libre): “Las personas tienen un efecto de primer orden en el desarrollo de software, no un efecto de un orden inferior. En consecuencia, la comprensión de este efecto de primer orden debe convertirse, por tanto, en un elemento de investigación de primer orden y no ignorado como un elemento de segundo orden”.

Los profesionales con alta capacidad técnica y alta productividad son muy demandados en el mercado, sin embargo se suele dejar en un segundo plano a personales que sean capaz de tener una actitud de liderazgo y una capacidad de gestión lo suficientemente válida como para hacer que equipos de personas alineen su esfuerzo para conseguir los objetivos.

Se pueden tener técnicos maravillosos pero muchos de ellos necesitan que les marquen un ritmo, que les indiquen un camino hacia donde ir y que se les cree un contexto en el que puedan sacar el máximo partido posible a su talento.

Las relaciones personales son complicadas porque la vida de las personas con las que tienes que tratar en el proyecto son diferentes y sus prioridades y visión de la realidad y de los problemas no serán iguales a las que tú tengas (tampoco será igual su estado de ánimo y tampoco será igual probablemente al que tuvieran hace un mes o al que tendrá dentro de dos). Se trata de tener empatía, de tener claro que es importante trabajar con consensos y que también será necesario tomar decisiones y entrar en situaciones de conflicto porque desgraciadamente no siempre se consigue todo por la vía más diplomática (el todo el mundo es bueno en la realidad no funciona y provoca desequilibrios).

De la misma forma que dos no se pelean si uno no quiere, dos no pueden trabajar juntos si uno no quiere.

Se trata de habilidades personales, las cuales se cimentan en la experiencia y en el conocimiento de contextos concretos (hay personas que tienen de manera innata habilidades personales pero su efectividad no es la misma en todos los contextos). La teoría es un background a tener en cuenta pero no es un elemento decisivo en comparación con otras variables como la experiencia o las propias habilidades del individuo.

Alistair Cockburn sobre este asunto opina lo siguiente: “Toda la teoría del mundo no garantiza que la gente pueda funcionar o trabajar bien junta. Cada individuo tiene efectos extraños sobre los demás: puede incrementar la confianza o provocar inesperados ataques de ira”.

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”.

Comenta Alistair Cockburn que “La cooperación implica confianza”, por ese motivo tal y como comentaba hace unos días un cita de Brad Appleton, la confianza es un elemento de que debe empezar a cimentarse desde el inicio del proyecto.

Mientras no se rompa la relación entre cooperación y confianza, se realimentan. La cooperación incrementa la confianza y la confianza la cooperación. Se crea una espiral positiva, de la misma manera que cuando se rompe la confianza se crea una espiral negativa en la que se rompen esos nexos de unión entre los equipos y como consecuencia sufre el proyecto (es una situación en la cual nadie cree a nadie y se opta por una posición defensiva).

Por encima de cualquier proceso y de cualquier metodología están las personas, si las relaciones entre ellas no funcionan de nada importa lo que haya por debajo, es por eso que cuando se producen este tipo de problemas hay que tomar las decisiones necesarias para reconducirlo.

Para Alistair Cockburn la distancia es cara.

Coincido absolutamente con su apreciación aunque es necesario tener en cuenta que la distancia no se debe medir exclusivamente en términos físicos, a veces puedes trabajar de manera más colaborativa, directa y abierta con alguien que está a mil kilómetros que con quien está en la mesa de al lado.

El desarrollo de software es el resultado de la colaboración entre personas y conforme se pongan más obstáculos a esa cooperación necesaria, más complicado será conseguir los objetivos que se hayan marcado.

Se tiene que facilitar y poner los medios necesarios para que la comunicación sea fluida e intentar que quienes lleven el peso del desarrollo trabajen de la manera más directa y próxima posible (aquí sí que resulta mucho más interesante que la distancia física sea la menor posible).

Esto no es incompatible con que ciertos componentes del equipo estén deslocalizados o que ciertos días a la semana los componentes del equipo puedan trabajar desde donde prefieran pero sí que veo necesario una necesaria disciplina para que determinados días de la semana el núcleo fuerte del proyecto trabaje junto.

Deslocalización no debe ser lo mismo que una persona o un equipo de personas a los que les arrojo trabajo “al otro lado del muro“, sino que debe ser considerado como un grupo que sirve de apoyo al proyecto y sobre el cual interesa mantener una comunicación lo más fluida posible, de manera que parezca como si estuvieran en el despacho de al lado.

Pero como decía antes, no se trata solo de poner medios sino de también crear una cultura en el equipo de que lo más importante es el proyecto y que esa es la prioridad. Esto es más fácil para el equipo de proyecto que para los usuarios donde en función del contexto de su trabajo las prioridades se pueden (se suelen) enfocar en otras tareas, lastrando al proyecto.

Yo estoy muy acostumbrado a trabajar con equipos dispersos y no es algo que recomiende a nadie. Hablo de mi experiencia, es posible que otros opinéis justamente lo contrario.

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).

Alistair Cockburn realiza la siguiente reflexión: “El primer objetivo es entregar el software; el segundo objetivo es estar preparado para el siguiente partido”.

En la misma refleja la esencia de la naturaleza evolutiva o iterativa del desarrollo de software. El desarrollo de software no termina con su entrega, su ciclo de vida va más allá independientemente de la metodología utilizada. Si el enfoque es iterativo incremental la entrega de una versión no es más que el punto de partida de la siguiente.

Es muy importante el detalle de que hay que estar preparado para lo que venga después y es que lo que desarrollemos hoy tendrá impacto en las evoluciones futuras del producto y todo trabajo debe hacerse con intención minimizando o eliminando la improvisación.

El primer objetivo debe ser la entrega porque sin esta versión no hay versiones posteriores.