archivo

Archivo de la etiqueta: CMMI

Es el siguiente escalón en los niveles de madurez de CMMI. Del caos del nivel 1, se pasa al nivel 2 en un modelo donde se administran/gestionan procesos orientados a proyectos y de ahí al nivel 3 donde los procesos tienen una orientación a nivel del departamento o de la organización. El siguiente nivel de CMMI pretende la gestión cuantitativa de los procesos que se han definido de manera que los mismos puedan ser predecibles (hacia dónde vamos) y analizables de manera cuantitativa (dando una mayor objetividad a su análisis).

Si en el nivel 2 teníamos un área de proceso de medición y análisis, en este caso se trata de aplicar un concepto similar pero un amplio abanico de procesos, interdependientes muchos de ellos y que se aplican al conjunto de proyectos de desarrollo en los que participa la organización.

El propio control del correcto desempeño de las áreas de proceso de nivel 3 se podría considerar suficiente, sin embargo es en este nivel donde se le da carta de naturaleza a la administración y gestión de las mismas.

Por tanto, en este nivel se utilizarán estrategias y herramientas que permitan obtener el desempeño/rendimiento real (presente) de las áreas de proceso implantadas y los productos y servicios que ofrece la organización, así como su comportamiento futuro.

Del caos del nivel 1 de CMMI, al nivel 2 donde se gestionan/administran determinados procesos, en donde por lo menos a nivel de proyecto se quiere establecer un orden y de ahí al nivel 3 donde los procesos tienen un ámbito de aplicación organizativo (se pretenden eliminar las repúblicas independientes, que tanto daño hacen a las organizaciones que desarrollan software o que tienen que gestionar este tipo de servicios) y en donde se pretende normalizar el proceso de desarrollo de software.

La tendencia de las organizaciones, conforme van creciendo o cuando ya han llegado a un número de empleados y/o proyectos que no se puede gestionar de manera adecuada (no hace falta especificar un número concreto de unos o de otros, ya que un gestor de cualquier entidad de este tipo y si me apuráis, cualquier empleado, se da cuenta cuando la maquinaria no funciona y para verlo no es necesario revisar resultados económicos) debería ser establecer un modelo organizativo orientado al proceso.

Los procesos pueden gustar o no, pero permiten definir un ámbito de trabajo, siempre es mejor esto, que el hecho de que cada cual haga su guerra por separado y se pierda la visión de que la empresa puede ser un conjunto de piezas distribuidas, pero siempre atendiendo a un interés común.

La clave de la implantación de CMMI o de cualquier otro tipo de modelo orientado a procesos se encuentra en ajustarlo a la realidad de la organización donde se implanta, a su contexto y a su negocio. Es decir, no se puede implantar un modelo que no se pueda cumplir, un modelo a ciegas que no tenga en cuenta qué es la organización, qué puede asumir y hacia dónde se va a dirigir. Precisamente éste es uno de los factores de fracaso de la aplicación de este tipo de modelos, definirlo como si la organización no existiera.

La aplicación de CMMI no asegura que los proyectos salgan mejor, ya que el éxito o el fracaso de los proyectos trasciende a los procesos, pero sí que determina un buen punto de partida y habla bien a las claras de cómo es la organización de la entidad que desarrolla el software. Por eso no es de extrañar que tanto administraciones públicas, como organizaciones privadas tengan cada vez más en cuenta la adecuación de las entidades a las que contratan servicios de desarrollo de software a modelos organizativos orientados a procesos basados en algún estándar o modelo reconocido internacionalmente.

Como mínimo una entidad debe aspirar a tener el nivel 3, si bien, en función de su estado actual, podría optar por pasar primero por el nivel 2 y aplicar algún área de proceso de nivel 3. ¿Se requieren muchos cambios? Se requieren cambios y si son muchos o pocos, significativos o no, depende de cómo la organización funcione actualmente y también dependerá de la definición de un modelo de procesos acorde a las necesidades y naturaleza de la organización. Desde mi punto de vista se ve CMMI nivel 3 como un muro insoslayable y sin embargo, un simple vistazo a sus áreas de proceso, permite darnos cuenta de que el monstruo no es tan fiero como lo pintan.

