archivo

Archivo de la etiqueta: Dick Fairley

El hecho de que esté escribiendo una serie de artículos sobre CMMI y que valore positivamente lo que puede aportar a una empresa de desarrollo de software (si su definición es adecuada), no supone un cambio en mi apoyo y creencia en la máxima agilista que dice que: “Los individuos y su interacción se encuentran por encima de los procesos y las herramientas”.

Son las personas las que finalmente hacemos buenos o malos los procesos, ya que participamos en su definición, en su mejora continua y en su ejecución.

Richard (Dick) E. Fairley realiza una reflexión sobre la hegemonía real que existe de las personas sobre los procesos (traducción libre): “Programadores motivados y con conocimientos pueden sobreponerse a procesos inadecuados, sin embargo procesos perfectos nunca pueden compensar malos programadores o malos gestores de proyectos”.

Lo ideal es que responsables técnicos del cliente, usuarios y equipo de desarrollo formen un equipo, cada uno con sus roles, pero un equipo, sin embargo en la mayoría de las ocasiones no se dan las circunstancias para hacer eso posible, de manera que por lo menos hay que intentar conseguir que cada grupo funcione como un equipo, que persigan un objetivo general común (obtener un sistema de información que satisfaga las expectativas del usuario, pero no a cualquier coste, sino al presupuestado y con los plazos fijados, siempre y cuando, claro está, ambos estén adecuadamente dimensionados a la naturaleza del proyecto) y existir unos mecanismos adecuados de comunicación y colaboración entre los mismos.

En el momento en que los objetivos individuales de las personas o de estos equipos se impone al objetivo general se produce la ruptura de la unidad, afectando primero a la comunicación y más adelante a la confianza.

Cada grupo puede tener sus propios intereses, pero se tiene que intentar que los mismos estén siempre detrás de los objetivos generales. Si hay problemas se deben exponer al grupo por si fuera necesario hacer algún ajuste en esos objetivos generales.

Lo cierto es que por regla general, cada uno de los grupos de personas de un proyecto de desarrollo de software suelen funcionar poniendo sus objetivos individuales a la altura de los objetivos generales (o por encima) y esa es una de las causas que provoca un incremento de la complejidad en los proyectos.

Lo peor de todo es que se sabe que ese funcionamiento es nocivo para los intereses generales del trabajo a ejecutar pero se prefiere que cada uno desempeñe su rol en el proyecto y que la comunicación solo se realice en momentos puntuales (sobre todo en fase de análisis en proyectos con ciclo de vida clásico o en cascada o cuando en modelos iterativos e incrementales se definen entregas con un tiempo de desarrollo amplio).

Si no existe comunicación dentro del equipo de proyecto o la misma no fluye de manera adecuada tendrá consecuencias en el resultado final del producto que se obtiene, esto es así porque no hay que dar por sentado que todos los integrantes del equipo de proyecto tienen la misma percepción del sistema o producto que hay realizar, de qué es lo realmente prioritario y cuál no, de cómo se va a organizar el trabajo, de cuáles son los plazos y de cuál es el nivel de calidad exigido en el proyecto.

Es necesario armonizar en lo posible la visión de los distintos integrantes del equipo de proyecto para la cual la existencia de comunicación, dando información precisa y adecuada, resulta fundamental para ello.

La comunicación no debe entenderse de manera exclusiva de arriba hacia abajo, sino que también debe ser fluida a nivel horizontal, para poder coordinar de manera adecuada los trabajos que se realizan, para consultar cualquier tipo de duda o para solicitar ayuda y de abajo hacia arriba para que se puede conocer en cada momento el estado real del proyecto y, además, puedan llegar las inquietudes del equipo hacia los niveles superiores.

Richard E. Fairley realiza una reflexión que refleja la importancia de una buena comunicación dentro de un equipo de proyecto: “La estructura de un sistema software refleja la estructura de comunicación del equipo que lo ha desarrollado”.

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”