Facts and Fallacies of Software Engineering

A continuación les voy a poner un extracto de un libro que me pareció interesante compartir con ustedes. El autor tiene varios años de experiencia desarrollando software y cuenta lo que ocurre generalmente en proyectos de software.

El libro es "Facts and Fallacies of Software Engineering". (ISBN 0-321-11742-5)

Aquí va un extracto del libro (en color azul):

//----------------------extracto--------------------------------------

...Se supone que.... las personas son mas importantes que la tecnología.... ..
...pero en la realidad ocurre que.... las empresas desarrolladoras de software se esmeran en usar y adoptar metodologías tipo CMMI (Capability Maturiy Model) para que la empresa tenga cada vez mejores "procesos y funciones" al punto en que "las personas pueden intercambiarse" pero la metodología se mantiene como un modelo a seguir. Felizmente algunas empresas ya se han dado cuenta de que un buena metodología no va a lograr que una persona con poca habilidad haga bien su trabajo y por eso se preocupan en aplicar más bien el "PEOPLE CMM" (People Capability Maturity Model) http://www.sei.cmu.edu/cmm-p/version2/ que está enfocado al desarrollo de las personas, administración del conocimiento, trabajo en equipo, .etc. y todos esos términos que las empresas curiosamente "utilizan para promover la calidad de equipo humano que poseen" cuando presentan sus propuestas de ventas :)

...Se supone que.... la estimación de algo se hace cuando sabes que es ese "algo"
...pero en la realidad ocurre que... la estimación de los proyectos de software se hace lo más temprano posible en el proyecto... cuando se sabe lo menos posible sobre el proyecto a realizar....

...Se supone que.... la estimación (de proys. de software) se debería hacer por gente que sabe de software (quien mejor para saber del software que los programadores?)
...pero en la realidad ocurre que... la estimación se realiza por un conjunto de personas, algunas de las cuales ni siquiera son del área de ingeniería de software: marketing, usuarios, .etc.

...Se supone que.... a medida que avanza un proyecto y nos damos cuenta que la estimación no es realista, actualizamos los valores de la estimación para reflejar los nuevos tiempos...
...pero en la realidad ocurre que... una vez que ya se sabe que las estimaciones estuvieron mal y además se sabe quienes hicieron la hicieron mal.... le echan la culpa a los programadores porque no cumplieron a tiempo su trabajo...

...Se supone que....una vez que ya nos dimos cuenta de que las estimaciones son incorrectas, que no se actualizan a la realidad y que no podemos confiar en ellas... deberían ser tratadas como un dato sin importancia para el proyecto...
...pero en la realidad ocurre que... las estimaciones son lo MAS importante del proyecto!... TODO se mide con ellas....en las reuniones para revisar el avance del proyecto a la gerencia sólo le interesa saber si se cumplió con el hito X en tiempo fijado Y o si se avanzó o se retrasó en Z tiempo.

Hablando de las estimaciones.... hice este experimento: le di a un programador una tarea, le dije que la programara y a propósito le di tiempo insuficiente para completarla. Resultado del experimento: La persona lo hizo! pero el programa no tenía suficiente calidad ni tenía todas las opciones que le pedí. Lo interesante es que, la persona no se preocupó por el tiempo que le di sino que en todo momento hizo su mejor esfuerzo y "automáticamente" quitó calidad al programa con tal de cumplir con la fecha. Conclusión: en el problema de la estimación todos son cómplices.

...Se supone que...si un proyecto se retrasa, todos se ponen tristes y se preocupan...
...pero en la realidad ocurre que...al personal técnico (desarrolladores) poco le importa el retraso; pues generalmente ocurre que el proyecto se retrasó porque en la estimación no consideraron el tiempo que tomaron los desarrolladores en resolver complejos algoritmos y crear interfaces nuevas con tecnología nueva (y todos los retos tecnológicos que el proyecto requería pero no fue tomado al momento de estimar -adivinen por qué. Conclusión: los desarrolladores están felices porque el proyecto es un "reto tecnológico".

...Se supone que...COBOL es un lenguaje horrible y obsoleto y no se debería usar más...
...pero en la realidad ocurre que...su uso sigue creciendo día a día...

1 Response to Facts and Fallacies of Software Engineering

5 de agosto de 2008, 8:57

Henry, muchos de esos problemas son enfrentados por los métodos ágiles de desarrollo, las cuales valoran a los individuos y la colaboración entre los mismos por sobre los procesos y las herramientes. Asimismo exigen, entre otras cosas, que los desarrollares realicen las estimaciones. Es más, la estimación es algo que se realiza periódicamente a lo largo de todo el proyecto.

Otra asunto clave que mecionas es la calidad. Los métodos ágiles como Scrum o XP son claros en promover la entrega de software de calidad desde un inicio y en intervalos regulares. Sacrificar calidad en aras de "acabar a tiempo" debe ser considerada una decisión de negocio pues produce una deuda técnica que afecta la mantenibilidad y extensibilidad del producto de software en futuros releases.