Metodología Ágil: Scrum + Kanban

El modelo con enfoque tradicional

El modelo con enfoque tradicional

Pese a que el foco de este curso estará puesto en las metodologías ágiles, es fundamental conocer cómo se han
venido haciendo las cosas. En este sentido, dentro de los métodos tradicionales, el denominado “en cascada” -a
pesar de ser evidentemente un modelo simple, básico y lógico- ha sido ampliamente utilizado en la industria.

¿Qué es un modelo tradicional?

Como señalamos anteriormente, un modelo con enfoque tradicional emplea metodologías en cascada o waterfall
para el desarrollo de software. Este modelo fue descrito por primera vez por Winston Royce, un ingeniero de
software senior de la empresa Lockheed Martin. Él mismo advirtió que se trataba de un modelo riesgoso, que
invitaba al error, ya que las fallas de diseño se propagan y se detectan solo al final. Sin embargo, al ser el único
enfoque existente en esa época, además de simple, básico y lógico, ha sido ampliamente adoptado y utilizado en
la industria.

Este esquema muestra un ejemplo de las fases típicas que considera una metodología en cascada utilizada para
el desarrollo tradicional de software.
Según esta metodología, todas las fases se deben ejecutar siguiendo un orden secuencial. Una de ellas solo
puede iniciarse si la fase anterior ha sido terminada y aprobada; por ejemplo, no se empieza la construcción
(codificación) mientras el diseño final no ha sido aceptado por las partes interesadas. Pese a ello, en ciertas
situaciones, se acepta la ejecución en paralelo de tareas pertenecientes a diferentes fases.

Metodología Ágil: Scrum + Kanban

1
Metodología Ágil: Scrum + Kanban
El modelo con enfoque tradicional

En este modelo el alcance se establece y compromete al inicio del proyecto. Solo una vez que el alcance ha sido
definido y aceptado comienza la planificación de tiempos, costos y calidad, entre otros procesos. Uno de los
elementos resultantes de la planificación es un cronograma, generalmente una carta Gantt, que guiará la
ejecución de cada una de las tareas hasta el término del proyecto.

La naturaleza predictiva de las metodologías en cascada

Las metodologías en cascada requieren, desde el inicio del proyecto, el conocimiento completo y total del
problema a resolver. En base a ese conocimiento previo, durante la planificación se realizan las estimaciones de
esfuerzo, tiempo y costos requeridos para obtener el producto final esperado.
Existen diferentes técnicas que, tradicionalmente, se han utilizado para realizar dichas estimaciones; entre las que
encontramos:

Líneas de código.
Puntos de función.
Puntos de caso de uso.
Modelo constructivo de costo (COCOMO II, por su acrónimo del inglés Constructive Cost Model).

Es importante señalar que todas estas técnicas presentan debilidades, principalmente, porque dependen del
juicio experto y no están desprovistas de subjetividad.
La importancia de la estimación reside en que es la base de las demás actividades de la planificación y, por
consecuencia, de la ejecución del proyecto. Debe ser precisa y exacta, aunque no siempre se cuente con toda la
información necesaria (ni siquiera información histórica de proyectos similares).

¿Cuál es el impacto del incumplimiento del cronograma?

Históricamente, una gran cantidad de proyectos tradicionales de desarrollo de software que utilizan metodologías
en cascada han presentado problemas en el cumplimiento de los tiempos programados y comprometidos para el
término de las fases del cronograma.
Inevitablemente los retrasos de las actividades planificadas impactan negativamente en los costos del proyecto,
ya sea por multas aplicadas, horas hombre adicionales, pérdidas de oportunidades de negocio, entre otros costos,
los que se verán aumentados respecto al presupuesto inicial, impactando en las utilidades esperadas del
proyecto.
Por otra parte, los incumplimientos de los tiempos no solo afectan los costos del proyecto, sino también la calidad
de este, debido a la necesidad de recuperar terreno perdido y disminuir el impacto en el costo. Frecuentemente se
cae en la tentación de “recortar” las tareas de las fases finales, es decir, las pruebas. En las fases previas (diseño
y construcción) es muy difícil efectuar “recortes” sin afectar el alcance comprometido, por lo tanto, las principales
víctimas de esta mala práctica son las pruebas del sistema, lo que se verá reflejado en la calidad del producto
final.
Los incumplimientos de tiempos pueden tener diversas causas, pero se originan en la estimación temprana de los
plazos reflejados en el cronograma, derivados -a su vez- de la estimación del esfuerzo y los recursos
comprometidos en cada una de las tareas. Es así como, cualquier evento o situación que altere los supuestos que
respaldan las estimaciones, incluyendo la posibilidad de una mala estimación, afectarán el cumplimiento del
cronograma.
Metodología Ágil: Scrum + Kanban
El modelo con enfoque tradicional

