Estudios de balística en el software

En los viejos cuentos y leyendas europeos se decía que una bala de plata es el único instrumento capaz de acabar exitosamente con un hombre lobo. Del mismo modo, en la ingeniería del software se habla de bala de plata cuando se consigue una metodología de desarrollo capaz de ser aplicada con éxito en todo tipo de proyectos. El problema en ambos casos es que la leyenda no se cumple. En el primero porque los hombres lobo son sólo eso: materia de cuentos. En el segundo porque las metodologías infalibles son aún más legendarias que los licántropos.

En realidad no es que no existan buenas metodologías en el desarrollo de software, sino que cada metodología es aplicable a un contexto determinado. De hecho incluso dentro de una misma organización la metodología tomada como referencia debe ser evaluada y en su caso adaptada para cada proyecto concreto, en función de características diversas como son el número y la experiencia de los participantes, la relación con el cliente, los plazos, etcétera.

En resumen, hay que evitar ser un talibán de la metodología. La definición de los procesos de desarrollo en una organización debe ser configurable para cada proyecto, de forma que no se pierda el foco de lo realmente necesario para el éxito del mismo. Eso sí, los procesos resultantes de la adaptación no deben desviarse de los mínimos criterios de calidad impuestos por la organización. Se trata de modificar el cómo cumplir con los objetivos, no los objetivos en sí.

Institucionalizando el nivel 2 de CMMI en el Departamento de I+D de una PYME

Por su interés enlazo el vídeo de la ponencia que realizamos en la Universidad Carlos III dentro del ITGSM 2011 el pasado junio sobre nuestra propia experiencia implementando el nivel 2 de CMMI en el Departamento de I+D de Answare Technologies.

En él explicamos los principales desafíos que supuso la adaptación de las diversas áreas de proceso de CMMI al modelo de negocio del I+D+i, así como las pautas que a nosotros mejor nos funcionaron para implantar exitosamente las prácticas en la organización.

La ponencia surgió a raíz del interés de la organización del congreso en difundir el contenido del artículo -del mismo nombre que la ponencia- que se puede encontrar en este enlace.

Gestión de imprevistos

Cuando nos encontramos a tope de trabajo, con varios proyectos encima de la mesa y multitud de tareas por ser completadas, suele ser el momento propicio para que aparezcan los imprevistos, popularmente conocidos como marrones. Los imprevistos pueden llegar desde varias direcciones, y sólo son verdaderos marrones si su resolución es urgente y obligatoria, más incluso que el resto de los proyectos: un cliente solicitando un favor al que no nos podemos negar, un jefe que desvía sus tareas aguas abajo, un compañero que cae enfermo… Los imprevistos en algunos casos son síntoma de una planificación poco cuidada, pero en otros, como su propio nombre indica, eran prácticamente imposibles de prever.

Ante un imprevisto, un equipo de desarrollo cuenta con cuatro alternativas, que enumeraré en orden desde la más deseable hasta la que debe ser tomada como último recurso.

  1. Elegir a una persona con la formación adecuada que pueda retrasar sus tareas sin impactar en la fecha de entrega. Esta opción es la más deseable porque las tareas que la persona está realizando se encuentran fuera del camino crítico, y por lo tanto su retraso, dentro de un límite -concretamente la holgura de sus tareas asignadas-, no impacta en el trabajo de los compañeros ni en las fechas de entrega.
  2. Retrasar la fecha de entrega. Si no se dispone de recursos para afrontar las tareas que son desviadas por el marrón, y estas tareas ya se encontraban ajustadas de fechas, lo primero que se nos pasa por la cabeza es retrasar el hito. En este caso, por razones obvias, más nos vale disponer de un buen negociador en el equipo para interceder ante el cliente.
  3. Disminuir el alcance del proyecto. Si bueno debe ser el negociador que retrase la fecha de entrega, mejor debe ser el negociador que recorte los objetivos del proyecto. Cuando las tareas asignadas no pueden resolverse en tiempo, es evidente que determinadas funcionalidades y características del producto han de verse recortadas. Una disminución del alcance reducirá con total probabilidad el valor percibido por el cliente y por lo tanto una rebaja en el precio final será prácticamente obligatoria.
  4. Hacer horas extra. En el caso de que las horas extra estén bien pagadas y el equipo esté motivado, es muy posible que ésta no sea ni mucho menos la opción menos deseada para afrontar el imprevisto, pero también es cierto que este caso ideal no siempre se da y que por lo tanto el exigir un esfuerzo adicional del equipo para cumplir con el imprevisto y con el resto de tareas a tiempo y dentro de los objetivos marcados, va a exigir grandes dosis de mano izquierda y motivación por parte de los responsables de la organización.

