archivo

Archivos diarios: enero 2, 2012

Tener reuniones en las que salen de manera sistemática ciertos problemas que habría que solucionar (ya sea en el proyecto, en el equipo de proyecto, entre los stakeholders, en el departamento, etc…) y en las que la única conclusión que se saca es que, efectivamente, algo hay que hacer, pero donde no se concretan cuáles son las medidas a realizar, quiénes se van a encargar de ellas, qué plazo se fijan y cómo se va a hacer un seguimiento de las mismas.

Es algo demasiado frecuente, ¿verdad?. Lo peor de todo no es que no se definan actuaciones sino que habrás quienes crean que realmente la reunión o la charla ha servido para algo, lo que hará que este antipatrón se vuelva a repetir una y otra vez.

Tenemos la tendencia optimista (e inocente) de que los proyectos van más avanzados de los que creemos y lo que es todavía peor, tendemos a exagerarlo aún más al usuario o a los clientes.

En desarrollos siguiendo planteamientos iterativos e incrementales con sprints cortos, el avance del proyecto entre los participantes en el mismo sean o no desarrolladores es más objetivo, ya que hay entregas con cierta continuidad y se sabe a ciencia cierta qué funcionalidades están cerradas, cuáles están aún abiertas y cuáles no se han tocado todavía.

Otra cosa es que a la dirección de cada stakeholder que probablemente tengan una relación muy superficial con el proyecto se les venda otra cosa.

En “desarrollos en cascada o siguiendo otras metodologías con entregas tardías, el problema es bastante más serio, ya que la posibilidad de error en el avance es mayor y el riesgo del optimismo exacerbado y/o el miedo a decir la verdad sobre el estado real del desarrollo situarán las expectativas en un lugar, probablemente, que no le corresponde.

Y a todo lo anterior hay que sumarle la incertidumbre inherente a todo proceso de desarrollo software.

¿Soluciones? Intentar en cada momento conocer de la manera más objetiva posible el alcance del proyecto, informar del mismo, tal cual, al cliente o al usuario, darle a conocer a los mismos los riesgos existentes en cada momento del proyecto e intentar llegar a una situación donde no se demoren en el tiempo las entregas.

Este antipatrón es una mala práctica de programación y se llega a él a través de la implementación de métodos que intentan ser lo suficientemente flexibles como para ser adaptado su comportamiento a multitud de circunstancias, sobrepasando el umbral de una mantenibilidad adecuada del mismo (elevado número de parámetros donde la mayoría de ellos a veces se usan y otras no, alta complejidad ciclomática, etc…).

Presenta una analogía con el antipatrón “objeto todopoderoso“, pero teniendo como protagonista a un método y no a una clase.