SEPG North America 2013

Hoy he recibido un correo de notificación del CMMI Institute, recordando la celebración de un interesante evento que tendrá lugar en Pittsburg el próximo 1 y 2 de Octubre de 2013. Nada menos que el SEPG North America 2013, un evento anual (bueno, vale, hay otros similares en Europa y Asia, también anuales), donde se tratarán temas candentes y de actualidad como por ejemplo:
– Kanban y CMMi
– Flexibilidad Agile: cómo CMMi hará que Agile sobreviva y se fortalezca.
– Implementación ágil de CMMi
– Métricas.
– Desarrollo de Software seguro con Secure by Design for CMMI-DEV
– Microsoft IT Data Management Maturity
…y más.

Me parece muy interesante el esfuerzo por simplificar y acercar CMMI al movimiento ágil, y en general, al resto de iniciativas y tendencias actuales en el desarrollo de software. Espero que sean muy interesantes, y aunque no creo que esté presente, espero poder acceder al material de los eventos y poder estudiarlos. Algunas de las conferencias prometen bastante.

Aunque ya os he puesto más arriba el enlace principal al evento, os adjunto otro par de enlaces directos a:
– Agenda: Conferencias y ponentes.
– Acerca de: ¿Qué son las conferencias SEPG?

Ética e Ingeniería del Software

Fuente: http://www.asme.org/

Recientemente, en el blog de Javier Garzás he leído un post donde se propugna algo que llevo repitiendo hasta hartarme desde el primer post: que debemos comportarnos profesionalmente, de forma ética.

No somos charlatanes, patanes de feria que vendemos lo que nos convenga en función del beneficio que nos proporcione. En lugar de eso, damos al cliente lo que necesita en cada momento, maximizando su satisfacción y nuestro beneficio a largo plazo. Porque creemos en que la relación con nuestros clientes se cimenta en una confianza mutua, y ésta sólo puede realizarse a largo plazo.

Esta forma de pensamiento la he visto como eco en algún otro post. Me hace mucha gracia, que Javier afirma: «una metodología no es un equipo de fútbol, ni un partido político, ni una religión». Sin embargo, leo por doquier en la red continuas llamadas talibanistas a defender la religión del bloguero de turno:

• Metodologías ágiles
• Software libre
• CMMI
• Integración continua

El pensamiento que defiendo es similar al promulgado por Alistair Cockburn hace ya unos años:

«Estoy cansado de la gente que es de una escuela de pensamiento y que rechaza las ideas de otra escuela de pensamiento. Tengo hambre de gente que no le importe de donde vienen las ideas, que les importe sólo lo que significan y lo que producen. Así que se me ocurrió esto del “juramento de no lealtad”.
Esto significa el fin de afirmaciones como “eso no está bien – no es ágil / orientado a objetos / puro / etc.”, en vez de discutir sobre si la idea (ágil o tradicional o impura o lo que sea) funciona bien en las condiciones del momento.»

Por desgracia, hay gente que incluso afirmando defender estas ideas, confiesa sus prejuicios y reticencias al respecto de ciertas formas de trabajar: «metodologías», «prácticas», «marcos de trabajo»…llamadlo como queráis.

Podemos estar convencidos de una cosa, pero no debemos defenderla si no es con argumentos probados, objetivos y no sólo cualitativos sino también cuantitativos. Por desgracia, esta forma de pensar encaja perfectamente en los que yo llamo «indecisos patológicos» o «charlatanes del depende». Sí, ya los conocéis. Me refiero a los que siempre contestan a todo con un «depende» (hasta aquí todo va bien), pero que cuando se les pide algo más de detalle o chicha en su discurso, podemos tener dos tipos de respuesta:

• Verborrea coherente pero carente de fondo y forma, que al final no termina de dar ningún tipo de argumento veraz ni mucho menos objetivo hacia un lado u otro. Esta verborrea de político le viene muy bien a algunos individuos, que incluso les facilita la promoción profesional. Pero lástima de los clientes que acaben con ellos, y mucho peor: lástima de los que acaben en un proyecto dirigido por estos pseudo-profesionales.
• Verborrea que sólo está orientada a alimentar el ego del que escucha. Son los llamados aduladores, los pelotas, que difícilmente terminan hablando del tema, sino que redirigen la conversación a un terreno menos objetivo y relacionado con el proyecto en cuestión.

