Realidades de los Peer reviews

Las inspecciones y revisiones están consideradas como una de las mejores prácticas en la industria para identificar de manera efectiva y eficiente defectos en los productos. Adicionalmente, permiten compartir el conocimiento dentro del equipo, mostrar supuestos, compartir expectativas y establecer un entendimiento común sobre los productos de trabajo. Todo lo cual se traduce en reducción de los costos de mantenimiento y mejora e incremento de la calidad del producto. La inversión que se haga en este sentido, cuando se hace adecuadamente, mostrará los resultados de manera inmediata. 

Elementos a considerar en los Peer reviews

Peer reviews o revisiones entre colegas es una técnica de revisión estructurada, que puede utilizar diferentes enfoques, donde participan los “colegas” del autor de los productos de trabajo para identificar defectos y cambios que se requieren. 
Son una parte fundamental de las verificaciones, una meta específica en el área de proceso VER “obliga” a ejecutar peer reviews además de otras técnicas que se puedan considerar, por constituir un mecanismo efectivo en la eliminación de defectos. Permite desarrollar un mayor entendimiento del proceso y de los productos de trabajo que puede ayudar a prevenir los defectos e identificar mejoras al proceso.

Organismos “certificadores” CMMI

A diferencia de otras normas o modelos, en el caso del modelo CMMI, para la ejecución de evaluaciones SCAMPI no existen “organismos certificadores”. El SEI certifica individuos que están encargados de liderar al equipo de evaluación en la ejecución del método. Por otra parte un SCAMPI en ninguna manera “certifica”, es un método de evaluación.

Un SCAMPI Lead Appraiser (SLA) es un individuo certificado por el SEI que utiliza el método SCAMPI y guía un equipo de profesionales para conducir la evaluación de las áreas de proceso. En el caso de evaluaciones de niveles altos de madurez, 4 y 5, se requiere un perfil más especializado que se certifica como High Maturity Lead Appraiser (HMLA)


El SCAMPI Clase A requiere la participación de un SLA o HMLA, según sea el caso. En el caso de un SCAMPI B o C no es requerido. En todos los casos el método permite identificar fortalezas y debilidades del proceso respecto al modelo CMMI seleccionado. En el caso del SCAMPI Clase A es el único que puede ser utilizado para determinar el nivel de madurez o capacidad alcanzado por la organización. 


Para convertirse en Lead Appraiser existen ciertos requisitos que se pueden consultar en http://www.sei.cmu.edu/certification/process/scampi/. Un requisito importante a cumplir es ser patrocinado por una empresa que sea Partner del SEI, pero esta condición no hace a la misma una entidad "certificadora". Solo un SLA o HMLA es reconocido y autorizado por el SEI para garantizar el cumplimiento del método y conducir al equipo de evaluación a la ejecución adecuada del método SCAMPI.

Herramienta para gestión de proyectos: dotProject

dotProject es una herramienta OpenSource para gestión de proyectos. Se puede consultar y descargar en la página www.dotproject.net. La herramienta ha sido desarrollada en PHP y utiliza MySQL para el manejo de los datos. Está soportada vía Web para diferentes sistemas operativos (Linux, Windows, Mac). Se puede explorar y revisar a través de una aplicación demo en el mismo sitio de la herramienta. 


Las funcionalidades de la herramienta se pueden integrar a las actividades del proceso de gestión de proyectos para facilitar la aplicación del mismo en la Organización. Cubre diferentes prácticas del modelo CMMI en diferentes áreas de proceso. Veamos como se cubren en términos generales estás prácticas, indicadas entre paréntesis el área de proceso y la práctica específica (SP) o genérica (GP) según corresponda. Sólo se cubren algunos elementos para tener una idea del uso de la herramienta respecto a CMMI. 

Sobre el tipo y contenido de las líneas base

En días recientes publiqué un artículo sobre las líneas base para el control de la configuración. Un colega me hizo llegar la siguiente pregunta, que reproduzco completamente.


"Acerca de las líneas base, comentas que formalmente se establecen cuatro, si bien esas líneas base están a su vez relacionadas entre sí, es decir, existe una correspondencia entre líneas base funcionales, de definición, de desarrollo y de producto. En proyectos de desarrollo que siguen metodologías clásicas es más o menos habitual recibir las peticiones de cambio al final de los desarrollos, durante la fase de pruebas del producto, lo que afectaría a todas las líneas base, teniendo, por ejemplo que la línea base 1 Funcional corresponde con la línea base 3 de desarrollo, y tras la petición de cambio la línea base 2 Funcional corresponde con la línea base 4 de desarrollo, una relación entre las diferentes líneas base. 