En realidad el afrontar imprevistos es muy común en el mundo del desarrollo de software, y rara vez no se resuelven recurriendo al uso de horas extra. Que esos esfuerzos extraordinarios sean ocasionales entra dentro de lo perfectamente normal. El problema viene cuando se convierten en una práctica habitual.

¿Por qué los jefes de proyecto ganan más que los programadores?

Estaba preparando un artículo sobre gestión básica de requisitos en los proyectos de software, pero he preferido dar un volantazo y exponer mi punto de vista sobre un asunto que se discute estos días en la red sobre por qué los jefes de proyecto cobran más que los programadores.

Según he podido ver en artículos como éste (bien es cierto que tan solo se trata de una traducción al español de la respuesta dada por un internauta en stackexchange), culpan de este supuestamente injusto hecho ni más ni menos que a nuestra sociedad [sic], aduciendo una visión de la remuneración orientada a la jerarquía y un modelo de gestión poco menos que represor. Como prueba de ello, completan su análisis exponiendo el vocabulario habitual entre los jefes de proyecto: recursos, procesos, eficiencia, control, etc. En contraposición expone el caso de las compañías de software que funcionan de forma análoga a como lo hacen los estudios cinematográficos, en los que cada miembro es remunerado en función del valor que aporta al producto final independientemente de su posición en la jerarquía.

En mi opinión en esta manera de explicar por qué los jefes de proyecto ganan más que los programadores radica un profundo desconocimiento de las leyes del mercado. El hecho de que el trabajo de los programadores sea más complicado o no que el de los jefes de proyecto es aquí completamente irrelevante. El problema radica en la escasez, o lo que es lo mismo, en la ley de la oferta y la demanda. Un jefe de proyecto debe tener una serie de habilidades que, independientemente del valor que aporten al producto final (muy difícil de medir ya que se trata en su mayoría de un trabajo de gestión) y de la complejidad que implica el desarrollo de dichas habilidades, lo cierto es que escasean más que las habilidades aportadas por los programadores.

Con esto no quiero decir que cualquiera pueda programar o que los buenos programadores abunden, nada más lejos de mi intención. Lo que quiero decir es que si cualquiera no puede programar, menos aún puede ser jefe de proyecto. Y si los buenos programadores escasean, más aún escasean los buenos gestores.

El nivel 2 de CMMI

“Y al principio fue el caos…”

Una de las particularidades de CMMI como modelo de procesos para la fabricación de software es que considera perfectamente factible la entrega de productos de acuerdo a las especificaciones originales de los mismos aún a pesar de no cumplir ninguna de las prácticas de calidad que su propio modelo predica. Eso sí, sufriendo al menos dos inconvenientes nada despreciables: por un lado la necesidad de contar con el esfuerzo de los llamados héroes para superar el trámite y por otro, la pérdida de oportunidades por parte de la organización de acumular conocimiento para superar futuras situaciones de riesgo, reforzándose el círculo vicioso que lleva a una empresa de desarrollo de software a ser poco más que la suma de la experiencia de sus miembros en un momento dado, en vez de ostentar un conocimiento propio.

Este estado es el que CMMI reconoce como Nivel 1 de madurez: los productos se entregan y aparentemente funcionan bien, pero acostumbran a sobrepasar las previsiones, si es que había tal cosa, de coste y calendario.