Al querer escribir yo este post, me he encontrado con otro post bastante interesante. En él, su autor deriva la conversación a la ética informática, y al colegio profesional. Este autor, plantea la existencia de un tribunal de ética. Yo no sé lo que pensaréis pero empiezo a estar harto de tribunales, comisiones, cortes, comités de supervisión, equipos de trabajo, etc, etc. Y estoy harto de apelar siempre a un «ser superior» que nos proteja y defienda.

Es muy fácil: lo único que puede definir el comportamiento ético o no en un proyecto es la documentación. Los criterios objetivos, y la forma en que se basan y defienden, es lo único que puede usarse como valor ético en un proyecto. Pero claro, decir esto cuando la moda es ir en contra de la documentación, ser ágil, y entregar todo de forma rápida (y sin documentación), es poco menos que escupir al viento. Pero no deja de ser cierto. No es posible verificar la ética en un proyecto sin contrastar el contrato, con las decisiones tomadas (y las decisiones, o se documentan…o se pierden). Y es así en todas las profesiones.

Después de todo, en una profesión en la que no hay estándares cerrados, en los que no hay normas internacionales que establezcan la forma correcta de trabajar, todo vale. No podemos a la vez defender que hacer software es un arte, y al mismo tiempo querer crear Colegios, Comisiones éticas que verifiquen el buen hacer…respecto a qué?

En fin…excelentes Alistair Cockburn en su comentario, y Javier Garzás y Jorge Ubeda en sus respectivos posts. Espero que esta pequeña reflexión mía haya podido aportar algo.

Documentación de Cierre de un Proyecto

Como respuesta a un lector que me presentaba unas dudas, voy a tratar de indicar qué es necesario al cierre de un proyecto y para qué sirve (o al revés: dadas las necesidades, ver qué documentos aplicarían en cada caso). Las metodologías suelen centrarse en el primer caso. Las guías, o las adaptaciones de una metodología, prefiero centrarlas en el segundo. Porque no se trata de hacer documentos (primer caso), sino de resolver necesidades (segundo caso).

En primer lugar, decir que esta documentación que voy a nombrar, trata de cubrir objetivos. Si los objetivos no aplican en el proyecto, o están cubiertos de alguna otra forma, se puede obviar cada documento. Además, el alcance de cada documento debe ser acorde al tamaño del proyecto, o de los riesgos asociados. Estoy harto de repetir por activa y por pasiva, una y otra vez, que las prácticas y los procesos, están al servicio del proyecto. Y no al revés. Y que si no aplica una práctica a un proyecto, y requiere de adaptación, pues se hace: se adapta, y se busca cómo cubrir los objetivos y la esencia del proceso.

Los documentos que harían falta serían:

1. Informe de cierre. Este documento suele estar en realidad compuesto por una serie de apartados o subdocumentos como:
   • 1.1. Estado final del proyecto
   • 1.2. Buenas prácticas
   • 1.3. Lecciones aprendidas
2. Aceptación del cliente
3. Encuesta de satisfacción

1. Informe de Cierre.

1.1. Documento de Estado Final del Proyecto.

En respuesta a lo que el lector me preguntaba, este documento contendría la foto final:

• dónde dejamos la documentación y qué documentación dejamos
• qué objetivos se tenían, cuáles se han cumplido y cuáles no
• cumplimiento de estimaciones (esfuerzo, fechas, costes), incluyendo razonamientos y demostraciones de porqué hubo alguna variación.
• métricas de cierre: demostración de que los objetivos de calidad y de cierre se cumplen. Si es un desarrollo, podemos aquí demostrar cómo el número de defectos encontrados por período de tiempo ha disminuido drásticamente (esta podría ser una métrica válida). Estos criterios objetivos (métricas), podrían suponer el punto de arranque al equipo de soporte que recoja el testigo y arranque la fase de mantenimiento.
• etc.

1.2. Documento de Buenas Prácticas.

Este documento o apartado recogería la experiencia del proyecto en cuanto a buenas prácticas que se han seguido, y que han tenido éxito demostrado en el proyecto.

1.3. Documento de Lecciones Aprendidas

En este apartado recopilaríamos todas las experiencias recopiladas durante el proyecto a todos los niveles:

• Técnico
• Funcional
• Comunicaciones
• Gestión de equipos
• Gestión de riesgos
• Organización de entregas
• etc.

