Por dónde comenzar

En un grupo dedicado a CMMI, un participante preguntó: "es el área de REQM (gestión de requerimientos) un buen lugar para comenzar con CMMI?". Yo no me atrevía a contestarle, en parte porque no quería exponerme a una quema por hereje.

CMMI plantea un área de proceso de gestión de requerimientos (REQM) en su nivel 2 con un solo objetivo específico: gestionar los requerimientos. Puedo imaginarme que significa 'Gestionar los Requerimientos', pero si uno anda corto de imaginación, el SEI proporciona una guía.

El SEI define como único componente obligatorio del modelo de CMMI a los objetivos específicos y generales, mientras que las prácticas son componentes esperados (o deseables?). Menos obligatoria es la, emho, siniestra lista de productos típicos (que es capaz de incluir un producto llamado ‘lista de criterios para distinguir las fuentes apropiadas de requerimientos’), así que nos quedamos solo con la descripción del objetivo.

La idea, según la definición de CMMI, es mantener un conjunto de requerimientos aprobados y consensuados a desarrollar. Ni más ni menos que un backlog.

Nada en la definición de CMMI dice que ese backlog no debe cambiar, ni que el nivel de consenso debe ser el mismo para todos los requerimientos del backlog. Es perfectamente posible que convivan en el backlog requerimientos de los que se tiene un entendimiento profundo con algunos que son comprendidos vagamente. Si esto no fuera aceptable para CMMI, daría lo mismo: sería inevitable. El problema viene cuando uno trabaja en un entorno donde no se acepta que los niveles de entendimiento diferentes generan grados de compromiso diferentes.

La gestión de requerimientos según CMMI implica mantener las relaciones entre los requerimientos y de estos con el plan de proyecto y los productos producidos. Esto es algo que uno puede hacer en la forma tradicional, armando planillas donde se relacione cada requerimiento con cada tarea identificada con cada producto de trabajo. Y cada producto podría ser un componente identificado en los modelos de diseño. Y lo mejor, hacer todo eso de entrada, antes de tirar una sola línea de código.

También se podría entender que el producto en un producto de software es el módulo a ser desplegado. Así, un determinado requerimiento está relacionado con un cierto build de una cantidad de módulos (si tenemos un proyecto grande), y la relación entre un requerimiento y el plan se completa indicando la fecha en que suponemos liberaremos el requerimiento, si es que la sabemos. Y por supuesto, no tenemos que entender como encajan todos los requerimientos antes de comenzar a desarrollar el primero, porque el entendimiento es un proceso iterativo.

Yo veo una pequeña diferencia entre las dos opciones, y es que la primera es irrealizable.

Además, CMMI también indica la necesidad de la gestión de cambios de requerimientos. Los agilistas acuerdan (acordamos) en que el control de cambios no debería servir para impedir el cambio, pero es útil conocer la tasa de cambio de un backlog porque es útil saber cuan bien venimos entendiendo el producto a construir.

Además, me gustaría agregar un detalle: recuerdo los valores ágiles de responsabilidad, honestidad, y demás virtudes. Pero ocurre que la gente es gente, y cuando las papas queman y alguien pregunta por determinados retrabajos o por qué se ha invertido seiscientas horas de desarrollo en algo que debería haber tardado doscientas, no es descabellado esperar que quien nos ha guiado a través de un camino sinuoso intente endilgarle la responsabilidad a otro. Quiero decir: que un Product Owner que nos ha hecho trabajar y retrabajar haciendo una cosa y luego la contraria continuamente intente explicar el poco valor conseguido luego de un tiempo considerable hablando de la falta de habilidades técnicas de los programadores.

Pienso que quizá no todos los requerimientos del backlog deban ser sometidos al control de cambios, solo aquellos donde se ha consensuado un cierto nivel de entendimiento, ya que muchos requerimientos del backlog ingresan a él simplemente como recordatorios de que algo hay que hacer respecto de un determinado tema. Pero aún así, el control de cambios es necesario.

Así planteadas las cosas, no se si el área de REQM es un buen lugar para comenzar por CMMI. Lo que me queda claro es que si no se ha comenzado a pensar como gestionar los requerimientos de un proyecto de software, no se está en condiciones de comenzar el proyecto. Dicho de otra manera, REQM no es un buen lugar para comenzar con CMMI, es un lugar por el que tenés que comenzar salvo que quieras llevar tu proyecto al desastre.

CMMI y la agilidad: el largo y sinuoso camino a la paz

Ya había escrito sobre el asunto, basado en lo que SEI había publicado alguna vez. Hace unos meses, el SEI publicó un artículo mucho más extenso sobre la relación de CMMI y Ágil, analizando la historia de CMMI y del enfoque ágil, los problemas de comunicación entre ambas comunidades, y de la posibilidad de coexistencia.

En el enfrentamiento (si es que se puede usar esta palabra) entre ambos paradigmas, es el SEI el que, desde hace un tiempo, se ha encaminado a mostrar que la confrontación es, no solo innecesaria, sino que perjudicial.

Por su parte, la comunidad ágil, en tanto comunidad, no tiene una voz unificada: las reacciones que he escuchado incluyen la declamación de victoria (el SEI se rinde ante la victoria de la agilidad y no quiere perder su base de cliente), la indiferencia, o el acuerdo con la visión del SEI. Yo tiendo a compartir esta última opinión.

En este artículo, que no es una excusa para no leer el documento original, recorro los puntos que me parecen más interesantes. El documento se defiende de las acusaciones que relacionan CMMI con cascada, diciendo algo que es cierto: CMMI es básicamente un conjunto de objetivos, y las prácticas no son más que puntos de partida que sirvan para guiar al que adopte CMMI en la forma de lograr esos objetivos.

CMMI no es un estándar, lo que hace que esas prácticas no sean obligatorias. CMMI está injustamente asociado con el desarrollo en cascada: las prácticas y los objetivos no son procesos, nada específica que se deban ejecutar en un determinado momento del proyecto. El documento desliza críticas a sus propios appraisals por no tener en cuenta que CMMI no establece requerimientos, sino un marco para organizar el análisis y las acciones de mejora, diciendo textualmente que:

"However, for people and organizations that do not have the skills or experience to understand, interpret, and implement the practices and goals to their specific contexts, the informative material takes on the mantle of requirements. This situation is also true for appraisal teams and lead appraisers. Thus, the over-emphasis on specific model examples, typical work products, and subpractices often results in prescriptive processes with little gain in quality or organizational performance. "

Salvando el hecho de que a pocos puede culpar el SEI más que sí mismo de este problema (tal vez debe revisar a quienes le da patente de appraiser) la frase me parece gran resumen: el problema es que se toma el marco de CMMI, pensado para guiar y ayudar a pensar, analizar y actuar como requerimientos que toman la fuerza de mandamientos.

Yo veo un problema adicional, e iría más lejos: veo valor en CMMI, pero no veo valor en la certificación de CMMI. El hecho de que el mismo SEI cuestione a sus appraisals en un documento público no mejora mi apreciación de la certificación precisamente. Pero el problema, emho, no es este (que es coyuntural) sino otro (más bien estructural): yo en mis procesos de desarrollo hago unas cuantas cosas, que tienen que ver con algunas áreas de proceso de CMMI (como por ejemplo Verificación, Validación y hasta Análisis y Resolución de Decisiones), pero no me detengo a dejar 'rastro' (documentos formales) de estas actividades porque decido que no aportan valor. Eso provoca que un SCAMPI juzgue que mi proyecto no cumple con los objetivos de esas áreas de proceso. Me encuentro con un problema: si bien el proceso aporta valor, para llegar a la certificación tengo que perder valor.

Definitivamente, y dejando de lado cuestiones comerciales, la certificación no agrega valor.

