archivo

Archivos diarios: julio 9, 2011

Jim Highsmith es uno de los más fervientes defensores del “Do Less” como estrategia para mejorar la calidad del producto que se desarrolla y hacer más efectiva la inversión que se realiza en el desarrollo. Si a esto sumamos que fue uno de los firmantes del manifiesto ágil y su convicción en la naturaleza adaptativa del desarrollo de software, lo hace, en mi opinión, uno de los autores a tener más en cuenta.

Me parece muy interesante la técnica de análisis de falsa funcionalidad que Jim Highsmith menciona en su blog, haciendo referencia a una conferencia de Josh Keriesvky.

La técnica consiste en presentar a los usuarios una funcionalidad o módulo en el sistema, de manera que cuando quieran acceder a la misma les salga una ventana indicando que se trata de una funcionalidad en construcción y se le pregunta si cuando esté desarrollada será muy probable, probable o poco probable que la utilicen.

Por lo visto Josh Keriesvky hizo uso de esta técnica en un proyecto y como consecuencia de la misma se decidió no implementar una solución de alto coste en el mismo.

En concordancia con el artículo: “Desarrollo de software. Menos es más“, cuando tenemos un sistema de información con funcionalidades o módulos que no se utilizan o que tienen un uso marginal, no solo tenemos que pensar en el esfuerzo inútil que se ha perdido en el desarrollo de los mismos (que lo mismo hasta han sufrido evoluciones o modificaciones) sino en el esfuerzo que no hemos podido invertir por culpa de esto en las funcionalidades y módulos más esenciales del sistema de información que lo mismo hubieran tenido un mayor recorrido y con ello una mayor adaptación a las expectativas de los usuarios y una mayor calidad.

Antes de desarrollar una funcionalidad, es necesario que transmitamos al usuario hasta que punto va a ser necesario llevarla a cabo.

Buscar una solución finalista y/o compleja a una funcionalidad de un sistema de información puede ser un error ya que obliga a invertir un esfuerzo importante en su desarrollo.

Al tener una mayor envergadura, el mantenimiento de la funcionalidad se hace más complejo lo que supone un obstáculo tanto para el mantenimiento de la misma como para el mantenimiento del sistema. La consecuencia es que la capacidad de adaptación de la aplicación al feedback del usuario o el desarrollo de nuevas funcionalidades se verá mermada.

Es mejor hacer un enfoque pensando en incrementar la complejidad de las funcionalidades o de los módulos poco a poco. Una vez consolidada una solución y se quiere ampliar su funcionamiento o determinado que la forma en que se trabaja en la misma requiere cambios (porque la alternativa elegida finalmente se aprecia que es mejorable o no es del todo correcta) es el momento de dar el siguiente paso.

Yo entiendo la agilidad como la capacidad de respuesta al cambio, independientemente de su origen y como la capacidad de que los cambios funcionales estén dirigidos por el feedback del usuario. Esa capacidad de respuesta requiere de unos plazos aceptables, a veces será más fácil, otras más complicado, en función de la cantidad de esfuerzo que se requiera.

En función del grado de madurez del sistema, será inevitable que determinados cambios significativos requieran un esfuerzo importante llevarlos a cabo (aunque se realicen siguiendo aproximaciones iterativas e incrementales), sin embargo cuando se trata de forzar la madurez de una aplicación, buscando una completa implementación de un módulo o funcionalidad compleja, estamos provocando un sobrecoste que ha podido ser perfectamente evitado.