archivo

Archivos diarios: septiembre 8, 2011

Existe una diferencia entre la percepción del desarrollador, la percepción de los usuarios y el universo de discurso. Hay que tener en cuenta que los usuarios son expertos en los procesos que manejan y aunque el desarrollador conozca bien el negocio, cada organización es diferente y lo que en una funciona, en otra no necesariamente tiene que dar los mismos resultados.

También hay que tener en cuenta que el desarrollador es el que conoce las limitaciones de la tecnología que va a utilizar, en el sentido sobre todo de la dificultad y coste de los que se pide (más que en el sentido de si se puede hacer o no), por lo que su percepción también es valiosa.

Habrá proyectos donde diferentes desarrolladores participen en las etapas de análisis y cada uno de ellos puede entender el problema de una manera, no necesariamente diferentes, pero tampoco idénticas.

Visiones diferentes requieren del consenso y comunicación entre usuarios y desarrolladores para que se pueda reducir esa diferencia entre lo que se cree que se quiere y lo que se quiere realmente, objetivo que necesitará también saber elegir en cada proyecto de forma adecuada la proporción de la visión de los usuarios y desarrolladores que llevará la fórmula (además de seleccionar los ingredientes que aporta cada uno).

Richard (Dick) E. Fairley es una profesor universitario y autor americano especialista en ingeniería del software y sobre tema comenta lo siguiente (traducción libre): “En el sentido más real, el ingeniero de software convierte modelos de situaciones físicas en software. El mapeo entre el modelo y la realidad que ha sido modelada se conoce con el nombre de distancia intelectual entre el problema y la solución computerizada del problema.

Uno de los objetivos principales de la ingeniería del software consiste en diseñar productos software que minimicen la distancia intelectual entre el problema y la solución; sin embargo, la variedad de posibles soluciones en el desarrollo de software solo está limitada por la creatividad e ingenuidad del programador. En muchos casos no está claro cuál de las soluciones es la que minimizará la distancia intelectual y a menudo diferentes soluciones podrán minimizar diferentes dimensiones de la distancia intelectual”

He tenido la oportunidad de leer una entrevista que Jim Highsmith publica en su blog y que realizó a Alistair Cockburn hace diez años. Os recomiendo que le echéis una ojeada porque representa la visión que tenía Cockburn de manera contemporánea al nacimiento del movimiento ágil.

En dicha entrevista Cockburn hace referencia a la complejidad de definir una metodología general para el desarrollo de software ya que lo que él había podido apreciar en proyectos de desarrollo de software dentro y fuera de IBM es que lo que se aplicaba en proyectos reales presentaba divergencias respecto a lo que definían teóricamente los libros.

Las metodologías se adaptaban a las necesidades de una organización, se moldeaban a las mismas, a su forma de hacer las cosas, por eso resultaba complicado trasladar estas normas de una organización a otra porque la cultura suele ser diferente. Sin embargo, Cockburn comenta que lo que realmente se podía trasladar con éxito eran las buenas prácticas.

Resulta también muy interesante como Cockburn comenta que cuando aplicó una recopilación de buenas prácticas (que al fin y al cabo conformaban una metodología) a un proyecto real se dio cuenta que aunque el proyecto se ejecutó con éxito, los técnicos en muchos casos no aplicaban las especificaciones metodológicas y que eso le provocó una serie de dudas hasta que comprendió que el desarrollo de software es así, se trata de personas que resuelven problemas, que están centradas en los mismos y eso perjudica el seguimiento de determinados aspectos de la metodología.