Luego de un gran período de silencio, de dedicarme a recuperar las energías luego de un año intenso y de recuperar un poco de mi salud, he vuelto a las andanzas y a la inspiración para escribir.
Pero bien, retornemos a nuestra tónica acostumbrada.
Recientemente, mientras estaba en esta recuperación necesaria, volví un poco a las preguntas canónicas del desarrollo: ¿Cual es la mejor manera de hacer las cosas? ¿Cómo evitar los problemas de la archiconocida Crisis del Software? ¿Cómo cubrir con las expectativas de tiempo y costo sin tener que llegar a la pérdida de la salud, de la motivación o las energías?. Estas preguntas son habituales en aquellos que hemos presenciado proyectos desastrosos y deseamos evitar presenciarlos nuevamente.
Un poco con esto me recuerda el caso de
Fred Brooks, quien luego de pasar por un episodio desastroso con la administración del proyecto del OS/360 en IBM, decidió dedicarse al mundo académico y a escribir ensayos clásicos de ingeniería de software como
The Mythical Man-Month y
No Silver Bullet.
No me parece absurda la conclusión de que luego de experiencias duras en el desarrollo de software comenzamos a pensar en mejores técnicas de desarrollo, en reforzar los procesos usados; en general, en Ingeniería de Software y en como implementar una metodología de desarrollo reforzada para evitar. Claro que no existe la panacea (idea esta dibujada en el mencionado ensayo
No Silver Bullet), pero igual uno espera conseguir un mecanismo para disminuir riesgos en el futuro.
La metodología de desarrollo de software es un determinante del éxito del proyecto, de esto no me queda la menor duda. No obstante, hoy por hoy no existe la metodología que lo resuelve todo; una metodología no se va a adaptar completamente a todos los distintos casos, ni podemos esperar que una receta de cocina vaya a funcionar para todos los imprevistos y todas las situaciones inesperadas que la
Ley de Murphy va colocando a lo largo de nuestro trayecto. Lo que les puedo asegurar es que un proyecto que no define su metodología (sus actividades, sus prácticas, sus técnicas, sus herramientas y sus estándares) va más derecho al fracaso del proyecto que a su éxito. Recordemos que un proyecto no es exitoso sólo porque su producto funcione, sino que hace falta que cliente, equipo de desarrollo y producto puedan (y/o quieran) seguir avanzando en sus relaciones de manera fructífera.
En mi humilde opinión, una metodología debe aportar los líneamientos necesarios de ingeniería que aporten valor sin ralentizar en demasía el avance y debe permitir el nivel suficiente de libertad para permitir que los artistas de software expresen su creatividad sin mayores ataduras.
Próximamente, hablaremos de las técnicas más útiles encontradas en diferentes metodologías.
