Steve McConnell. Un equipo

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.

Christopher Alexander, Sara Ishikawa, Murray Silverstein. Flexibilidad, ¿por qué no?

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. El crecimiento

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.

Gamma et al. Abstracción

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.

Desarrollo de software. Los beneficios de la retrospectiva

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.

Algunas reflexiones sobre el riesgo en los proyectos de desarrollo de software

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…

Donald Norman. El diseño y lo simple

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.

Ron Jeffries, Ann Anderson, Chet Hendrickson. El necesario enfoque iterativo y evolutivo del software

Ron Jeffries, Ann Anderson y Chet Hendrickson en el libro «Extreme Programming Installed» hacen la siguiente reflexión: «Si tu cliente sabe ahora exactamente lo que quiere, y si en el momento en que haya terminado todavía va a querer lo mismo, puede ser la primera vez en la historia del software que esto ha sucedido. Probablemente habrá un premio para ti en algún sitio».

Está bien que estos autores lo pongan en su libro pero probablemente tu propia experiencia te hará llegar a la misma conclusión.

La aparición de la agilidad y métodos de trabajo potencialmente ágiles (siempre os digo que realmente lo que la hacen ágil o no es la actitud de las personas en el proyecto) no fue un capricho, sino una respuesta a unos métodos de trabajo que no respondían a una realidad que se repetía de manera insistente en los proyectos de desarrollo de software y que se basaba generalmente en el ciclo de vida tradicional.

Pero las metodologías, marcos o estrategias de desarrollo son solo herramientas, es necesario entender el fundamento del enfoque iterativo incremental y se puede resumir perfectamente en la cita en la que se basa este artículo.

Los usuarios pueden tener claro lo que tienen (cosa que está por ver) e incluso que el contexto del proyecto se pueda mantener de forma más o menos estable y no influya excesivamente en la línea de desarrollo del producto pero lo más probable es que los usuarios vayan haciendo ajustes en su visión del producto conforme se trabaja con más detalle en el mismo y conforme van viendo versiones del producto mientras se está desarrollando o mientras se entregan sprints y eso es debido a que es muy difícil abstraer lo que se cree que se quiere, a algo concreto.

Si pese a que sois desarrolladores habéis sido usuarios (incluso vuestros propios usuarios) os habréis encontrado muy probablemente con situaciones en la que vuestra idea inicial del desarrollo ha sufrido cambios sensibles.

Gestión de proyectos de cerca y de lejos

Los proyectos se pueden llevar más de lejos o más de cerca. Personalmente prefiero realizar un seguimiento más directo del proyecto y tener un mayor contacto con el área usuaria, con el equipo de proyecto y otras áreas implicadas en el proyecto.

Es posible que tengas que realizar una gestión del proyecto desde más distancia debido a que tal vez la carga de trabajo que tengas asignada sea excesiva, ante ese tipo de circunstancias lo más que se puede hacer es tratar de estar lo más implicado posible y saber muy bien dónde y cómo priorizar el esfuerzo, ya que prácticamente lo que te tocará es ir apagando fuegos.

Tener a un jefe de proyectos sobrecargado presenta sus inconvenientes porque los separa de lo que se cuece en los proyectos. A veces los informes que te envían o los números del proyecto te pueden dar una idea, pero la verdad no está ahí, sino en lo que pasa en el día a día.

Esa mayor implicación traerá consigo ir más lejos porque te permite de primera mano atender a las necesidades del proyecto, sentir más empatía con tu equipo y el resto de stakeholders, tomando decisiones y realizando acciones que no harías si no te sintieses parte del proyecto.

Desarrollo de software. Consensuar la solución técnica

Un problema que se suele producir bastante a menudo es que se desarrolle un determinado producto software sin tener en cuenta determinadas restricciones o problemáticas a nivel de base de datos, servidores o incluso determinadas políticas en cuanto a cómo debe realizarse la entrega.

Muchas veces esas restricciones, problemáticas y normativas están escritas incluso con detalle y también se cuenta en numerosas ocasiones con la experiencia de trabajar en esos entornos pero si se tienen dudas, por ejemplo, porque se trate de un desarrollo que presenta diferencias significativas con respecto a lo que es común instalar o que tenga unas necesidades de proceso de datos, almacenamiento o infraestructura que puedan resultar necesarias analizar, es fundamental reunirse con las partes implicadas.

Tal vez pueda ser complicado llegar a determinados acuerdos o consensos pero mucho mejor resolver los problemas en este momento que encontrarlos cuando ya se ha invertido una parte importante en el producto o cuando esté en producción y esas necesidades no funcionales no puedan ser cubiertas de manera satisfactoria con la infraestructura existente.

Además, servirá para hacer equipo porque las personas de los departamentos de base de datos, de sistemas, etc… valoran que se les tenga en cuenta en ese proceso de toma de decisiones, ya que cuando existen problemas en el sistema también les afecta a ellos.