Guía completa para comprender, comparar y aplicar las metodologías de desarrollo de software más utilizadas en la industria TI colombiana, orientada a estructurar propuestas técnicas con criterio profesional.
"Estructurar propuesta técnica de servicio de tecnología de la información según requisitos técnicos y normativa"
Una metodología de desarrollo de software es el conjunto de prácticas, principios, roles y herramientas que un equipo adopta para planificar, ejecutar y controlar la construcción de un sistema de información. No es simplemente un "orden de pasos": es un marco de toma de decisiones que determina cómo se gestiona la incertidumbre, cómo se comunica el equipo y cómo se entrega valor al cliente.
En el contexto de los proyectos de tecnología de la información, elegir la metodología correcta es tan crítico como elegir el lenguaje de programación o la base de datos. Una mala elección metodológica puede hacer que un proyecto técnicamente correcto fracase en tiempos, costos o satisfacción del cliente.
En Colombia, el Ministerio de Tecnologías de la Información y las Comunicaciones (MinTIC) ha adoptado estándares como PMBOK (Project Management Body of Knowledge) e ISO/IEC 12207 para el ciclo de vida del software. Conocer las metodologías de desarrollo permite alinearse con estos marcos al estructurar propuestas técnicas.
Los proyectos de desarrollo web tienen características particulares: los requisitos cambian con frecuencia, el cliente quiere ver resultados pronto y la tecnología evoluciona rápidamente. Esto hace que la elección entre una metodología predictiva (como Cascada) o adaptativa (como Scrum) tenga consecuencias directas sobre el éxito del proyecto.
Antes de continuar: ¿tu equipo tiene claro quién hace qué, cuándo y con qué herramientas? Si la respuesta es "más o menos", este es el problema metodológico que vamos a resolver.
La Metodología Cascada (del inglés Waterfall) es un modelo de desarrollo de software de tipo predictivo o secuencial. Fue descrita formalmente por Winston W. Royce en 1970, aunque irónicamente Royce la propuso como ejemplo de un modelo que no debería usarse sin verificaciones intermedias.
Su nombre evoca una cascada de agua: cada fase "cae" hacia la siguiente, y una vez que el agua ha caído, no puede subir. Esto significa que cada fase debe estar completamente terminada y aprobada antes de pasar a la siguiente. Los cambios en etapas tardías son costosos y difíciles de gestionar.
El flujo es estrictamente unidireccional: una fase completa antes de iniciar la siguiente.
Es la fase más crítica. Aquí el equipo se reúne con el cliente para documentar todos los requisitos funcionales (qué debe hacer el sistema) y no funcionales (rendimiento, seguridad, usabilidad). El entregable es el Documento de Especificación de Requisitos del Software (ERS).
Se traduce el documento de requisitos en una arquitectura técnica. Incluye el diseño de la base de datos, la arquitectura de software, los diagramas de flujo y el prototipo visual de la interfaz (wireframes).
El equipo de desarrollo escribe el código siguiendo estrictamente el diseño aprobado. No se toman decisiones de diseño en esta fase; si aparece un problema, se escala a la fase de diseño (con el costo que eso implica).
El equipo de calidad (QA) verifica que el sistema construido cumple con los requisitos especificados en la fase 1. Se realizan pruebas funcionales, de integración, de estrés y de usuario.
Una vez desplegado el sistema en producción, comienza la fase de mantenimiento: corrección de bugs, actualizaciones de seguridad y mejoras menores. Esta fase puede durar años.
Documentación exhaustiva que facilita auditorías · Cronograma y costos predecibles · Ideal para equipos con poca comunicación continua · Fácil de explicar a clientes con poca experiencia técnica · Estructura clara de responsabilidades por fase.
El cliente solo ve el producto completo al final · Los cambios tardíos son costosos y difíciles · No se adapta bien a proyectos con requisitos cambiantes · El tiempo entre inicio y primera entrega puede ser de meses · Los errores de análisis se descubren muy tarde.
Scrum es un marco de trabajo ágil para gestionar proyectos complejos. Fue desarrollado por Jeff Sutherland y Ken Schwaber a principios de los 90 y oficializado en la Scrum Guide. Parte del Manifiesto Ágil (2001), que establece cuatro valores fundamentales:
Ágil no significa "sin documentación" ni "sin plan". Significa que el plan se adapta continuamente a la realidad del proyecto. La documentación existe, pero es proporcional al valor que genera.
El tablero Kanban (o tablero Scrum) es la herramienta visual del equipo para gestionar el flujo de trabajo. Tiene columnas que representan el estado de cada tarea:
El Work In Progress limit (límite de trabajo en curso) es una regla que prohíbe tener más de N tareas en "En progreso" simultáneamente. Superar este límite es la causa más común de desorden en la etapa de desarrollo. Si todos están "en progreso" con todo, nadie termina nada.
Las tareas del backlog se escriben como historias de usuario con el formato:
Como [tipo de usuario],
quiero [funcionalidad que necesito],
para poder [objetivo o beneficio que obtengo].
Ejemplo: Como visitante del sitio web, quiero poder registrarme con mi correo electrónico, para poder acceder a contenido exclusivo.
| Criterio | Cascada (Waterfall) | Scrum (Ágil) |
|---|---|---|
| Enfoque | Predictivo — todo se planea al inicio | Adaptativo — el plan evoluciona con el proyecto |
| Requisitos | Fijos y completamente definidos desde el inicio | Pueden cambiar y refinarse en cada sprint |
| Entrega al cliente | Una sola entrega al final del proyecto | Entregas parciales funcionales cada sprint |
| Cambios | Costosos y complejos en etapas avanzadas | Bienvenidos y gestionados en el backlog |
| Documentación | Extensa y obligatoria en cada fase | Justa y necesaria; el código funcionando es la prioridad |
| Pruebas | Al final, como fase separada | Continuas, integradas en cada sprint |
| Equipo | Especialistas por fase (analistas, diseñadores, devs...) | Equipo multifuncional que cubre todas las áreas |
| Riesgo | Alto — los errores se detectan tarde | Bajo — la retroalimentación continua reduce riesgo |
| Ideal para... | Proyectos con requisitos estables y regulados | Proyectos web, apps y productos digitales iterativos |
| Visibilidad del progreso | Baja — el cliente no ve avances intermedios | Alta — el cliente ve y retroalimenta en cada sprint |
Los proyectos de desarrollo web en entornos formativos y empresariales modernos se benefician más de Scrum porque los requisitos del cliente cambian, las tecnologías evolucionan y es necesario entregar valor de forma incremental. Sin embargo, la fase de análisis inicial de Cascada (bien ejecutada) puede complementar perfectamente un proceso Scrum.
Toda propuesta técnica profesional debe referenciarse en estándares reconocidos. Los más relevantes para proyectos de desarrollo web en Colombia son:
Define los procesos del ciclo de vida del software desde la concepción hasta el retiro. Establece qué actividades deben realizarse, no cómo hacerlas. Tanto Cascada como Scrum pueden implementarse dentro de este estándar.
El Project Management Body of Knowledge es el estándar de gestión de proyectos más utilizado globalmente. Su sexta edición integró un capítulo completo sobre enfoques ágiles. Es la base de la certificación PMP (Project Management Professional).
Aunque no es exclusiva de software, ISO 9001 establece los requisitos para que una organización demuestre que puede entregar productos y servicios de calidad. Muchas empresas exigen a sus proveedores TI la conformidad con este estándar.
El Ministerio TIC ha publicado guías para la arquitectura empresarial de entidades del Estado colombiano. Para proyectos gubernamentales, la metodología debe alinearse con este marco.
Una propuesta técnica de TI debe incluir: alcance del proyecto · metodología elegida y justificación · cronograma o plan de sprints · equipo y roles · requisitos técnicos (infraestructura, tecnologías) · criterios de aceptación · normativa aplicable · presupuesto estimado · plan de riesgos.
Aplicar ambas metodologías al proyecto web real que está desarrollando tu grupo, identificar los problemas de desorganización actuales y proponer una estructura metodológica concreta. Esta actividad contribuye directamente al resultado de aprendizaje de la competencia.
En una hoja en blanco, traza una línea horizontal de izquierda a derecha. Encima de ella, escribe en orden las 5 fases: Análisis → Diseño → Desarrollo → Pruebas → Mantenimiento. Deja espacio vertical debajo de cada fase.
Debajo de cada fase, escribe las tareas reales de tu proyecto web que corresponden a esa fase. Usa flechas hacia abajo. Si una tarea no encaja claramente en ninguna fase, déjala al margen con un signo de interrogación.
Con lápiz rojo, dibuja una flecha de retorno (hacia atrás) en cualquier momento en que tu equipo haya tenido que volver a una fase anterior por un cambio o error. Anota la causa. Este ejercicio visibiliza el costo del cambio tardío en Cascada.
En la segunda hoja, dibuja 4 columnas con estos encabezados: Backlog · Sprint actual · En progreso · Terminado. Dibuja una línea vertical entre cada columna.
Recorta 8 tarjetitas de la hoja de color. En cada una, escribe una funcionalidad o tarea del proyecto (ej: "formulario de contacto", "menú de navegación", "conexión a base de datos", "sistema de login"). Cada tarjeta = una historia de usuario.
Sin mentir: ubica cada tarjeta en la columna que refleja el estado real de esa tarea hoy. Aplica el WIP limit: si hay más de 2 tarjetas por persona en "En progreso", enciérralas con un círculo rojo — ese es el problema de desorden que tiene tu equipo.
El Product Owner prioriza: ¿cuáles 3 tarjetas del Backlog se mueven al "Sprint actual" para la próxima semana? Escríbanlo con nombre del responsable y fecha de entrega. Firmen el compromiso.
En el reverso de cualquiera de las hojas, respondan como equipo:
Cada grupo pega sus dos hojas en la pared. El Scrum Master explica: qué descubrieron sobre su proyecto, cuántas tarjetas tenían en progreso y qué cambia metodológicamente a partir de hoy.
El instructor señala los patrones comunes de desorden identificados en todos los tableros y los conecta con las causas metodológicas. Conecta los hallazgos con la competencia: ¿cómo influye esto en una propuesta técnica de TI?
Cada aprendiz escribe en su tablero: "En el próximo sprint terminaré: [tarea específica] antes del [fecha]". Lo firma. Los tableros quedan expuestos en el aula durante el resto del módulo.
Recorta o reproduzca estas plantillas en el taller.
Escribe las tareas de tu proyecto debajo de cada fase. Usa flechas de retorno en rojo cuando hayas tenido que volver atrás.
Retroalimentaciones / flechas de retorno encontradas: ____________________________
Recorta tarjetitas y ubícalas en la columna correspondiente. WIP máximo: 2 tareas por persona en "En progreso".
Fecha del sprint: _____________ al _____________ | Scrum Master: _______________________
Nombre: ___________________________________ Proyecto: ___________________________
1. La metodología que más le conviene a mi proyecto es ___________ porque:
2. El mayor problema de desorganización de mi equipo en la etapa de desarrollo es:
3. En la próxima semana (sprint) me comprometo a terminar:
4. Para estructurar una propuesta técnica de TI, debo incluir:
La actividad se evalúa según los criterios de la competencia. La siguiente tabla indica los indicadores de desempeño y el nivel esperado:
| Indicador de desempeño | Nivel | Evidencia esperada |
|---|---|---|
| Diferencia correctamente las características de Cascada y Scrum | Básico | Tabla comparativa correctamente diligenciada en la actividad |
| Ubica las tareas de su proyecto en la metodología correcta | Básico | Diagrama de Cascada con tareas reales del proyecto |
| Construye un tablero Scrum con el estado real del proyecto | Medio | Tablero Kanban físico con tarjetas en columnas correctas |
| Identifica el WIP limit y los problemas de flujo de su equipo | Medio | Análisis escrito del número de tareas en progreso y causa del desorden |
| Justifica la elección metodológica con argumentos técnicos | Alto | Respuesta escrita a la pregunta 5 de reflexión con criterios técnicos |
| Estructura los elementos básicos de una propuesta técnica de TI | Alto | Lista de componentes de la propuesta con justificación metodológica |
| Sustenta oralmente las decisiones del equipo ante el grupo | Alto | Participación en la plenaria con claridad conceptual y técnica |
Los tableros físicos deben quedar expuestos en el aula. En la siguiente sesión de desarrollo, se realiza un Daily Scrum de 15 minutos revisando el tablero de cada grupo. Esto institucionaliza el hábito sin requerir herramientas digitales desde el primer día.