Otro aspecto interesante del documento es su análisis histórico. Se hace una recorrida por la historia del desarrollo de CMMI, partiendo de los problemas del DoD y su necesidad de resolverlos. Admite que la asociación Cascada/CMM está justificada, ya que CMM se focalizaba en una serie de procesos y actividades que intentan obtener la descripción acabada de lo que hay que hacer antes de comenzar. Es una pena que no pueda ver de primera mano esto, ya que nunca leí nada de CMM de primera mano del SEI y han retirado la especificación, dejando solo información para la actualización de una a otra.

Menciona, además, algunas características del entorno que vio nacer a CMM: se trataba de un entorno donde lo que se buscaba era cubrirse, no buscar la mejor solución. Esto estaba generado por la naturaleza de entidad estatal del DoD y su necesidad de registración y transparencia para cualquiera que preguntara que se estaba haciendo con el dinero público, la forma de contratar y la naturaleza de los problemas que resolvían: software relacionado al control de aviones, misiles, instrumental médico y cosas por el estilo. Este último punto (negar la agilidad para desarrollos donde esté en juego la vida humana) es discutible, y no lo tengo claro: aplicaría un método ágil para construir el software de control de un misil?.

Como dice el artículo, lo que puede aportarle CMMI a un enfoque ágil son métodos y prácticas para apoyar y guiar la adopción de metodologías ágiles en una organización: básicamente, foco en la definición e integración de los equipos y el proceso. No es que no se pueda guiar la adopción de un enfoque ágil en una organización grande y compleja sin CMMI, pero CMMI ayuda a que los esfuerzos de adopción y expansión del enfoque ágil no queden en el folclore oral de la organización.

Asimismo, se reconocen algunos puntos que ningún agilista está dispuesto a negar: en necesario acordar una visión global de la arquitectura, a veces es necesario escribir documentación y, en definitiva, sin algo parecido a un proceso nos vamos al demonio.

Es muy interesante la comparación que se hace entre el paradigma ágil y CMMI en una serie de puntos. En particular, me interesaron dos puntos:

• El primero, que tiene que ver con el foco en la organización: mientras CMMI se focaliza en la organización completa, el paradigma ágil se focaliza en cada proyecto y en el equipo. Creo que vale la pena recordar que la focalización en la organización puede llevarnos al peligro de querer optimizar el funcionamiento de la operación de la organización y no del proyecto, y esto es, definitivamente, un peligro. Trato de explicarme: puestos a mirar la organización como un todo, nos podríamos sentir tentados de reducir los tiempos muertos de un equipo de analistas, cuando en realidad, desde el punto de vista de un proyecto complejo y particularmente sensible, es conveniente asumir esos tiempos muertos. No veo mayor problema aquí siempre que se recuerde que, a veces es conveniente que el foco esté en el proyecto antes que en la organización.
• El segundo, es el que tiene que ver con la confianza: el paradigma ágil requiere la confianza casi como un prerrequisito. Yo veo esto como una debilidad, porque a veces, hay que hacer cosas aún cuando no hay confianza entre las partes. Vamos, en algún momento se empieza y uno no confía la primera vez.

Y por último, lo mejor: el SEI me da la razón a mí (ja) en que la evidencia de que la agilidad funciona es, hoy por hoy, puramente anecdótica. Esto no implica que la agilidad no funcione, sino que es necesario un esfuerzo de formalización de los resultados.

Ilusiones y Certificaciones

Estos últimos años, la revolución cognitiva se ha estado extendiendo hacia los libros de divulgación. También es probable que uno, en sus esfuerzos infructuosos para dejar de ser la bestia inculta que es, haya dado por casualidad con los autores que se dedican a escribir sobre el asunto (Steven Pinker, Noam Chomsky, Thomas Kida, por ejemplo) para creer, como el estudio mismo de la cognición explica, que la fiesta comenzó cuando uno dio con ella (o dicho más generalmente, que uno entiende como la situación 'normal' a la que se conoció en el primer acercamiento).

Encuentro estos libros sumamente interesantes. Me interesa saber que parte de lo que somos está en nuestra naturaleza y que parte ha sido moldeada por el ambiente. Por otra parte, encuentro el estudio sobre la cognición (en particular el estudio de los sesgos cognitivos), además de muy interesante, importantísimo para mi trabajo diario: saber en que trampas suele caer nuestro proceso intelectual podría ser útil, si es que tuviéramos la esperanza de hacer algo para evitarlas.

Hace poco, vía Diego Navarro he conocido a Nassim Taleb. Taleb, un simpático (es un decir) ex agente de bolsa, anda por el mundo gritandole a quien quiera oirle que el rey no solo está desnudo, sino que además es gordo, feo y bastante tonto: nos recuerda que suponer que sabemos algo sobre el futuro comportamiento de sistemas que, por su propia naturaleza, son altamente volátiles es caer víctima de un sesgo cognitivo llamado ilusión de control. Esto es, creemos erróneamente que podemos prever, al menos con cierto grado de aproximación, qué va a suceder. Y lo peor es que sobre esas predicciones fallidas, falsamente rigurosas, decidimos nuestra conducta y tomamos riesgos.

Taleb compara el uso de estos modelos predictivos con la medicina del siglo XVIII: los médicos y los pacientes suponían que sus rudimentarios procedimientos eran, al menos, mejor que nada, cuando en realidad lo mejor que uno podía hacer era alejarse de los médicos y sus tratamientos nocivos ( la mala interpretación de esta situación dio nacimiento a una de las pseudociencias más exitosas: la homeopatía. Pero ese es otro tema).

En forma análoga a los médicos de antaño, nosotros pensamos que nuestra 'evaluación del riesgo' es mejor que nada. Nos dan escalofríos de placer cuando nuestra evaluación del riesgo es cuantitativa y cuando le asignamos probabilidades a los sucesos que identificamos. Que no haya la más mínima evidencia de que las probabilidades que estimamos tengan alguna relación con la realidad no nos impide disfrutar como enanos haciendo esto. Incluso más, tampoco nos importa que lo que termine por pasar no haya sido identificado siquiera con una probabilidad baja en nuestras predicciones.

Es divertido leer a Taleb (bueno, sería más divertido si uno viviera en Marte). Es divertido reírse de los financieros. Al fin y al cabo, nosotros somos informáticos, no tenemos esos modelos predictivos y ya mirábamos con sorna a los managers que hacían matrices de cuantificación de riesgos. Estamos a salvo de esta...

... No, yo no creo que estemos a salvo. Nosotros caemos en nuestras propias versiones de la ilusión de control. Creemos que podemos controlar los riesgos inherentes a la selección de proveedores o a la selección de personas. Y creemos que los podemos controlar por medio de una certificación de una entidad venerable, que nos garantiza que la-empresa-que-desarrolla-software cumple con el nivel cinco de CMMI. O que la-persona-que-lidera-proyectos es Scrum Master o PMP o ambas cosas, o alguna otra cosa. O que la-persona-que-gestiona-infraestructura tiene una certificación en ITIL.

Antes me preguntaba si saber de nuestros sesgos cognitivos nos abre la posibilidad de hacer algo. Creo que si no podemos hacer nada, al menos sí podemos no hacer algo: podemos dejar de experimentar la sensación de confianza tan hija de la ignorancia y tan buena para el desastre. Al fin y al cabo, como clientes, que un proveedor haya pasado un SCAMPI no baja nuestro riesgo, así como que el gerente sea PMP no implica que el riesgo del proyecto esté bajo control.

No niego la utilidad de los marcos teóricos que sistematizan (con suerte dispar, hay que admitirlo) el conocimiento adquirido por la industria y dan la oportunidad de encontrar los propios puntos débiles, como señala Martin Fowler. Me corto las venas antes de negar la importancia del conocimiento, el entrenamiento y la educación formal y no formal (aunque, como diría Stroustrop, no hay nada interesante que se pueda aprender en tres meses, y eso incluye a ser un buen gerente de proyecto). Creo que la educación formal y no formal en forma complementaria son imprescindibles para mejorar.

