¿Cuando aplicar y no aplicar el desarrollo ágil?

En tiempos recientes, el empleo de fundamentos y marcos de trabajo de desarrollo ágil se ha extendido en la industria de desarrollo de software y en el ámbito interno de las organizaciones en general. Sin embargo, esta amplia difusión está ocasionando que parezca que pueden aplicarse a cualquier tipo de proyecto, aunque en muchos casos esté respondiendo realmente a una moda en lugar de a una necesidad concreta.

En este artículo se describen algunos factores a considerar para saber si conviene aplicar un enfoque ágil o no, tales como: Evaluación de la naturaleza del problema, evaluación del conocimiento de la solución técnica al problema que tenga la organización y el equipo de trabajo, así como otros factores de la cultura de la organización.

Presentamos a continuación los factores a considerar para aplicar (o no) los fundamentos del desarrollo ágil:


Los fundamentos ágiles responden a la necesidad de reducir el gran porcentaje de proyectos de tecnología que fracasan, debido a los requerimientos cambiantes de las áreas de negocio y la incertidumbre sobre las soluciones técnicas aplicadas para resolver problemas reales.

A pesar que el Desarrollo Ágil surgió de las limitaciones de los métodos predictivos tradicionales (Desarrollo en cascada), estos aún siguen siendo preferibles cuando el entorno de organización es estable, sin posibilidades de cambios en la aplicación durante el desarrollo, cuando las interacciones frecuentes con usuarios finales y otros involucrados no son posibles, o cuando existe riesgo de rotación de personas en el equipo (renuncias).

Por esto, se requiere contar con un criterio para decidir si debe aplicarse un enfoque de desarrollo ágil o no.

Evaluación de la naturaleza del problema

Implica saber hasta que punto el usuario, representado en el dueño del producto (Product Owner) “Sabe lo que necesita y lo que quiere”. Para evaluarlo, se pueden realizar las siguientes preguntas:

¿Se tiene una idea de negocio que da origen a la solicitud de la solución técnica?

¿Se tiene definido el modelo de negocio a seguir para implementar esa idea?

¿Se tiene definido los objetivos y metas asociados con el modelo de negocio?

¿Se conoce que problema de organización se desea resolver?

Esta evaluación puede dar resultado de concluir si se conoce o no se conoce que problema se desea resolver.

Evaluación de nuestro conocimiento de la solución

Partiendo de un problema a resolver, que puede ser conocido o desconocido, el siguiente paso es determinar si se está desarrollando algo nuevo, o al menos nuevo para el equipo que lo está construyendo, o si por el contrario es algo que se ha hecho antes. Asimismo, es necesario evaluar el grado de complejidad de la solución técnica.

Se pueden evaluar las siguientes preguntas:

¿Cual es el grado de complejidad de la solución requerida para atender el problema?

¿La solución propuesta, es el mismo producto que se construye siempre o es algo nuevo?

¿Cual es el grado de urgencia de la solución?

¿La fecha tope es agresiva?

¿La Tecnología a utilizar para la implementación está probada en la organización?

¿La usabilidad (flujo de pantallas, procesos, etc.) es conocido por el usuario?, ¿Está documentado?.

¿El usuario conoce como quiere resolver el problema y puede documentarlo en la forma de Casos de Uso detallados, Especificaciones Técnicas, Casos de Prueba, etc.).

¿De entrada se tiene una visión del producto? o ¿Se irá concretando a medida que se vaya desarrollando?

¿Se espera alta inestabilidad en los requerimientos?

De esta evaluación se determinará en que grado es conocida la solución técnica o no lo es.

Consideración de otros factores

Es necesario considerar adicionalmente otros factores, específicamente:

¿El Desarrollador del proyecto es interno de la organización o es un proveedor externo?

¿La forma de contratación o presupuesto para el proyecto deseada es de alcance y precio cerrado? o es de otra forma como por ejemplo ¿Tiempo y materiales? o ¿Tiempo y costo fijo con alcance variable (Servicio)?.