2. Aceptación del cliente.

Este documento, recopila una descripción del proyecto, nuestra labor y papel en el mismo, y en él el cliente reconoce que acepta los servicios prestados, que son adecuados en alcance y calidad. Es un documento que enviamos al cliente, y éste nos lo devolverá firmado, sirviendo como referencia y credencial para futuros proyectos.

3. Encuesta de satisfacción.

Sobre éste ya hablé en un anterior post «La eficacia de las encuestas de satisfacción«.

Como me he extendido un poco, creo que habéis cogido la idea. Dejaremos para un post posterior el detallar estos documentos y el cómo adaptarlos a la situación real del proyecto.

Fuente: CMMi

Defectos de CMMI

Aquí quiero contar los defectos de CMMI per-se, y por sus malas implementaciones en metodologías apresuradas o porque el único interés era conseguir «el sello de calidad».

Si has leído otros post, verás que no estoy a favor de defender metodologías porque estén de moda (como Scrum), sino solamente porque demuestren razonadamente beneficios. Para mi desgracia, sí que me gustan las metodologías ágiles, a pesar de mi resistencia a defenderlas “porque sí”. Eso me hace, por convicción, tener que evitar la tentación de venderlas constantemente y a ciegas. De hecho, suelo «darles caña», simplemente porque creo que en ellas está el futuro, pero requieren de disciplina y sentido común a la hora de implantarse, y sobre todo no olvidar que hay más cosas que «picar código» y que la empresa y el cliente necesitan que se lleven a cabo.

Vamos a razonar los defectos (que los tiene) que se suelen alegar en contra de CMMi.

Alcance.

Efectivamente, no se obtiene normalmente el CMMi para una empresa. Se obtiene con un alcance determinado (un departamento o unidad de negocio), varios de ellos, o un conjunto de proyectos relacionados de alguna forma. Ojo con esto, porque seguramente las empresas que afirman que son CMMi nivel X, en realidad suelen tener un alcance inferior al 100% de su  personal y proyectos. Basta que vayáis a la base de datos de empresas que han obtenido el nivel X de CMMi, y leáis los detalles del alcance. No es que se mienta, es la gente quien al desconocer estos detalles, se hace una idea equivocada. Es interesante decir también que en los resultados de la evaluación se hace mención explícita de los proyectos y personas evaluados. De esta forma, se da una idea porcentual del alcance de la certificación CMMi en la empresa.

CMMi no cubre todo

CMMi deja de lado diversas áreas de la empresa, como pueden ser las contrataciones, motivaciones, y en general todos los temas relacionados con las personas. Bien, al respecto hay que decir que CMMi-DEV es un modelo de madurez del desarrollo de software, no de la gestión de personas. Para eso, existe un People CMMi. Si alguien quiere tener en cuenta a las personas, puede certificarse en ambos. O si sólo quiere certificarse en la gestión de personas…pues ahí está. De todas formas, en mi empresa, lo que se evalúa es la metodología, y en nuestro caso incluía gestión de recursos, formación a nivel corporativo, etc. Vamos, los típicos procesos de training, staffing y recruiting. Y esos procesos fueron revisados durante el SCAMPI, como parte de la metodología. De hecho, al final del SCAMPI, se obtienen “puntos fuertes” que son buenas prácticas más allá del mínimo que exige el modelo.

Es una foto parcial de la empresa en un momento, pero el título es para siempre.

Bueno, los resultados de un SCAMPI tienen validez de 3 años. Si ANTES de ese tiempo no se ha hecho una nueva evaluación igual o superior, se pierde ese nivel de madurez. Lo que sí es cierto es que es una foto parcial de la empresa. Los proyectos pasado el SCAMPI, pueden descontrolarse, y perder todas esas buenas prácticas, pero claro, si es así, ya se pasará factura si se trata luego de renovar el nivel de madurez. Mi experiencia es que si las metodologías implantadas son ligeras, y se hace contando con la gente, su uso es suficientemente beneficioso para que los proyectos lo mantengan por sí mismos.

CMMi no reconoce ciclos de vida (SDLC) como parte del modelo.

A ver, CMMi es un modelo. Recopila paquetes de actividades que se consideran básicas, y dentro de cada una, se puede tener un nivel u otro de madurez. Los ciclos de vida son parte de las metodologías, pero CMMi deja libertad a ciclos en cascada, iterativos, ágiles, etc. Yo comprendo que hay gente que quiere que CMMi les resuelva la vida. Y no lo va a hacer. CMMi dice lo que se necesita hacer en todo proyecto, pero es el buen juicio y el sentido común de los creadores de las metodologías, los responsables de que se haga trabajo de más, o de que a un proyecto de 3 personas acabemos pidiendo documentación fuera de lugar.

Burocracia.

Bueno, de esto ya hablé en el mito de la burocracia. No le daré más vueltas. Puede efectivamente convertirse en un grave defecto si no sabemos adaptar y aligerar las metodologías a los proyectos. Sin embargo, lo veo más una excusa para evitar involucrarse en CMMi, con la errónea creencia de que va en contra de los métodos ágiles.

Proyectos de distinto tipo a los que han pasado la evaluación de madurez CMMi.

Efectivamente, puede ser que todos los proyectos que pasen CMMi fueran Oracle, de desarrollo, y con ciclo de vida iterativo. ¿Qué pasa ahora? Pues nada, los proyectos que no sean así, dependerán de si la metodología también se adapta a ellos, y de un montón de cosas más. ¿Qué cómo contempla esto CMMi? Pues no lo contempla. Por eso existe un alcance.

CMMi no es una certificación.

A pesar de que llevo ya varias frases utilizándolo aposta (a ver si alguien dice algo), en realidad no puede decirse “la empresa X está certificada CMMi nivel…”. Lo que se hace es una evaluación de madurez, pero en ningún momento el SEI (Software Engineering Institute) proporciona certificado de ningún tipo, al contrario de por ejemplo ISO-9001 que sí emite certificados que pueden enmarcarse o presentarse. Podemos leer en las páginas del SEI:

– SEI no certifica los resultados de niveles de madurez de ninguna evaluación

– SEI no certifica organizaciones. SEI solo licencia a consultores asociados para realizar evaluaciones. Ni SEI ni ninguna otra organización es una autoridad de certificación de los resultados de estas evaluaciones.

CMMi es responsabilidad del SEI, y no emite certificaciones. Lo que sí es posible es que se emita un informe por parte del consultor evaluador o de la empresa certificadora, justificando el alcance y resultados. Pero nada más.

CMMi no asegura la calidad.

Siguiendo el hilo del anterior, el haber pasado un SCAMPI y obtener el nivel de madurez tal o cual, no asegura nada. Por eso no pueden publicarse como “certificados”. La evaluación CMMi es para la empresa, para que sea consciente de su estado de madurez en las condiciones establecidas. Pero no garantiza nada, ni el SEI ni la consultura que hace la evaluación, se hacen responsables de la calidad de los productos (salvo la propia empresa evaluada).

Métricas – Las 7 preguntas al analizar los datos

Los datos son los datos. Y tendemos a darles mucha importancia. Y la tienen. Sin embargo, a la hora de interpretarlos, no solemos tener la disciplina de estudiar su origen y circunstancias. Lo que es peor, no solemos tener criterio a la hora de agregarlos o no a los demás datos recopilados.

Aquí van 7 preguntas que me parecen fundamentales a la hora de analizar los datos recopilados en un proceso de MA (Medición y Análisis), o en general en cualquier proceso de Métricas:

1. ¿Quién recopiló esos datos? (Esperemos que fueran las mismas personas que se formaron en las técnicas adecuadas de recopilación de datos)
2. ¿Cómo se recopilaron los datos? (Esperemos que fuese mediante herramientas/procesos automatizados, y que no requiriesen esfuerzo adicional al trabajo diario)
3. ¿Cuándo se recopilaron los datos? (Esperemos que fuese al mismo tiempo o en el mismo día que las tareas relacionadas a dichos datos)
4. ¿Qué significan esos valores? (¿Ha habido cambios recientes en el proceso? ¿Realmente esos valores me dicen lo que quiero o necesito saber?)
5. ¿Cómo se obtuvieron esos valores calculados a partir de los datos originales?
6. ¿Qué fórmulas se usaron para calcular esos datos? (¿Están midiendo lo que necesitamos medir? ¿Funcionan? ¿Son relevantes? ¿Son obsoletos?)
7. ¿Estamos recopilando los datos de la forma correcta? ¿Son los datos correctos? Los datos deberían ser consistentes, y la forma en que se recopilan, a su vez, también debería ser consistente. Hay que asegurarse de que los datos tengan la información requerida para los análisis que necesitamos llevar a cabo.

