A través de javahispano descubro este artículo. En él, Steve McConnell nos cuenta que en la construcción de un fuerte para sus crios ha acumulado un 200% de desviación con respecto a su planificación inicial. Una vez construido el fuerte, Steve analiza el por qué de ese desajuste entre lo planificado y la realidad, y como se dedica a escribir libros de planificación de proyectos, compara los errores de estimación que ha tenido con los que surgen cuando se trata con proyectos software.
Dados los antecedentes del sujeto, es más que probable que esta historia sea una fabulilla para prevenir a los pobrecillos responsables de desarrollo de posibles errores, aún así da en el clavo en puntos como el que dice que no se planifican todas las taréas, bien porque van apareciendo sobre la marcha o bien porque no se ha descompuesto el problema suficientemente,o que se quieren planificar taréas de las que se tiene un desconocimiento completo.
Sin embargo para mi la madre del cordero es el punto 4 (Substituting a target for an estimate) ,es decir, en vez de hacer una estimación de tiempos, se ajusta ésta a una fecha de fin de proyecto inamovible. En el ejemplo del fuerte nos cuenta que disponía de 7 días libres y los quiere emplear en hacer el fuerte y que casualidad que la planificación le cuadra justo. 7 días ni uno más ni uno menos. Finalmente concluye que se ha tomado todo el tiempo necesario puesto que no le interesaba comprometer la calidad de la construcción por el bien de su hijo, y al tratarse de un desafío personal, no suponia un gasto de dinero adicional que pudiera llevarle a abandonarlo.
En el mundo real lo que ocurre es que al intentar alcanzar una fecha imposible se compromete la calidad del producto y se hipoteca su mantenimiento, primero porque los errores saltan en cualquier momento y una vez en producción, estos son intolerables y hay que solucionarlos a mata caballo (poniendo parches más o menos chapuceros) y segundo porque al disminuir la calidad de código aumenta desproporcionadamente el tiempo que habrá que invertir a la hora de añadir una funcionalidad o solucionar un problema, máxime cuando el que mantiene o continúa el proyecto puede no formar parte del equipo que lo desarrolló. Con lo que también se añaden trabas a futuros desarrollos. Y la documentación… de la documentación mejor no hablamos.
¿Cuál sería entonces la manera de romper el triángulo (o tetraedro) de la gestión de proyectos, consiguiendo la misma calidad, aumentando las especificaciones iniciales y sin añadir ni tiempo ni dinero?.
Evidentemente no hay una fórmula mágica para esta resolver este problema, pero a botepronto se me ocurre:
- No inventar la rueda una y otra vez, si disponemos de un sistema de loggeo, una librería de criptografía o una librería para el manejo eficiente de hilos, sería estupido crearse uno propio. No sólo por el tiempo que podría llevarnos, sino porque la nuestra será más propensa a fallos, porque cualquiera que se incorpore al equipo conocerá la librería genérica y dificilmente nuestra implementación y un largo etcetera de motivos que aunque todos conocemos, muchas veces se nos olvida y nos liamos la manta a la cabeza.
- Compartir el conocimiento. Si durante la creación de una herramienta de análisis de señales, en encargado de presentarlas al usuario se convierte en un experto en Java 3D (por poner un ejemplo), una buena idea sería el montar un taller de Java 3D para compartir parte de ese conocimiento.
- Construir siempre pensando en la reutilización de código. Es verdad que construir una casa puede llevarnos un mes y si tenemos que construir otra pues otro, sin embargo en software se puede contruir una casa una y otra vez empleando un mes para cada una o construir una base en dos o tres meses con la cual podremos hacer casas como churros.
- Contar con equipos de trabajo que cooperen estréchamente y si disponemos de alguna herramienta de control de versiones mucho mejor, porque es tremendamente enriquecedor leer código de otras personas y además, si tu código lo van a leer tus colegas, ¿Verdad que te esforzarás en que sea limpio y elegante?.
Y como seguro que se me pasan por alto otras muchas cositas, voy a acabar como Mr McConnell, pidiendo la colaboración del lector para, entre todos, seguir mejorando…
¿Algún comentario?
