archivo

Archivos diarios: septiembre 7, 2012

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

Las iteraciones o sprints requieren estabilidad, cambios en los requisitos te pueden destrozar el sprint. Si hay alguno de los objetivos que debe variar respecto a como se han especificado lo mejor es no llevarlo a cabo y dedicar ese tiempo a hacer alguna tarea contemplada en la pila de sprint con una prioridad menor y que no se tenía claro si iba a dar tiempo o no a realizarla.

En el caso de que no haya tareas de ese tipo (no se incluyen en el sprint tareas del tipo “por si acaso”), lo mismo hay que aprovechar ese tiempo para realizar alguna tarea de índole técnico en el proyecto (siempre habrá alguna que realizar: refactorización, mejora de la deuda técnica, mejorar la automatización de testing, mejorar los procesos de instalación, etc…) o para estudiar con más detalle algún aspecto funcional que no se termina de tener lo suficientemente claro.

Iteraciones o sprints demasiado largos están sometidos más tiempo a la incertidumbre y por tanto se incrementa la posibilidad de que haya cambios en las especificaciones (en muchos casos sin excesivo fundamento, solo por el hecho de que al responsable funcional, Product Owner o usuario se le ha ocurrido algo nuevo sin tener como elemento comparativo una versión del software funcionando con las funcionalidades que inicialmente comentó y que se iban a llevar a cabo en esta evolución).

Necesitamos estabilidad en las iteraciones pero las mismas deben tener la duración que se considere más adecuada para el proyecto en el que estamos trabajando, hay que jugar con ambas variables para intentar encontrar el punto más óptimo.