En Scrum, ¿quién es el responsable de gestionar las bases de datos?

La semana pasada comentaba en ¿Y qué pasa con la integración continua de bases de datos? que me parecía interesante sacar a la luz el tema de cómo gestionar distintos aspectos de las bases de datos (relacionales sobre todo). Y ver también cómo se hacía en otras empresas.
Dándole vueltas al asunto, llegué a la conclusión de que, como en muchas otras cosas, un buen punto para empezar a enfocar el tema es identificar responsabilidades.
Es decir, ¿quién se encarga de las bases de datos en el equipo? Por ejemplo, ¿quién se encarga de este tema en un equipo Scrum?
Y dirás, ¡pero si una de las bases de un equipo Scrum es que sea multifuncional! (recuerda el post Los equipos modernos de desarrollo son multifuncionales, así disparan la velocidad y la productividad.).
Sí, no lo estoy contradiciendo. ¿Pero qué grado de responsabilidad tiene cada rol? ¿Diferenciamos roles en el equipo cuando hablamos de bases de datos?
Por ejemplo, existen diferentes tipos de pruebas, distintos grados de pruebas. Y distintos roles.
Los QAs, los testers, pueden hacer pruebas funcionales, de carga etc. Pero el testing no solo es responsabilidad de los QAs y de los testers, sino que también los desarrolladores tienen que probar que su código funciona e implementar pruebas unitarias.
Entonces, yo me planteo: en un equipo Scrum, ¿de quién es la responsabilidad de gestionar las bases de datos? ¿Y de evolucionar su diseño? ¿Debe haber algún rol específico en el equipo? ¿O no hace falta, mientras que el equipo sepa de ello?
Scrum se basa en un ciclo de vida iterativo e incremental, donde una de las cosas importantes es que vamos refinando y mejorando tanto el proceso Scrum en sí mismo (con las reuniones de retrospectivas, por ejemplo) y el producto (esa parte de ciclo de vida iterativo en la que también promovemos refactorizaciones y mejoras de calidad de código).
Si estamos de acuerdo en que con este enfoque el código debe ir mejorándose y refactorizándose, debemos tener una batería de pruebas automáticas que nos aseguren que la refactorización no ha roto nada, y que es necesario versionar integrar el código frecuentemente…¿Qué pasa con la base de datos? ¿Por qué tiene que ser más rígida? ¿Por qué no hacemos lo mismo? ¿Diseño iterativo de código + base de datos? ¿Por qué parece que tendemos a que el código vaya por un lado y la base de datos por otro?¿Por qué solemos tener más miedo a evolucionarla?
Y sobre todo…¿quién se va a encargar de ello?
Personalmente me he encontrado con 3 enfoques diferentes para tratar esto, que han funcionado en diferentes empresas:

1 – Las bases de datos las gestiona el DBA

Un DBA (DataBase Administrator) típico, es una persona, o grupo de personas, responsables de tareas como la instalación, configuración, actualización, mantenimiento, administración y monitorización de las bases de datos de una organización.
Aunque normalmente la cosa no se queda ahí. Normalmente un DBA es alguien que tiene una visión global de la base de datos.
Cuando un desarrollador quiere modificar algo de la base de datos, deberá consultar y conseguir el consentimiento del DBA, ya que este rol es un experto en este tema.
El DBA sabe cómo debería evolucionar la base de datos y cómo mantener un buen diseño y optimización.
Pero la pregunta aquí es, ¿cabe este rol dentro de un equipo ágil? Personalmente no lo descartaría del todo, sobre todo en empresas que quieren adoptar un enfoque más ágil, pero tienen tradición de tener un rol de DBA.
Es un rol especialista, útil, que sabe de un área en concreto. Lo que si es importante es cambiar el enfoque… hacia un rol de DBA más ágil.

1.1 – Un DBA Ágil

Para ciertas empresas, el rol de DBA es muy importante. Estas empresas son capaces de aplicar Scrum, teniendo un rol de DBA en cada equipo, o compartido entre varios equipos.
Lo que si es cierto, es que este rol debe adaptarse desde un enfoque más típico hacia los valores ágiles.
Igual que el rol de tester cambió, este rol también adquiere un nuevo enfoque.
Lo más importante es que el DBA no está separado del resto del equipo. Al igual que otros perfiles, participa en las reuniones, en las estimaciones etc.
Por otra parte hay que fomentar una muy buena comunicación entre el todos los miembros del equipo y el DBA, solucionando posibles cuellos de botella. Y debe estar sentado con el resto del equipo.
Otra cosa importante es que un DBA ágil no solo tiene el papel de administrador de base de datos; no solo monta bases de datos para distintos entornos, gestiona si alguna se ha caído, define estándares, modelado de datos etc.
También se encarga de la parte “iterativa” de un proceso ágil, en este caso aplicado a la base de datos.
Por ello, también debe saber temas de diseño evolutivo de bases de datos, refactoring de base de datos y es bueno que sepa temas de programación.
Trabaja muy estrechamente con los desarrolladores. Los desarrolladores aprenden del DBA, y viceversa.

2 – No existe DBA, sino que ciertas personas del equipo asumen ese rol

Otro posible enfoque puede ser que no exista ese rol específico como tal dentro del equipo.
En su lugar, ciertas personas del equipo dominan estos temas, y según sea necesario se irán incluyendo en los sprints tareas de refactorización, de mejora de la base de datos, de las que se encargan ell@s.
Este enfoque también suele funcionar. Pero es muy importante acordar un procedimiento para tratar los cambios diarios de la base de datos, el versionado, la integración continua, para que todo marche perfectamente.
En el caso anterior, entre otras cosas, el DBA se encargaba de estar pendiente del versionado y gestión de scripts y de controlar el estado de las bases de datos de los distintos entornos.
En este caso, toda la responsabilidad de cara a las bases de datos es de todo el equipo.

3 – El rol de DBA lo tiene la gente de sistemas

La gente de sistemas puede encargarse perfectamente de optimizaciones, rendimiento, gestionar permisos, seguridad, montar bases de datos de distintos entornos, migrar datos etc.
Pero normalmente, estos perfiles no suelen tender a gestionar la parte de refactoring y diseño evolutivo de la base de datos, cuya responsabilidad es de los desarrolladores.
En este caso repartimos responsabilidades de rendimiento, gestión de entornos y demás para sistemas y el diseño evolutivo, versionado etc. vuelve a desarrollo.
 
¿Cómo gestionáis el tema bases de datos en vuestras equipos ágiles? ¿Existen roles definidos? ¿Se reparte entre el equipo?
La semana que viene hablaremos del versionado de bases de datos.