“Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum.”

Esta es una serie de traducciones al español del artículo publicado el 12 de Enero en InfoQ con un extracto del libro “Succeeding with Agile: Software Development Using Scrum” de Mike Cohn. Hoy publico la sección de “DBAs" como parte de la serie "Roles ágiles".

DBAs Ágiles


Los profesionales de datos, sean administradores de bases de datos, ingenieros de base de datos, o algo más, pueden ser unos de los más resistentes a la adopción de Scrum. Mucho de lo que en la sección anterior se dijo acerca de los programadores también aplica para los administradores de base de datos. Además, los profesionales de datos se enfrentan a aprender a hacer gradualmente lo que ha sido considerado tradicionalmente como parte de un proyecto tradicional.

El estándar en asesoramiento en diseño de bases de datos ha sido el de hacer un análisis completo de las necesidades del sistema, crear un diseño de base de datos lógica o conceptual, y luego el mapeo de esos conceptos a las limitaciones de una base de datos del mundo real, durante el diseño de base de datos física. El éxito en esta serie de pasos se basa en un análisis completo y preciso por adelantado. El punto de vista de los profesionales de datos tradicionales fue resumido de la mejor manera por un compañero de viaje en un avión de Chicago a Sacramento. Era un vicepresidente de desarrollo de base de datos para una compañía de salud relativamente grande. Su punto de vista sobre el mundo era "las aplicaciones cambian, los datos son para siempre".

Este tipo de pensamiento conduce a un fuerte enfoque en hacer un análisis completo por adelantado. Esto es lindo en teoría, pero al mismo tiempo en que estamos haciendo  el análisis completo, el mundo sigue evolucionando. Las necesidades de los usuarios están cambiando. Los competidores están lanzando sus productos. Las bases de datos necesitan evolucionar para apoyar la evolución de las aplicaciones construidas sobre ellos.

En muchas formas, el diseño de experiencia de usuario, arquitectura y diseño de bases de datos son todos casos especiales del mismo desafío: trabajar de forma incremental en algo que está pensado de manera integral. Gran parte del día a día de un DBA no va a cambiar mucho, pero cómo los DBAs van a enfocarse y agendar su trabajo va a cambiar drásticamente y se discutirá en el capítulo "Trabajando Juntos a lo largo del Sprint".


Dime lo que piensas. Por favor, deja un comentario más adelante (y luego dale click a ese botón de 'Me gusta'!)

Seguir leyendo


Comentarios

comments powered by Disqus