El Arte del Desarrollo de Software
Me he revuelto en mi asiento leyendo un par de posts acerca del Desarrollo de Software o Ingeniería de Software y su control y gestión a propósito de una publicación de Tom DeMarco, un antiguo gurú en esto del Software, que se retracta de la visión sobre la gestión de los proyectos de software que escribió hace muchos años, especialmente en la parte de control y medición.
El Control de Software, dice Tom DeMarco, cuesta dinero y esfuerzo. Para un proyecto de 1 millón de dólares que va a producir 1.1 millones de facturación, el control es importatisimo. Para un proyecto de parecido coste que va a producir 50 millones, el control no es tan importante. Entonces: deberíamos enfocarnos sólo en el segundo tipo de proyectos. No dice que el control y la medición no sean necesarios, pero es cierto que en la mayoría de los proyectos, sobretodo en los mejores, el control, teniendo en cuenta el coste que tiene en todos los sentidos, puede no ser importante.
Es evidente que el control es necesario en el mundo actual, los proyectos de software se integran en el mundo empresarial… pero hay que saber qué hay que controlar, y cuanto menos sea necesario ese control, mejor.
Quizá está en los genes del ser humano querer controlar. O quizá esté en el propio raciocinio el miedo a perder el control de lo que le rodea que se convierte en obsesión en ciertos individuos. Quién no ha visto alguna vez al típico jefazo, normalmente sin idea de software ni intención de tenerla, perdiendo su propio control y blasfemando acerca de los desarrolladores.
Hemos tratado de encapsular los proyectos de software bajo los parámetros clásicos de gestión de proyectos, tiempo, coste y calidad, nos hemos roto la crisma y posiblemente haya sido un error y hayamos perdido el tiempo miserablemente.
Echando la vista atrás, viendo los proyectos en los que he participado y cuáles han sido los más exitosos, me salen una serie de factores básicos comunes que hablan de gente más que de otra cosa:
- Contar con buenos desarrolladores a los que les guste su trabajo, mejorar, aprender, disfrutar de la tecnología.
- Contar con un ambiente en el que haya confianza entre los desarrolladores y la gente de negocio, capaces de comunicarse y entender posiciones.
- Contar con desarrolladores que sean capaces de ver más allá del código, que entiendan los objetivos finales y se impliquen con ellos.
- Contar con gente de negocio que sepan comunicar esos objetivos y ser flexibles a cambios según avance el desarrollo de software, abiertos a encontrar limitaciones y soluciones alternativas.
- Contar con desarrolladores con experiencia, que sepan estimar esfuerzos, expectativas, anticipar problemas, en base muchas veces a “feeling” y experiencias pasadas.
- Contar con gente de negocio que se preocupe por entender la tecnología, con experiencia desde el punto de vista de usuario.
En resumen, se me ocurre que un proyecto de software está destinado al fracaso si:
- El coste y tiempos de desarrollo es crítico para el éxito del proyecto.
- Hay que ahorrar a toda costa, mejor becarios y personal junior a tutiplén que gastarse el presupuesto en gente buena.
- No hay tolerancia a tiempos y margen.
- No hay interés por entender la tecnología.
Realmente el control de software, la predicción precisa y la anticipación del resultado final del producto, es ciencia ficción, como se concluye en el artículo. Siempre tendrá un componente experimental. Algunos de mis profesores de gestión de proyectos, admitían, como hace Tom DeMarco, que a lo mejor han acertado una o dos veces con la planificación de un proyecto en toda su vida (esto se llama casualidad).
Cada día estoy más convencido de que el desarrollo de software se acerca más a un arte. Nunca dos desarrolladores escribirían el mismo código, posiblemente ni parecido. Nunca se acertará en el tiempo ni el coste, y la calidad dependerá más de quién lo hace y las circunstacias del momento. ¿No suena esto a algo artístico?. Ya lo dice el eslogan de Wordpress: Code Is Poetry.
De recomendable lecura las reflexiones de Jeff Atwood y Ricardo Galli
Monday, August 3rd, 2009
No concibo un departamento de tecnología o un proyecto medianamente serio y organizado sin un seguimiento de tareas e incidencias. Hay algunas herremientas, denominadas issue trackers, que sirven a este propósito. La herramienta sirve a un método o una forma de organizarse. Podrían ser post-it pegados en la pared en los que cada desarrollador pusiese el estado de la incidencia… no es lo mejor, pero preferiría eso a no tener nada.
La frustración es muchas veces una constante cuando se trata de abordar un proyecto de software, ya sea un proyecto grande o pequeños desarrollos, ya sea interno o externo. Es sorprendente que en un área aparentemente tan predecible, a base de combinaciones de unos y ceros, sea tan difícil hacer predicciones precisas, tanto en tiempo como en coste.