No es fácil encontrar procesos de desarrollo de software que parezcan ser diseñados por personas que desarrollen software, al menos en mi experiencia personal. Sin embargo, me he cruzado con el caso prácticamente inverso: procesos diseñados por personas que no les atraía en lo más mínimo desarrollar software o aprender algo sobre el tema.En estos casos, la línea de pensamiento parece ser la siguiente: "Aquellas personas a las que nos les atrae desarrollar software (diseñar una solución, escribir código, testearlo) pueden dedicarse a otra área, como la definición de procesos". De esa manera, se puede evitar la necesidad de conocer y dominar aspectos que hacen posible la construcción de software, porque se puede cubrir el vacío con conceptos abstractos o genéricos como variación, estabilidad de proceso, causas especiales y causas comunes de variación, entradas, herramientas o salidas.
Para hablar sobre estos temas no hace falta conocer de software. De hecho podríamos hablar de manufactura de tornillos y aplicar estos mismos conceptos. Por esta razón, considero que la aplicación directa de estos conocimientos generales carecen de gran valor si no tienen detrás un análisis que busque mejorar una realidad en un ámbito definido. Muchas veces este análisis no es realizado, o las personas que lo hacen no tienen los conocimientos necesarios para hacerlo adecuadamente. Esa situación indefectiblemente conlleva inconvenientes.
Philip Armour analiza este y otros problemas relacionados a los procesos de desarrollo de software en The Laws of Software Process: A New Model for the Production and Management of Software. Tiene varias ideas interesantes para tener en cuenta:
En muchos casos, los procesos [de desarrollo de software] son ideados por ingenieros de proceso, pero frecuentemente ellos no son las personas que están creando el sistema. Estos ingenieros incluso son separados para definir estrictamente el proceso. Los desarrolladores están demasiado ocupados haciendo el trabajo y, a veces, evitando aplicar el proceso. Cuando un proceso es desarrollado por personas que de hecho no lo utilizan, pasan varias cosas:
- Los ingenieros de proceso pierden de vista la aplicación detallada que hacen un proceso valioso.
- Sin tener acceso al detalle, ellos están forzados a trabajar mas a un nivel meta, que es fácil para ellos porque no tienen que desarrollar real conocimiento del dominio dentro del proceso.
- Como ellos usualmente no aplican el proceso que están ideando, pueden perder la habilidad de validar si el proceso es realmente útil.
- Casi inevitablemente, crece la mentalidad de que si el proceso es bueno, entonces mas proceso debe ser mejor.
- El proceso toma importancia para estas personas, no por el valor que trae, sino porque es la razón por la cual tienen trabajo.
- La definición del proceso es dejada a un nivel descriptivo, en forma de libro, no de manera ejecutable... Esto deja el trabajo real de hacerlo funcionar a los desarrolladores usando el proceso. Este es un lugar muy seguro para estar - para los ingenieros de proceso. Si el proceso funciona, el grupo de proceso puede reclamar el crédito; si no funciona, la culpa puede ponerse sobre los desarrolladores por no aplicarlo apropiadamente.
