 |
| Imagen de: Picasa Web Albums |
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.
La 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.
Lecturas recomendadas
El método Lean Startup: Cómo crear empresas de éxito utilizando la innovación continua (Edición en Español)
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 el enfoque de una empresa en emprendimiento (Startup), 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: ¿Estás de acuerdo?, sino lo esta, ¿Consideras que se puede comenzar a desarrollar el proyecto ágil si la idea (lo que se quiere) no tiene suficiente madurez?.
La 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.
Lecturas recomendadas
Autor: Eric Ries
Lean Startup: How Relentless Change Creates Radically Successful Businesses (Edición en Inglés)
Autor: Eric Ries
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 el enfoque de una empresa en emprendimiento (Startup), 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: ¿Estás de acuerdo?, sino lo esta, ¿Consideras 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 la solución técnica es conocida, 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, es preferible un enfoque predictivo tradicional, como por ejemplo desarrollo en cascada.
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: ¿Estás de acuerdo con esa postura?, ¿Porque?, o ¿Porque no estas 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ás de acuerdo?, ¿Considera que si es posible proponer un esquema Agile desde un proveedor externo?, ¿Como lo haría?.
¿Y que opinas tu?
¿Cual es tu opinión? ¿Consideras que los fundamentos ágiles son aplicables a todas las situaciones?, ¿o sólo algunas?, ¿Cuales situaciones?, ¿Existen situaciones en las que es más recomendable un enfoque predictivo tradicional?.
¿Buscas más información de metodologías ágiles?
¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de metodologías ágiles y gerencia de proyectos?, suscribete a continuación.
También puedes seguirnos vía Twitter, Facebook o Linkedin:
Referencia
Cohn, M. Deciding What Kind of Projects are Most Suited for Agile. Mountain Goat Software
Nayab, N. Agile vs. Waterfall - Is There a Real Winner?. Bright Hub PM.
Artículos relacionados
>> Refactorización: 6 preguntas y respuestas
>> TDD: Componentes difíciles de probar
>> Test Driven Development (TDD): Pruebas del desarrollador
>> Test Driven Development (TDD): Como llevarlo a la práctica
>> Test Driven Development (TDD): Ventajas y desventajas
>> Test Driven Development (TDD): 9 retos para su implementación y cómo hacerles frente
>> 5 Preguntas y respuestas sobre el Feature Driven Development (FDD)
>> Plantillas Scrum: historias de usuario y criterios de aceptación
>> Scrum de Scrum: Desarrollo ágil para grandes proyectos
>> 5 métricas de desempeño para proyectos de desarrollo ágil y Scrum
>> Herramientas de software para gestión de proyectos de desarrollo ágil
>> El Desarrollo ágil en un entorno de fechas y presupuestos predefinidos
>> Los Programas de Certificación del Scrum Alliance
>> Preguntas y respuestas sobre Scrum Alliance
>> Gestión de Proyectos PMI y el Desarrollo Ágil: ¿Que tienen en común?
>> Metodologías de desarrollo ágil
Qué pasa en una empresa donde su fuente de ingresos es la alta disponibilidad de sus servicios. Los usuarios solicitan muchos cambios a un Core Transaccional, estos cambios se han hecho por años, pero cada semana se suben a producción más de 10 mantenimientos y un par de proyectos. Todo desarrollo es interno, los usuarios conocen bien el negocio y los cambios a nivel técnico, pero no documentan. ¿Es posible aplicar el desarrollo agil???
ResponderEliminarHola Armando, Si esos los mantenimientos y proyectos se están entregando dentro de las estimaciones iniciales (es decir el error de estimación es muy bajo), estos son muy buenos resultados, es muy posible que muchos de los principios y valores de la agilidad ya se estén aplicando.
ResponderEliminarSi existe retraso o errores de estimación, ¿estamos seguros que realmente conocemos el negocio y los cambios técnicos?, o quizás si los conocemos pero existen muchos cambios de prioridades o de alcance, en ese caso sería conveniente revisar las prácticas actuales y hacer algunos cambios hacia la agilidad.
Un Saludo,
Desafortunadamente si existen muchos errores, de hecho muchas veces se sube el fix del fix.
ResponderEliminarLa estimación no es la adecuada; sobre todo porque los desarrolladores y los testers se sobresaturan de trabajo por cumplir los compromisos.
Los cambios de prioridad están a la orden del día y sobre todo tenemos muchos usuarios que indican su prioridad de acuerdo a sus propias necesidades.
yeah its a very good article.Certifications will definitely increase the salary significantly. For project management professionals, I would suggest them to attend any genuine agile scrum certification courses (eg. Scrum Master Certification). If not anything, at least it will give a boost to your career and salary.
ResponderEliminarcreo que la documentación es un activo para la continuidad y el desarrollo de mejora continua, creo la eficiencia en el desarrollo ágil pero debe entrar documentación... dentro de su dinamica
ResponderEliminar