|
Dudas: ¿Procesos y/o agilidad? |
|
|
|
03.09.2008 |
|
PSP (Personal software Process) es materia de estudio en muchos temarios de Ingeniería del Software, como modelo para mejorar la calidad y eficiencia de los ingenieros. CMMI es el modelo de evaluación y mejora para empresas de programación más renombrado del planeta...
Y el otro día Bruno, certificado en PSP, comentaba en el artículo "PSP (Personal Software Process) o como pasarse de rosca midiendo ":
"El problema real de PSP es que fue desarrollado por un ancianito como de 80 años (Watts Humphrey), que ignora la forma en que la tecnología ha evolucionado en los últimos años, es probable que hace dos o tres décadas, las ideas de Humphrey hubiesen sido útiles para la industria del software, pero en la actualidad son simplemente obsoletas e inadecuadas"
Me llamó la atención al leerlo. ¿Bruno tiene razón? ¿Se trata de mitos, de dinosaurios?
Dudas parecidas surgen al analizar los intentos de aplicar modelos de procesos (CMMI, PSP...) simultáneamente con modelos ágiles.
Si Humphrey (autor de PSP y de los modelos CMM - CMMI) afirma:
"La actitud típica en el software de empezar a construir pronto, y concretar después es errónea" (Winning with software an Executive Strategy, pág 68)
...
Entonces, ¿la estrategia de "bala trazadora" del desarrollo ágil, de entregar valor temprano y mejorarlo de forma continua es errónea?.
Los primeros construyen su teoría sobre el axioma "La calidad del producto la determinan la calidad de los procesos empleados", los segundos sobre el principio del manifiesto ágil: "preferimos el valor de las personas al de los procesos"
Y como afortunadamente, cada uno pensamos de forma distinta... las opiniones para todos los gustos, están servidas :-)
|
Muy interesante el debate que presentas.
En el número de Julio/Agosto de la revista IEEE Software hay un articulo titulado "Essentials of Software Process" de Hakan Erdogmus que habla de las caracteristicas esenciales de los procesos de software: human-centricity, technical orientation, discipline,
pragmatism, empiricism, experimentation, and
value orientation.
Opino que son estas caracteristicas las que cada "religión", agilistas hasta los dinosaurios y los intermedios, manipulan en pos de su visión de cómo producir software. Ambos persiguen lo mismo, producir mejor software pero la bala de plata no existe y lo que manda es el contexto. Cada uno desde su contexto de conocimientos y experiencias tiene razones para justificar su discurso. Sería interensante modelar los contextos y aproximar qué caracteristicas han probado ser mejor para cada uno de ellos.
Saludos,
Adrian