Comentas que cada organización o proyecto determina el contenido y tipo de líneas base. ¿Sería válido establecer líneas base globales del proyecto definidas como un conjunto completo de entregables del proyecto, y que las líneas base cambien siempre debido a una petición de cambio (bien interna o bien del cliente) y que se lleve por control de configuración las versiones de los diferentes productos (Plan de Proyecto, Planificación, Análisis Funcional, Matrices de trazabilidad, software, manuales,....) que incluye cada línea base? "


Líneas base y control de configuración
Sobre este punto es conveniente puntualizar algunas cuestiones en principio para poder aclarar el planteamiento. Cuando menciono que son “líneas bases formales” es porque en cualquier literatura sobre el tema es muy común encontrar la referencia a ellas, pero no implica que el modelo o la práctica obligue a cubrir el número y contenido de las líneas base que se plantearon. 


Por otra parte se pueden implementar diferentes niveles de control según las necesidades del proyecto u organización. En ciertos componentes es necesario un control y gestión de la configuración que cumpla con todos los elementos definidos por CM, que sería un nivel alto de control, y por otro lado podemos tener componentes donde es suficiente conocer su ubicación y la última versión aprobada con un nivel más bajo de control asociado con documentos y productos del proceso (Planes, registros, acuerdos, matrices y demás). Esto se puede encontrar explicado en las notas que acompañan a la práctica genérica 2.6 en el modelo CMMI, al inicio de la parte II. 


Definición de las líneas base
El sentido de definir una línea base es más con el objetivo de permitir la comunicación adecuada entre los grupos que participan en un proyecto, de manera que si esa línea base se modifica sea fácil identificar la afectación que pueden tener los grupos que están haciendo uso de ellas. 


Por poner un ejemplo, cuando un arquitecto realiza los planos de una construcción y son aprobados, el maestro albañil toma esos planos para comenzar el trabajo. Durante la obra considera adecuado que se requiere modificar una pared para crear un ventanal, primero debe revisar con el arquitecto la cuestión estructural para decidir el impacto que puede tener en la construcción y la afectación que puede tener con instalaciones eléctricas, hidráulicas o de seguridad que él no visualiza al querer dejar el espacio para la ventana. En este caso los resultados se deben reflejar nuevamente en los planos y permitir que todos estén informados de esas adecuaciones. En este caso el plano y los documentos asociados es una línea base, y quizás la siguiente pueda ser la obra ya terminada.


Las líneas base deben funcionar en el mismo sentido y tener sentido para el proyecto y los grupos que participan. Si tengo un ciclo de cascada y un solo equipo de trabajo que contribuye a la solución, posiblemente la línea base de producto sea suficiente para garantizar mantenimientos posteriores. Pero si en ese mismo ciclo de vida tengo grupos independientes, tal vez el escenario cambia y necesite definir líneas base que permitan entregar los elementos que el otro grupo requiere. Por así decirlo, la documentación de análisis para el diseño, los resultados del diseño para el desarrollo y los productos del desarrollo para probar y liberar el producto, marcarían las líneas base que se necesitan. 


Las líneas base tienen sentido para el proyecto y el desarrollo del producto
La decisión de las líneas base y contenido se pueden establecer al inicio del proyecto como parte del Plan de gestión de la configuración. Pueden ser modificadas y ajustadas en la medida que avanza el proyecto. Pero en cualquier caso se debe considerar la estructura de los equipos de trabajo y la comunicación que se requiere entre ellos, las fases y secuencia del ciclo de vida y que ayude a gestionar la evolución de los componentes. Si en algún momento sentimos que no son apropiadas o no es práctico ejecutarlas como se planteó, debemos hacer las modificaciones para permitir un uso adecuado. 


Sólo los proyectos y la organización determinan el tipo y contenido de las líneas base. El principio a tener en cuenta es, partiendo del concepto de línea base, primero debe ser aprobado el contenido de alguna manera para garantizar el resultado de las etapas posteriores, luego el contenido debe ser útil para las siguientes etapas y por eso tiene sentido controlarlo y finalmente cualquier cambio debe hacerse de manera controlada (el nivel de control lo determina el proyecto) de manera que no se afecten los grupos que están haciendo uso de ese contenido. 


Sobre la pregunta inicial es completamente adecuado si así funciona para el proyecto. Se puede tener un identificador de esa línea base con todas las versiones de los diferentes componentes que la integran y en caso de cambio ajustar el identificador de la línea base con las nuevas versiones de los componentes modificados. El tema puede dar para mucha discusión pero queda abierto por si aún no es claro, poder ampliarlo en trabajos posteriores. Al fin de cuentas esto nos sirve de línea base. ;-)

Goal Question Metric

Una organización requiere mediciones para entender lo que está pasando y generar una base de conocimiento hacia el futuro. Debe ser definida utilizando un enfoque que parte de los objetivos de la organización para llegar al nivel de productos, de arriba hacia abajo. 


Se considera que una medición es eficaz cuando es: 
  1. Centrada en objetivos específicos; 
  2. Aplicada a todos los productos de ciclo de vida, procesos y recursos; 
  3. Interpretada basado en entendimiento del contexto organizacional, el medio ambiente y las metas existentes. 
Goal Question Metric (GQM), o Meta-Pregunta-Métrica, es un enfoque presentado por Víctor Basili de la Universidad de Maryland (1984) que da respuesta a esta necesidad. Este enfoque parte de la suposición de que una organización para medir adecuadamente, debe identificar las metas que desea, derivar objetivos a medir de manera cuantificable y establecer un marco que permita interpretar la información respecto a los objetivos. 

Mitos y realidades sobre Aseguramiento de calidad

QA
Aseguramiento de calidad, según el modelo CMMI, es un medio planificado y sistemático de garantizar a la gerencia que los estándares, prácticas, procedimientos y métodos definidos para el proceso son aplicados. Es una herramienta fundamental para el logro de la institucionalización de los procesos y es base para el seguimiento de la implantación de los procesos como parte del proyecto de mejora. 


Líneas base

De acuerdo con el modelo CMMI una línea base es un conjunto de especificaciones o productos de trabajo que han sido formalmente revisadas y acordadas, que sirven como base para un desarrollo posterior y que sólo pueden ser modificadas por medio del procedimiento establecido de control de cambios. 
El área de proceso de CM establece como uno de sus objetivos principales el establecimiento y actualización de las líneas base del producto o productos de trabajo como una forma de crear bases estables para la evolución continua de los componentes de configuración. Las líneas base son incorporadas al sistema de gestión de la configuración en la medida que son desarrolladas y son elementos indispensables cuando se requiere interacción entre los individuos. Estas líneas base debe ser controladas y revisadas para mantener la integridad de sus elementos. 

Cambios en la representación contínua


De acuerdo con la información publicada por Mike Phillips del SEI, producto de las modificaciones que se están introduciendo en el modelo CMMI para la versión 1.3, existen algunos ajustes en la representación continua y los niveles de capacidad. Se eliminan las metas genéricas 4 y 5 y con esto cambian los niveles de capacidad.

La representación en el modelo CMMI es una forma de presentar la información. En el caso de la representación continua agrupa las áreas de proceso en categorías de procesos, permite seleccionar las áreas de proceso que se van a considerar y evalúa los resultados en términos de niveles de capacidad que corresponden al logro de las metas genéricas en cada área de proceso.

Ajustes en metas genéricas y niveles de capacidad

Con la adecuación del modelo para los niveles altos de madurez se han dado cuenta que existe cierta redundancia en la forma que se alcanza el nivel de capacidad 4 o 5 en un área de proceso, puesto que para alcanzar las actuales metas genéricas 4 o 5 se requiere cumplir con las áreas de proceso de los niveles de madurez 4 y 5 de la representación por etapas. Al analizar los resultados publicados por las organizaciones que realizan SCAMPIs de alta madurez, en un número poco significativo utilizan la representación continua para lograr niveles altos de madurez.

En los cambios se elimina como tal las metas genéricas 4 y 5, con sus prácticas genéricas asociadas, y con ello el nivel de capacidad 4 y 5. Ahora, para alcanzar niveles altos de madurez, se utilizará el esquema que presenta la representación por etapas que obliga a utilizar OPP y QPM para el nivel 4 - Gestionado Cuantitativamente y OPM, un área de proceso nueva, y CAR para el nivel 5 – En optimización. De igual forma se elimina la caracterización como satisfecho para un área de proceso, en un SCAMPI, y se incorpora la evaluación por niveles de capacidad por área de proceso que es mucho más efectivo y proporciona mayor información.

Con estos cambios las organizaciones pueden utilizar la representación continua para ir de los niveles de capacidad 0 - Incompleto al nivel 3 - Definido en sus áreas de proceso. Para alcanzar los niveles altos de madurez utilizarían la representación escalonada para identificar el orden y áreas de proceso a considerar.

Con esta simplificación se reduce la diferencia, mínima, que podía existir en la aplicación de una representación u otra. Con esto mejora el entendimiento del modelo y el uso efectivo de las áreas de proceso.

Grupo de procesos y Comité de mejora

