Interesante la siguiente reflexión de Steve McConnell en su libro “Rapid development”: “Un equipo existe cuando dos cabezas juntas son mejores que dos cabezas individualmente”.

Para llegar a esto es muy importante la actitud de las personas. Si se considera que gran parte de quienes trabajan contigo en el proyecto no son capaces de aportarte ideas estás perdiendo la posibilidad de descubrir nuevos puntos de vista y mejores soluciones que las que tenías pensadas inicialmente.

Trabajar en equipo no es fácil ya que los desarrolladores somos muy individualistas y muchas veces la presión dificulta todavía más este asunto, pero cuando se consigue funcionar de esa manera el rendimiento de las personas crece en gran medida, no solo porque todos sean capaces de aportar al colectivo sino porque se trabaja mucho más a gusto.

No se trata de improvisar, sino de ser flexible. Muchas veces los problemas en las arquitecturas y en el desarrollo de software son difíciles de resolver en tiempo de definición. No es cuestión de programar mediante prueba y error, de programar por permutación, siempre es conveniente reflexionar sobre la solución a aplicar tratando de reducir el nivel de abstracción con el que inicialmente se enfoca la solución.

Me parece muy interesante la siguiente reflexión de Christopher Alexander, Sara Ishikawa y Murray Silverstein en su libro “A Pattern Language”: “Todas esas decisiones de diseño detallado que nunca pueden ser resueltas con antelación en el papel, se pueden hacer durante el proceso de construcción”.

Esta cita está por encima de las metodologías o marcos de trabajo, es una forma de entender el desarrollo de software, de tratar de ser flexible y ser consciente de que no todo puede o debe ser predecible.

Peter Senge en su libro “The Fifth Discipline” realiza la siguiente reflexión: “No impulses el crecimiento, elimina los factores que limitan el crecimiento”.

Somos expertos en poner obstáculos, en crear resistencias, en hacer todo un poco más difícil. Muchas veces no se trata tanto de poner empeño en mejorar o de progresar (que efectivamente hay que ponerlo) sino de que te dejen hacerlo.

Como gestor de personas (y no hace falta estar muy arriba en una organización para que coordines el trabajo de otros) tienes la obligación de no empeorar su desempeño individual (en primera instancia, ya que además tienes que poner los medios para que puedan seguir creciendo) y hacer que funcionen de forma adecuada como colectivo. Esto parece fácil pero no lo es en absoluto.

Muchas veces los mimbres están ahí y solo hay que poner los medios oportunos para que puedan conseguir los resultados… o de eliminar las barreras o resistencias que los limiten.

Me parece muy interesante la reflexión que la Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides) realizaron en el libro Design Patterns: “Una clase es más reutilizable cuando minimizas los supuestos que otras clases deben hacer para utilizarla”.

Es cierto que si piensas demasiado en quién la puede utilizar y cómo, estás diseñando condicionado por ese motivo y en muchos casos se aplicarán supuestos más orientados a un desarrollo a medida de que probablemente reducirán su capacidad de ser utilizada por otras.

¿Es extensible esta reflexión al desarrollo de infraestructuras de mayor nivel? Mi opinión es que sí, pero en estos casos es necesario analizar los pros y los contras de esa solución más genérica y abstracta porque en este caso puede condicionar demasiado el diseño del sistema que hace uso de esa infraestructura y restarle posibilidades de ser más productivo y eficiente, pero también y desde otro punto de vista, si se particulariza demasiado es posible que al final tengamos diferentes componentes software muy parecidos replicados con determinadas características específicas y estemos reinventando la rueda.

A priori es complicado decir qué es mejor (refiriéndome a infraestructuras de mayor nivel) hay que analizar qué cometido hace ese componente software y que aporta que sea un elemento genérico o abstracto.

No se trata solo de tirar hacia adelante sino de hacerlo con intención buscando la mejor solución disponible en cada momento y eliminando resistencias que nos impiden progresar como debiéramos.

El día a día nos limita la perspectiva, solo nos deja ver los problemas que nos afectan en ese momento que, pudiendo ser importantes, pueden tener su origen en otras circunstancias que siguen vigentes tras su resolución.

La retrospectiva con su análisis de lo que hemos hecho, de dónde estamos y de en qué podemos mejorar nos permite recuperar la perspectiva, atacar a la raíz de los problemas y detectar desviaciones y riesgos que no tenemos presentes.

La retrospectiva no debe hacerse solo cuando parezca que la cosa no marcha sino que debe hacerse de manera periódica porque siempre es posible mejorar y porque no siempre van las cosas como parecen. Y siempre dispuestos a escuchar y a la autocrítica.

Para Tom DeMarco en su libro “Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency” (traducción libre): “Si identificas cualquier proyecto como libre de riesgos, o incluso relativamente libre de riesgo, cancélalo. Vas a necesitar los recursos y el plazo para hacer algo transformacional”.

Desde mi punto de vista, DeMarco trata de poner sobre la mesa la importancia de tener en cuenta los riesgos que se presentan en un proyecto de desarrollo de software y que van más allá de un análisis superficial del mismo.

Claro que hay proyectos con menos riesgos y donde se prevé una cierta estabilidad que facilite la gestión del proyecto, el trabajo de las personas y las relaciones entre los diferentes implicados, pero también lo es que la incertidumbre es una variable inherente en los proyectos de desarrollo de software y que se pueden producir situaciones que en un plazo corto de tiempo requieran hacer adaptaciones y ajustes sobre el proyecto y ahí es donde pueden aparecer problemas que afecten de manera sensible al mismo, entre otras cosas porque no se suele ir muy sobrado ni de presupuesto ni de tiempo y si el producto además se encuentra en producción, la presión que se recibe se incrementa considerablemente.

Es cierto que hay incertidumbre y circunstancias que no son sencillas de ser previstas pero también lo es que sí hay otras que pueden ser previsibles a corto, medio y largo plazo y ahí es donde entra la gestión de riesgos en los proyectos de desarrollo de software, en la capacidad de identificarlos y de tomar medidas o no en función del impacto del riesgo, del coste de las medidas, de la probabilidad de su ocurrencia, etc…

La identificación de riesgos debería comenzar desde incluso la etapa de conceptualización o definición del proyecto porque lo mismo, tras un análisis de los mismos se decide que lo mejor es no realizar el proyecto, buscar otras alternativas, plantearse alcances, presupuestos y plazos más realistas, etc…

Me parece muy interesante la siguiente reflexión de Donald Norman: “Cuando las cosas simples necesitan instrucciones, es una señal segura de un diseño pobre”.

Los usuarios y los desarrolladores somos expertos en complicar los sistemas de información, en lugar de centrarnos en lo que realmente resulta relevante se invierte un gran esfuerzo en funcionalidades complejas que no son necesarias (y que en muchos casos tienen una utilidad discutible en términos de coste/beneficio) o en ir complicando progresivamente funcionalidades que ya resuelven de manera solvente una problemática.

En lugar de pensar dos veces la solución o iterar desde lo simple para ir adaptando la idea a un resultado interesante se tiende a tomar decisiones que no solo dan lugar a una solución complicada sino que generalmente llevan consigo una deuda técnica que hace costoso hacer reajustes.

A posteriori se ve más fácil en qué aspectos del diseño y desarrollo del sistema nos hemos equivocado tanto usuarios como desarrolladores pero tenemos herramientas para tratar de darnos cuenta de que se han tomado decisiones erróneas en el propio proceso de especificación de las funcionalidades o historias de usuario o en la propia evolución del producto, para ello se debe tender hacia un enfoque iterativo incremental en el que mediante retrospectivas y análisis de los productos resultantes vayamos haciendo las adaptaciones oportunas para que el resultado que se va obteniendo se aproxime cada vez más a las expectativas.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.216 seguidores