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.