archivo

Archivo de la etiqueta: software

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

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.

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.

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.

Conforme vayamos adquiriendo experiencia en el desarrollo de software tendremos una visión más amplia ante cualquier situación que nos encontremos en un proyecto, también de manera paradójica tendremos más asentadas unas prácticas o enfoques que limitan nuestro margen de maniobra independientemente de que esa visión nos muestre que existen otras posibilidades o alternativas.

¿Qué hacemos si la solución más adecuada parece que se encuentra fuera de los límites de nuestras buenas prácticas y/o enfoques?

Analizar si realmente es así. Si tenemos esas prácticas es por algo, son consecuencia de nuestra experiencia en diferentes proyectos y de todo el conocimiento que hemos adquirido hasta ahora.

Volverlo a analizar.

Si realmente fuéramos infalibles, no seríamos humanos, por ese motivo siempre se debe dejar una puerta abierta a otras alternativas. Llegado el punto de tomar una decisión que nos lleve a unas acciones fuera de nuestras prácticas o enfoques, si la situación nos obliga, tendremos que hacerlo (no todo vale, hay líneas rojas, pero no puedo hablaros de ellas ya que cada uno tendrá las suyas).

Si al final tenemos que salir de nuestro camino y optar por otras soluciones podrá pasar que hayamos acertado o nos hayamos equivocado, en ambos casos habremos ganado conocimiento y experiencia y lo mismo nuestras prácticas o enfoques se han consolidado todavía más o bien abarcan ahora un mayor abanico de posibilidades, en caso de habernos equivocado tendremos que afrontar las consecuencias (en cualquier caso, eso es inherente a cualquier profesión, tenemos que convivir con el éxito y con el fracaso).

Es fundamental saber hacia dónde se quiere ir, cuáles son los objetivos y esto es extensible tanto a las personas como a las organizaciones.

De lo contrario, al no tener referencias, se vive en un continuo cortoplacismo en el que los árboles te impedirán ver el bosque incluso en circunstancias que puedan resultar evidentes.

El cortoplacismo y la ausencia de referencias son muy peligrosos ya que en estas circunstancias te encuentras como un barco a la deriva.

Supongamos que tenemos objetivos, ¿qué tal si planificamos todas las acciones necesarias para alcanzarlo?. Pues que probablemente hayamos ganado en conocimiento de la situación por el análisis necesario para realizar la planificación y hayamos perdido tiempo ya que buena parte de lo planificado no servirá de nada una vez que el contexto previsto en el que se van a ejecutar las acciones varíe (y variará).

Comenta Ron Jeffries que (traducción libre): “Cómo podemos saber lo lejos que podemos llegar si normalmente no vamos tan lejos”.

Tiene razón y es uno de los riesgos de la planificación: plantear acciones sobre escenarios abstractos sobre los que no se tiene un conocimiento o un dominio concreto y sobre los que no se tiene un control.

Es por eso que resulta más adecuado el concepto de plan (planteo las acciones a realizar en mi contexto actual) y el concepto de evolución centrado en los objetivos (sé a dónde quiero llegar, probablemente no conozca el camino, pero si mido bien los pasos estaré más cerca de la meta).

Hace poco leí una cita de Henrik Kniberg que resume perfectamente lo que debe ser el enfoque evolutivo en el desarrollo de software: “La perfección es una dirección, no un lugar”.

El objetivo es conseguir que el software mediante iteraciones sea cada vez mejor, que cuando se evolucione se haga con la intención de mejorar el estado anterior (no especulando y evitando situaciones de prueba y error en la medida de lo posible) y que llegado un punto se evalúe si realmente el valor de seguir evolucionándolo compensa el esfuerzo de realizar ese trabajo.

Como dice Kniberg, la perfección no debe ser un objetivo pero sí una referencia, de lo contrario se deja de lado la intención y en consecuencia la evolución del software es más lenta y resulta más costoso la obtención de una versión que satisfaga realmente las expectativas puestas en el producto.