archivo

Archivos diarios: agosto 21, 2012

El feedback permite ajustar el sistema a las expectativas del usuario. Por un lado hemos podido interpretar erróneamente las especificaciones del usuario, haber realizado una ejecución no adecuada de la misma, haber detalles que no hemos resuelto correctamente o bien el usuario tras ver las especificaciones implementadas (y estar bien) darse cuenta de que su idea inicial era incorrecta, que es mejorable o darse cuenta de posibilidades que previamente no había contemplado.

Este feedback lo podemos obtener tanto de versiones utilizables del producto (en un entorno de producción) que sería lo ideal ya que los usuarios adquieren un rodaje y una visión de la aplicación totalmente diferente a cualquier otra estrategia que se utilice, pero también lo podemos obtener a través de versiones en un entorno de preproducción o de demostración, a través de esqueletos andantes o revisando con ellos prototipos de pantallas ya sean dinámicos o en cartón piedra.

Revisaréis cien veces (o mil) una pantalla con un usuarios y en todas ellas saldrán cambios. Es importante saber cuándo hay que parar y pasar página (es el usuario el que debe autolimitarse y ser él el que tome la decisión, para ello es importante que entienda y que le expliquemos qué es el desarrollo de software, cuál es el presupuesto y cuáles son los plazos) sobre todo si estamos trabajando con prototipos porque de lo contrario habremos agotado el presupuesto y no habremos avanzado casi nada, con el peligro añadido de que conforme el producto vaya madurando el usuario añadirá nuevos cambios, estos generalmente con más acierto al estar trabajando a un nivel de abstracción menor.

Tenemos que asumir que en cada revisión los usuarios sugerirán cambios, esto es así y es bueno que suceda, ¿queremos desarrollar un producto que no le sirva al usuario?, pero en el horizonte debe estar siempre, como decía antes, el estado presupuestario del proyecto, de ahí la necesidad de que los usuarios también pidan con intención (previa priorización de lo que les resulta más importante), pensando qué piden y para qué lo piden y nosotros proporcionarles las herramientas y el soporte para ayudarles a ello.

Nuestro conocimiento y nuestra experiencia constituyen nuestro verdadero background a la hora de afrontar un proyecto de desarrollo de software y las diferentes contingencias y cambios de contexto que se van a producir en el mismo. Todo lo demás: metodología, procesos, buenas prácticas, herramientas, etc… son instrumentos que utilizaremos según convenga y que en el caso de que haya alguno de carácter obligatorio (por si se quiere armonizar algún aspecto del desarrollo entre proyectos diferentes) debe ser lo suficientemente flexible para ofrecernos el margen de maniobra necesario para poder adaptarnos a la nueva situación e incluso prever la posible existencia de excepciones cuando exista una circunstancia que lo justifique.

La repetibilidad es algo deseable, ¿por qué no querer industrializar una manera de hacer las cosas que nos permita alcanzar el éxito con una alta probabilidad?, sin embargo en el desarrollo de software donde cada proyecto es algo singular y en donde los contextos cambian es buscar una quimera.

Por tanto, la repetibilidad basada en términos absolutos es algo que deberíamos descartar de base, lo cual no quiere decir que en función de las características de un proyecto apliquemos unas estrategias de fondo que nos puedan resultar de utilidad (pero como instrumento no como un martillo de oro).

Sobre esto, Jim Highsmith opina lo siguiente: “Los agilistas creen que las buenas prácticas y procesos puede mejorar la consistencia pero que la repetibilidad es una fantasía”.

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.