Si el desarrollador es externo, pudieran existir una desconfianza inicial (en el caso de un proveedor nuevo) por diferencias culturales en ambas organizaciones. Asimismo, si la organización cliente favorece un esquema de presupuesto o contratación de alcance y precio cerrado, no podría aplicarse el desarrollo Ágil.

¿Como decido?

A continuación se propone un criterio para determinar si es recomendable aplicar los fundamentos ágiles, sin embargo, existe mucho debate y controversia respecto al tema en la comunidad del Internet, por lo que les invitamos también a exponer su propio criterio en los comentarios del artículo.

Es recomendable aplicar fundamentos ágiles cuando:

1.- El Problema es conocido

La aplicación exitosa de los fundamentos del desarrollo ágil requieren que un representante del usuario, como lo es el “Product Owner” en Scrum, pueda explicarle al equipo “Que es lo necesita y quiere lograr con la solución técnica”.

Pero, ¿Que ocurre si este usuario no sabe lo que quiere?, ¿Existen diferentes puntos de vista en la organización cliente? o si el usuario necesita experimentar con su modelo de negocio antes de aplicar la solución.

En ese caso no sería recomendable aplicar los fundamentos ágiles porque se corre el riesgo de iterar constantemente sin lograr ningún objetivo. En su lugar a organización debería aplicar un enfoque de tipo emprendimiento, en el cual el concepto sea sometido a evaluaciones con clientes finales (como por ejemplo Focus Group o reuniones internas), antes de recurrir al desarrollador de Software.

Por lo tanto, para que los fundamentos ágiles pueden agregar valor, el problema debe ser conocido.

Consultamos a la audiencia: ¿Esta de acuerdo?, sino lo esta, ¿Considera que se puede comenzar a desarrollar el proyecto ágil si la idea (lo que se quiere) no tiene suficiente madurez?.

2.- La Solución Técnica es desconocida

Saber que se quiere hacer es diferente a saber como, pues quizás el usuario tenga un concepto de producto claro, pero no sepa como implementarlo en la práctica.

Los Fundamentos ágiles agregan más valor cuando la solución técnica es desconocida, es decir, si es de un alto grado de complejidad, distinto a lo que el equipo de desarrollo ha trabajado y si es una solución innovadora que el equipo nunca ha realizado.

Cuando el problema es conocido, es decir, el entorno de organización es estable, los cambios son infrecuentes y se esta desarrollando un producto que el equipo ya ha desarrollado varias veces, un enfoque predictivo tradicional, como por ejemplo desarrollo en cascada es preferible.

Más allá de considerar el Desarrollo Ágil como una moda, si tenemos un equipo que hace mantenimiento de una aplicación, los requerimientos de mantenimiento son similares y el mismo equipo ha hecho ese trabajo durante años, no se necesita un enfoque ágil.

Consultamos a la audiencia: ¿Esta de acuerdo con esa postura?, ¿Porque si esta de acuerdo?, o ¿Porque no esta de acuerdo?, ¿Cuales son las razones?.

3.- La forma de contratación o presupuesto es distinta de alcance y presupuesto cerrado

Los Fundamentos ágiles parten de la premisa que el alcance puede ser modificado de iteración en iteración, según las necesidades y prioridades del negocio, por lo que si de entrada la organización necesita que el alcance del proyecto y su presupuesto estén definidos desde el principio, y que al final del proyecto se entregue exactamente ese alcance, no es Agile.

Consultamos a la audiencia ¿Cuales formas de contratación se podrían considerar?.

4.- El Proveedor de la solución es interno, o es un proveedor con una relación de largo plazo

Si se está desarrollando la solución con un proveedor externo con una relación de corto plazo, la organización, al no existir suficiente grado de confianza, tenderá a favorecer un esquema de alcance y precio cerrado para la contratación, por lo cual, no sería recomendable para este proveedor proponer un esquema Agile, siendo en su lugar preferible un enfoque tradicional.

Consultamos a la audiencia: ¿Está de acuerdo?, ¿Considera que si es posible proponer un esquema Agile desde un proveedor externo?, ¿Como lo haría?.

Vía | pmoinformatica.com

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s


A %d blogueros les gusta esto: