¿Scrum para el DBA?

¿Es esto Ágil/Scrum. ¿Qué es?

No. Esto es Comando y Control disfrazado de Scrum.

¿Cómo encaja scrum para el DBA de producción de esta manera?

Scrum es para el trabajo que es difícil de estimar pero que comparte un objetivo común por el que se puede trabajar. Lo que describe es más una colección de tareas distintas que están programadas o completamente ad-hoc. Algo como Kanban encajaría mucho mejor.

También muchísimos errores de scrum:

se están asignando puntos por todo lo que se está haciendo. 1 punto se equipara a 1 hora, 1/2 punto es 1/2 hora y así sucesivamente.

Los puntos en scrum no son asignados por la gerencia sino por quienes realizan las tareas. Además, los puntos no tienen traducción a horas. Idealmente, terminarán teniendo algo así como una correlación.

Entonces, todos los días se le pregunta al DBA qué se está haciendo en el scrum diario.

Esto no es un scrum diario, es un informe de estado. Un scrum diario es para que el equipo se sincronice y decida/determina/comparte lo que se va a hacer. Corresponde al equipo comunicar los problemas al scrum master. Es en beneficio del equipo, de nadie más.

el gerente (que también es un maestro de scrum (no, no lo es) ) dice: Todo lo que está haciendo es configurar el script y dejar que la copia de seguridad funcione. No está haciendo nada hasta que se realiza la copia de seguridad. ¿Qué debe hacer el DBA? Por lo tanto, no hay puntos para monitorear los servidores/bases de datos, ya que son un trabajo de 24 horas al día, 7 días a la semana o más bien un trabajo de 8 horas completas para el DBA.

No está del todo equivocado en eso. Gran parte de este trabajo se puede automatizar. Aún así, debe programar tareas según el esfuerzo requerido en su situación actual, no el esfuerzo requerido dada la máxima automatización. También se debe calcular una cierta cantidad de tiempo para el cambio de contexto y los pasos manuales restantes.

En scrum/sprint, ¿el tiempo está realmente asociado con la serie de Fibonacci (0,1,2,3,5,8,13,21, etc.) puntos asociados con el tiempo de una forma u otra?

Lo que está describiendo es una ayuda para ayudar a estimar los puntos de artículos atrasados. La idea de usar números de Fibonacci es que ayudan a demostrar la mayor incertidumbre inherente a la estimación de tareas más grandes. No es necesario hacerlo así SI comprende que las estimaciones de nivel superior son menos confiables y que una tarea grande de X puntos probablemente no se dividirá en N subtareas con un total de X puntos.

Pero otra vez. ¡Estos son puntos, no horas! Estimar en horas transmite una falsa precisión a los desinformados. Las personas generalmente son malas para estimar valores absolutos como las horas, pero la gerencia es realmente buena para agarrarlos. Sin embargo, las personas son mucho mejores para estimar valores relativos (es decir, ¿limpiar su apartamento es más o menos trabajo que limpiar su automóvil?). El poder predictivo de Scrum no se deriva de estimaciones precisas sino de estimaciones consistentes y la capacidad de comparar estimaciones anteriores con resultados reales.

Suena como un montón de banderas rojas para mí. Como Professional Scrum Trainer, leí bastantes fragmentos aterradores. Para comenzar:

Sí, Scrum y el trabajo de DBA pueden ir bien juntos.

Uno, estimación.

En la planificación de Sprint, el trabajo se planifica y, opcionalmente, se estima. No es algo que hagas durante el scrum diario. Y aunque las técnicas de estimación relativa son útiles para la previsión, son un poco inútiles para planificar el trabajo real, especialmente si tiene una idea clara de la cantidad de tiempo necesario.

Mirar las tareas recurrentes y asegurarse de que sean parte del plan del sprint es algo que encaja en Scrum, se haría durante la planificación del sprint. Para estas cosas, especialmente cuando el trabajo es bien conocido, simplemente lo restaría de su capacidad para tareas más desafiantes.