Pero tal vez, convenga separar nuestra valoración del conocimiento y el examen crítico de competencias de las certificaciones de entidades venerables. O, en todo caso, vayamos nosotros por el conocimiento y dejemos las certificaciones para los comerciales.

Tratamos de decidir

Esta es una continuación del post donde contaba como nos habíamos hecho pasar por epistemólogos en pantuflas al momento de abordar el área de proceso de Decision Analysis and Resolution.

Las prácticas específicas de esta área son:

• Establecer guías para el análisis de decisión (SP 1.1-1)
• Establecer criterios de evaluación (SP 1.2-1)
• Identificar soluciones alternativas (SP 1.3-1)
• Seleccionar métodos de evaluación (SP 1.4-1)
• Evaluar las alternativas (SP 1.5-1)
• Seleccionar las soluciones (SP 1.6-1)

Más allá del mantra tenemos que cumplir con CMMI, intuimos que había (hay) una enorme oportunidad de apoyarnos en estos conceptos para mejorar la calidad de lo que producimos. Algo nos hacía (hace) ruido entre nuestra autovaloración y el resultado observado, aunque siempre hemos podido balancear la ecuación agregando un delta que sería la culpa de un tercero.

Todos confiamos en nuestras capacidades de decisión. Todos creemos entender que sucedería ante un curso de acción u otro ( sí, sí, ya se: tampoco escapamos al sesgo de creer que conocemos las variables y las opciones posibles, o dicho de otra manera, siempre vamos a tener el riesgo de ser engañados por la aleatoriedad ). Pero, como decía antes, el resultado nos empujaba hacia la acción: la realidad sugería que el proceso podía ser mejorado (muy mejorado, de hecho), porque más allá de nuestra confianza, los resultados estaban lejos de ser los que esperábamos.

El primer punto de la práctica habla de decidir que temas han de someterse al proceso formal de toma de decisiones (SP 1.1-1). No fuimos capaces de dar un algoritmo para determinar ante que situaciones comenzar con el proceso, y francamente no creo que lo haya. El gerente/líder/jefe de proyecto (o como quieran llamarlo) es insustituible por una máquina: va a tener que decidir que cosa es importante, clave o crítica.

Lo que sí fuimos capaces de hacer es de escribir ciertas obvias recomendaciones para definir que algo es importante, clave o crítico: si tiene un impacto no menor en atributos de calidad del producto, rentabilidad o tiempos del proyecto (que no son dos compartimientos estancos), o en las personas involucradas, es altamente probable que amerite el proceso de decisión formal.

Toda decisión se toma de acuerdo a cierto marco de referencia que prioriza determinadas cuestiones sobre otras. Ocurre que muchas veces (diría siempre, pero me contengo) no compartimos los marcos de referencia y de acuerdo a nuestras preferencias personales, experiencias, conocimientos y, sobre todo, posición en la organización, ponderamos mucho más ciertos factores que otros. Así se dan discusiones donde la seguidilla de argumentos y contra argumentos se hace interminable solo porque se discute presuponiendo un acuerdo en el marco valorativo. Una buena manera de evitar esto es que el marco valorativo fuera explícito (SP 1.2-1), e incluso, si fuera posible consensuado.

Todos pensamos, por cierto caracter de formación, que la explicitación del marco en términos cuantitativos sería preferible a una en términos cualitativos. Al final, se impuso la razón: los términos cuantitativos son deseables solo para aquello que sepamos cuantificar bien (performance, por ejemplo). No solo es inútil, sino también peligroso, andar poniendole números a las cosas sin ninguna base solo porque la matemática nos hace rendir ante su irrazonable efectividad. La efectividad de la matemática, tal como se entendió Eugene Wigner era un fenómeno de la física, no de la informática (ni de la economía).

Esto generó cierta inesperada reacción, que en ningún momento se planteó de forma abierta, en el nivel de gerenciamiento de los proyectos. Hubo algún tibio intento de sostener que determinados criterios debían permanecer privados porque eran demasiado delicados para exponerlos a la plebe: algo así como acabo de bajar del monte con las decisiones de dios escritas acá, miren. La posibilidad de no exponer motivos le da cierta ventaja al que asegura conocerlos, ya que siempre puede rechazar ideas con reglas ad hoc. Ser explícito es el primer paso para ser honesto. Unos pocos gritos después, seguimos adelante con el acuerdo de que los marcos de decisiones tienen que ser explícitos.

Los métodos de evaluación fueron un punto conflictivo. Hay determinados tipos de decisiones que necesariamente se definirán en el campo de las hipótesis, por así decirlo: son aquellas donde es imposible experimentar y los que pasa si son solo elucubraciones, ya sea por la naturaleza de la pregunta ( por ejemplo, como va a impactar en nuestra relación con el cliente un atraso de quince días?) o porque no tenemos la información adecuada .

Pero hay otro tipo de decisiones, particularmente decisiones importantes, donde el tiempo y la energía que se pierde discutiendo y conjeturando que va a pasar pueden ser invertidos en desarrollar una prueba. El post anterior contaba la historia del desarrollo de la guías para adoptar el método de decisión basado en la experimentación. El proceso de definir los métodos de evaluación (SP 1.4-1) es el mismo que el definir las soluciones alternativas (SP 1.3-1). En particular cuando la decisión sea lo suficientemente importante como para requerir experimentación, algunas alternativas quedarán descartadas por infalsables.

Para los métodos de evaluación basados en las etéreas elucubraciones, comenzamos por el final: el proceso de evaluación de alternativas tiene que tener una fecha de finalización o un máximo de esfuerzo invertido en él. La experiencia muestra que las primeras horas de las reuniones de revisión de pares y de análisis son las más productivas. No es que subestimemos la importancia y el poder del análisis abstracto, pero si nuestro proceso de análisis 'en abstracto' no tiene al menos algunos puntos de corrección por la experimentación, corremos el riesgo de desarrollar invertir esfuerzo en elucubraciones inútiles.

El ser humano no será demasiado racional, pero está enamorado de la coherencia. Nos resulta más fácil ponernos a defender la alternativa elegida con uñas y dientes que aceptar un error, porque así podemos percibirnos a nosotros mismos como personas coherentes, y porque, además, defendiendo nuestra elección, nos convencemos de que hemos elegido bien. Por esto, había que decidir que el jueguito dialéctico en alguna parte debía cortarse.

En este punto, alguien dijo la palabra mágica: brainstorming. Debo decir que no soy un gran fan del brainstorming. En particular, no compro la idea de que sin crítica se pueda arribar a una buena solución. No me imagino como se decantan por las mejores ideas si no las someten a un proceso de análisis crítico buscando los puntos débiles de las ideas propuestas. Por supuesto que la crítica tiene que ser fundamentada y no debe basarse en la autoridad ( el post sobre falacias argumentales, vale la pena o se soluciona con guglear un rato?) o en motivos emocionales, pero pensar que sin crítica vamos a obtener una buena solución es igual a pretender llevar a producción un sistema sin testing.

Definidas las guías para entrar al proceso, las de documentación de criterios de evaluación y del proceso, habiendo escrito un pequeño tutorial sobre como hacer experimentos, y como documentar los resultados (nada muy estructurado, apenas guías para que quede rastro del asunto) había algo que seguía haciendo ruido: nos parecía que había una tendencia general a no profundizar en las causas de algo al tomar una decisión.

No éramos los primeros en sentir eso, ya alguien había determinado que con cinco 'por qué' estábamos cerca de la causa última. Me mantengo escéptico sobre la pertinencia de este número, pero rescato el hecho de que anima a ir más allá al analizar algo y no quedarse con la primera explicación que, normalmente, suele ser incompleta. Por lo que pese a mi escepticismo (o gracias a él) la regla quedó en cinco por qués, o una explicación de por qué hay menos. El tiempo dirá como nos va con esta regla.