¿Cómo se manejan los errores?

En todo proyecto de desarrollo de software, independiente de la metodología empleada, se producirán errores de
distinta naturaleza; algunos de ellos producto de:

El escaso conocimiento del problema a resolver,

la mala interpretación de un requisito o
errores técnicos en el diseño o en la codificación de la solución.

Por lo tanto, al emplear una metodología en cascada deben existir estrictos elementos de control que permitan
verificar y validar los productos parciales obtenidos en cada fase. Aun así, muchos de estos errores recién serán
detectados en una fase avanzada del proyecto -especialmente en la fase de pruebas- o, lo que es peor, durante la
implementación y puesta en marcha del sistema, obligando a efectuar correcciones bajo un proceso de control de
cambios, lo que de alguna manera impactará en el cronograma.

Fuente: http://www.agilemodeling.com/essays/costOfChange.htm

El costo de corregir errores aumenta en forma exponencial a medida que avanza el proyecto. Al comienzo este
costo es muy bajo, mientras que corregir el mismo error en una fase posterior tiene un costo mucho mayor.
Metodología Ágil: Scrum + Kanban
El modelo con enfoque tradicional

Adicionalmente, existen algunos problemas encontrados cuando el sistema ya implantado se encuentra en

operación. No se pueden calificar de errores, pues cumplen con el alcance en términos de la funcionalidad y
calidad comprometida, y corresponden a funciones que no son utilizadas por el usuario final (desperdicio de
recursos empleados en su desarrollo) o funciones que solo al ser utilizadas se determina que requieren cambios
o mejoras. En estos casos, el producto final obtenido por el cliente puede cumplir perfectamente en términos de
alcance y calidad, pero no implica que corresponda a lo que realmente el cliente necesita.
La detección y corrección de errores es uno de los principales incentivos para adoptar un modelo iterativo con
períodos de feedback corto como Scrum.
Pese a lo anterior, la metodología en cascada se muestra como una buena alternativa para el desarrollo de
software donde existe poca incertidumbre respecto a los requisitos funcionales y factores ambientales que
pudiesen incidir en el producto a desarrollar y donde el plazo sea relativamente corto, es decir, un proyecto
acotado.

Las cartas Gantt en el desarrollo de soluciones bajo el modelo tradicional

El uso de la Carta Gantt en la planificación de tareas, tiempos y recursos es ampliamente difundido. Sin embargo,
son prácticamente inútiles en el proceso de desarrollo de una solución en el ámbito tecnológico, pues la varianza
en los tiempos de desarrollo es tan alta que hace que la incertidumbre torne irrelevante hacer una predicción.
Por ejemplo, si se aproxima que en un mes más desarrollará una tarea que requiere diez días, con una baja
varianza diríamos que se puede demorar dos días adicionales. Sin embargo, con una alta varianza, se podría, con
una alta probabilidad, demorar diez días adicionales, lo cual es equivalente al tiempo original. Por tanto, pierde
relevancia hacer una predicción, ya que hay una alta probabilidad de que no se cumpla.
Existe evidencia de que la intuición humana funciona con un comportamiento asociado a una distribución
gaussiana, aunque el desarrollo de software se comporta con tendencias más similares a distribuciones del tipo
Pareto.
Metodología Ágil: Scrum + Kanban
El modelo con enfoque tradicional

En este sentido, en las cartas Gantt - a menos que sea muy básica- existen múltiples rutas paralelas que se deben
ir cumpliendo y que desencadenan tareas en serie. Ello, si ponemos varias tareas en paralelo e incluso les
asignamos una alta probabilidad de terminar en el tiempo predicho.
Metodología Ágil: Scrum + Kanban
El modelo con enfoque tradicional

A pesar de que cada tarea finalice en su tiempo con alto nivel de probabilidad, la probabilidad, a su vez, de que el
proyecto falle en su predicción de tiempo (por ende, de recursos) es altísima. Lo anterior no pasa por la habilidad
de quien hace la predicción, sino por una deficiencia del sistema. ¿Has escuchado decir que las cartas Gantt
nunca se cumplen?
En conclusión, las graves deficiencias del modelo tradicional propiciaron la búsqueda de modelos más
evolucionados, que aumentarán las probabilidades de éxito. Así, a comienzos de los años 90, nace el “Manifiesto
Ágil”, a partir de la industria del software y por la imperiosa necesidad de contar con un modelo acorde a las
exigentes demandas de dinamismo, escalabilidad y flexibilidad de dicha industria. En la actualidad, prácticamente
cualquier startup o empresa en tecnologías innovadoras implementa modelos ágiles de desarrollo, más por una
necesidad que por una opción.

Metodología Ágil: Scrum + Kanban