Existen modelos de referencia en el mercado, por ejemplo CMMi, pero lamentablemente no se han llegado a aplicar de una manera consecuente en muchas compañías.
CMMi inicialmente estaba pensado para soportar los procesos de proyectos de Desarrollo, lo que se ha venido en llamar la Constelación de Desarrollo (CMMi DEV). Pero el enfoque de esta constelación está orientado para dar respuesta al modelo de procesos necesario para la ejecución de grandes proyectos de desarrollo en responsabilidad. Esto introdujo un debate importante entorno al concepto del “just enough process”. Es decir, usar realmente aquellos procesos necesarios para la ejecución de las actividades que una organización necesita. Del mismo modo que si uno está enfermo por mucho que tome el bote completo de medicamentos no significa que va a sanar antes, incluso es posible que sea contraproducente, para el caso que nos ocupa será mucho más efectivo que una organización tenga un conjunto de procesos más limitados pero concretos, definidos y repetibles, que ser una organización que pueda disponer de todas las certificaciones oficiales pero que solo aplican a un conjunto muy reducido de sus servicios de desarrollo. Y esto es mucho más habitual de que uno se puede creer.
Todas estas situaciones desvelaron las carencias de la constelación de desarrollo para poder soportar, por ejemplo, los procesos que se requieren para la compra, gestión y seguimiento de servicios y productos a proveedores y desde una perspectiva estratégica. A tal fin el Software Engineering Institute publico la versión CMMI para la constelación de Adquisición (CMMi ADQ).
Esta constelación tenía un propósito claro de servir de referencia para aquellas organizaciones que no hacen desarrollos, pero si subcontratan todas las actividades del ciclo de vida, y su función es de gestión.
Pero este proceso de reflexión no ha parado ahí, dado que en general incluso dentro de las actividades de desarrollo, CMMI DEV no daba respuesta a absolutamente todas las casuísticas de desarrollo, sobre todo relacionado con las actividades de mantenimiento. CMMI DEV, como hemos mencionado sirve para los procesos que soportan la gestión de proyecto de cierto tamaño. Pero qué sucede si el 80% de las actividades de desarrollo de nuestra organización son tareas de mantenimiento de tamaño reducido. La experiencia ha demostrado que en estos casos los procesos de la constelación de Desarrollo de CMMI eran muy pesados y exigían mucho esfuerzo adicional de gestión, seguimiento e incluso documentación, que en realidad no eran necesarios.
¿Quién no ha escuchado a empresas u organizaciones certificadas en CMMi DEV decir que no son capaces de usar sus procesos para las tareas de mantenimiento de tamaño reducido? Incluso a veces es difícil por parte de ellos el reconocerlo. Pero la realidad nos demuestra, que es de sentido común pensar en que no se pueden usar procesos pensados para soportar ciclos largos de desarrollo en actividades que duran días. Tiene todo el sentido el concepto del “just enough process”, y es el punto de partido para la mejora de la productividad.
La consolidación del mercado de Outsourcing acelero esta reflexión del “just enough process”, que provocó que el SEI, a principio del 2009, publicase el CMMi pero su constelación de Servicios (CMMi SRV), que en origen puede sirve como modelo de referencia para cualquier actividad que se considere servicio, inclusive de cualquier sector, pero en el ámbito del desarrollo de Software ha dado una respuesta importante para todas aquellas actividades de desarrollo de software que no suelen ser de gran tamaño, pero si requería igualmente del uso de procesos, como es el mantenimiento y soporte de aplicaciones, que suele representar típicamente el 80% de los departamentos de desarrollo.
CMMi inicialmente estaba pensado para soportar los procesos de proyectos de Desarrollo, lo que se ha venido en llamar la Constelación de Desarrollo (CMMi DEV). Pero el enfoque de esta constelación está orientado para dar respuesta al modelo de procesos necesario para la ejecución de grandes proyectos de desarrollo en responsabilidad. Esto introdujo un debate importante entorno al concepto del “just enough process”. Es decir, usar realmente aquellos procesos necesarios para la ejecución de las actividades que una organización necesita. Del mismo modo que si uno está enfermo por mucho que tome el bote completo de medicamentos no significa que va a sanar antes, incluso es posible que sea contraproducente, para el caso que nos ocupa será mucho más efectivo que una organización tenga un conjunto de procesos más limitados pero concretos, definidos y repetibles, que ser una organización que pueda disponer de todas las certificaciones oficiales pero que solo aplican a un conjunto muy reducido de sus servicios de desarrollo. Y esto es mucho más habitual de que uno se puede creer.
Todas estas situaciones desvelaron las carencias de la constelación de desarrollo para poder soportar, por ejemplo, los procesos que se requieren para la compra, gestión y seguimiento de servicios y productos a proveedores y desde una perspectiva estratégica. A tal fin el Software Engineering Institute publico la versión CMMI para la constelación de Adquisición (CMMi ADQ).
Esta constelación tenía un propósito claro de servir de referencia para aquellas organizaciones que no hacen desarrollos, pero si subcontratan todas las actividades del ciclo de vida, y su función es de gestión.
Pero este proceso de reflexión no ha parado ahí, dado que en general incluso dentro de las actividades de desarrollo, CMMI DEV no daba respuesta a absolutamente todas las casuísticas de desarrollo, sobre todo relacionado con las actividades de mantenimiento. CMMI DEV, como hemos mencionado sirve para los procesos que soportan la gestión de proyecto de cierto tamaño. Pero qué sucede si el 80% de las actividades de desarrollo de nuestra organización son tareas de mantenimiento de tamaño reducido. La experiencia ha demostrado que en estos casos los procesos de la constelación de Desarrollo de CMMI eran muy pesados y exigían mucho esfuerzo adicional de gestión, seguimiento e incluso documentación, que en realidad no eran necesarios.
¿Quién no ha escuchado a empresas u organizaciones certificadas en CMMi DEV decir que no son capaces de usar sus procesos para las tareas de mantenimiento de tamaño reducido? Incluso a veces es difícil por parte de ellos el reconocerlo. Pero la realidad nos demuestra, que es de sentido común pensar en que no se pueden usar procesos pensados para soportar ciclos largos de desarrollo en actividades que duran días. Tiene todo el sentido el concepto del “just enough process”, y es el punto de partido para la mejora de la productividad.
La consolidación del mercado de Outsourcing acelero esta reflexión del “just enough process”, que provocó que el SEI, a principio del 2009, publicase el CMMi pero su constelación de Servicios (CMMi SRV), que en origen puede sirve como modelo de referencia para cualquier actividad que se considere servicio, inclusive de cualquier sector, pero en el ámbito del desarrollo de Software ha dado una respuesta importante para todas aquellas actividades de desarrollo de software que no suelen ser de gran tamaño, pero si requería igualmente del uso de procesos, como es el mantenimiento y soporte de aplicaciones, que suele representar típicamente el 80% de los departamentos de desarrollo.
Pero a pesar de todo, CMMi tiene que ser considerado como una guía para poder establecer los procesos que sean los suficientes y necesarios. No podemos considerar CMMi como un libro de cocina porque entonces fracasaremos en el intento.
No hay comentarios:
Publicar un comentario