archivo

Archivo de la etiqueta: Alistair Cockburn

Es cierto que pueden existir ciertas reglas o patrones que se repiten con una cierta asiduidad en los proyectos de desarrollo de software pero en muy pocas circunstancias se da el caso de que la receta aplicada en otro proyecto garantice el éxito en el que estás trabajando.

Sí que es bueno conocer esas experiencias, esas buenas prácticas, esos patrones, esos antipatrones, ese cuerpo de conocimiento pero sabiendo que se trata de herramientas que están a nuestra disposición si entendemos que son de utilidad para el proyecto (y no siempre lo serán).

Se trata de conocimientos y experiencias de terceros y si le vas sumando tu propia experiencia la caja de herramientas ofrecerá más posibilidades y será más precisa. No obstante y por encima de todo se encuentra nuestra capacidad de entender que cada proyecto es distinto y que cada situación puede requerir soluciones particulares.

Alguna vez he comentado en el blog que no entiendo muy bien esos casos en los que vienen empresas o consultoras a proponer la implantación de un conjunto de procesos o metodologías sin haberse preocupado en conocer las particularidades de la organización del posible cliente, como si tuvieran entre manos una talla única que encaja en todas las situaciones.

Me parece muy interesante la siguiente reflexión de Alistair Cockburn: “Si se sigue una metodología tal cual, tendrás una que se adapte a algún proyecto en el mundo, pero probablemente no el tuyo”.

No resulta positivo que los desarrolladores intervengan en exceso en la definición de las historias de usuario, más allá de dar salida a las especificaciones de usuario con prototipos (pantallazos) que permitan facilitar la comprensión al usuario del efecto que tiene la definición que ha realizado.

No debemos olvidar que el producto no es para los desarrolladores sino para los usuarios.

El otro extremo, en los que los desarrolladores son meros ejecutores de las historias de usuario tampoco es el mejor modelo, ya que los desarrolladores pueden detectar funcionalidades que no terminan de encajar en el sistema y/o que tienen una complejidad que está muy por encima de los beneficios o valor que va a proporcionar a los usuarios.

Alistair Cockburn lo resume bien en la siguiente reflexión (traducción libre): “Un proyecto sufre cuando los desarrolladores no mencionan los problemas que descubren. El proyecto pierde la interacción creativa de programadores ofreciendo sus conocimientos para perfeccionar las peticiones de los clientes”.

La mejor solución es la doble dirección, es decir, desarrolladores y usuarios realizando y conociendo sus responsabilidades y funciones, colaborando, ofreciendo conocimiento y abriendo debates cuando sea necesario.

Para Alistair Cockburn: “Cada equipo de proyecto debería tener como objetivo reducir el coste total de energía necesario para detectar y transferir ideas”.

Comparto absolutamente esa reflexión. Un equipo que comparte información, la buena y la mala, que conoce lo que está pasando, los objetivos del proyecto y el contexto es un equipo que comprenderá mejor las decisiones que se toman y funcionará más como conjunto que como individualidades.

Si la información no llega, surgirán los malos entendidos, mucha de ella vendrá sesgada (que es casi peor que el hecho de que no llegue), provocará distracciones y distanciamiento entre los miembros del equipo y/o entre el propio equipo y el resto de la organización.

Es importante que todos, absolutamente todos los miembros del equipo tengan acceso a la información del estado actual del proyecto y de los problemas que hay.

¿Qué aporta el oscurantismo?, ¿qué aporta ofrecer solo información interesada?, ¿qué aporta que solo unos cuantos elegidos conozcan la realidad del proyecto? Nada.

A veces es tan grande el muro que tenemos ante nosotros que ni siquiera nos planteamos pasar por encima de él siendo la decisión más habitual rodearlo (teniendo en cuenta que lo mismo no terminamos nunca de ver donde se encuentra su extremo).

Dejar las cosas como están porque entendemos que no es posible cambiar es muy habitual. A mi me ha pasado, me pasa y me pasará. A veces estás tan harto de todo o lo ves todo tan complicado que consideras que no merece la pena hacer un esfuerzo que lo más probable es que no tenga recompensa.

Sin embargo, si no eres conformista intentarás revertir muchas de esas causas perdidas incluso por mucho que te fastidie tener que ser tú el que te eches el peso a la espalda.

Lo más probable es que no puedas por ti mismo provocar grandes cambios, cambios radicales que permitan resolver a corto plazo lo que entiendes que no funciona como debiera.

Comenta Alistair Cockburn que: “Muchos cambios microscópicos pueden producir un efecto muy grande al unísono” y realmente es algo que suele funcionar independientemente de que sea muy grande o no o que tengan que realizarse de manera simultánea. Pequeños cambios realizados de manera sostenida sí pueden producir cambios y lo que es necesario es tener la paciencia y determinación suficiente para seguir con el empeño para conseguirlo y para volver a intentarlo si no lo consigues aunque sea en otra circunstancia y con otra problemática.

