CMMI V1.3 – SCAMPI MDD. La puñetera fórmula

Como he comentado en algún post anterior, los cambios más importantes que se producen en la nueva versión del modelo CMMI están en el método de evaluación SCAMPI. Tanto miedo se le tiene que al final ya veréis como es pouca coisa.

En el MDD (Method Definition Document) de la nueva versión que está pendiente de publicación y que saldrá a mediados de Diciembre, se plantea que la selección del alcance (appraisal scope) se realice mediante el apoyo una fórmula.

Antes de explicar la fórmula, debemos entrar a aclarar ciertos conceptos que aparecen en el método y que son imprescindibles para entender en que consiste la fórmula.

Sampling Factors

Traduzco “Sampling” como “Muestreo”. Los factores de muestreo permiten al LA y el Sponsor entender como funciona la organización que va a ser evaluada. Los factores de muestreo se obtienen al comienzo del proceso de evaluación, pues sin ellos no se podría definir el appraisal scope.

El término parece complejo pero es muy sencillo. ¿Haces proyectos de desarrollo o también los mantienes y evolucionas? Pues el tipo de proyectos que haces es un factor de muestreo. ¿Trabajas igual para todos tus clientes o no? Si adaptas tu forma de trabajar dependiendo del cliente ahí tienes otro factor de muestreo.

Ya, esto no es nuevo, ya se hacía antes. Te estoy oyendo pensar. Es cierto, ya se hacía. Vamos al siguiente paso.

Subgroups

Pasamos a definir las agrupaciones de las futuras “Basic Units”… ya, ya salió el término. Los subgrupos nos van a permitir cuantificar la representatividad de los factores de muestreo que hemos definido anteriormente.

Desarrollamos Java y .Net, Ok. Si, pero cuanto java y cuanto .net.

No vale un 40-60, hay que cuantificarlo. Si es un 60% es un 60% de cuanto? De 100, de 200 entidades evaluables? (no he dicho proyectos!)

Obtenemos un subgrupo que se llama proyectos de desarrollo en tecnología Java. (LA, y te lo apuntas porque luego este análisis tiene que justificarse en el appraisal plan!). Este grupo por ejemplo tiene un total de 20 basic units (teníamos un total de 50 proyectos de desarrollo, de los cuales un 40% es Java).

Basic Units & Support Functions

Las unidades básicas son “eso” que vamos a analizar para evaluar la madurez de la unidad organizativa. No vamos a llamarlo proyectos, porque pueden ser servicios, pero si has participado en appraisals CMMI basados en el método SCAMPI de clase A, piensa que es lo mismo.

Seleccionas 2 proyectos de desarrollo Java y uno de mantenimiento, otros 3 de .Net y las áreas de HR para la formación, Compras para evaluar SAM, etc.

No lo llamamos ya proyectos, lo llamamos Basic Units o Unidades básicas. No me lo ha dicho nadie y no he podido oirlo, pero esto es para no tener que hacer un SCAMPI MDD for Development y otro for Services.

La fórmula

Ya tenemos los factores de muestreo, los subgrupos y las unidades básicas. Llega el desenlace de la novela. Ya verás como os quedáis con una sensación de “tanta trama para luego esto?”

La formula nos va a permitir seleccionar las unidades básicas a analizar de cada subgrupo definido. Nos ayuda a que seleccionemos 2 proyectos de desarrollo Java no porque lo consideramos adecuados, sino porque representativamente son 2 y no 3 ni 1 los que tenemos que analizar.

Aquí está

Numero de Basic Units Nº de subgrupos X Nº de Basic Units del grupo

a seleccionar de un = ------------------------------------------------------------------

grupo determinado Total de Basic Units

Creo que es físico nuclear el que la ha ideado. No la voy a comentar, mejor un ejemplo con los datos de antes.

¿Cuántos proyectos (Basic units) de desarrollo Java tengo que seleccionar?

• Subgrupos: 6 (Desarrollo Java, Desarrollo .Net, Mantenimiento Java, Mantenimiento .Net, Compras y HR), por ejemplo
• Basic units del grupo de desarrollo de proyectos Java: 20 (el 40% de 50)
• Total de Basic Units: 50 por ejemplo

Osea, (6X20)/50 = 2,4

