Una metodología de desarrollo de software es la forma acordada de organizar un proyecto. Marca en qué orden se hacen las fases, cada cuánto se entrega y cómo se aceptan los cambios. Hay dos grandes familias. Las predictivas, como la cascada, planifican todo al principio. Las ágiles (Scrum o Kanban, por ejemplo) entregan en ciclos cortos y corrigen el plan sobre la marcha.
Qué es una metodología de desarrollo.
Todo proyecto de software pasa por las mismas actividades, desde entender qué se necesita hasta mantener el programa en uso. La metodología no cambia esas actividades. Cambia cómo se ordenan en el tiempo, quién decide y cuándo ve el cliente algo que funciona.
Elegirla bien pesa más de lo que parece. Con la misma gente y el mismo presupuesto, un proyecto puede salir bien o mal según cómo se gestionen los cambios de opinión. Y en software casi siempre hay cambios de opinión.
Metodologías predictivas: la cascada.
En cascada, cada fase empieza cuando termina la anterior. Primero se escriben todos los requisitos, luego se diseña, después se programa y al final se prueba. El cliente ve el programa completo casi al terminar.
Funciona cuando los requisitos están cerrados y no se van a mover. Por ejemplo, adaptar un programa a una norma con especificaciones técnicas publicadas, o migrar un sistema que ya existe a otra tecnología.
En España, la administración publicó su propia metodología, Métrica versión 3, para planificar, desarrollar y mantener sistemas de información. Ordena el trabajo en procesos sucesivos, del estudio de viabilidad al mantenimiento. Es un buen ejemplo de enfoque predictivo pensado para proyectos grandes.
Variantes como el modelo en V o el modelo en espiral mantienen la planificación inicial. Añaden más puntos de prueba o de revisión de riesgos entre una fase y la siguiente.
Metodología ágil de desarrollo de software.
La metodología ágil nace como reacción a los proyectos que tardaban tanto que, al entregarse, ya no servían. Su referencia es el Manifiesto por el Desarrollo Ágil de Software, de 2001. Valora más a los individuos y sus interacciones que los procesos y las herramientas. También antepone la respuesta ante el cambio a seguir un plan.
En la práctica, ágil significa entregar pronto y a menudo. Uno de sus principios pide entregar software que funcione entre cada dos semanas y cada dos meses, mejor cuanto más corto sea el plazo. Cada entrega se revisa con el cliente, y lo aprendido cambia la siguiente.
Ágil no significa improvisar ni trabajar sin documentación. Significa planificar en ciclos cortos y aceptar que el plan se corrige con lo que se aprende al usar el programa.
Scrum, Kanban y XP.
Bajo la etiqueta ágil hay marcos de trabajo concretos. Estos son tres de los más conocidos en desarrollo de software.
Scrum organiza el trabajo en sprints de duración fija, de un mes o menos. Cada sprint acaba con una parte del producto que funciona y una revisión con el cliente. Lo explicamos a fondo en Scrum en el desarrollo de software.
Kanban no usa ciclos fijos. Su guía oficial lo define como una estrategia para optimizar el flujo de valor a través de un proceso. El equipo ve las tareas en un tablero y limita cuántas puede tener empezadas a la vez.
XP (Extreme Programming) se centra en las prácticas técnicas. Propone programar en parejas, escribir las pruebas antes que el código e integrar cambios varias veces al día. A menudo se combina con Scrum.
Comparativa de metodologías.
| Metodología | Cómo planifica | Cada cuánto entrega | Cambios | Encaja en |
|---|---|---|---|---|
| Cascada | Todo al principio | Al final del proyecto | Caros, obligan a replanificar | Requisitos cerrados y estables |
| Scrum | Por sprints de un mes o menos | Al final de cada sprint | Entran en el sprint siguiente | Productos que se descubren usándolos |
| Kanban | De forma continua | Cuando cada tarea está lista | En cualquier momento, si hay hueco | Mantenimiento y soporte |
| XP | En ciclos cortos | Con mucha frecuencia | Bienvenidos, protegidos por pruebas | Equipos técnicos con un cliente muy disponible |
| Híbrida | Alcance general al inicio y detalle por ciclos | Por hitos | Dentro de un margen pactado | Presupuesto cerrado con requisitos abiertos |
Cómo elegir la metodología de tu proyecto.
- Si sabes exactamente qué necesitas y no va a cambiar, una planificación en cascada es razonable.
- Si vas a descubrir lo que necesitas al ver las primeras pantallas, elige un enfoque ágil.
- Si el trabajo son peticiones pequeñas y continuas, como un mantenimiento, Kanban encaja mejor.
- Si tienes un presupuesto cerrado, pide un enfoque híbrido con un alcance mínimo garantizado.
- En cualquier caso, pregunta cada cuánto verás algo funcionando.
Esa última respuesta dice más que el nombre de la metodología. Hay algo, además, que ninguna metodología resuelve, la falta de tiempo del cliente. Un enfoque ágil exige que alguien de tu empresa revise cada entrega y decida prioridades.
Para el día a día del proyecto, con plazos, riesgos y herramientas, tienes gestión de proyectos de software. Nuestro fundador desarrolla software desde 2013. Si quieres saber cómo plantearíamos tu caso, cuéntanoslo en desarrollo de software a medida o mira nuestros proyectos.
Preguntas frecuentes.
No hay una mejor para todo. La cascada encaja con requisitos cerrados, y las ágiles con proyectos que se definen sobre la marcha.
Sí. Scrum aplica los valores del Manifiesto Ágil con sprints, responsabilidades y eventos fijos.
Sí, aunque conviene hacerlo al cerrar una entrega. Cambiarla en mitad de una fase suele dejar trabajo a medias.
