Si diriges un proyecto de software, una de las preguntas más frecuentes es qué metodología de desarrollo utilizar. Algunos prefieren el enfoque tradicional en cascada, mientras que otros son firmes defensores de la metodología ágil. En realidad, muchos proyectos terminan adoptando una metodología intermedia, que no es ni extremadamente ágil ni extremadamente rígida.
En comparación con el modelo en cascada, estas metodologías intermedias pueden parecer flexibles, ya que permiten realizar cambios entre iteraciones. Sin embargo, en comparación con la metodología ágil, suelen parecer rígidas y mucho menos colaborativas.
Al elegir la metodología de desarrollo adecuada para tu proyecto, considera su flexibilidad y qué aspectos de diferentes enfoques puedes incorporar para que se ajuste mejor a tus necesidades. Analiza la magnitud del proyecto, la composición de tu equipo, la cultura organizacional y los objetivos que deseas alcanzar. Luego, diseña la metodología que mejor se adapte a tus necesidades específicas. Incluso si tu organización recomienda un enfoque determinado, siempre habrá oportunidades para mejorarlo y adaptarlo a tu proyecto.
Para ayudarte a decidir qué enfoque se adapta mejor a tu situación, ten en cuenta los siguientes aspectos. Las preguntas te ayudarán a determinar el grado de flexibilidad que requiere tu metodología, en una escala que va desde muy flexible (ágil) hasta muy rígida (cascada).
Consulta también: Metodologías ágiles frente a metodologías en cascada: una guía estratégica para gestores de proyectos (con tabla comparativa detallada).
1. ¿Qué tan claros son los objetivos y requisitos del proyecto?
En algunos proyectos, los clientes saben con exactitud qué buscan lograr y cuáles son los criterios de éxito. En otros, puede resultar difícil determinar qué se necesita conseguir o cuáles son los requisitos. Cuando los requisitos son difíciles de definir o es probable que cambien significativamente, se necesita un enfoque relativamente experimental y flexible; un enfoque que permita demostrar y prototipar ideas rápidamente al cliente e incorporar los requisitos cambiantes.
2. ¿Qué tan clara y bien definida es la solución?
Puede que te encuentres en una situación donde el resultado deseado del proyecto sea claro, pero la solución para lograrlo no lo sea. Cuando el equipo se enfrenta a decisiones difíciles y arriesgadas en torno a la tecnología, el diseño y la implementación, tu metodología de desarrollo de software debe ser lo suficientemente flexible para adaptarse a esta situación e iterar a través de las distintas etapas de creación de prototipos, desarrollo y lanzamiento.
3. ¿Qué tan fácil o difícil es acceder a los usuarios finales?
¿Es probable que los usuarios, expertos en la materia y responsables del producto estén disponibles para proporcionar comentarios y ayudar a probar los entregables con poca antelación, o prevé que será difícil contactarlos? ¿Sería más sencillo involucrarlos en un ciclo de pruebas planificado previamente donde se puedan probar muchos entregables a la vez? Cuantas más limitaciones haya en la disponibilidad de los usuarios, más rigurosa deberá ser la metodología.
4. ¿Cuál es el tamaño del proyecto?
¿Tu proyecto es de gran envergadura o es relativamente pequeño y ágil? Cuanto mayor sea el proyecto, más difícil será incorporar muchos cambios con poca antelación y reorientar al equipo. Los equipos pequeños y cohesionados que trabajan en estrecha colaboración con el cliente y los usuarios finales son más flexibles y están mejor preparados para incorporar cambios rápidamente.
5. ¿Qué grado de dispersión tiene el equipo del proyecto?
¿Tienes varios equipos de proyecto ubicados en diferentes lugares geográficos o el equipo es más homogéneo y trabaja en la misma ubicación? Cuando el equipo está disperso geográficamente, puede resultar difícil coordinar rápidamente nuevas tareas y adaptarse a los cambios de prioridades. Los equipos que trabajan juntos, incluso compartiendo la misma sala, están mucho mejor preparados para trabajar en un entorno ágil con prioridades cambiantes.
6. ¿Cuál es la experiencia del equipo y de las partes interesadas con estas metodologías?
¿Su equipo y las partes interesadas ya están acostumbrados a trabajar con una metodología específica? De ser así, tenga en cuenta que cambiar las prácticas de trabajo de un equipo lleva tiempo. Si su proyecto es crítico en cuanto al tiempo, tenga cuidado de no realizar ajustes demasiado drásticos a la metodología existente, ya que podría poner en peligro los plazos y el éxito del proyecto.
7. ¿Cuáles son los criterios de éxito del proyecto?
¿Qué es más importante para su patrocinador y cliente? ¿Contar con un presupuesto y un cronograma relativamente firmes que deben cumplirse, o garantizar que los entregables finales aporten valor y satisfagan las necesidades y expectativas del usuario? ¿Está su cliente dispuesto a adoptar un enfoque más flexible y centrado en la calidad, aunque ello implique sacrificar los costos y los plazos fijos?
8. ¿Cuánto valor añadido aportaría el desarrollo incremental basado en funcionalidades?
¿El proyecto se presta a ser entregado de forma incremental y esto aportaría un valor real a las partes interesadas? ¿Es necesario entregar los productos y las funcionalidades de una sola vez para obtener beneficios tangibles o sería una ventaja real entregarlos gradualmente?
Republicado con permiso de Susanne Madsen.
Autora:
Susanne Madsen
Susanne Madsen es una coach, formadora y consultora de liderazgo de proyectos reconocida internacionalmente. Es autora de *The Project Management Coaching Workbook* y *The Power of Project Leadership*. Susanne cree que el éxito en la gestión de proyectos radica tanto en liderar personas como en gestionar tareas, eventos y procesos. Es una firme defensora y practicante del método GTD (Get Things Done) y disfruta ayudando a las personas a formular y alcanzar sus objetivos. Para obtener más información sobre Susanne, visite http://www.susannemadsen.com/
Comentarios
0 respuestas