Muchas veces he visto cómo se plantea el modelo de proceso (la estrategia global de desarrollo) como el principal elemento que diferencia a un enfoque tradicional de uno ágil, diciendo que el tradicional usa un modelo de proceso Waterfall (en cascada) mientras que el ágil usa un modelo iterativo e incremental. Puede que esto valga como comparación muy simplificada de ambos enfoques, pero al hacerlo se incurre en varios errores. Primero, si bien el modelo de proceso es importante, no lo es todo, hay muchos otros aspectos diferenciadores entre ambos enfoques. Segundo, todos los métodos ágiles proponen un modelo de proceso incremental, pero no todos requieren que también sea iterativo. Scrum y Extreme Programming son claramente iterativos (utilizan Sprints) e incrementales, sin embargo, Kanban, por ejemplo, es solo incremental. Y en tercer lugar, y a propósito de lo que comentaré en este post, un proceso incremental NO solo lo es respecto de la construcción del producto, sino que también puede/debe serlo en su especificación.
En la figura A se observa una representación temporal de esfuerzo dedicado a especificación de requisitos (R) y a construcción (C) en lo que sería un modelo de proceso secuencial. En este modelo de proceso todo se especifica en detalle antes de comenzar la construcción, y no se pretende hacer ninguna entrega parcial hasta que no esté todo construido.
Rational Unified Process (RUP) es, en desarrollo de software, la metodología tradicional de referencia. RUP utiliza un modelo de proceso iterativo e incremental pero no por eso es una metodología ágil. En gran medida la clasificación de "Tradicional" para RUP se le otorga porque la mayor parte de la especificación se hace de forma anticipada (con o sin iteraciones), durante la llamada Fase de Elaboración, en la cual se realiza en detalle la especificación de requisitos, análisis y diseño del sistema para, posteriormente, en la Fase de Construcción, abordar iterativamente la construcción del producto. Como se muestra en la figura B lo que hace RUP diferente respecto de un enfoque secuencial es realizar la construcción de forma iterativa. Esto permite detectar posibles defectos de especificación u otros cambios necesarios al evaluar el resultado de cada iteración, sin embargo, la mayor parte del esfuerzo de especificación se concentra en la Fase de Elaboración. En la estrategia mostrada en la figura B no se considera explícitamente la posibilidad de cambios en los requisitos durante la construcción.
Concentrar la mayor parte de la especificación del sistema al inicio está alineado con el establecimiento de un contrato a Precio-Fijo, ya que así, antes de comenzar la construcción, se puede conseguir un presupuesto que fije alcance, plazo y precio. Sin embargo, como ocurre en muchos proyectos, cuando el grado de incertidumbre es alto, por mucho tiempo que se le dedique a una especificación anticipada, esta no será eficaz pues probablemente habrá cambios durante el proyecto. Los cambios obligarán a rehacer especificaciones, descartar especificaciones por estar obsoletas, o que incluso requisitos ya especificados no alcancen a ser implementados (puede que simplemente pierdan prioridad respecto a otros nuevos no identificados inicialmente).
Mi impresión, por lo que he observado en empresas que dicen usar un Enfoque Ágil, es que su proceso se parece bastante al de RUP, ilustrado en la figura B. La especificación detallada mayoritariamente la hacen anticipadamente, junto a la firma del contrato. Es decir, al menos en este aspecto siguen siendo tradicionales :-).
¿Pero es factible que la especificación también se realice de forma incremental? ¿Es posible realizar un desarrollo incremental que incluya también una especificación incremental? ¿Sería esto compatible con una adecuada gestión de alcance y/o un contrato del tipo precio-fijo?
La respuesta es sí, es factible hacer una especificación incremental y alinearla con un proceso de construcción incremental. Para esto debemos diferenciar entre "identificar" requisitos y "especificarlos en detalle". Si queremos gestionar el alcance de de un proyecto es vital que tengamos identificados los requisitos involucrados en dicho alcance (al menos la mayoría y entre ellos los más importantes). Pero identificar un requisito es ponerle un nombre y poco más. Lo que sucede es que tenemos la natural tendencia a especificar anticipadamente un requisito porque queremos tener estimaciones que nos permita establecer el alcance y acordar un compromiso, no es porque lo necesitamos ya para implementar cada requisito. Pero la especificación detallada de un requisito se podría postergar en extremo hasta el instante justo antes de comenzar a implementarlo.
Veamos dos alternativas factibles de desarrollo incremental que incluye también especificación incremental. En la Figura C se presenta un proceso en el cual al comienzo y por un breve período se realiza una identificación de los requisitos (sus nombres y poco más), por eso este bloque inicial R tiene un color menos intenso. Después de esta breve identificación de requisitos se hace un ordenamiento estratégico de ellos, el cual corresponderá con su orden de implementación. A continuación, los requisitos que se implementarán primero se especifican en detalle y luego se implementan. Si además, este primer conjunto de requisitos tiene una orientación MVP (Mínimo Producto Viable) con su implementación podríamos ya tener una primera entrega parcial (primera realease). A partir de ahí, y posiblemente con ciertos espacios entre nuevos desarrollos de incrementos, se continuaría con el desarrollo del resto de requisitos en ciclos cortos de especificación detallada y construcción.
Lo importante es tener en cuenta que existen alternativas y variantes sobre ellas. La elección del modelo de proceso debe estar basada en el contexto de desarrollo de cada producto. Las ventajas de los modelos iterativos e incrementales (y que además incluyen especificación incremental) son mucho mayores cuando el contexto nos hace prever cambios durante el desarrollo.
Lecturas recomendadas:
Patricio Letelier