Un primer paso en el camino hacia la madurez, según el modelo CMMI, es trepar hasta el Nivel 2: el nivel Gestionado. Aunque existen consultores y expertos que aseguran que el paso más complejo en la larga carrera de la certificación es el avance del nivel 2 al 3, a mí personalmente me resulta complicado pensar que puede haber algo más difícil para una organización que pasar del caos absoluto a la definición de procesos adecuados para al menos siete áreas del desarrollo: la Gestión de Requisitos, la Planificación, la Monitorización del Proyecto, el Aseguramiento de la Calidad, la Gestión de Configuraciones, la Medición y Análisis y la Gestión de Acuerdos con Proveedores. Ni qué decir tiene que según se va avanzando de nivel, nuevas áreas de proceso surgen con nuevas metas que alcanzar y nuevas prácticas que implementar.

Además, no conviene olvidar que existe una serie de prácticas generales aplicables a cada una de las siete áreas del nivel 2, que son si cabe más importantes que las metas particulares de cada área. A menudo estas prácticas genéricas son despreciadas por los responsables de los procesos en las organizaciones, que las ven como un agregado al modelo sin demasiado que aportar. Craso error. De hecho las prácticas genéricas son la argamasa que junta todas las áreas y da consistencia al proceso.

CMMI para principiantes (y III)

Los niveles de madurez de CMMI

Como comenté en el post anterior, CMMI está representado escalonadamente en 5 niveles de madurez, que califican a las empresas según la calidad de su proceso de producción. Estos niveles, además de por su correspondiente ordinal (del 1 al 5), se conocen por el adjetivo que los describe: Inicial, Gestionado, Definido, Cuantitativamente gestionado y el más alto de todos, Optimizado. Veamos brevísimamente en qué consiste cada uno de ellos.

Nivel 1 (Inicial): La organización no sigue conscientemente las prácticas especificadas en el modelo CMMI, pero de una forma u otra consigue que sus productos salgan al mercado. Supone una gran dependencia de los llamados héroes, profesionales sobresalientes que con su esfuerzo y habilidad personal sacan a la empresa del atolladero. La organización no genera conocimiento y la pérdida de estos héroes supone generalmente la pérdida de la capacidad acumulada.

Nivel 2 (Gestionado): Supone el cumplimiento, por parte de cada proyecto, de varias áreas de proceso de CMMI relacionadas con la gestión de requisitos, la planificación, la monitorización, la gestión de la configuración, el aseguramiento de la calidad, el acuerdo con los proveedores y la medición y análisis de los procesos. Se trata de asegurar que las buenas prácticas se mantengan independientemente de los vaivenes coyunturales que afecten a la organización. El conocimiento reside en la organización.

Nivel 3 (Definido): En este nivel, los procesos ya no sólo se definen de manera independiente para cada proyecto sino que toda la organización goza de unas pautas comunes. Se instaura una serie de procesos que, llevando la explicación al paradigma de la orientación a objetos, suponen la clase sobre la cual se instancian los proyectos. En resumidas cuentas, la empresa goza de una plantilla bien caracterizada que al ser aplicada a cada caso particular, genera un proyecto.

Nivel 4 (Cuantitativamente gestionado): Llegados a este punto, la organización ya no sólo gestiona los proyectos mediante procesos bien definidos, sino que además, se fijan objetivos tangibles que los procesos deben cumplir en lo relativo a su calidad, de manera que se analizan estadísticamente los procesos, propiciando una exactitud y predictibilidad, si se me permite el palabro, de la que no goza el nivel anterior.

Nivel 5 (Optimizado): En el nivel más alto de CMMI, la organización entera experimenta una optimización continua de los procesos a través de la innovación en los mismos y de las mejoras tecnológicas. Se modifican y reconducen los procesos en función de los defectos revelados durante el análisis estadístico.

¿Y cómo se le reconoce oficialmente a una organización su nivel de madurez?