A continuación, se enumeran las áreas de proceso de nivel 3.

CMMI-DEV

Desarrollo de requisitos.
Solución técnica.
Integración de producto.
Verificación.
Validación.
Enfoque en el proceso organizativo.
Definición de proceso organizativo.
Formación organizativa.
Análisis de riesgo.
Análisis de decisiones y soluciones.
Gestión de proyectos integrada.
Gestión de proveedores integrada.

CMMI-DEV + IPPD

Equipos integrados.
Ambiente organizacional para la integración.

Dentro de CMMI-DEV que es el modelo de madurez de CMMI orientado al desarrollo de software existe una división en dos modelos, lo que sería el CMMI-DEV tal cual o el CMMI-DEV + IPPD (Integrated Product and Process Development).

La diferencia entre ambos modelos se encuentra en la aplicación o no de las siguientes áreas de proceso de nivel 3, las cuales son exclusivas de IPPD:

Equipos integrados.
Ambiente organizacional para la integración.

La aplicación de IPPD puede proporcionar además un enfoque adicional a las distintas áreas de proceso de CMMI-DEV, de manera que si la propia aplicación del nivel 3 ya proporciona una visión del proyecto a nivel organizacional, IPPD sube un peldaño esa visión, al tener como objetivo una mayor integración entre los equipos de trabajo, los propios empleados y su alineación con la cultura definida en la organización.

El área de proceso de Equipos Integrados del nivel 3 de CMMI requiere para poder efectuarse de manera efectiva de una estrategia a nivel organizativo que favorezca la alineación de los empleados con los objetivos de la organización, a sentirse parte de la misma y no un número más, a que sean conscientes de que la clave para obtener resultados no se centra exclusivamente en el esfuerzo individual sino que es necesario el trabajo en equipo y el trabajo en el colectivo (más allá del grupo de personas con las que compartes una actividad). En definitiva a definir una cultura y visión de empresa que sea compartida por aquellos que pertenecen a ella.

Todo esto requiere la definición de esa cultura de empresa y los mecanismos para que la misma sea conocida por los empleados y más allá de eso, para que esté integrada dentro del día a día de los trabajadores. Esa cultura de empresa, deberá tener como aspecto de gran interés el fomento de trabajo en equipo, para ello debe proporcionar y promocionar un ambiente integrado de trabajo (pasar de las buenas palabras a hechos que fomenten y permitan la colaboración).

Toda maquinaria requiere de engranajes, este área de proceso tiene en cuenta que para que la cultura de empresa prevalezca es necesario de personas que dinamicen su funcionamiento, que lideren las actividades que permitan mantenerla.

El equipo de proyecto, el proceso para conformarlo, para seleccionar los roles adecuados, para orquestar la posible colaboración entre diferentes equipos. De esto trata este área de proceso del nivel 3 de CMMI.

En demasiadas ocasiones se le presta muy poco atención a la composición del equipo. A veces parece como si la selección de los integrantes se hubiera echado a suertes.

Esto es un error. El equipo debe ser el mejor posible, teniendo en cuenta el contexto de todos los stakeholders. ¿Por qué digo que debe ser el mejor posible y no que el mejor (a secas)? Pues porque no siempre van a estar disponibles para trabajar en el proyecto en el momento adecuado las personas que mejor se ajusten al alcance del mismo (estarán asignadas a otros proyectos, tareas o trabajos y no es posible o conveniente su participación en este, el presupuesto del proyecto no permite que determinados perfiles puedan participar en él, etc…), ahora bien, esto no debe ser un obstáculo para renunciar a conformar el mejor equipo que sea posible.

