Después de más de dos años de trabajar en una estructura de departamento de desarrollo altamente aislada, estamos adoptando Agile SCRUM. Excelente. Me gusta ágil; como desarrollador, lo mantiene enfocado, ocupado y productivo sin tener una miríada de partes interesadas empujando proyecto tras proyecto por la garganta con la expectativa de que todo se hará ayer.
Sin embargo, hay un aspecto de pasar a SCRUM frente a nuestro "modelo" actual, que creo que a las personas ajenas al Desarrollo no les va a gustar en lo más mínimo. Esa es su capacidad actual para que hagamos pequeños cambios "mientras espera". Una gran parte de nuestro desarrollo es solo para consumo interno, y estamos principalmente en el mismo edificio. Por lo tanto, ha sido una práctica común durante años para un jefe de departamento o gerente en otro lugar acudir al "propietario de la base de código" de una aplicación en particular y pedir cosas pequeñas (a veces no tan pequeñas, pero somos bastante buenos para no asumir tres) proyectos semanales basados en estos "drive-bys"). Incluso nuestro jefe a veces transmite las cosas que se le presentan de esta manera. Muy a menudo, si estamos trabajando en la base de código en cuestión en ese momento, simplemente podemos abrir el archivo fuente,
Con una metodología básica Agile SCRUM, estos ajustes se registrarían como defectos (no cumplimos con un requisito especificado en una historia previamente consumida) o nuevas historias pequeñas (cumplimos con todos los requisitos establecidos, pero esos requisitos eran incompletos, vagos o incorrectos , o cambiaron después de la entrega una vez que los usuarios vieron las nuevas funciones). De cualquier manera, la gran mayoría sería uno de triples en la mayoría si no ceros, y de prioridad relativamente baja (el sistema se puede utilizar en su estado actual, pero sería por lo tanto más fresco si ...), haciéndolos poco probable que sea llevado a un sprint cuando se trabaja el backlog de arriba hacia abajo.
Esta posibilidad se planteó en una reunión de desarrollo como una fuente de oposición activa a nuestro proceso ágil por parte de otros departamentos, que lo considerarían menos "ágil" que nuestra capacidad actual de realizar pequeños ajustes a pedido. Es una preocupación válida de la OMI; las partes interesadas detrás de la OP no siempre están de acuerdo en qué cosas son más importantes, porque no todas tienen el mismo punto de vista, sin embargo, generalmente son solo los gerentes quienes toman la decisión final, y por lo tanto su sesgo es el que se muestra en la cartera de productos.
Luego se propuso una solución, que tentativamente se denominó "tarro de dulces" (otro término que se descartó fue "gravy boat"). Pequeños ajustes solicitados por los "pequeños" en los diversos departamentos, que no son defectos en una historia existente, que se estiman por consenso o aclamación dentro del equipo para tomar menos de la mitad de un día de desarrollador, y eso habría tenido un impacto inmediato, significativo y positivo en la experiencia del usuario en la opinión del usuario final, se colocan en una lista paralela al trabajo acumulado primario. Se identificarían como "historias", pero se mantendrían separadas de la cartera de pedidos primaria de "grandes" historias sujetas a priorización. Si, en cualquier momento durante el progreso normal de un sprint, estamos trabajando en un área del sistema en la que se puede hacer uno de estos ajustes, haciendo que el ajuste sea trivial, podemos llevar el ajuste al sprint y codificarlo junto con la historia más grande. Haciendo estoNo debe poner en peligro la finalización de la historia más grande o cualquier otro trabajo comprometido. El PO también tendría acceso a esta lista, y si estuvieran trabajando en una próxima historia de usuario que toque la característica básica que involucra el ajuste, podrían incluirla en la historia como un requisito y luego cumpliríamos el requisito como lo haríamos otro. Esto, se pensaba, haría que los ajustes sean más propensos a ser trabajados más temprano que tarde.
Esto desencadenó la reacción entre aquellos de nosotros con el entrenamiento ScrumMaster de "uh-uh". Hay un retraso. Two backlogs introduce la pregunta de qué elemento n. ° 1 es realmente el más importante, qué elementos de la lista determinan la velocidad real y a cuál de los dos backlogs pertenece realmente una historia (cualquier demarcación de tamaño / complejidad tendrá algunos casos que caerán relativamente arbitrariamente a un lado u otro). "Dejemos que el proceso funcione", dijimos; Si el cambio es realmente significativo para los usuarios finales, harán suficiente ruido como para que los jefes de departamento tomen decisiones de tiempo / dinero a bordo, y se verá afectado en la conciencia del equipo de desarrollo hacia la parte superior de la cartera de pedidos.
Pensé en plantear la pregunta al suelo: en su opinión, una lista paralela de historias de "tamaño de bocado" tendría valor para hacer que los cambios pequeños, útiles pero en última instancia de baja prioridad se realicen más rápido, o en general es una mejor decisión para plegarlos en la cartera de pedidos principal y dejar que el proceso básico rija su inclusión en un sprint?