La evaluación, conocida como Appraisal, del grado de madurez de una empresa es llevada a cabo por un equipo que debe estar formado, según el método SCAMPI (Standard CMMI Appraisal Method for Process Improvement), por un evaluador oficial (Lead Appraiser) formado por el SEI y por un conjunto de personas que deben haber recibido el curso de introducción a CMMI y entre las que se puede encontrar, y de hecho es lo habitual, personal de la propia organización. Este enfoque de que gente de la propia organización evalúe el grado de madurez que su empresa merece puede parecer chocante, y con razón. Sin embargo de una forma u otra el complejo método SCAMPI se las apaña para asegurar la objetividad, o al menos eso garantiza el SEI.

Se trata de una prueba exigente, que puede llegar a durar varias semanas, durante las cuales, entre otras cosas, se recogen y analizan las evidencias de cumplimiento de las áreas de proceso a evaluar y se entrevista a los involucrados en la organización. Al finalizar la Appraisal, el evaluador emite un informe que debe ser confirmado en Estados Unidos por nuestros amigos del SEI.

Conclusiones

En resumen, CMMI, y más concretamente CMMI for Development, puede ser en mi opinión un estupendo modelo para la mejora de procesos en una empresa, si es que esta organización se adecúa al modelo, es decir: la organización persigue la mejora real antes que la certificación, está dispuesta a asumir el elevado coste que conlleva la implantación y evaluación y su tamaño y características evitan que CMMI suponga una elevada carga adicional a los proyectos.

<< Ver CMMI para principiantes (II)

CMMI para principiantes (II)

¿Eso de las prácticas, cómo va?

Es sencillo, y a la vez complejo. CMMI-DEV (El CMMI for Development del que hablé el otro día), se divide en áreas de proceso, 22 en total, que a su vez se dividen en metas para cubrir satisfactoriamente el área. Para complicar un poco más el tema, cada meta se compone de varias prácticas específicas, que son las que realmente nos aportan la chicha de lo que hay que cumplir. Por si fuera poco, además de haber una serie de metas y prácticas específicas por cada área, existen metas genéricas, con sus respectivas prácticas genéricas, que deben de cumplirse para todas las áreas. Incomprensible, ¿no? Veámoslo entonces con un ejemplo:

Una de las 22 áreas de proceso es REQM, Requirements Management. La gestión de requisitos, según CMMI, debe cumplir una única meta específica: gestionar los requisitos. De cajón. ¿Y qué es gestionar los requisitos? Eso se explica mediante las cinco prácticas específicas que componen la meta de gestionar requisitos. A saber:

SP1.1 Entender los requisitos: desarrollar un entendimiento sobre el significado de los mismos con sus proveedores.

SP1.2 Acordar los requisitos: obtener el acuerdo de todos los participantes en el proyecto.

SP1.3 Gestionar los cambios de los requisitos: gestionar los cambios mientras los requisitos evolucionan durante el proyecto.

SP1.4 Mantener la trazabilidad bidireccional de los requisitos: mantener la trazabilidad entre los requisitos y los productos de trabajo.

SP1.5 Asegurar la consistencia entre los requisitos y los productos de trabajo: mantener alineados los planes y el trabajo realizado con los requisitos acordados.

Además, la gestión de requisitos debe cumplir una serie de prácticas genéricas que son aplicables de manera transversal a todas las áreas (REQM no iba a ser menos). Éstas son, entre otras: establecer una política organizacional para la gestión de requisitos, diseñar y mantener un plan al respecto, proveer recursos, asignar responsabilidades, etc.

Las otras 21 áreas tienen una estructura similar, si bien pueden constar de más metas. Como se observa en el ejemplo de REQM, el modelo no explica cómo hay que implementar las prácticas, sino simplemente qué es lo que hay que obtener (entendimiento, acuerdo, gestión de cambios, trazabilidad y consistencia).

Pero… yo he leído que CMMI va por niveles, ¡no sabía nada de 22 áreas!