La estimación por hora directamente relacionada con los puntos de la historia es un área claramente prohibida, especialmente si existe una correlación directa de 1 punto = 1 hora. Hay mucha documentación sobre los puntos de la historia, así que lo dejaré así.

Dos, scrum diario

El scrum diario es para seguir el progreso hacia la meta del sprint y para planificar el día siguiente. No por "punto de puntuación", no me importaría cuántos puntos vale algo. Si tu trabajo para el día siguiente está planificado, no hay nada que impida alcanzar la meta del Sprint y sientes que eres productivo, eso sería lo más importante.

También es un momento para que el equipo trabaje en conjunto para elaborar un plan para las próximas 24 horas. Ni por un momento para informar el estado a un gerente. El gerente puede seguir el progreso del trabajo visualizándolo y mediante la revisión del sprint, momento en el que se demuestra y revisa el trabajo. En su caso, rara vez haría una demostración directa de su trabajo, debería ser evidente como parte de otras cosas que aterrizan en el entorno o mediante la solución de problemas que afectaron a los usuarios del entorno.

Tres, la naturaleza del trabajo.

La forma en que su función como DBA se describe anteriormente es bastante tradicional. La promoción de esquemas entre entornos es algo que se puede automatizar bastante bien.

Se puede configurar una gran cantidad de monitoreo para activar alertas, lo que no requiere mucha mano de obra para realizar la tarea de monitoreo. El tiempo necesario para expandir unidades y asignar recursos se puede automatizar o asegurarse de que asigna más espacio cuando se expande es una manera fácil de reducir la sobrecarga de este tipo de trabajos al reducir su frecuencia y, opcionalmente, limitar su impacto.

El acto de hacer una copia de seguridad y restaurar es algo que se puede configurar en un horario. Los actos manuales de copia de seguridad o restauración son algo que a menudo también se puede delegar a otros miembros del equipo y es posible que no requieran el trabajo de un DBA. Lo mismo se aplica a la implementación de nuevas versiones de herramientas, poner el instalador en un recurso compartido y señalar a los miembros del equipo que actualicen cuando sea conveniente o usar técnicas de distribución remota puede distribuir fácilmente estas cosas a escritorios, servidores, etc.

Cómo proceder

Intente mirar críticamente el trabajo que se puede automatizar o delegar. Dedique su tiempo al trabajo que es realmente complejo y requiere sus habilidades específicas. Trabaje con otros miembros del equipo Scrum para asegurarse de que puedan realizar muchos de los trabajos menos complejos.

Utilice la retrospectiva para analizar su trabajo y el trabajo que realizan otros y ver dónde es posible la optimización.

Trabaje con el equipo para deshacerse de la necesidad de "ganar puntos", scrum no se trata de hacer tantas tareas como sea posible, se trata de hacer lo menos posible para hacer la mayor cantidad de trabajo.

Trucos para combinar el trabajo operativo con el desarrollo

Los equipos que tienen más trabajo operativo en su cartera de pedidos a menudo mantienen una cartera de productos y un calendario operativo. El trabajo pendiente del producto contiene el trabajo que se produce porque se implementan nuevas funciones o se realizan cambios en el entorno; los problemas detectados en las inspecciones recurrentes pueden terminar en el trabajo pendiente del producto para su investigación y solución. El calendario operativo contiene todo el trabajo que ocurre en un cronograma y se puede planificar con mucha anticipación.

Otros equipos combinan Scrum y Kanban. El desarrollo de nuevas características y los cambios más grandes se planifican a través de la cartera de productos. El trabajo recurrente está mayormente automatizado y los incidentes se tratan a través de un "carril prioritario" que usa kanban y no está planificado al comienzo de cada sprint. Con el tiempo, el equipo aprenderá cuánto tiempo debe reservarse para el trabajo ad-hoc. Esta forma de trabajar se aleja de las tareas recurrentes y los planes a largo plazo basados ​​en el calendario, y asume el trabajo tal como sucede con parte del trabajo. Se ordena otro trabajo a través de la cartera de productos y la velocidad del equipo se puede usar para pronosticar puntos probables en el tiempo cuando se asume este trabajo (en qué sprint).