No se puede entender el desarrollo de software sin cooperación y sin el elemento imprescindible para que sea efectiva: la comunicación.

Cuantos más distancia (no me estoy refiriendo a distancia física) haya entre las personas y los equipos y más muros (o fosos) se pongan en medio más complicado será que el proyecto vaya a algún sitio.

La creatividad también es importante si no se pierde el control sobre la misma ya que no poseemos un recetario que ofrezca soluciones a todos los problemas.

Comenta Alistair Cockburn que: “El desarrollo de software es un juego cooperativo de invención y comunicación” y estoy totalmente de acuerdo con esa apreciación: si no sabes o no quieres jugar el trabajo se resiente.

Reducir distancias, eliminar fronteras y agilizar las relaciones requiere de mucho esfuerzo y habilidad pero sobre todo depende de que creamos que realmente es así como hay que trabajar. No basta con que lo leamos o que nos lo digan, hay que creer en ello porque mantener el equilibrio no es nada sencillo debido a que las propias contingencias de un proyecto desestabilizan y porque detrás de todo estamos las personas y no hay nada menos estable que nuestro comportamiento.

Podemos tener una intención en lo que queremos transmitir y pensar que lo hemos hecho de manera clara y sin ambigüedades de manera que el receptor lo ha entendido (el mensaje) y captado (sensaciones) de la forma que queríamos.

Es posible que hayamos acertado pero también sucede de manera muy frecuente que no es así, que no se entiende el mensaje como queríamos y/o que no provoca las sensaciones que pretendíamos llegándose incluso a situaciones de malos entendidos.

Si consideramos que la comunicación es uno de los pilares fundamentales en el desarrollo de software no debemos olvidar que la percepción de las personas sobre un mismo hecho es diferente independientemente del sentido o sentidos que utilice para captarlo. Tenemos que tener en cuenta que lo mismo nuestro mensaje no es tan evidente como parece y que el receptor puede estar condicionado por una visión previa que tenga de la situación o tal vez su atención no es la más adecuada en esos momentos.

Si hay que repetir el mensaje lo hacemos, si hay que hablar sobre ello se habla, lo importante es que se llegue a una situación donde ambas partes estén hablando de lo mismo (aunque existan determinados matices que puedan ser aclarados más adelante). Si se comunica es para informar, si no se consigue ese objetivo no se ha realizado de manera adecuada la comunicación (no importa realmente donde se haya producido el fallo).

Si crees que dedicar tiempo a que las partes se entiendan es una pérdida de tiempo acuérdate de eso cuando tengas que tirar una semana de trabajo (en el mejor de los casos) por una funcionalidad que no has entendido de manera adecuada qué es lo que debe hacer.

Ya lo dice Alistair Cockburn: “El fenómeno de la comunicación no depende de lo que se transmite sino en lo que le sucede a la persona que lo recibe”.

Sabemos que el desarrollo de software requiere comunicación continua entre todas las partes involucradas en el mismo: hay dudas, hay que revisar prototipos, documentación, iteraciones, obtener feedback, etc…

Sin embargo se tiende a poner fronteras entre los diferentes equipos involucrados. Estos muros crean “ciudades estado” que miran más por su parte del trabajo que por el conjunto del producto que se está desarrollando (antipatrón “arrojar al otro lado del muro“) y ese sentimiento de islote independiente crece (como mecanismo de defensa) conforme crecen los conflictos entre las partes.

¿En qué consisten esas fronteras? Comunicación a través de herramientas (bugtrackers, herramientas de gestión de proyectos, etc…) y limitación de las comunicaciones directas entre personas.

Es cierto que es necesario establecer un cierto orden ya que para poder trabajar en condiciones se requiere una cierta continuidad y para ello hay que evitar las interrupciones. Para ello se pueden establecer una serie de reglas entre las partes y sobre todo y por encima de ellas, aplicar el sentido común: por ejemplo si se dedica la primera y la última hora de la jornada a resolver dudas y sin embargo surge una que resulta muy importante resolver de inmediato, pues se hace una excepción. El sentido común entra en juego tanto para aceptar estas interrupciones como para no interrumpir cuando realmente pueda esperar.

En mi forma de entender el desarrollo de software la comunicación es esencial y cuando un proyecto no la tiene o no existe suficiente fluidez supone una resistencia muy fuerte para conseguir un resultado final aceptable.

Ya lo dice Alistair Cockburn: “Las personas son seres comunicativos” por ese motivo poner trabas a la comunicación es ir en contra de una actitud inherente en todos nosotros.