El modelo CMMI, en los ejemplos de responsabilidad y autoridad en la mejora de procesos en la GP2.4 para la institucionalización de las prácticas del área de proceso OPF, establece la existencia de dos grupos en la organización: el Grupo de ingeniería de procesos y el Comité de mejora de procesos. 

Reconocimiento como motor del cambio

El reconocimiento es un arma poderosa en la organización y es una necesidad básica del ser humano, todos necesitamos sentirnos reconocidos por nuestro trabajo. En el proceso de cambio en la organización el reconocimiento es un motivador y acelerador para lograr los resultados que esperamos. En el modelo CMMI, en las prácticas de OPF para establecer la estrategia de adopción de los procesos, se deben tomar en cuenta estos principios. Utilizado adecuadamente puede ser la diferencia entre el éxito o el fracaso del proyecto de mejora. 

Certificación vs. evaluación

En numerosas ocasiones y contextos se habla sobre las “certificaciones” CMMI a organizaciones en algún nivel de madurez, o capacidad. Para el caso del modelo CMMI no se debe hablar de una certificación, lo que realmente se hace es una evaluación o apreciación, derivado del término en inglés appraisal

Certificar es asegurar, afirmar, dar por cierta alguna cosa. Es hacer cierto una cosa por medio de instrumento público. Por otra parte evaluar es valorar, estimar, apreciar el valor de las cosas no materiales. 

Efectividad y eficiencia

El enfoque en la eficiencia y la efectividad es una de las bases que toman como objetivo las empresas cuando trabajan para mejorar sus resultados. Se busca hacerlo bien, rápido y barato pero muchas veces la combinación no es adecuada y se afecta la operación y por consiguiente los resultados. 


La eficiencia está relacionada con obtener resultados con el mínimo de recursos y la efectividad es cuando se alcanzan los máximos resultados con el mínimo de costo. Existe un ejemplo muy claro que ayude a entender el concepto de eficiencia y efectividad. Matar una mosca con un cañón es efectivo pero no es eficiente, mientras que hacerlo con un mata moscas es igualmente eficiente y efectivo. Eso es lo que se busca con la empresa, proporcionar herramientas que ayuden a alcanzar resultados eficientes y efectivos.

Mecanismos de capacitación y formación

El modelo CMMI establece prácticas para gestionar y ofrecer la capacitación que garantiza a los individuos la ejecución de sus actividades de manera adecuada, a nivel del área de proceso OT y en cada área de proceso a través de la práctica genérica 2.5 que establece la necesidad de formación para ejecutar las actividades del proceso. 

Proyectos de mantenimiento

El modelo CMMI DEV, según se establece en el prefacio, "es un modelo de madurez para la mejora de procesos de desarrollo de productos y servicios". Contiene mejores prácticas orientadas a las actividades de desarrollo y mantenimiento que cubren el ciclo de vida del producto desde su creación hasta la liberación y mantenimiento. Adicionalmente en el glosario establece que desarrollo incluye también las actividades de mantenimiento, por lo que las empresas pueden considerar las prácticas tanto para el desarrollo como el mantenimiento.

Aplicación de prácticas a proyectos de mantenimiento

En empresas dedicadas al desarrollo y comercialización de productos propios, típicamente sus proyectos son mayormente de mantenimiento correctivo o por mejoras. En este caso la aplicación de las prácticas de ingeniería, en el modelo CMMI, son cuestionadas por los ciclos que tienen para los proyectos, en general con un esfuerzo disponible de horas o días para ofrecer la solución.

Una posible alternativa es manejar los proyectos de mantenimiento por ciclos, tal vez un año o seis meses, donde se considere la planificación de recursos y mecanismos de seguimiento.

Lo ideal para estos proyectos es contar con una herramienta para seguimiento de órdenes de servicio o requerimientos de cambio. En la misma herramienta se puede documentar fácilmente lo que se hizo y así tener documentado todo el producto en un repositorio único. Para las actividades de PPQA lo mejor es definir periodos de revisión y elegir las órdenes que se tengan ya sean cerradas o activas, mayormente los hallazgos son lecciones aprendidas para las siguientes.

En el caso de las mejoras planeadas que pueden ser proyectos de más tiempo y mejor controlados se puede tener un esquema más amplio aunque muchas veces se reutilizan muchos de los artefactos porque los ambientes, productos y recursos muchas veces son los mismos.

CMMI v2, cinco puntos para entender la nueva versión del modelo

El mes de marzo del 2018 fue el lanzamiento de la versión 2.0 del modelo CMMI (Capability Maturity Model for Integration) por el CMMI Ins...