En este proceso de CMMI el equipo de proyecto no es solo el equipo de desarrollo, sino también está formado por personal de las distintas áreas involucradas cada uno de los cuales con el rol, dedicación y poder de decisión suficiente (en su ámbito de actuación).

El alcance de este proceso comienza desde la propia metodología para identificar las tareas que debe realizar el equipo de proyecto y los conocimientos y habilidades que se necesitan para su ejecución. Con esta información y el conocimiento del personal que puede estar a disposición del proyecto, se realizaría la selección de los integrantes.

Una vez conformado el equipo lo siguiente es definir las actividades que permiten fomentar una visión compartida de los objetivos a conseguir y del método para conseguirlo (comunicación, trabajo en equipo, etc…), dar a conocer a cada componente su rol y responsabilidades, establecer los procesos necesarios para coordinar el funcionamiento del equipo y por último definir los procedimientos para poder establecer relaciones de colaboración con otros equipos de trabajo (para ello además de existir determinados procesos horizontales, requiere tener un conocimiento de las tareas y proyectos que se están realizando en la organización o en los que colaboran algunos de los interesados).

El nivel 3 de CMMI extiende el área de proceso del nivel 2 denominada Gestión de acuerdos con proveedores.

En el anterior nivel el objetivo principalmente era gestionar esos acuerdos, sin olvidarnos del proceso que permite llevarnos a los mismos, de la adquisición de esos productos o servicios y de la aceptación de los mismos.

En este nivel los objetivos son los mismos aunque con un enfoque más formal, más estratégico y con una visión más allá del alcance de un proyecto (o de un conjunto de ellos).

Este área de proceso se ocupa desde el método para la analizar proveedores potenciales de productos o servicios, evaluarlos y seleccionarlo hasta la verificación del cumplimiento de los compromisos fijados con los mismos y la posibilidad de revisar, si fuera necesario, los acuerdos adoptados con determinados proveedores.

En una organización, incluso en aquellas orientadas principalmente al desarrollo de software existen diferentes planes que se ejecutan en paralelo a los diferentes proyectos en los que se esté trabajando: plan de mejora continua de los procesos, plan de marketing, plan de comunicación interna, plan de análisis de costes, etc…

Un proyecto que se lleva a cabo no puede estar de espaldas a estos otros procesos porque insisto, los proyectos no son procesos independientes (fundamento del nivel 3 de CMMI y que ya comenzamos a tratar en el ámbito de la gestión de proyectos en el artículo anterior) sino que están integrados con otros muchos relacionados directa o indirectamente con el desarrollo de software o con la propia gestión organizativa. Por tanto, es necesario tenerlos en cuenta en la gestión del proyecto, siendo necesario tener bien identificados los interfaces a través de los cuales se envía y recibe información para evitar que llegado el momento no se conozca a quién dirigir unos determinados datos o no pueda recibir aquellos que sean necesarios para la integración con el conjunto de planes y procesos organizativos.

Conforme vayamos mirando de más arriba a los proyectos nos daremos cuenta cómo existen interesados en diferentes áreas dentro de la organización y del cliente que participan en diferentes proyectos en los cuales los equipos de proyecto pueden ser distintos o tener pocos componentes en común. Esta circunstancia recomienda igualmente una gestión integrada de las relaciones con los interesados, ¿cuántas veces se ha hecho llegar un mensaje contradictorio a un cliente desde personas distintas dentro de un equipo de proyecto o entre integrantes de proyectos distintos?. Hay que tener cuidado con estos traspiés ya que merman la credibilidad de los interesados afectados, todavía más grave si el interesado es el cliente (no solo se consigue la confianza de estos obteniendo buenos resultados en el producto, también se consigue a través de las relaciones con los mismos).

También es importante no solo tener controlado lo que se dice a los interesados sino también la información que se recibe de ellos.

Por último, en este proceso se definiría la visión integrada del proyecto y la estructura y selección de los equipos integrados de proyecto (lo veremos más en profundidad en áreas de proceso posteriores).