La tendencia a no profundizar lo suficiente en las causas se aprecia cabalmente cuando entramos en esa hermosa fase del ciclo de vida llamada 'mantenimiento': un bug corregido produce otros tres que a su vez producen otros más y así. Afortunadamente (porque no se debe sino a la fortuna de vivir en un universo con reglas que, al fin y al cabo, permiten la vida) en algún punto se estabiliza y cada patch nuevo no genera otros tres bugs, y entramos en régimen de uno a uno, o casi. Un régimen de mierda (aunque régimen al fin) provocado porque estamos solucionando síntomas y no causas.

Que como y cuando se solucionan las causas últimas? Bueno, llegado cierto momento, de ninguna manera, nunca. Pero aún cuando no tengan solución, siempre es mejor saber cuales son. Al menos, para no intentar resolver lo irresoluble.

Diseñando experimentos o experimentando diseños

Hubo un tiempo que fue hermoso, y fui libre de verdad. En ese tiempo era un técnico, me perdía entre arquitecturas y optimizaciones, y las fechas, rentabilidades, calendarios, ofertas no eran mi problema. Mi responsabilidad se limitaba a aquellas cosas que hacía yo directamente. Estaba en la gloria. Además, como solo mi trabajo era mi responsabilidad, podía hacerme el vivo.

Magnificadas y embellecidas por la memoria, de esa época tengo recuerdos como el que sigue.

Una programadora del equipo se acercó a D., intuyendo lo peor. No se por qué se acercó a D. , siendo que yo era la interfaz más amable de ambos y nos sentábamos uno al lado del otro (yo era algo así como el arquitecto de aplicaciones y D. el de base de datos). Ella, que sabía lo que seguía, le dijo a D.: "esta query anda lenta" y se dispuso a aceptar con resignación su destino. D. ni siquiera levantó la cabeza del monitor y dijo "ahá. y que querés hacer..." (D. siempre citaba a Tom Kyte diciendo "no optimices queries, comprendé la pregunta").

Hasta aquí, la morocha (dije que la programadora era morocha?. Bueno, era morocha y de ojos verdes) tenía una oportunidad. No es que D. fuera muy amable, tampoco es que la curvilinea figura de esta chica lo conmoviera, sino que él siempre intentó ser justo. Ella no se dio cuenta que tuvo una oportunidad de ser rediminda y dijo "no, es que quería ver si desde la base podíamos hacer algo para que ande más rápido". Era exactamenet lo que D. estaba esperando para reconfirmar que toda oportunidad otorgada es una pérdida de tiempo: "algo así como poner el parámetro turbo=true? no, todavía no existe. Te aviso cualquier cosa".

Se puede decir que D. era (es) un tipo áspero. Que no hay necesidad de andar presumiendo de lo que uno sabe, porque uno en algún momento uno tampoco supo. Pero creo que en esta oportunidad el problema no era con la ignorancia, sino con un concepto problemático: la performance no importa, la performance se agrega después, es como la cobertura de un helado, y además es algo que depende del DBA.

A D. lo irritaba esa postura. A mí también. El origen de mi molestia tiene que ver con que considero que no se puede evitar el pensar la arquitectura al principio del proceso de desarrollo del software (lo que no implica, claro, que uno no tenga que pensarla durante todo el proceso), no importa cuan ágil sea uno (de todas formas, el paso de planear la arquitectura se evita más por desordenado que por ágil, se reconoce desde la comunidad ágil que la fase de architecture envisioning es necesaria), particularmente si uno no quiere encontrarse al final del proyecto con que algo anda más lento de lo esperado, o algo peor.

Se podría argumentar que ese no es un problema hoy en día: hay arquitectos, fases para definir la arquitectura, sectores de arquitectura, libros sobre arquitectura y toda una parafernalia sobre el asunto. Me permito pensar que todo eso, o bien es insuficiente, o bien está mal dirigido.

Volvamos al principio, que es la arquitectura?. Yo tengo una definición de arquitectura: “la arquitectura de un sistema es el conjunto de decisiones de diseño que tienen un impacto profundo en la calidad del mismo” (en realidad, como todos las cosas que valen la pena, ya alguien la pensó antes).

Por eso, creo que la fase de pensar la arquitectura, de decidir las características más importantes del sistema antes de comenzar la construcción y no esperar que las decisiones tomadas por un grupo de desarrolladores sobre la marcha sean acertadas, es ineludible. De todas maneras, creo que una vez más conviene bajar a detalle y preguntarse que significa obtener una visión de la arquitectura. No creo que unos modelos en papel alcancen para tomar decisiones importantes, particularmente cuando uno incorpora componentes nuevos (no recuerdo ningún proyecto en los últimos años en los que no haya tenido por lo menos un componente nuevo). La solución viene dada por construir diseños experimentales que sometan a la arquitectura propuesta a condiciones extrapolables a las que soportará una vez implementada.

Las características que normalmente deseo observar al someter a una arquitectura a un experimento son:

• El comportamiento bajo alta carga.
• La posibilidad hacer andar en forma aislada los componentes, como forma de poder detectar y corregir problemas una vez que esté el sistema implementado.
• El comportamiento ante situaciones límite, como caídas de equipos, operaciones maliciosas, errores en otros componentes.
• La facilidad de implementar cambios en la arquitectura (reemplazar un componente por otro).
• Cierta seguridad sobre la estabilidad de los componentes. Si bien no tengo demasiado cariño por la costumbre de gritar ‘hay un bug en Oracle’ ante el primer error que uno cometió en una query, me he encontrado con algunos productos open source con algún que otro error (un memory leak, por ejemplo). Y me he encontrado con que MS se pasa algunos estándares por el forro, y agrega algunas condiciones a las del estándar....
• Y el más importante, nuestras suposiciones sobre el funcionamiento de lo que vamos a usar son razonables? O sea, podemos estar seguros que, al menos en lo importante, nuestro diseño no va en contra de algunas limitaciones de la tecnología?
  

Bien, el problema es que esto es mucho más fácil de enunciar que de hacer. Diseñar un experimento significativo y a la vez sencillo es una habilidad que requiere conocimiento, práctica, y hasta diría que talento. Si es difícil hacerlo, escribir unas guías sobre como hacerlo es aún más difícil, pero concluímos que hacer el esfuerzo (más adelante explico el por qué, además de porque consideramos que aporta valor) de explicitar algunas guías para definir experimentos valía la pena. Acá va un resumen de los pasos de la guía:

1. Identificar las interfaces relevantes: pueden ser algunas pantallas, mecanismos de IPCs e integración (colas de mensajes, web services)
2. De las pantallas identificadas, abstraer la presentación y pensar unicamente la interfaz de la operación
3. Desplegar el software de base. Acá me refiero a desplegar todo el software de base, no un poco, particularmente si uno no lo conoce. Me refiero a base de datos, appl. server, broker de mensajes, todo.
4. Implementar mocks de cada interfaz relevada. El mock, de acuerdo a cada caso, puede ser una clase que simplemente no haga nada y tenga un sleep o similar para simular el delay de procesamiento o una clase que haga algunas operaciones contra el soft de base, sin mayor lógica, simplemente para obtener tiempos reales de operaciones en el soft de base
   
5. Conseguir un simulador de carga (o hacer al menos un par de scripts en ant, nant o shell) que tire transacciones.

A partir de ahí, ir variando las condiciones y ver que sucede (algunas ideas):

1. Ejecutar lo construido en (5) y verificar límite de capacidad de procesamiento (ese momento donde las colas no entran en régimen: al margen, la utilidad de los modelos de colas para el análisis de performance, tema para otro post)
2. Bajar intempestivamente un componente y ver cuan fácil es determinar el problema
3. Determinar que posibilidad hay de ejecutar aisladamente un componente construido sin el software de base (obviamente, con máquina virtual y sistema operativo, unicamente)
4. Medir el consumo de memoria de los componentes, particularmente de los nuevos (si pusimos un nuevo framework, medir el consumo de memoria en la máquina virtual, por ejemplo)
   

