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.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Gracias por el post, aprendo mucho con vosotros, no soy informático pero me encanta mejorar la calidad de cualquier proceso.
Tengo una pregunta en base a una frase del post, aunque no directamente con el BDA… ¿cuál es la diferencia entre los testers y los QA’s?
Muchas gracias de antemano.
Encantada, Santi 🙂
Para mi el término QA es más amplio que tester. Para mi un tester es un tipo de QA.
Y aún así, creo que en este post he generalizado el término tester. Normalmente cuando escucho hablar de tester suele ser un QA funcional (hace pruebas de caja negra, ve entradas y salidas). Pero hay más tipos de tester.
Y veo más tipos de QAs, como por ejemplo:
– QA técnicos: Aquí vería a QAs que saben programar muy bien, saben buenas prácticas de programación y demás, y se centran en medir la calidad del producto software: obtener métricas, pensar mejoras, refactorizaciones etc.
– QA negocio: Gente más en contacto con la parte de negocio, que trabaja bastante con ellos para ayudar a obtener buenos requisitos software. Por ejemplo aquí entrarían temas como BDD (http://en.wikipedia.org/wiki/Behavior-driven_development).
– QA automatización: Gente que se dedica a automatizar pruebas, y a pensar qué tipo de pruebas hay que automatizar primero, qué automatizar y que no y para qué.
– También vería otro rol de QA orientado a la mejora del proceso de desarrollo, control de versiones, metodologías etc.
– Relacionado con lo anterior, también incluiría el rol de DevOps (aunque no me gusta llamar DevOps a un rol). Alguien que automatice procesos repetibles, se oriente a implantar temas de integración continua, despliegue y entrega continuos, a mejorar el rendimiento de todo ese proceso etc.
– Otros tipos de tester.
…
Aunque he de decir que esta clasificación no es oficial…Es como veo el panorama de QA 🙂
No me gusta que al hablar de QA solo pensemos en testers funcionales.
En mi caso particular el rol del DBA tiene un enfoque de gestion de la BD y de desarrollo de procedimientos el esta incluido dentro del equipo agile y con este se negocian los requerimientos internos que se necesiten a nivel de la capa de datos, la responsabilidad es compartida por todo el equipo y aun que estoy rompiendo la regla de «todos somos multidisciplinarios» a quien queremos engañar siempre en nuestros proyectos tenemos personas especializadas. 😛
Suelo encontrarme bastante esa visión!
La cosa es que el equipo sea multidisciplinar…No significa que todos hagan todo, sino que el equipo como ente sepa hacer de todo 🙂
Hola Javier, muy interesante el artículo.
En la empresa donde laboro, como es un proyecto de desarrollo de software, tenemos una persona que tiene un rol de administrar la base de datos hasta que termine el proyecto; así mismo se tiene reuniones o hacemos consultas al DBA principal/senior así como el oficial de seguridad.
Al terminar el proyecto, se pasa a producción y la gestión/administración la responsabilidad es de otra área (producción de sistemas). Los cambios que se generen en la estructura de base de datos es responsabilidad sobre el área de desarrollo, y el pase a producción lo ejecuta el área de producción sistemas.
Espero que esta experiencia les ayude.. sería bueno que otros comenten sus experiencias.
Gracias por compartir tu experiencia Roberto! Útil sin duda 🙂
Buen post, tenia dudas pero con esto me quedo el tema mucho más claro.. Gracias