Desde hace unos años, las palabras scrum, sprint y kanban se pasean por los pasillos del departamento de IT como si fueran las nuevas religiones del desarrollo. Todo es Agile. Todo es iterativo. Todo es colaborativo. Pero cuando uno trabaja con SQL Server, especialmente desde el lado de administración o desarrollo de bases de datos, la pregunta no es si Agile tiene sentido. La pregunta es si sobreviviremos al intento de aplicarlo.
Spoiler: se puede trabajar bien con Agile en entornos de SQL Server. Pero también se puede hacer tan mal que acabas con más deuda técnica que un país en default. Vamos a hablar de cómo aplicar principios Agile sin romper el modelo de datos, sin convertir cada sprint en un festival de migraciones mal versionadas, y sin sacrificar la estabilidad en nombre de una falsa “velocidad”.
¿Qué pinta una base de datos en un sprint Agile?
Uno de los grandes malentendidos cuando se mete a SQL Server dentro de un equipo Agile es asumir que los cambios en base de datos son iguales que tocar código. Spoiler: no lo son. El código es fácil de versionar, reversible y aislado. La base de datos es persistente, compartida y en producción suele ser más vieja que muchos de los devs que la usan.
A pesar de eso, en muchos equipos se nos pide trabajar “por historias”, entregar cambios “al final de cada sprint” y hacer despliegues “continuos”. ¿Y qué podría salir mal cuando cada dos semanas hay que versionar un esquema que afecta a 7 aplicaciones, 3 procesos ETL y un cubo de SSAS?
Por eso, el primer paso para aplicar Agile en SQL Server es entender que no somos iguales. No somos un microservicio. No podemos borrar y volver a compilar la base de datos en cada commit. Tenemos otra naturaleza y, por tanto, otras prácticas.
La trampa de las historias de usuario para bases de datos
Otra joya del enfoque Agile mal entendido: escribir historias de usuario para tareas de base de datos. “Como usuario quiero que el sistema guarde más información sobre los pedidos”. Y con eso se supone que debemos deducir que toca añadir 4 columnas, migrar millones de registros históricos, modificar 5 procedimientos almacenados y rezar para que el index seek sobreviva. Todo eso en 3 días.
En SQL, una historia mal escrita puede implicar semanas de refactor. O peor aún, puede parecer sencilla hasta que en QA revientan los tiempos de respuesta por culpa de una tabla sin estadísticas actualizadas.
¿Queremos usar historias de usuario? Perfecto. Pero que estén escritas por alguien que entienda el impacto en la base de datos. Y si no lo saben, que pregunten. A tiempo.
CI/CD y versionado de bases de datos: entre la teoría y el desastre
Uno de los pilares del Agile moderno es el uso de pipelines de integración y entrega continua. Maravilloso concepto. En teoría, cada cambio va versionado, probado, y desplegado automáticamente. En la práctica, cuando metemos SQL Server en la ecuación, muchos pipelines acaban con más condicionales que un CASE mal diseñado.
La verdad es que versionar correctamente una base de datos requiere herramientas específicas. No vale con subir scripts sueltos a un repositorio. Hablamos de herramientas como Flyway, Redgate SQL Source Control o SSDT bien utilizado. Y no, tirar un CREATE OR ALTER al azar en cada commit no es CI/CD. Es suicidio asistido.
Lo que necesitamos es definir una estrategia clara:
¿Vamos a usar enfoque basado en estado (state-based) o en migraciones (migration-based)? ¿Qué herramientas usamos para validar los cambios? ¿Cómo se testea una migración antes de tocar producción? ¿Quién revisa los PRs de cambios en la base de datos? Si nadie puede responder a eso, entonces lo que tenemos no es Agile. Es una bomba de relojería.
¿Sprint o esguince?: ritmo sostenible vs parche continuo
La obsesión por cerrar historias en cada sprint lleva, muchas veces, a decisiones absurdas sobre el modelo de datos. Esquemas pensados “para salir del paso”, duplicación de columnas por no refactorizar a tiempo, cambios acumulativos que nadie documenta… Y claro, luego llegan los sprints de “deuda técnica”, que suenan muy bien pero rara vez se priorizan. Porque claro, refactorizar un varchar(1000) a varchar(255) no tiene glamour. Pero mantenerlo durante años, eso sí que duele.
Un equipo Agile que no entiende la evolución del modelo de datos acabará creando un monstruo. Cada sprint mete una columna. Nadie borra nada. Y cuando miras el esquema tres meses después, parece un museo de decisiones mal tomadas. Peor aún: decisiones que nadie recuerda por qué se tomaron.
Si queremos trabajar bien, hay que introducir prácticas de diseño evolutivo del esquema. Sí, eso también existe. Y sí, también requiere tests, control de versiones y una cultura de refactor continuo. Pero sobre todo requiere que alguien se haga responsable del estado de la base de datos. Porque si todo es de todos, ya sabemos cómo acaba: en el limbo del SELECT *.
Testing y QA Agile en bases de datos: ese gran olvidado
El testing en SQL Server no es opcional, pero tampoco es trivial. Y en metodologías Agile, donde todo debe estar probado y listo para producción cada dos semanas, esto se convierte en un reto constante.
¿Se hacen pruebas de rendimiento cuando se añaden índices? ¿Hay scripts de rollback para cada migración? ¿Los procedimientos almacenados se testean con entradas límite? ¿Tenemos pruebas automatizadas que validen integridad referencial y resultados esperados?
Si la respuesta es “no”, estamos corriendo cada sprint con los cordones desatados. Un paso en falso y nos vamos de cabeza. Agile no significa mover deprisa, significa moverse bien, con ciclos de mejora continua. Y eso implica pruebas, aunque a veces piquen más que el DBCC CHECKDB.
Comunicación y ownership: el verdadero Agile en SQL
Más allá de herramientas y pipelines, lo que más influye en el éxito de una metodología Agile aplicada a SQL Server es la comunicación. Si los DBA, desarrolladores y analistas no están en el mismo canal, cada cambio será una batalla campal.
El modelo Agile bien llevado implica ownership compartido: el esquema de la base de datos no es territorio sagrado del DBA, pero tampoco puede ser tocado por cualquiera que sepa escribir ALTER TABLE. Hay que definir reglas, establecer responsables y fomentar el trabajo conjunto. Si eso no existe, el resto es teatro.
Ah, y no olvidemos lo esencial: si un cambio en la base de datos requiere más esfuerzo que el resto del sprint, no es que el DBA sea lento. Es que la historia está mal dimensionada. O mal entendida. O ambas.
Conclusión
Agile no es una metodología mágica. No convierte scripts en código limpio, ni convierte un modelo relacional en un playground de experimentos. Lo que sí hace, si se aplica con cabeza, es fomentar ciclos de mejora, colaboración y visibilidad. Pero si se aplica mal, acaba siendo solo una excusa para pedir resultados imposibles en tiempos ridículos.
SQL Server puede trabajar perfectamente bajo Agile. Pero no como el resto del código. Necesita prácticas específicas, herramientas adecuadas, y sobre todo, respeto por su complejidad. Porque esto no es un sprint. Y desde luego, si no lo hacemos bien, acabaremos en esguince.
Y no, no hay daily stand-up que arregle una base de datos destrozada por sprints sin control. Solo rollback.
