Mi equipo, que consiste en arquitectos y desarrolladores de redes, ha estado ejecutando Scrum durante los últimos meses y el mayor problema que tenemos es cómo se supone que debemos registrar el trabajo de BAU.
Consideramos que el trabajo de BAU son cosas que son repetibles (es decir, proporcionar una nueva cuenta de usuario) que tenemos que hacer de vez en cuando y que no se relacionan en absoluto con nuestro proyecto. No podemos asignar estas tareas a personas ajenas al proyecto porque somos un equipo pequeño y tenemos funciones diarias fuera del proyecto.
Usamos un proyecto JIRA para ejecutar nuestros Sprints y hemos considerado usar Trello u otro proyecto JIRA para realizar un seguimiento de nuestro trabajo BAU. Todavía no hemos implementado ninguno de estos, ya que todavía estamos considerando las posibles opciones y aún no hemos identificado los criterios de éxito.
He visto tres variantes dependiendo de la naturaleza de las tareas de interrupción:
Si el trabajo está muy uniformemente distribuido, simplemente restarlo de la capacidad de antemano.
Cada desarrollador del equipo tiene una reunión individual de una hora con su gerente de línea durante cada sprint. Cada desarrollador tiene que completar sus hojas de tiempo. Hay un simulacro de alarma contra incendios programado para todo el personal en el edificio este sprint.
Si el trabajo es predecible, haz una historia de él, estímalo y ponlo en el sprint.
Después del lanzamiento de la nueva biblioteca, el equipo hermano necesitará ayuda para implementarla en su propio producto. Las preguntas o dificultades aún no se conocen, pero surgirán tan pronto como comiencen a funcionar.
Si aparecen solicitudes aleatorias en frecuencias aleatorias y calidad aleatoria, necesita que alguien conteste el batiphone rojo cuando suene.
Decidir sobre una sola persona por sprint que manejará todas esas solicitudes. Su trabajo probablemente será interrumpido constantemente. Es posible que no produzcan nada hacia el objetivo de este sprint. Pero al menos las interrupciones se contuvieron y el resto del equipo pudo concentrarse en el sprint en cuestión. Además, es más fácil medir cuánto tiempo se perdió en esas tareas, en comparación con dárselas a diferentes personas y tener que calcular un número después.
cualquier tipo de trabajo de apoyo.
Mi pensamiento inicial es que Scrum no es apropiado para esta situación, y algo como Kanban es más apropiado. En los casos en los que gran parte del trabajo es trabajo BAU que aparece repentinamente, no tiene las ventajas de poder planificar una cadencia de Sprint y entregar regularmente un conjunto de trabajo de valor agregado al final. Las cantidades bajas de trabajo BAU no planificado significan que terminará haciendo más trabajo de todos modos, mientras que las cantidades altas de trabajo BAU urgente y no planificado significan que no puede terminar su plan. Un flujo continuo de entrega de valor basado en la urgencia y la prioridad con una planificación del trabajo justo a tiempo parece encajar mejor. Puede optar por tener actividades, como revisión del trabajo entregado y retrospectivas para mejorar el proceso, en una cadencia regular o realizadas justo a tiempo.
Un área posible en la que puede aplicar Scrum es si sus expectativas de nivel de servicio para el trabajo de BAU son mayores que su cadencia de Sprint. Es decir, independientemente de cuándo llegue el trabajo de BAU, la mayoría no necesita adelantarse al trabajo planificado de Sprint. Todavía puede ser necesario que haya algunos casos que sean críticos, pero considere los equipos de desarrollo de software que mantienen un sistema en producción: estos incendios de producción que se adelantan al trabajo planificado deberían ser la excepción y no la norma.
Independientemente de la solución, abogaría por usar una sola herramienta. La visibilidad es importante, y si el trabajo de BAU está afectando el trabajo de su proyecto, sería más difícil hacerlo visible si el trabajo se rastreara en dos herramientas separadas.
nathan cooper