Un experimento (o prueba de concepto, o como se desee llamarlo) es un entorno controlado donde podemos generar variaciones planificadas y observar los resultados. Es sencillo de enunciar, pero diseñar un experimento razonablemente significativo es algo que requiere práctica, conocimiento del dominio y no se si talento natural ( sí, se que todo parece indicar que no somos una tabla rasa, pero tampoco es que don Pinker se haya impuesto por tanto).

Aún así, y dado que teníamos que cumplir, pensamos que sería útil hacer el esfuerzo de escribir un manual, o al menos unas guías, que ayuden a quien tenga que hacerlo a diseñar un experimento. Al fin y al cabo, que sea difícil de aprender, no significa que no valga la pena de ser enseñado, no?

Por qué todo esto?. Basicamente porque existe en CMMI L3 un área de proceso llamada ‘Decision Analysis and Resolution’. Como además de la certificación siempre tuvimos como norte que el proceso sirva, además, para que mejoremos la calidad de nuestros productos, nos atrevimos a perder tiempo pensando en el proceso de desarrollo además de la estrategia para el SCAMPI.

En la próxima parte de este post veremos como encaja esto en la process area de 'Decision Analysis and Resolution'.

El valor ganado

Scott Ambler, entre otros, critica el uso de Earned Value como métrica para los proyectos de desarrollo, y como siempre, con muy buenas razones:

• Se tiende a asumir que toda tarea realizada es valor ganado, así, por ejemplo, llegamos a que ganar el 90% del valor nos cuesta el 90% del esfuerzo y el último 10% de valor otro 90% ( me encantan esos proyectos donde siempre estamos finalizando.)
• Es difícil usar el EV para el software, ya que el nivel de interdependencia de los componentes es alto.

Repasando el earned value, la forma de calcularlo es asignarle un valor a cada tarea, definir una política de suma (es decir, si puedo sumar un 50% de la tarea o solo sumo tareas completas), y luego, con el avance, recolectar lo terminado y hacer una suma de los valores de cada tarea terminada.

Yo siempre pensé que me gustaba el Earned Value, de hecho, iba a escribir un post para defenderlo. Lo que ocurre es que estuve años diciéndole Earned Value a otra cosa. Suele pasar, sucede lo mismo cuando digo que soy liberal y me saludan como compañeros de ideología cada personaje... (no, no voy a hablar de política, pero soy liberal, humanista, y ... bueno, si les interesan sigan los links al think tank de Paul Kurtz ).

Volviendo, mi earned value se basa en lo siguiente:

• Primero, no toda tarea aporta valor. Hay tareas necesarias para laburar pero que, luego de terminarlas, no tengo algo de software que mostrar. Sería delirante decir que tengo dos mil pesos de earned value porque terminé de conectar mi entorno de desarrollo. Después de tener mi entorno de desarrollo up & running, mi earned value es cero. Todavía no gané ningún valor.
• Yo entrego productos, no tareas cumplidas. Por lo tanto, el earned value se incrementa cuando termino una parte del producto, no cuando termino una tarea (y por cierto, terminado es terminado, no es terminado pero me falta probarlo)
• Lo que me dice cuan cerca estoy del objetivo es la distancia que me separa del mismo, no cuanto recorrí para llegar a él. Mi objetivo no es estático, aún cuando trabaje con BRUF, ya que manejo el cambio. Entonces, mi EV no lo voy a comparar con la estimación original, sino con la estimación actual de acuerdo a la configuración actual del producto que debo entregar
• El software sí puede dividirse en piezas: si tengo una lista de componentes a realizar, un diseño de alto nivel y una lista de funcionalidades, es que cada una de esas tiene alguna entidad propia. Y como tal, puedo decir que cada una de ellas está implementada o no está.

Claramente, en un proyecto ágil 'puro', donde no se cierren los requerimientos al principio, el earned value no tiene sentido. Pero como argumenté en otro post, me veo obligado a trabajar con lo que Ambler llama BRUF.

Y así tengo un gráfico con una linea que representa el valor actual del producto a construir (es decir, la sumatoria del valor de todos los componentes que representan la configuración actual del producto a construir) y una linea que representa el valor ganado (la valorización de aquellos componentes terminados y útiles para la configuración actual del software). Esto implica, claro, que el valor ganado puede bajar y que el objetivo no es estático. Acá hay un ejemplo del gráfico en cuestión:




Por supuesto, hay más datos que tal vez valgan la pena volcar en el gráfico (la valorización de las tareas que no aportan valor directamente al producto, por ejemplo), pero por ahora lo uso así.

La forma de medir el avance de un proyecto siempre es un tema complicado. Lo que subyace, me parece, es uno de los dos grandes problemas que también subyace al tema de las estimaciones: no tenemos una buena forma de medir el tamaño del producto de nuestro trabajo (como nota al margen, no creo que lo ignoremos por tontos, sino por recién llegados).

Y esto que tiene que ver con el earned value?. Bueno, para mí es el earned value: es el valor que logré ganar. Ah... que la definición era otra?. Bueno, podría ser. Ya comenté que soy liberal?

La importancia de la historia

Amo la frase "Dejó de andar. Y nosotros no tocamos nada" porque ha hecho que casi todo el mundo acepte la necesidad de la práctica de gestión de la configuración, cuyos beneficios van más allá de dar respuesta a esta frase. Además, claro, es una de las áreas del nivel 2 de CMMI, así que la tenemos que cumplir. La tenemos que cumplir, no se discute: no importa para qué, acá no se discute, la duda es la jactancia de los intelectuales (*): si lo dice CMMI hay que hacerlo.

Perfecto, lo hacemos. Y vamos a la definición de CMMI, que como todos sabemos explica, en un lenguaje accesible el significado de algunos términos criollos . (van solo los objetivos específicos, las prácticas y subprácticas se encuentran muy fácil por ahí)

• Se establecen las lineas bases (cuidado!!! no es el concepto de linea base de ITIL que es más o menos el que todos entendemos por linea base) de los productos identificados.
• Los cambios a los productos bajo gestión de la configuración son seguidos y controlados
• La integridad de las lineas base se establece y mantiene
  

Clarísimo, no?. Bueno, no para nosotros. Como siempre la pregunta ante esto es... "y que hacemos?". Después de un tiempo de discutir, van unos revolucionarios conceptos a los que llegamos:

• Tener versionado de código no es hacer gestión de la configuración: además tenemos que identificar los hitos o releases usando el versionador de una forma coherente y homogenea. Por ejemplo, teníamos que poder decir "volvamos a la versión que entregamos el viernes pasado". Pan comido, un sencillo mecanismo de tags y branches y listo.
• El código fuente en el versionador no es suficiente: he visto que hay una tendencia a no versionar los objetos de la base de datos. A veces, con suerte, llegamos a los stored procedures, pero no versionar ni tablas ni índices es lo habitual: después de todo no son código fuente, no?. Yo me atrevo a proponer una tesis subversiva: si no hay coherencia entre el código y los objetos de la base, existe cierta posibilidad de que la release sea fallida.
• Tenemos que saber que incluía cada revisión: que bugs estaban resueltos, cuales no, que funcionalidad implementada, que errores conocidos que íbamos a resolver en cada revisión. Para esto, necesitábamos algo más que un versionador de código. Había que adoptar un issue tracker e integrarlo con el versionador. Primero a mano, incluso ingresando la relación con los branches y tags a mano en el campo de descripción, después si se puede, se automatizará. ( Esto da pie a hablar del mejor argumento para impedir cualquier mejora: Pedir la perfección. Si uno no quiere hacer nada, puede atacar cualquier cosa que le propongan por no ser perfecta. Será motivo para otro post)
• Si algo había cambiado, teníamos que saber cuando había cambiado, ser capaces de elucidar las diferencias con la versión anterior y en lo posible, tener una noción de por qué había cambiado y el impacto. Esto estaba bien, no? Al fin y al cabo ya teníamos el versionador de código. Bueno, tampoco: esto incluye a los planes, descripciones técnicas y funcionales, algún que otro modelo (no soy un gran fan de modelizar todo y no me asusta la documentación de diseño desactualizada después de que el proyecto ha terminado, me inclino más por el modelado ágil, tema para otro post). Además de incorporar todo esto al versionador, usamos el issue tracker para conocer el momento, motivo e impacto de los cambios
• Deberíamos ser capaces de sacar una foto completa de una release. Esto es, no solo lo necesario para desplegar cualquier release por la que hayamos pasado (esto es código, scripts, objetos de la base, dtd, etc, etc, etc) sino especificaciones, reportes de bugs, scripts de pruebas y demás. De nuevo, no era difícil si subíamos todo (no solo el código) a un gestor de versiones y nos apoyábamos en el issue tracker.
  

