archivo

Archivos diarios: octubre 20, 2012

Comentan Mary y Tom Poppendieck que: “El rápido desarrollo tiene muchas ventajas. Sin velocidad, no se puede retrasar las decisiones. Sin velocidad, no tenemos información fiable. En el proceso de desarrollo, el ciclo de descubrimiento es fundamental para el aprendizaje: diseñar, implementar, feedback, mejorar”.

Me parece muy interesante que cita como ventajas, inconvenientes o deficiencias propias de otras estrategias de desarrollo: como atrasar casi indefinidamente decisiones que hay que tomar (gusten o no) y que las hipótesis formuladas queden sin ser demostradas durante demasiado tiempo.

Lo que está claro es que un enfoque clásico donde hay que esperar al final del proyecto a que se levante el teĺón para ver si el resultado es el adecuado es un riesgo absolutamente innecesario y que no se ajusta a la naturaleza del contexto del desarrollo de software: incertidumbre y cambio.

Si la solución no es acertada hay que esperar hasta el final, si hay que mejorar cosas (no solo del producto sino también del funcionamiento de las personas implicadas en el proyecto) también hay que esperar al final (es cierto que se pueden corregir deficiencias en ese funcionamiento sobre la marcha pero se escaparán muchas de ellas debido a que no se tendrá conciencia del impacto real que están teniendo en el desarrollo del producto).

Si el usuario no termina de tenerlo claro o nosotros no terminamos de entender o captar lo que quiere necesitamos ir puliendo la funcionalidad a través del feedback. En este caso no es recomendable huir hacia adelante y esperar al feedback tras la nueva versión del producto, ya que estaríamos ante una situación de prueba y error, alejándonos del background en el que debe basarse toda iteración: la intención.

Es una generalización, lo mismo si el desarrollo no requiere mucho esfuerzo y el ciclo es corto se puede optar por obtener el feedback tras la construcción de la funcionalidad, como digo siempre: analiza el contexto, las necesidades y decide.

Lo más recomendable en estos casos es trabajar la funcionalidad con prototipos (utilizarlos como un canal de aprendizaje) que requieran el menor esfuerzo posible ya que interesa obtener el feedback cuanto antes y seguir trabajando a partir de él.

Es importante que entendamos lo que quiere el usuario y que el propio usuario traspase a un plano más real lo que tiene en la cabeza. El prototipo no cubrirá toda la distancia entre lo abstracto y la solución final pero si se trabaja bien y el usuario muestra interés ofrece una aproximación interesante que después se puede seguir trabajando a través del feedback de las distintas versiones del producto.