Parece más fácil la evaluación de la calidad de un producto software si la asociamos con la calidad del proceso de desarrollo de software, bajo la creencia de que si se sigue un determinado procedimiento de manera adecuada, necesariamente obtendremos un producto de calidad.
Con esta visión, se le da más importancia a un instrumento (porque un proceso no es más que eso) que al resultado del mismo. ¡Cuánto daño ha hecho, está haciendo y seguirá haciendo esto al desarrollo de software!.
Y eso que la idea de partida no era mala, ya que en origen el desarrollo de software era heroico: personas que se remangaban, cogían los manuales y trataban como fuera de conseguir los resultados que estaban buscando (el desarrollo de software decenas de años después sigue siendo todavía muy así, demasiado así). Sin embargo ese modelo inicial se tambaleaba conforme se incrementaba la complejidad del proyecto y el trabajo implicaba a diferentes personas o grupos, dando lugar a unos esquemas de trabajo caóticos que afectaban al producto final.
Por ese motivo se trató de sistematizar no solo el proceso de desarrollo sino también otros campos como el de su gestión. Supuso un primer paso, tratando de dar un orden al caos, tratando de conseguir, además, una cierta repetibilidad en los resultados (si esto ha funcionado bien aquí, ¿por qué no va a funcionar de manera adecuada en otras situaciones?).
Y este fue el esquema predominante desde entonces y lo sigue siendo ahora, aunque exista una división clara entre los defensores de los enfoques clásicos y los partidarios de la agilidad, la mayoría de estos últimos, entre los que me incluyo, con la vehemencia y radicalidad de todo converso (tal vez como forma de curar las heridas y los malos momentos vividos y que seguimos viviendo, porque no siempre se puede desarrollar como se quiere, con los enfoques clásicos).
Jummp 