La idea de tener aunque una descripción de los motivos del cambio levantó algunas discusiones sobre si era agil escribir el por qué de cada cambio importante (no, no hay una definición de importante. Aún no hemos encontrado un buen sustituto para la inteligencia, y espero que no aparezca). Mi postura fue que sí (o que si no era ágil, igual lo teníamos que hacer), basado en el siguiente argumento: si no está escrito no se puede revisar y aprender de ello (**), y necesitamos aprender de nuestra experiencia. Lo ágil, desde mi punto de vista, es no escribir más de lo necesario ( y cuanto es lo necesario? bueno, ver definición de importante más arriba).

Por supuesto que la frase "Dejó de andar. Y nosotros no tocamos nada" es cierta a veces (los tablespaces se llenan, los campos númericos se muestran cortos de un día para otro, bugs latentes salen a flote cuando se pasa determinada cantidad de información). También, como decía antes, la gestión de la configuración no solo da respuesta a esta frase. Incluso, el orden temporal no es necesariamente indicio de causalidad: que dos cosas hayan pasado en secuencia es prueba insuficiente de que la primera hay causado la segunda (o sea, la falacia post hoc ergo propter hoc. Motivo para otro post: falacias argumentativas)

No me propongo argumentar que la gestión de la configuración haya sido una respuesta a la costumbre de reportar errores usando esta frase, pero sí decir que donde han sufrido estas cosas es más fácil hacer ver la importancia de la gestión de la configuración.

Lo que me queda claro es que se agradece que haya gestión de la configuración cuando "dejó de andar. Y nosotros no tocamos nada". Primero, porque como diría el gran Dr. House, "todos mienten" (a propósito o sin querer, todos mienten). Y después, porque si estamos en alguno de los extraños casos donde efectivamente, ellos no tocaron nada, sirve corroborar tan sospechosa frase en los registros de gestión de configuración y comenzar a buscar campos que quedan chicos, problemas de memoria latentes que surgieron cuando se incrementó el volumen de transacciones, funcionalidad que hasta ese momento no había sido usada, un diseño deficiente de sincronización de transacciones que por obra y gracia del espíruto santo no había llegado a verse envuelto en la condición que lo hizo dispararse.


Ahá, muy interesante, pero con todo esto que nos explicaste vamos a cumplir con CMMI?. Sí?. Bueno, entonces hacelo y comprá el software que necesites, pero buscá el más barato.

Me encanta sentir que he cautivado a mi audiencia.


(*) Frase que ha pronunciado el filósofo Aldo Rico durante una rebelión carapintada. Algunos aseguran que fue Ortega y Gasset ( tan filósofo éste como el antes mentado) el autor original del a frase.
(**) No me imagino a un científico diciendo "Lo que ocurre es que yo no escribo papers porque hago ciencia ágil. Mejor que se siente el revisor al lado mío y le voy contando las ideas" (sí, como dije, considero la ciencia como paradigma de éxito en cuestiones intelectuales)

Estimo que...

Como parte de nuestro programa de mejora continua en el proceso de estimación, y dado que aún tenemos la hermosa sensación de desafío que produce el saber que existe una magnífica oportunidad de mejora en este tema (esta forma de decir 'quilombo a resolver' la aprendí en un curso de coaching), estuvimos pensando en que, si el proceso de estimación está tan verde, tal vez mereciera la pena invertir un par de horas en revisar los resultados.

Tuvimos que asumir que era (y es) nuestro punto más débil. Listo, agarramos la definición del proceso y le agregamos un paso más. Y salvado el hombre, hermanos!. Bueno, nada es tan simple: como hacíamos para que las revisiones tuvieran un mínimo de sentido crítico? (no es el sentido crítico una de las cosas que nos salgan naturalmente a los humanos, de hecho, la tendencia a buscar acuerdos es un sesgo cognitivo bien descripto. Motivo para otro post, o simplemenet podría recomendar un libro).

Entonces comenzamos a hacer un checklist de cuestiones a repasar cuando revisamos una estimación. El desafío y la oportunidad de mejora siguen ahí, de modo que la lista sigue abierta (como un recordatorio, esto lo aplicamos al método de estimación por descomposición). En estos momentos,la guía para el revisor se basa en un par de aspectos generales, que explico en los puntos siguientes.


Coherencia con los objetivos y requerimientos

La estimación debe mantener coherencia con los requerimientos no funcionales y los objetivos de rendimiento (*). Por incoherencia entendemos el incluir un objetivo o requerimiento y que las tareas para alcanzarlo o cumplirlo no tengan el foco (esto es, esfuerzo) necesario o directamente brillen por su ausencia.

Las formas más comunes de estas incoherencias son:

• Mencionar en los objetivos de rendimiento que vamos a construir un producto (o un framework) a partir del proyecto, y las tareas de diseño no tienen mayor peso que de costumbre, o las tareas de documentación brillan por su ausencia.
• Hablar de objetivos de performance del producto y no incluir tiempos para tareas de pruebas de carga, ni especialistas en el asunto.
• Incluir cuestiones tecnicamente complicadas ( como por ejemplo, alta disponibilidad) y no estimar el esfuerzo adicional de diseño, y, fundamentalmente, prueba.

Por otra parte, el ciclo de vida seleccionado tiene incidencia en las estimaciones. El riesgo aquí es no estimar el esfuerzo de ciertos roles o actividades que el ciclo de vida que adoptamos incluye.


Identificación y estimación de tamaño de las tareas

Dijimos que adoptábamos un método de descomposición y no uno paramétrico como nuestro método principal porque no teníamos la suficiente madurez para un método paramétrico. Ahora, eso no implica que no podamos identificar algunos patrones de errores comunes en la identificación de tareas:

• Las tareas o componentes identificados son lo suficientemente pequeños como para que su estimación sea posible?. Como regla general, establecimos que cualquier tarea o componente que insuma más de 150 horas es sospechoso de estar pobremente especificado y comprendido (otra regla general: no hay cosas que estén mal por definición, hay luces amarillas)
• Se han identificado las oportunidades de reutilización?
• Se distingue entre lo que se debe modificar, lo que se integra y se prueba en integración y lo que se construye desde cero?

Coherencia histórica

No tenemos una historia especialmente explotable, en un sistema de datamining que nos permita descubrir patrones de esfuerzo en proyectos pasados. Bueno, pero que no tengamos el non plus ultra de los repositorios no implica que no podamos ver como nos fue en el pasado ( en algún caso, junto con algún otro galeote hemos mirado un reporte en excel decidiendo por una descripción a que componente imputar las horas de un proyecto pasado... un trabajo apasionante cuando hay cientos de componentes y miles de entradas de cargas de horas ).

Y aquí la pregunta que terminamos haciendo: si para hacer un ABM tardaste miles de horas, por qué ahora suponés que lo vamos a hacer en veinte?. Resumiendo, este paso implica buscar componentes o tareas parecidos (al menos parecidos en una primera aproximación) en proyecto anteriores y justificar la diferencia si la hubiera. No es que siempre tengamos que tardar lo mismo, pero la diferencia debe tener una buena justificación.


Evaluación de la incidencia del entorno

