viernes, 27 de octubre de 2017

¿Desarrollo Incremental implica Especificación Incremental? ¿debería implicarlo?


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.

¿Pero es esta estrategia de desarrollo a su vez incremental? Scrum define que el resultado de un Sprint (iteración) debería ser una versión potencialmente entregable de un producto, debería ser un incremento del producto tal que en algún momento puede llegar a ser una entrega parcial que se pase al cliente para que la utilice. El solo hecho de realizar iteraciones no garantiza que se consigan incrementos del producto al finalizar cada iteración. Por ejemplo, en la Fase de Elaboración de RUP aunque se pueda realizar con iteraciones, éstas no darán como resultado un incremento del producto. Solo durante la Fase de Construcción de RUP se tendría la posibilidad de conseguir incrementos del producto puesto que en cada iteración se obtendrían requisitos implementados. Sin embargo, el planteamiento de RUP contempla solo una entrega al finalizar la Fase de Transición (después de la Fase de 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.

Pero ¿cómo podríamos firmar un contrato y gestionar el alcance durante el desarrollo si no tenemos una especificación detallada de los requisitos al inicio?. Si el equipo ejecutor tiene experiencia en cuanto a la solución que debe implementar no debería tener inconvenientes en realizar buenas estimaciones contando solo con requisitos identificados (sin mayor especificación). Pero si en el equipo no tiene dicha experiencia, lo cual incrementa la incertidumbre, aún así tendremos siempre tres apoyos respecto de las estimaciones. Primero, si hemos hecho un ordenamiento estratégico de los requisitos, probablemente los de mayor valor y/o riesgo serán los primeros en implementarse, pues entonces éstos serán inmediatamente especificados en detalle y se podrá tener un estimación más argumentada para ellos al inicio del desarrollo. Segundo, en situaciones de incertidumbre respecto de la estimación si se realizan estimaciones normales (ni pesimistas ni optimistas), probablemente las sub-estimaciones se compensarán globalmente con las sobre-estimaciones. Habría que tener demasiada mala suerte para que todas la estimaciones resulten estar por debajo de lo real :-). Tercero, en un caso puntual de imposibilidad para poder asignar una estimación a un requisito por inexperiencia técnica para implementarlo o poca claridad respecto a su definición, se puede hacer algún prototipo que ayude a reducir esa incertidumbre y poder dar una estimación, o incluso para ese requisito puntualmente hacer una especificación más detallada, lo suficiente para atrevernos a argumentar una estimación.

Una variación del modelo de proceso mostrado en la Figura C, más extrema en cuanto a la especificación incremental, se muestra en la Figura D. En este caso, con o sin una estrategia MVP, se realizan Sprints más cortos y se solapa la construcción del Sprint actual con la especificación detallada de lo que se implementará en el siguiente Sprint. Esto se hace hasta conseguir una primera release. A partir de allí se podría seguir con dicho solapamiento, o realizar Sprints no continuos según el ritmo posterior de desarrollo o mantenimiento que requiera el producto. 


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




No hay comentarios:

Publicar un comentario