Veamos un ejemplo:
Tenemos unos datos de defectos encontrados en pruebas unitarias. Nos haríamos cada unas de las preguntas y analizaríamos las respuestas:

1. La persona nos dará una pista de en qué circunstancias se obtuvieron los datos, si han sido automáticos, o si se han rellenado de forma asíncrona al proceso de pruebas.
2. Si el proceso no es automatizado, será más propenso a errores o a manipulación deliberada. En este caso nos va a interesar saber las ejecuciones que se han hecho de los tests, y cómo se han obtenido los defectos. ¿Se han lanzado todas las pruebas, o se ha parado al llegar a un error grave?
3. Si el proceso no es automático, habrá que ver cuándo se han rellenado esos datos. Normalmente, todo lo que no se rellene en el mismo día en que se produce, es mucho menos fiable.
4. Significado: hay que interpretar si ante las mismas pruebas, ayer hubo 5 fallos, y hoy 10. ¿Qué ha cambiado en el código? ¿Y en el proceso? ¿Se han modificado los tests para que se justifiquen ese doble nº de fallos? ¿Ha habido un programador menos experimentado que haya estado tocando hoy el código? etc, etc. Hay que tener cuidado, porque seguramente los datos no nos van a dar las respuestas a las preguntas que busquemos (en este caso, buscamos la calidad del código).
5. Similar a la siguiente.
6. Las fórmulas (manuales o automáticas), pueden haber tergiversado el significado de los datos originales, eso hay que tenerlo en cuenta.
7. Hay que ver si estamos trabajando con los datos de forma consistente. El que haya variaciones (ayer 5 fallos, y hoy 10), puede tener muchos significados. Además, es posible que errores en diversas etapas del proceso de recogida y cálculo hayan alterado los datos o pervertido su significado.

Como resultado, siguiendo el ejemplo de que ayer teníamos 5 defectos en unit testing, y hoy tenemos 10, las preguntas pueden llevarnos a varias conclusiones:

• Se han alterado los casos de prueba, o el número de unit testings existentes.
• Por algún motivo, se han ejecutado más casos de prueba o más pruebas unitarias.
• El proceso automatizado o manual, ha cambiado.
• Las fórmulas usadas o la forma de recogida ha cambiado.
• Nuestra calidad de código es la mitad de ayer.

Estaremos tentados de ir directamente a la última conclusión. Sin embargo, es posible que cualquiera de las anteriores (o muchas otras), sean realmente las conclusiones. Como ingenieros de software, es nuestra responsabilidad llevar a cabo correctamente tanto el proceso como la interpretación de los resultados.

Fuente: Interpreting the CMMI: A Process Improvement Approach (by  Margaret K. Kulpa and Kent A. Johnson )

Beneficios de implantaciones CMMi

¡Ey, hoy es mi post nº 100! Pues nada, tras un auto-abrazo, paso al tema.

Recientemente he leído una presentación que mostraba, de la mano de Grupo Pragma Consultores, unos resultados de encuestas a empresas certificadas CMMi .

Las empresas estaban certificadas nivel 2 (80%) y nivel 3 (20%), y se trataba de empresas de España, Argentina y Chile.

Los resultados de la encuesta muestran, que en contra de los argumentos que esgrimen los detractores de estos marcos de trabajo, tras una implantación de CMMi se obtienen una serie de beneficios:

• Más del 90% observó mejoras en los tiempos/plazos.
• Alrededor del 70% observó mejoras en los costes. Esto se apreció, a pesar de considerar que una implantación CMMi tiene un alto coste inicial. Desde luego, el beneficio neto no se aprecia a corto plazo.
• El 100% observó mejoras más que apreciables en la calidad. Esto se apreció en una gestión más transparente, y un número de errores mucho menor.
• El 80% apreció una mejora sustancial de la satisfacción del cliente. Esto se aprecia principalmente debido a una mejor gestión del proyecto y de los requisitos, así como una planificación realista y adecuadamente comunicada a todos los involucrados.
• Más del 90% observó una mejor alineación de los objetivos del negocio con el desarrollo.

Los detractores de CMMi suelen alegar que éste modelo supone supone burocracia, exceso de documentación y sobrecarga de trabajo. Cuándo se les preguntó a los proyectos al respecto:

• Ante la pregunta de si se detectó sobrecarga de trabajo y en qué porcentaje, la respuesta está en todos los casos por debajo del 10%, siendo ese máximo de 10% la sobrecarga inicial en gestión. Por supuesto, una vez instaurados los procesos, la costumbre y la mejora continua producen una disminución progresiva en dicha sobrecarga de trabajo.
• Casi un 70% de los encuestados encuentra mucho aportado valor por la documentación que se generó
• Más de un 80% de los encuestados ve la documentación como algo provechoso (especialmente en los temas de estimaciones y métricas).

Finalmente, comentar que los resultados de la encuesta muestran que a la empresa, le proporciona de forma global unos interesantes beneficios:

• ROI (retorno de la inversión) se considera positivo en más del 70% de los casos
• Se generan nuevos negocios debido a la mejor percepción de los clientes, mejora en la comunicación con dichos clientes, y posibilidad de competir en mejores condiciones para conseguir concursos públicos, etc. Hay que recordar que para muchos clientes del sector público o privado, se exige CMMi nivel 2 ó 3 para optar a ganar un proyecto.

¿Significa esto que CMMi es bonito y maravilloso? ¿Todos los que se quejan de CMMi mienten?

Pues NO. A ver, CMMi es un modelo para la implantación de un marco de trabajo, que como ya he comentado otras veces, depende en su éxito de cómo se implanta. Las empresas no siguen CMMi. Lo que siguen son metodologías y procesos basados en CMMi. Unos procesos demasiado burocráticos pueden contentar a los gerentes, pero también enfadar y sobrecargar por ejemplo a los programadores. Por eso, la responsabilidad del fracaso sería en todo caso de los procesos implantados, no de CMMi.

¿Quién se preocupa de que todos en la empresa estén contentos con su forma de trabajo?

Pues la propia empresa, en su metodología y procesos, han de buscar ese equilibrio donde el control, el ligero aumento de documentación y la mejora continua, permitan lograr los objetivos marcados. Lo que no suelen tener en cuenta los detractores de CMMi es que la metodología que se usa, no se diseña para hacerles felices a ellos (que parece que todos queremos ser el ombligo del mundo!). La metodología resultante se enfoca a cumplir una serie de objetivos, que habrá definido previamente la empresa. Y es ahí donde el programador que tiene que hacer 2 o 3 documentos nuevos, lo puede interpretar como burocracia. De eso ya hablé en otro post (El Mito de la Burocracia).

Cuando hablamos de CMMI

Observo constantemente en blogs y comentarios frases como éstas:

• «La metodología SCRUM es mucho más ágil que CMMI»
• «CMMI es una metodología arcaica y excesivamente burocrática»
• «No tengo claro qué metodología usar en mi proyecto: CMMI, SCRUM, xxx»

¿Nadie se da cuenta? El problema es que en todas las frases, se está hablando de CMMI como metodología, y no lo es. Por tanto, es absurdo compararla con cualquier otra (he usado por ejemplo SCRUM, pero podría haber puesto cualquiera).

CMMI es un modelo de referencia. Según wikipedia: «es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software«. Realmente, los que hayáis estudiado CMMI más o menos a fondo, veréis que en este modelo no se dice cómo se han de hacer las cosas, sino qué cosas deben hacerse.

Os preguntaréis…¿hacerse…para qué? Pues para tener una metodología (conjunto de procesos) que cubran todos los aspectos necesarios, que cubran todas las necesidades de la gestión y el desarrollo. Es por eso que es absurdo comparar a CMMI con cualquier metodología (ya que no lo es). Es como lo de las peras y las manzanas: no se pueden comparar.

Otra forma impropia de hablar de CMMI es cuando se usa para hablar de excesiva burocracia, métodos arcaicos, poco ágiles, o como cuando se vincula con metodologías en cascada (las famosas Waterfall Methods). Aquí hay varios problemas que provocan esto:

• Excesiva burocracia: evidentemente, si algo no nos apetece hacerlo, pasará a segundo plano (ver mi reciente entrada sobre procrastinacion), aunque eso no signifique es es innecesario. Por desgracia, eso también ocurre si bajo nuestro punto de vista no es necesario. Por ejemplo, yo desarrollo software. No me gusta facturar al cliente, no me gusta hacer seguimiento de cobros…pero sin ello, ya puedo ser el mejor programador del mundo: no puedo vivir del aire. Yo, mi familia, todos necesitamos el dinero que cobramos. Luego el control de horas trabajadas, el control de pagos/cobros, y muchas otras actividades, son necesarias para la empresa. Cuando hablamos de burocracia, se nos olvida que no trabajamos para nosotros. Hay metodologías que por fin han involucrado a los clientes  (enhorabuena por el descubrimiento), pero siguen ignorando a la empresa en la que trabajan. Por desgracia, y es un mal endémico en nuestro sector, todavía hay quien cree que cobra por sus horas trabajadas, cuando en la mayoría de los casos, se cobra por cumplir un contrato.
• Métodos arcaicos: algo es arcaico o antiguo en comparación o referencia a otra cosa. Resulta divertido ver cómo los defensores de ciertas metodologías, las consideran muy modernas para unas cosas, y luego para defender que están arraigadas y no son algo inmaduro, acreditan estar basadas en métodos, prácticas, y otras referencias de 10, 20, 30 años o más. Por desgracia, en nuestro sector se consigue que algo sea bueno o atractivo, en base a destruir la reputación de todo aquello que le pueda hacer competencia.
• Agilidad: los métodos son tanto más ágiles, cuanto más rápidamente nos acercan a nuestros objetivos. Eso no significa que sean los más rápidos. Se nos olvida muchas veces, que para llegar antes, no es más importante correr mucho, sino tener claro hacia dónde debemos ir (y no desandar constantemente el camino). Esto me recuerda muchos proyectos en los que no se tienen claros los objetivos, ni qué hay que hacer, pero los jefes de proyecto insisten en «redoblar los esfuerzos». Por eso, las técnicas, prácticas y metodologías, serán sólo ágiles, cuando en las condiciones favorables, nos acerquen a nuestros objetivos de forma que se aumente el rendimiento.
• Desarrollo en cascada. Esto casi lo dejo para otro post, tan grande es la confusión que observo respecto a este término, y su vinculación con CMMI y muchos otros conceptos.

 CMMI es desde luego un método imperfecto a la hora de evaluar la madurez de las empresas y los procesos, pero tiene muchos puntos a su favor:

• No hay muchos métodos de evaluación de la madurez
• Es un método en constante evolución y mejora. Actualmente CMMI DEV está en su versión 1.3.
• Se integra muy bien con prácticamente todas las metodologías de ciclo de vida.
• Es un modelo extendido a nivel mundial, y está diseñado para comparar uniformemente a organizaciones de todo el mundo.
• Para las empresas, es un modelo de evaluación ventajoso: proporciona prestigio, y el «sello» de calidad queda referido a la empresa, no a sus individuos. Los individuos se van o vienen, pero los beneficios se quedan en la empresa.

Bueno , hasta ahora hemos visto que usar CMMI en comparación con otras metodologías, no es adecuado, y que se desprestigia injustamente a este modelo (en la mayoría de los casos, por ignorancia o para crear prestigio por comparación), pero no pensemos que por ello, es perfecto, ni tiene defectos. Me guardo para un post el detallar los problemas y defectos de CMMI como modelo, y su mayor talón de aquiles: las pésimas implementaciones como metodología que se hacen a veces, cuando el único objetivo es «tener el sello de calidad».

El mito de la burocracia

Con frecuencia me encuentro con rechazo a las tareas a realizar durante el proyecto, y en muchas ocasiones la respuesta tiene una raiz común: la gente las llama burocracia.

Si a un programador le pides que anote las horas que ha dedicado a hacer una tarea, lo tildará de burocracia. Sin embargo, si tiene que probar una nueva tecnología para la que existe la rara posibilidad de que se use en el proyecto, esas horas las considerará una inversión.

Hay una importante corriente de favor por metodologías y prácticas «ágiles», y es sorprendente la facilidad con que todo el mundo se apunta a «ser ágil» (aunque realmente hay poca gente que te sepa decir exactamente qué supone ser ágil). Muchos contestan que ser ágil, es básicamente, eliminar la burocracia.