Este paso, al igual que todos los otros, tiende a buscar incoherencias entre lo que ha escrito y especificado sobre proyecto y su circunstancia y lo que se supone que se hará en virtud de eso. Mencionar una característica del entorno, como por ejemplo un riesgo, y que no haya ninguna característica de la estimación o del plan de proyecto que responda a ésta es wishfull thinking, es creer en la utilidad de un conjuro. Por eso, lo que hacemos aquí es recorrer cada riesgo, cada característica del entorno (capacidad del equipo, motivación, estabilidad de los requerimientos), y preguntar y esto como influyó en la estimación? como hubieses estimado si esta hubiese sido diferente?


Pasos de la estimación

Por último, el aspecto formal, aunque debería haber sido el primero. Si el único repositorio de la estimación y sus motivos está en las conexiones neuronales de un iluminado, dificilmente podrá ser sometido a revisión. Entiendo que los genios tengan esa reticencia a la revisión, pero, queridos genios, entiendan que, nada personal, nosotros los mediocres, nos vemos forzados a actuar como si la regla fuera la mediocridad y no la genialidad, como si ustedes los genios fueran raras avis. No es que dudemos de vuestra genialidad. Y así hemos logrado estructurar al mundo: aún los premios nobeles escriben sus ideas para que los demás las puedan evaluar, juzgar, corregir, ampliar y si las encuentran útiles, usarlas de base para otras ideas. Incluso, para permitir que si los demás las encuentran terriblemente revolucionarias, les den el premio nobel.

Así que acá vamos con los pasos en cuestión:

• Se han establecido, a grandes rasgos, los límites del alcance y los objetivos de rendimiento?
• Se han indentificado los riesgos?
• Se han identificado las tareas y componentes siguiendo la taxonomía que se usa habitualmente o si se la ha ampliado hubo una buena razón?

Resumiendo

Cuando uno tiene un proceso cuyos resultados no han destacado por su fiabilidad en el pasado (esos papers que hablan de cuanto se van de presupuesto y calendario tantos proyectos de software no nos hablan en tercera persona, deberíamos asumirlo ...), y no sabe muy bien como mejorarlo, lo mejor es aumentar las actividades de revisión y rezar porque la coherencia interna de un producto tenga alguna relación con su pertinencia y ajuste a la realidad.

Gran parte de lo que hicimos lo tomamos de un checklist del SEI para revisar estimaciones, como cabe esperar, bastante más formal y estructurado que el nuestro.




(*) Objetivos de rendimiento le llamamos en este barco de esclavos a aquello que se espera que nos aporte el proyecto además, claro, de su rentabilidad (la base para algún producto, conocimiento, entrar en una cuenta)

Métricas, procesos y de como se juntan

"Les recomiendo hacer este estudio si y solo si van a tomar conducta a partir del resultado", nos dijo hace un tiempo el médico genetista. a mi pareja y a mí, cuando estábamos iniciando los trámites para un estudio genético invasivo que entrañaba cierto riesgo.

Este buen doctor podría dedicarse a la consultoría en informática, o, al menos, podría aportar su criterio en lo que refiere a la definición, recolección e interpretación de métricas de procesos. Su criterio es simple y útil: uno no debería medir algo si luego no piensa hacer nada con esa medición. Las métricas que se recolectan pueden no ser útiles hoy, pero debería existir al menos expectativas de usarlas en un futuro, y estas expectativas deberían ir acompañadas de alguna idea de como se espera que sean útiles. Más allá del abuso de su jerga médica (en castellano, lo que él dijo se diría más o menos como "si no van a hacer nada con el resultado, les recomiendo no hacer este estudio ya que entraña algún riesgo") su idea es aplicable a casi cualquier ámbito, con excepción, quizá, de la ciencia básica.

La respuesta a la pregunta sobre que métricas se deben recolectar en un proceso de desarrollo de software es sencilla: las que sean útiles para tomar decisiones. Lo que es un poco más complicado es la instrumentación de esta respuesta. Vamos a tratar de aplicar una variación libre del método GQM, que, como todo, tampoco es rocket science. Un mapa de ideas siempre es bueno para ordenar las idem:

Lo que se desea, basicamente, es ganar dinero. La rentabilidad en un proyecto de software se puede ver amenazada por una mala estimación inicial ( los proyectos a precio cerrado tienen sus problemas, como bien nota Scott Ambler, pero son la forma más común hoy, al menos en el entorno donde yo me desenvuelvo. Será tema para otro post), por retrabajos (generados por mala calidad de lo producido o por cambios en los requerimientos) y retrasos en el calendario que, además de posibles multas, entorpecen la disponibilidad de las personas del equipo de trabajo y los recursos asociados.

Después de mucho pensar (o de poco pensar pero durante mucho tiempo), derivé un conjunto de métricas con las que me siento cómodo:

• Cantidad de defectos, desagrupados por etapa del proyecto (cuando antes se producen, peor es) y tipo de entregable (defecto en software, en especificación funcional, en especificación técnica, o en el proceso mismo). Asimismo, me interesa el tiempo promedio de solución de un defecto.

• Sobreesfuerzo generado por defectos, es decir, el esfuerzo necesario para corregir los defectos, desagregado por actividad.

• Cantidad de cambios a los requerimientos, también desagrupados por etapa del proyecto y cantidad de cambios aceptados y rechazados.

• Velocidad de avance del equipo, medida por la cantidad de historias del usuario o de requerimientos implementados por unidad de tiempo y como avance ganado, definido como tiempo insumido / (tiempo insumido + tiempo estimado para completar ).

• Milestones cumplidos en tiempo, demorados y demora promedio.

• Cantidad de cambios al plan del proyecto, y el motivo de los mismos (cambios a los requerimientos, cambios a la dotación del equipo de trabajo, errores en la estimación).

• Desvío de la estimación original, por componente y actividad, para lo cual el sistema de registración de horas está alineado con la forma de estimar: se imputan horas con el mismo concepto y granularidad con que se estima el proyecto.

Es probable que al mapa le falten algunos objetivos (será más fácil ganar dinero si entrego un software que le entregue valor al usuario, no simplemente algo que cumpla con las especificaciones, por ejemplo), y seguir el rastro de esos objetivos probablemente nos agregue nuevas métricas.

Por otra parte, tengo un conjunto de métricas, las que por ahora no son útiles, pero espero poder utilizarlas en el futuro:

• Cobertura de código por el testing: en entornos manejados (java, .net), asociado al proceso de integración continua, se mide el porcentaje de código cubierto por las pruebas unitarias y de regresión. Mi esperanza es, en algún momento, relacionar esto con la cantidad de bugs detectados por los procesos de prueba y certificación del usuario, para derivar un valor que minimice la suma entre el esfuerzo necesario para corregir bugs y el esfuerzo de construcción de pruebas unitarias y de regresión.
• Cantidad de no conformidades detectadas por las herramientas de inspección automática, como PMD, Checkstyles, FxCop, Macker, con la misma esperanza que ya mencioné para la cobertura. Relación entre puntos de caso de uso y horas por actividad: guardo la esperanza de construir una base de datos lo suficientemente grande que pueda servirme de base para hacer una estimación por puntos de caso de uso.
• Métricas de complejidad y tamaño de la solución, como cantidad de clases, paquetes, componentes desarrollados sobre los especificados. Aquí la idea para el futuro es poder determinar cuantitativamente cuan confiables son mis espeficiaciones técnicas y cuanto del producto real terminan por cubrir.
• Espero poder madurar las métricas de defectos, para relacionarlas con la cantidad de pruebas realizadas y determinar si el no encontrar más defectos significa que el producto está estable o no se están buscando correctamente y armar tendencias de ocurrencias de errores.

De todas maneras, y como resumen, vale la pena recordar el concepto que vertió el buen doctor que nos atendió: el esfuerzo de recolectar una métrica sirve si ésta puede servir de base para una toma de decisión. Y por cierto, el objetivo de estas métricas (o de cualquier otras) no es cumplir con CMMI, signifique esto lo que signifique, sino dar información útil, que sirva para tomar decisiones, sobre la performance del proceso y el estado del proyecto.

La agilidad y CMMI

Luego de haber pasado por unos cuantos proyectos de desarrollo, he visto cosas que ustedes sí creerían (porque ustedes también las vieron, que no me refiero a naves de guerra en llamas más allá de Orion, ni rayos C resplandeciendo en la oscuridad). Y luego de haber visto tan terribles cosas,tengo un par de conclusiones apresuradas:

• Cualquier proyecto de desarrollo de sistemas debe manejar el cambio, no intentar impedirlo. Intentar impedir el cambio (en el entorno, en las especificaciones, en el equipo de trabajo), es similar a buscar la fuente de la eterna juventud.
• Muchas organizaciones necesitan adoptar marcos que les permitan, entre otras cosas, darle visibilidad a la ejecución de proyectos, delimitar responsabilidades, ser predecibles y construir una historia que pueda ser explotada con el objeto de saber donde deben mejorar.

La primera conclusión me hace mirar con simpatía las metodologías ágiles (debo -admitir que solo conozco XP) y la segunda me hace pensar en la necesidad de un marco formal y más riguroso, al estilo CMMI (que no es exactamente un metodología, sino un marco ). Un prejuicio ( el marco más comunmente usado para tomar decisiones ) me decía que no se podía estar a la vez de un lado y del otro: o sos ágil y desordenado o sos lento, paquidérmico, y eso sí, muy ordenado.

Conforme fui conociendo más de CMMI y XP, el prejuicio se fue debilitando ( es notable cuan perniciosa es la información y el conocimiento para la supervivencia de los prejuicios ), y hasta encontré que el SEI ya lo había contestado (no es exactamente CMMI, sino CMM, pero es una lectura recomendable).

Como sabemos, CMMI establece los famosos cinco niveles, con áreas de procesos en cada una de ellas. Cada área de proceso tiene objetivos específicos y prácticas específicas para cumplir sus objetivos. XP, por su parte, consiste en una serie de buenas prácticas asociadas al desarrollo del software.

Ninguna de estas es, como dirían los americanos del norte, rocket science: se trata de sentido común y lecciones aprendidas por la industria durante muchos años, llevadas al extremo en el caso de XP.


XP y CMMI, punto por punto …

… o más o menos, simplificando las áreas de proceso de manera caprichosa, vamos a recorrer las similitudes:

Requerimientos: CMMI plantea dos areas relacionadas con requerimientos en los niveles dos y tres: gestión de requerimientos y desarrollo de requerimientos, con foco en la elicitación, definición, verificación, validación y control de los requerimientos. XP plantea integrar un usuario o representante del usuario (como un jefe de producto) al equipo, con el objeto de que sea él mismo quien defina sus requerimientos, esté disponible permanentemente para consultas y pueda dar feedback sobre la implementación de los requerimientos luego de cada release.

Planificación y control: con XP estamos planificando continuamente: antes de cada iteración se recolectan requerimientos (‘user stories’, para XP), lo que se explica con la metáfora del carrito de compras: se recolectan user stories hasta colmar la capacidad del carrito (o sea, la capacidad de trabajo del equipo). La planificación es explícita (se seleccionan las user stories a implementar en cada release) y se actualiza continuamente, se estima el esfuerzo requerido para cada story y se planifica cada iteración antes de comenzar. El avance de cada iteración se monitorea durante las stand up meetings. La métrica de project velocity (la suma de la estimaciones de las stories implementadas en la iteración) proporciona una idea de la performance del equipo de trabajo. El avance global del proyecto se mide de forma muy conveniente por la cobertura funcional, es decir, por el porcentaje de user stories implementadas.

Quality Assurance, Validación y Verificación: la práctica de pair programming, la propiedad compartida del código y la integración continua refuerzan el foco de XP en QA. El código es verificado dado que se programa en pares que se verifican muamente. Más aún, se pueden incorporar al proceso de integración continua herramientas de verificación estática. XP hace foco en los test unitarios (toda clase o componente debe tener sus test unitarios) y los test de aceptación, que pueden ser perfectamente automatizados.

Gestión de la configuración: las releases sucesivas y cortas requieren una gestión de la configuración importante, aún cuando XP no lo mencione explicitamente: sin una adecuada gestión de la configuración, las prácticas de releases cortas, propiedad compartida de código e integración continua son imposibles.

Gestión de Riesgos: si bien XP no incorpora una práctica específica de gestión de riesgos, la integración continua, la disponibilidad permanente del usuario y las iteraciones cortas son, en definitiva, las políticas de mitigación para los riesgos más frecuentes en los procesos de desarrollo de software. Asimismo se recomienda acomodar las stories más problemáticas en las primeras releases para tener tiempo de corregirlas, lo que ayuda a mitigar los riesgos más comunes en los proyectos de desarrollo

Métricas y Análisis de las métricas: o existe en XP una práctica específica de análisis de métricas, pero el proceso produce métricas que pueden ser analizadas para identificar áreas de mejora. Las métricas como project velocity, bugs encontrados, cobertura de los test, errores de integración son producidas por el proceso y las herramientas que lo soportan.


Donde comenzamos a diverger

Existen algunas divergencias entre CMMI y XP, en particular, en áreas de proceso que adquieren mayor importancia conforme el número de integrantes del equipo de trabajo crece.

No existe ninguna práctica en XP asociada a las areas de proceso con foco en la organización, que tienden a asegurar la adherencia de toda la organización al proceso y encausar las actividades de mejora en toda la organización.

XP no posee ningún foco en estructurar guías de arquitectura al inicio del proyecto, lo que puede ser necesario para equipos grandes que trabajen en un desarrollo desde cero y no en mantenimiento. Esto último puede corregirse implementando primero las user stories más significativas desde el punto de vista de la arquitectura y que sirvan como molde, pero aún así, en determinados contextos la documentación de diseño puede ser necesaria ( en otros, puede ser absolutamente innecesaria y contraproductiva).

La práctica del refactoring continuo puede no ser extensible a grandes equipos, donde sea difícil mantener la visión global del producto a construir, o, al menos, donde es complicado que todo el mundo la tenga.


Mis personalísimas conclusiones

XP propone unas cuantas ideas que cualquier equipo de desarrollo que no quiera verse inmerso en un gran quilombo haría bien en seguir, como la planificación continua, el monitoreo de avance en virtud de lo que se hizo y no de lo que se supone que falta, el testing, tanto unitario como de aceptación, el diseño simple y el no tratar de resolver problemas que uno no tiene hoy.

De todas maneras, puedo pensar en contextos donde implementar XP en todo su esplendor sería peligroso: en los proyectos llave en mano, donde se asume de antemano un compromiso en tiempos y costos, no solo no tendremos a un cliente sentado aquí para que nos diga que quiere, sino que no podemos soportar el cambio continuo (tenemos que ganar dinero). Por otra parte, un compromiso inicial en tiempos y costos requiere un entendimiento inicial de todos los requerimientos, y un cambios en estos últimos podría significar un cambio en los primeros aspectos. En estos casos, seguimos sin poder anular el cambio, pero podemos saber cuando ocurre, por qué ocurre y que cambios adicionales (en tiempo y costos) se generan por un cambio en los requerimientos y el marco de CMMI nos ayuda a hacerlo.

Creo también que conforme el equipo crece en tamaño se necesita más foco en los aspectos organizacionales de la metodología, la gestión y el diseño y arquitectura

En definitiva, como dice el artículo del SEI linkeado más arriba, la postura extrema de XP requiere un management competente, y en eso se enfoca CMMI, por lo que un enfoque que complementario entre XP y CMMI puede ser valioso.


Fuentes:
Extreme Programming from a CMM Perspective, Mark C. Paulk
Planning Extreme Programming, Kent Beck
Extreme Programming Explained, Kent Beck