Paciencia. Existen dos representaciones alternativas que permiten trepar por CMMI en la búsqueda constante de la excelencia. Una es la representación continua, que permite seleccionar en cuál o cuáles de las áreas queremos mejorar y centrarnos en las metas y prácticas de ese área independientemente de lo bien que gestionemos las demás. Es una opción útil para organizaciones interesadas en la mejora de determinados aspectos del desarrollo, conscientes de sus debilidades y poco interesadas en la obtención de certificados, o al menos no obsesionadas con ello. Por ejemplo, una empresa puede estar preocupada por cómo se gestionan los requisitos y cómo se realiza la medición y análisis de los datos de sus proyectos y acudir por tanto únicamente a las áreas REQM y MA de CMMI, dejando de lado las 20 restantes.

Sin embargo, la opción más habitual es emplear la representación escalonada, que divide las 22 áreas en 5 niveles de madurez, de tal forma que las organizaciones poco conocedoras de sus propios defectos (la mayoría, para qué negarlo), obtienen una hoja de ruta sobre la que emprender su camino hacia la excelencia. Cada nivel supone cumplir las metas de una serie de áreas de proceso nuevas, y además, seguir cumpliendo las de los niveles anteriores. Una empresa que cumpla las 22 áreas de proceso y además satisfaga todas las metas genéricas, tendrá un nivel de madurez 5, la crème de la crème de CMMI. Sólo hay tres empresas así en toda España, así que nada de lanzarse en tromba a por el máximo nivel.

En el próximo post hablaré más en detalle de estos niveles y de cómo CMMI evalúa el grado de madurez de las organizaciones.

<< Ver CMMI para principiantes (I)

Ver CMMI para principiantes (y III) >>

CMMI para principiantes (I)

A lo largo de los próximos posts trataré de explicar brevemente qué es y en qué consiste CMMI, desde el punto de vista de un principiante que por el hecho de llevar pocos meses familiarizado con el modelo, conoce y aún sufre las dudas que asaltan a cualquier profano en la materia.

¿Qué es CMMI?

CMMI son las siglas de Capability Maturity Model Integration. Es un modelo desarrollado por el Software Engineering Institute para la mejora de los procesos de las empresas de software que califica las compañías según su nivel de madurez. Por proceso se entiende un conjunto de fases sucesivas que llevan a la obtención de un resultado, y por nivel de madurez, el grado de calidad que alcanzan los procesos. Recientemente el modelo fue aupado a la versión 1.3.

Así pues, y en pocas palabras, CMMI establece una serie de buenas prácticas que las empresas deben cumplir para ser consideradas de un grado de madurez determinado a la hora de generar resultados. Pero ojo: CMMI no te dice cómo llevar a cabo estas prácticas, simplemente te indica qué debes cumplir. Es cosa de cada empresa buscar el modo de cumplir con dichas prácticas (y es aquí donde comienza el gran negocio de los consultores en torno a CMMI, pero ésa es otra historia).

Existen tres tipos de CMMI, nombrados como constelaciones por algún gurú de las altas esferas. Está la constelación CMMI for Acquisition, para la mejora de procesos de contratación externa, la CMMI for Services, para el establecimiento y la entrega de servicios, y la que más nos interesa y de la que hablaré a partir de ahora: CMMI for Development, para la mejora del desarrollo de productos, esto es, software.

¿Y por qué tiene tanto prestigio?

Es una gran pregunta, pero lo cierto es que hoy en día CMMI es el certificado de moda para empresas de desarrollo de software por encima de otras muchas en principio igual de exigentes o completas. Atrae inversiones y genera clientela, eso es un hecho. Tal vez sea por tratarse de un invento americano auspiciado por el Departamento de Defensa, tal vez por la solidez de sus evaluaciones (conocidas como SCAMPI, y de las cuales hablaré otro día) o tal vez, quién sabe, porque realmente sea muy bueno.

En el próximo post hablaré sobre la división de CMMI en áreas, metas y prácticas y los diferentes caminos (dos, de hecho) que existen para certificarse en el modelo.

Ver CMMI para principiantes (II) >>