Lo que no me ha parecido ver es que dice el modelo que tenemos que hacer con ese 0,4 (evalúo solo PP y PMC? jajajaja (ssffff)

Y esto es todo. Bueno, luego hay que mapear todas las Basic units seleccionadas con las process areas y obtener métricas de porcentaje de Basic units y de población, pero eso ya lo dejamos para otro post, que no voy a contarlo todo en uno.

Salu2,

Dum.

CMMI V1.3 ¿Están integrados tus equipos? – Capítulo 2, Cambios

OPD

En el área OPD (Organizacional Process Definition) se ha incluido una práctica nueva, SP 1.7 Establish Rules and Guidelines for Teams. De alguna forma la IPPD Addition de esta área en la versión 1.2 se ha integrado en esa práctica. La forma de integrarla ha sido la que he descrito en el post anterior, el objetivo pasa a práctica y las prácticas a example work product.

Lo que viene a definir esta práctica en la nueva versión es que definas claramente 2 aspectos:

• Los roles aplicables a los proyectos y su responsabilidad en estos
• Las normas a aplicar para definir la estructura del equipo del proyecto

Traducido esto viene a significar por un lado, que debes disponer de unas normas que permitan potenciar (dotar de empowerment adecuado) al equipo, de forma que

1. Un rol determinado dentro de un proyecto sepa exactamente que papel desempeña. Cuidado!, el y la organización (expectations!)

2. Disponga de unos canales de comunicación adecuados

3. Sepa cuando ha de tomar una decisión (y que tipos de decisiones)

4. Y pueda actuar correctamente cuando se produce un incidente

En la anterior versión del modelo define acertadamente que:

“In a successful IPPD environment, clear channels of responsibility and authority must be established. Issues can arise at any level of the organization when integrated teams assume too much or too little authority and when it is unclear who is responsible for making decisions.”.

Por otro lado, una vez definidos roles, como se comunican estos, que responsabilidad tiene cada uno en la toma de decisiones y gestión de incidentes, tenemos un conjunto de cajas (roles) con unas características. Por tanto la otra parte de esta práctica consiste en disponer de unas guías y reglas que me permitan diseñar la estructura que tendrá el equipo del proyecto y poderla mantener a lo largo del ciclo de vida seleccionado.

Por ultimo, en cuanto a esta práctica hay que tener un aspecto en cuenta. Desaparecen las referencias a una práctica en la versión 1.2 (IPPD addition claro está), que es la SP 2.3. Generalmente y por experiencia, la estructura de las organizaciones no es proyectizada, sino matricial, de esto saben mucho los del PMI. Esto significa que nuestro proyecto no se desarrolla normalmente de forma aislada, sino que debe atender a otras áreas “funcionales” de la organización. Esto se ha perdido en la nueva versión del modelo. Las áreas funcionales de la organización tienen participación dentro del proyecto, y por tanto deben ser stakeholders del mismo y atender a sus necesidades.

IPM – Expectations y Shared Vision

He comentado en este mismo post el tema de las expectations. Más o menos esto viene a ser el meollo de la cuestión. En IPM se integra todo el objetivo 3 del modelo anterior (SG3) en una práctica, la 1.6. Recuerdo que en la versión 1.1 eran 2 objetivos.

El concepto de Shared Visión no es otro que, lo importante es que yo sepa mi rol dentro del proyecto, y que los demás también lo conozcan y no me soliciten ni más, ni menos de lo que debo realizar en el.

Para definir correctamente una visión compartida de los participantes en el proyecto, es necesario atender a esas expectativas. Si en esto se falla tenemos un conjunto de recursos que participan en el proyecto, pero no una idea clara (para todos) de quién hace qué.

El resto es el viejo establish and maintain, esto es, define el equipo (basándote en las normas OPD), emplea esos equipos y actualiza estos ante las variaciones del proyecto.

Saludos,

D.

CMMI V1.3 ¿Están integrados tus equipos? – Capítulo 1, Historia

Joer, ya con capítulos y todo….

Un poco de historia (que no viene mal para saber porque estamos donde estamos)

Desde 1991 CMM se desarrollo para un amplio conjunto de disciplinas, desde ingeniería de sistemas, de software, de adquisición, de gestión de equipos de trabajo y de desarrollo integrado de procesos y productos.

Cuando CMM se integró, convirtiéndose en CMMI, el equipo de desarrollo del modelo apoyo su trabajo en tres fuentes principales:

• El modelo de madurez para software SW-CMM
• El modelo de madurez para ingeniería de sistemas SECM
• y el modelo integrado para el desarrollo de productos IPD-CMM

Gran aportación de IPD, que prestó la “I”.

Y a P-CMM que le den. Ya volveremos, ya. (News, posiblemente para 2012 el People CMMI).

Esto es historia, algo más compleja de lo que aquí reflejo, pero básicamente así fue. Nació el modelo CMMI V1.0 que luego evolucionó (1.1)

Para adaptarse a las diferentes necesidades de la industria, el modelo CMMI fue evolucionando desarrollando aquello que se dio en llamar “disciplinas”.

- Que desarrollas software? CMMI-SW

- Que desarrollas software integrado en sistemas? CMMI-SE/SW

- Que además tus desarrollos son complejos y en ellos colaboran equipos multidisciplinares? CMMI-SE/SW/IPPD

- Si, esta SS pero no voy a hablar de ella (Permitidme la licencia).

En ese modelo, las propuestas CMMI relacionadas con el desarrollo integrado de procesos y productos (IPPD) se reflejaban en unos cuadros llamados “discipline amplifications”, las cuales no tenían valor alguno sin contar con las prácticas específicas correspondientes de cada área de proceso. Esto es, desarrollabas SE/SW + lo que se proponía desde IPPD.

Debido al rotundo éxito de la disciplina IPPD, el SEI relegó a partir de 2006 en su flamante CMMI-DEV V1.2 las prácticas IPPD al pobre término de “additions”, lo que significa que del modelo CMMI-DEV podías emplear las IPPD additions (con sus propias prácticas y objetivos en OPD, IPM) o simplemente pasar de ellas.

Alguien tiene datos sobre las acreditaciones CMMI-DEV/IPPD? Es que el SEI no las publica (Obi Wan?), y no me voy a picar el PARS entero para verlas. Yo por lo menos no las he visto.

Y llegamos a Noviembre de 2010, donde el SEI publicará la versión 1.3. Con el fin, porque ese es el fin, de conseguir que los equipos de desarrollo dejen de ir por libre y trabajen con un ojo en la estrategia de la empresa y otro en el cliente, se decide que ahora es IPPD si o si. Ya no valen medias tintas, ni esto no me aplica ni nada. IPPD es mandatory (bueno, es expected, ya la hemos liado, alternative practices y la madre que les parió).

Simplemente lo que en CMMI V1.2 era un goal (objetivo, ineludible) ahora es una práctica (expected). Y lo que eran en la anterior versión las prácticas, ahora son subpracticas (informative) y lo que eran subpracticas ahora son…. morralla. Quedas degradado IPPD, degradado pero CUIDADO, IPPD es, en la versión 1.3, MAN-DA-TO-RY, y no me vengas con cuentos sobre alternative practices, que eso es una milonga.

Debe ser el fin de semana. Continuará (TBC).

D.

Por fin CMMI & Agile se abrazan juntos (o no)

He trabajado para diversas compañías que estaban certificadas ISO 9001. También para compañías que desarrollan ágil, en cualquiera de sus técnicas y metodologías.

El SEI se ha dado cuenta de que si quiere que CMMI continúe siendo un estándar de facto tiene que seguir apostando por la integración y la adaptación a la nueva realidad. La nueva versión del modelo CMMI, la 1.3 da una vuelta de tuerca más en el acercamiento a otros planteamientos y necesidades de la empresa real.

El nuevo modelo CMMI se acerca a las metodologías ágiles. A mi juicio es un tímido acercamiento, pero podemos considerar que es un paso adelante. En concreto existen referencias a las metodologías ágiles en 9 áreas de proceso, entre las que cabe destacar la de riesgos, Risk Management, donde el nuevo modelo propone actividades específicas (no prácticas) para la gestión de riesgos en esos entornos ágiles.

Cabe mención especial al capítulo 5 del nuevo modelo "Interpreting CMMI When Using Agile Approaches", el cual parece desarrollar el punto de vista CMMI de las metodologías ágiles, sin tener que dar muchas explicaciones en las áreas de proceso. Enhorabuena Hillel, lo merecías! Simplemente con buscar en el modelo la frase “In Agile environments” encontrarás las referencias.

Con respecto a la ISO, pues que vamos a decir, según lo que cuentan parece ser que el nuevo modelo introduce el concepto de “customer satisfaction”, otro paso más allá de reconocimiento a la 9001. En concreto introduce este concepto como una de las actividades por las cuales un cliente es un implicado en el proceso (stakeholder) GP2.7. Además propone este concepto como una de las métricas que podría necesitar una organización (M&A), y como fuente para detectar mejoras (OPF) en los procesos. También se incluye en la nueva área de proceso (OPM).

Resumiendo, son listos estos chicos de Pittsburg. No solo hacen un guiño a otras formas de desarrollar procesos, sino que con la estandarización están desarrollando el multimodelo, de lo cual como empieza a ser costumbre, hablaremos en otro post.

Salu2,

Dumm

Appraisal efficiency en un CMMI SCAMPI Appraisal

El método Scampi, que no significa gamba rebozada, esta basado parcialmente en el CBA-IPI. Cuando se desarrolló el nuevo método (SCAMPI), se buscó reducir al máximo el tiempo necesario para realizar el appraisal. La utilización de la hoja de PIID (Practice Implementation Indicador Document), facilitó la tarea enormemente.

El problema es que se generó un nuevo monstruo, una nueva y costosa tarea llamada elaborar la hoja de PIID. Este y otros motivos han llevado al equipo que está desarrollando la nueva versión del modelo (y su correspondiente método de evaluación, SCAMPI V1.3), a mejorar algunos de los aspectos de este proceso crítico, la acreditación formal de las organizaciones.

En el artículo que Mike Phillips y Shandy Shrum publican en Crosstalk http://www.stsc.hill.af.mil/crosstalk/2010/01/1001PhillipsShrum.html hay más información al respecto. Entramos en materia.

El proceso de elaboración de la nueva versión del modelo CMMI tiene como uno de los focos principales mejorar la eficiencia de los appraisals. ¿Cómo se traduce esto en el nuevo método de evaluación?. El SEI ha enfocado la versión 1.3 del método SCAMPI a, literalmente, “asegurar que las evidencias presentadas demuestran que una actividad se encuentra suficientemente implementada en la organización para satisfacer las expectativas del modelo”. Esta afirmación da para otro post, simplemente por el termino “suficientemente”, o para un libro.

Y a partir de aquí viene la explicación del porque considero (ya lo he referido en otro post), que esta es posiblemente la alteración de mayor alcance que contiene la nueva versión de la suite CMMI:

- De alguna forma, los conceptos “instantation” o “proyecto” desaparecen y se convierten en “Basic unit”, “Sampling factor” y “Subgroup”. Ya lo explico en otro post. (joer, esta parece la coletilla de todos los post, es como un “to be continue”). Existe una fórmula para obtener las “Basic units” que por lo que se hasta el momento, producirá que la lista de (antiguamente proyectos), unidades básicas seleccionadas sea bastante amplia, con lo que “goodbye appraisal eficiency, welcome appraisal effectiveness”. Si, luego puedes justificar (va por vostros LA’s) que si la muestra es muy amplia y afecta al plan de appraisal se reduzca la muestra (y supongo que esto será un criterio que el SEI aplicará para las futuras auditorías).

- Desaparece la lucha sobre las evidencias directas e indirectas (los famosos articfacts). Ya son solo evidencias. Recae sobre el LA la responsabilidad de asegurar que las evidencias escritas (artefactos) y orales (afirmaciones) demuestran que la práctica esta correctamente implementada. Esto tiene mucho peligro, cuidado con las entrevistas, o te quedas sin evidencias.

- Este ultimo punto no estoy seguro que se haya desarrollado, pero lo pongo y ya corregiré, que es de sabios. A lo que voy, el equipo que está mejorando el SCAMPI, se ha dado cuenta (lo comento al comienzo), que la actividad de recogida y registro de información (la puñetera PIID), es una tarea costosa, pero no saben como reducir ese coco que han generado, y como buenos process experts, han decidido que lo primero antes de definir, es medir. Por eso el plan de recogida de toda la información tendrá que ser un documento aparte dentro del pack que el LA envía al SEI, para que sea analizado aparte.

Y ahora vienen aquí lo que considero algunos “desaciertos” por no llamarlos desbarres, idas de olla o simplemente errores, que van a dificultar aún más el trabajo de los Lead Appraisers y que ponen una vez más al SEI en la picota:

- Los miembros del equipo del appraisal (ATM para los amigos) deben tener una experiencia mínima global de 25 años. Para esto se suman los años de experiencia de todos los miembros del equipo, incluido el LA. Pues ya no. Esos 25 años los tienen que sumar los team members solos, sin el LA. ¿Quién no ha mentido alguna vez en este apartado? Pues ahora más. Es que un equipo pequeño de 3 miembros necesitaría aportar como mínimo 8 años de experiencia (y si las matemáticas no me fallan alguno debería tener 9). Esto se puede conseguir en una gran compañía, pero y en una Pyme (SME in English)?

- La estructura de licencias (Fees) cambia, y ya no será anual, sino por uso. 1000 dólares por inscribirte en el SEI, por cada appraisal, ahí es nada. Yo no entiendo a quién se le ha ocurrido la magnífica idea. A esto le llamo yo tirar piedras contra su tejado. Tu dile a una empresa que vale más el título que expide el Lead Appraiser que aparecer en el PARS, y que si quiere aparecer en el PARS son 1000 euritos y ya la tenemos liada. Volvemos a los CBA-IPI days.

Gracias a Peter Leeson, y su blog http://peterleeson.wordpress.com de donde ha salido gran parte de esta información. Gracias Peter, para aquellos que no podemos ser fans del SEI y seguirlos a todas partes.

Ya no merece la pena la versión 1.2 de CMMI

Este es el comentario que muchas empresas están haciendo ahora mismo. La nueva versión del modelo CMMI, ya en sus tres constelaciones, Mike “Obi Wan” Philips mediante, - Pat O’Toole dixit :-) – esta a punto de salir. En noviembre de 2010 se presentan las nuevas versiones del modelo CMMI-DEV,ACQ y SVC.

Es lógico este planteamiento por parte de las compañías, que piensan que mejor será acreditarse mediante la nueva versión, y poder sacar pecho.

Pero esto tiene un pero. (bueno, tiene varios). Los enumero:

1.- El modelo sale en Noviembre, si, pero el SEI espera un feedback de los usuarios hasta Enero 2011. Esto significa que podrían aparecer cambios.

2.- El método SCAMPI V1.3 sale en Diciembre, y la nueva versión del modelo hace una especial referencia a mejorar “appraisal efficiency”, que no es un punto baladí. El upgrade de los LA’s no va a ser algo tan liviano. Ya pondré un post explicando que entiende el SEI por “appraisal efficiency”.

3.- El upgrade de los LA’s e instructores (que no hayan estado rápidos con el workshop de las vegas) será en Enero 2010. Si, el SEI está analizando un face to face entre medias para que todos estén preparados cuanto antes, pero por ahora lo está analizando (y lo que se está analizando no existe).

4.- En ese mismo Enero 2010 estará disponible el upgrade online para los 117.869 colegas que han hecho el curso de introducción al modelo CMMI desde sus inicios (datos a agosto ’10). Significa que los ATM’s que vayan a participar en un appraisal CMMI solo podrán participar en un SCAMPI A Appraisal con la versión 1.3 desde Enero 2011 (y teniendo en cuenta que el appraisal plan se tiene que añadir antes en el SAS, pues se retrasa un poco más). Y si a eso le sumas que un ATM pueda no tener el curso oficial de introducción, súmale 3 días más. Pongamos Febrero 2011.

5.- ¿Tienes como objetivo acreditar un nivel 3 de madurez? ¿Te suena integrated teaming? Cuando el modelo salga a la luz mira OPD SP 1.7 e IPM SP 1.6. Esto se amplía en otro post que desarrollaré más adelante, pero vete haciendo a la idea que no puedes acreditar tus procesos en la versión 1.3 de por ejemplo CMMI-DEV si no realizas ciertos ajustes.

6.- ¿Vas a certificar niveles altos de madurez? Cuidado! OID is dead y llega OPM!!! (si, has leído bien, no es QPM, es OPM, Organizacional Performance Management). Bueno, OID no desaparece, pero como no me quiero desviar, esto lo cuento en otro post, pero pasa lo mismo que en el punto anterior, si quieres acreditar tu organización en CMMI en nivel 5, asegura que las innovaciones que introduces en tus procesos están alineadas con el negocio.

Seguro se me olvida algún pero, pero como se señala en el disclaimer, estoy encantado de aprender cosas nuevas.

Resumiendo, está muy bien la versión CMMI 1.3, es un acierto, pero un consejo, plantéate un SCAMPI A en la nueva versión a partir de mayo o junio, abril ya lo considero muy ajustado.

Salu2,

D.

Otro arreón

Este blog tiene ya un tiempo, aunque no lo cultivo. Parece que siempre es lo último en mi lista de prioridades. En mi empresa no puedo (no debo), y fuera de ahí sería masoquista. La nueva versión del modelo CMMI, la 1.3 esta al caer. Hay tantas dudas que aclarar y cosas aún en el aire que he decidido hacer una serie de post relacionados con este asunto. Espero que aclaren más que confundan. A ver si a partir de ahora este es el arreón definitivo a este blog.

Saludos,

D.