El problema reside en que primero, esa definición de agilidad no es correcta, y además, tampoco existe un acuerdo en qué es la burocracia. En mi empresa nos hemos certificado CMMi nivel 3, y constantemente leo en internet un constante rechazo a CMMI, en muchos casos recibiendo la calificación de «burocrática».

Sorprendentemente, los equipos de trabajo que usan nuestra metodología raramente se quejan de burocracia. Las tareas que se realizan, hay que realizarlas si o si, ya que proporcionan la única forma de llegar a tener control sobre el proyecto. Además, las tareas que se realizan no se llevan a cabo por CMMI, sino por el valor que aportan al proyecto o a la organización. Las quejas surjen durante las fases de implantación de la metodología, lo que nos lleva a concluir que el problema es de formación y falta de conocimiento.

Por otro lado, la burocracia, se presenta como principal argumento de metodologías ágiles como SCRUM. Se busca en muchas ocasiones rechazar dos conceptos que en realidad tienen poco que ver entre sí, y mucho menos con SCRUM:

• CMMI
• Ciclo de vida en cascada

Para empezar, CMMI no es una metodología, como tampoco lo es el ciclo de vida mencionado. CMMI es un modelo de madurez. El ciclo de vida en cascada, como cualquier ciclo de vida, es un modelo más o menos teórico que presenta una forma de realizar las actividades. Normalmente lo que se busca con afirmaciones de este tipo es conseguir crear en el modelo CMMI una imagen de burocracia y antiguedad. Por confrontación, conseguiríamos obtener una imagen (ficticia como vemos), de modernidad y agilidad en SCRUM.

Vemos entonces que la burocracia, sin terminar de definirse como término (aunque está claro que es negativo), sirve como argumento positivo (por confrontación).

Mi opinión es que en la mayoría de ocasiones nos gusta escondernos en nuestro pequeño mundo, y llamamos burocracia a las actividades que no nos aportan directamente algo a nosotros mismos. En una escala comparativa, tendríamos tareas cuyo beneficio va a parar:

• Al individuo
• Al proyecto
• A la empresa

Las actividades que producen principalmente beneficio al individuo (actividades que producen satisfacción personal, autoformación, investigación, etc), no se consideran nunca burocracia. Los integrantes del equipo se sienten cómodos con ellas.

Las actividades que aportan al proyecto, son calificadas como burocráticas por las categorías más bajas (programadores principalmente). Las necesidades de la gestión del proyecto no les importan, y la supresión de estas actividades, serían a su modo de ver, síntoma de agilidad.

Las actividades que aportan a la empresa, amplían el conjunto de individuos que las rechazan, incluyendo a las categorías medias/bajas.

Como conclusión, vemos que normalmente la definición de burocracia está asociada de forma egoísta o personal a unas actividades u otras, en función de nuestro rol. Se echa en falta pues, una visión más global de las actividades en los proyectos, y de su relación con los distintos roles. Un punto por ejemplo que no se suele tener en cuenta es el coste o beneficio en cada actividad, que suele ser percibido de forma diferente en función del rol en el proyecto.

Evaluación de madurez CMMi nivel 3

Recientemente me he visto involucrado en un proceso de evaluación de madurez CMMi Dev Nivel 3. He sido al mismo tiempo:

• Desarrollador de la metodología compatible CMMI
• Auditor de proyectos
• Parte del equipo evaluador CMMI
• Preparador de base de datos de evidencias

Tras un SCAMPI A, se adquiere una nueva experiencia, y se amplía la visión del mundo de la calidad y del desarrollo del software.

En el mundo del desarrollo software, hay muchas menos novedades de las que nos quieren vender, y de las que sin embargo los neófitos se hacen eco constantemente, abrazándolas como el nuevo mantra que nos sacará de la crisis y permitirá que los proyectos por fin tengan éxito (¿alguien tiene claro el concepto de éxito?).

CMMi lleva muchos años en el mercado (e incluso ha ido cambiando su nombre). Sin embargo, en muchos ámbitos se percibe como un dinosaurio. Leo en blogs a gente que habla (supuestamente por experiencia o conocimiento directo) de que CMMi es esto o aquello, que no resuelve la problemática, y que los proyectos siguen fallando.

El caso es que yo sigo observando proyectos que a pesar de usar metodologías y técnicas ágiles, fallan igualmente. ¿Dónde está el problema? ¿No era XP la solución? ¿No era Scrum la solución?