archivo

Archivos diarios: septiembre 19, 2013

El aprendizaje requiere también de experimentación con el objeto de obtener un feedback que nos permita seguir evolucionando y tomando nuevas decisiones.

El enfoque iterativo incremental en el desarrollo de software supone un marco ideal, si bien, lo ideal es que los ciclos no se demoren mucho en el tiempo para ir adquiriendo ese conocimiento lo más rápidamente posible (la duración en los ciclos, en mi opinión, no lo debe imponer la metodología sino las propias necesidades que tenga el proyecto).

Con ciclos demasiado largos probablemente los errores de enfoque por parte de desarrolladores o usuarios y el descubrimiento de alternativas más simples se detecten demasiado tarde, no porque no tengan solución (que dependerá del estado del proyecto) sino por el coste que tendrá afrontar los ajustes necesarios para evolucionar el producto hacia una solución que se vaya aproximando más a las expectativas que se tienen puestas en él.

Se debe evitar también, salvo que sea absolutamente necesario, entrar en un bucle de prueba y error porque cada iteración tiene un coste y de la inversión realizada se debe tratar de conseguir el mayor valor posible. Por ese motivo, cada evolución deben tener unas historias de usuario lo suficientemente trabajadas (en las tareas que se deben realizar en paralelo de refinamiento de la pila de producto), ya que permitirá ajustar mejor las estimaciones a realizar y se acertará (o nos acercaremos a una solución válida) en un mayor porcentaje de casos.

Un sistema levantado sobre arenas movedizas será un sistema que será muy costoso de ponerse en marcha y que estará sometido a continuamente a cambios, no tanto por la necesidad de evolucionar el producto sino por el hecho de que el proceso o procesos que se tratan de informatizar no están consolidados: hay varias personas con mando en la organización que tienen opiniones divergentes, procedimientos sobre los que se realiza continuamente labores de reingeniería significativas, cambios organizativos o legales numerosos, etc…

Un desarrollo iterativo incremental ayuda, en el sentido de que el producto se va desarrollando poco a poco y existe la capacidad, si se desarrolla con una deuda técnica bajo control, de poder reaccionar a los cambios de manera más o menos rápida, ahora bien, nada es infalible a cambios continuos de dirección y de criterios porque al final el sistema terminará reflejando de alguna u otra manera esos problemas.

Si el diseño de un sistema es caótico es importante analizar todas las contingencias que se han producido durante su desarrollo porque probablemente han tenido mucho que ver. ¿Han podido fallar los desarrolladores? Muchas veces tenemos la culpa pero muchas veces somos víctimas de unas especificaciones no consolidadas porque la base en la que se fundamentan tampoco lo está.

Mi consejo es que en estas circunstancias no se desarrolle ningún sistema y si fuera absolutamente necesario su diseño debería centrarse en tratar de dar una solución rápida y poco costosa, aunque se queden muchas funcionalidades fuera, ya que eso es mucho mejor que invertir dinero y esfuerzo en tareas que hay que rehacer en numerosas ocasiones.

Estas soluciones pensadas en principio como de usar y tirar tienen sus riesgos si se toma al pie de la letra este concepto. Es posible que, a veces, sea lo mejor. En otros casos puede ser más conveniente buscar esa solución de mínimos pero pensando en su posible crecimiento y evolución posterior. Esta última solución, en teoría, me gusta más, pero como siempre es necesario analizar el escenario para tratar de elegir la mejor solución.