¿Una acumulación de tareas de "tamaño de bocado" en paralelo con la acumulación de funciones "principal"?

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?

Hablaré sobre algunos puntos que, con suerte, te ayudarán a encontrar tu camino:

1. " SCRUM " se trata de ser ágil. Se requiere sentido común. Si el cambio es un cambio de unos minutos, no creo que necesite un retraso para ello. Si son más de 2 horas, creo que deberías pensarlo dos veces. No se debe hacer todo lo que es un "triunfo fácil". En SCRUM trabajas por prioridades. Creo que la OP debe obtener la información sobre lo que gana con la suma y el esfuerzo que requiere. Solo entonces la OP puede decidir si es importante o no. Pasando a SCRUM, a veces viene con muchas preguntas y los desarrolladores suelen decir "pero, eso solo tomará ד unas pocas horas". ¿Y qué? Pocas horas son tiempo, no todo lo que es corto necesita ser incluido.
2. Una vez trabajé en un proyecto donde teníamos "retrasos en ingeniería" . Esta acumulación contenía elementos sugeridos por los desarrolladores para mejorar el producto. Esos elementos no tenían un valor de usuario explícito (pero tenían un valor de usuario implícito). Por ejemplo: refactorizar un componente en el código. Habíamos descrito el cambio, el esfuerzo y la ganancia (en este caso, no se puede presentar nada al usuario. Pero si dicha refactorización hace que se desarrollen nuevas capacidades más rápidamente, definitivamente es una ganancia para el usuario). Nuestro PO decidió que durante la versión deberíamos invertir el 10% de cada sprint (en promedio) en dichos artículos. Antes de cada sprint, cuando el PO decidió sobre el trabajo pendiente del próximo sprint, se aseguró de que tuviéramos un 10% de elementos de trabajo de ingeniería. Entonces 2 versiones de la reserva -> 1 reserva de sprint.
3. Buffers : al comenzar a trabajar en SCRUM, las personas a menudo olvidan que, como ingenieros de software, nos vamos en un mundo de incertidumbre. Está bien contar 1 día de trabajo como 6 horas en lugar de 8. Digamos que tiene un sprint de 15 días, eso significa que tiene 30 horas adicionales que van a reuniones, a cosas que tomaron demasiado tiempo, y sí, también para esos pequeños cosas que son demasiado pequeñas para recordar pero que son parte de nuestro trabajo de 2 días.
4. Mantente enfocado : por último, pero no menos importante, en SCRUM es importante mantenerte enfocado. Decida cuánto de su esfuerzo total, y cuál es la prioridad, invertir en tales tareas y recuerde invertir este tiempo y esfuerzo. No se deje llevar a trabajar en "pequeñas cosas" solo porque son pequeñas. Tiene una orden de compra que lo ayudará a decidir y tiene su sentido común.
5. Manténgase ágil : y, al final, no se olvide de probar diferentes métodos para abordar el problema, pregúntese si esa es realmente la mejor manera. Mejora en el camino.

Buena suerte :)

Los marcos de programación como Agile y SCRUM están diseñados para aplicar disciplina y estructura al desarrollo. Sin embargo, la disciplina y la estructura parecen ser los antónimos de diversión y creatividad. Por lo general, debe trabajar más para establecer y mantener la disciplina. Es muy difícil encontrar un equilibrio entre estos conceptos opuestos. Por lo tanto, los marcos tienden a evitar el tema.

En mi último proyecto, observamos que los desarrolladores necesitaban un poco de tiempo cada día para refrescarse o despejarse, etc. Se les dio un tiempo presupuestado (.5 horas / día o 2.5 horas / semana) en el que podían hacer cualquier cosa, dentro de razón (con la posibilidad de ser aplicado a algo en el trabajo). Para mantener las cosas disciplinadas, se les pidió que documentaran sus actividades para que pudieran obtener crédito por cualquier logro, etc. Tener un presupuesto específico para "el tarro de dulces" se ajustaba a nuestros plazos y evitaba que las cosas se salieran de control.

Por cierto, llamamos nuestro "coolness del proyecto" y terminó siendo la fuente de muchas buenas ideas y mejoras en esa compañía.

Debes mantener las pequeñas historias en la cartera de pedidos principal.

Me enfrento a problemas similares a lo que está describiendo, aunque no estoy usando scrum. Veo que enfrenta desafíos de priorización y eficiencia .

Parece que bajo su "viejo estilo", cualquiera estaba implícitamente facultado para hacer de su tarea la "máxima prioridad" actual si visitaban la oficina de un desarrollador. Esto tiene algunos beneficios. El solicitante siente que se le está respondiendo, y tanto el solicitante como el desarrollador obtienen una "victoria rápida".

La desventaja es que la inserción frecuente de estas tareas tiende a ralentizar o descarrilar las tareas de mayor prioridad acordadas con el propietario del producto. (Nota al margen, a menudo todos subestiman la cantidad de tiempo necesaria para estas soluciones "rápidas").

Mi experiencia es que tratar de exprimir una tarea de baja prioridad socava los beneficios de la priorización. Como desarrollador, la priorización me valida que estoy trabajando en lo que el propietario del producto quiere que yo trabaje.El propietario del producto debe decidir si quiere asumir el trabajo adicional y el riesgo (aunque sea leve) de plegarse en una solicitud "agradable de tener".

A menudo, cuando le pido a las partes interesadas que prioricen, me preguntan "¿Puedes exprimir esto?". El deseo implícito es que yo complete mágicamente la nueva tarea sin afectar la prioridad más alta actual.

Lo que a menudo me pasa es que las partes interesadas solicitan LargeImportantProject y SmallLessImportantTask. El dilema es: ¿debería SmallLessImportantTask esperar a que finalice LargeImportantProject (o tener un obstáculo)? Hay compensaciones, y mi experiencia ha sido que el propietario del producto tiene que decidir. (Si el propietario del producto no decide, el equipo de desarrollo tiene que adivinar).

Uno de los objetivos de scrum (y la gestión de proyectos en general) es evitar obstáculos para las tareas de mayor prioridad. A medida que se vuelve más eficiente, hay menos espacio para exprimir el trabajo adicional "agradable de tener".

La eficiencia puede dar miedo, pero he visto que los beneficios superan el costo de dos maneras importantes.

1. A medida que se vuelve más eficiente, aumenta la capacidad de su equipo para completar un trabajo valioso, que incluye solicitudes "agradables".
2. Si una solicitud es realmente "agradable de tener", probablemente sea perfectamente legítimo que la solicitud espere hasta que se aborden prioridades comerciales más importantes.

En mi opinión; Su problema es la forma en que las tareas se priorizan en el trabajo atrasado. Por ejemplo, "prioridad" podría tener en cuenta tanto la importancia como la rapidez con que se puede completar. Algo que no es tan importante pero que se puede completar en 10 minutos puede tener una prioridad más alta que algo más importante que llevará varias semanas implementarlo.

He trabajado en ágil por un tiempo ahora. Todo lo que puedo decir es esto: hay situaciones en las que insistir en una metodología y todo lo que incorpora es absolutamente incorrecto. Tienes que ser ágil, y ajustar una metodología a situaciones específicas es, en mi opinión, una necesidad.

Como dijo Avi arriba, "SCRUM" se trata de ser ágil. Se requiere sentido común. Si el cambio es un cambio de unos minutos, no creo que necesite un retraso para ello.

Si el cambio lleva tiempo, significa que no es tan "inofensivo" y debe estar bien documentado.

Basado en su pregunta inicial y aclaraciones posteriores, esto es lo que he percibido que sus puntos de dolor son

• Requisitos constantemente cambiantes
• Incapacidad de los desarrolladores para centrarse en otras áreas de la aplicación, es decir. somos héroes en una parte de la aplicación pero no estamos interesados ​​en tocar ninguna otra.
• Diferentes enfoques de arquitectura, soluciones, marcos adoptados
• El proceso de recopilación de requisitos no parece funcionar

Scrum, si inicialmente se cumplió correctamente, debería solucionar muchos de estos problemas y, lo que es más importante, destacar otros problemas que deberían resolverse.

- Requisitos constantemente cambiantes

Tener una única cartera de pedidos en la que todo se alimenta y prioriza correctamente debería significar que el equipo no debería soportar la mayor parte de los requisitos que cambian mientras se encuentra en medio del desarrollo. Si se trata de un entorno muy dinámico, los sprints más pequeños de 1 o 2 semanas deberían garantizar que las prioridades cambiantes puedan facilitarse en un período de tiempo relativamente corto.

- Incapacidad de los desarrolladores para centrarse en otras áreas de la aplicación, es decir. somos héroes en una parte de la aplicación pero no estamos interesados ​​en tocar ninguna otra.

Un equipo de scrum que trabaje bien juntos y se apoye mutuamente, con un impulso específico para compartir el conocimiento dentro del equipo y en busca del desafío de trabajar en otras partes de la aplicación, buscará garantizar que el conocimiento de la aplicación se comparta. Algunas prácticas, como la programación en parejas, pueden ayudar a las personas a superar su miedo a trabajar en códigos con los que no están familiarizados, al tiempo que aprenden y comparten ese conocimiento. Esto puede tomar algunos sprints antes de que el conocimiento de la aplicación se distribuya entre los equipos y las personas se sientan cómodas trabajando en cualquier área de la aplicación. Además, permitir que las personas tomen las tareas de un tablero, es decir, hacer su propia elección sobre lo que les gustaría trabajar, puede alentar esto.

- Diferentes enfoques de arquitectura, soluciones, marcos adoptados

Scrum facilita una mejor comunicación, facilita el trabajo en equipo y una mejor toma de decisiones, además de proporcionar una mayor visibilidad de lo que está sucediendo. Este turno debería facilitar las decisiones organizativas en torno al uso de marcos, soluciones arquitectónicas, etc. y el uso de un mecanismo Scrum of Scrums puede ayudar a inculcar eso en toda la organización.

- Proceso de recopilación de requisitos

Una vez más, si se adhiere estrictamente a las reglas, si un requisito no se especifica claramente y no está listo para que el equipo pueda comprender y estimar lo que se requiere para cumplir con el requisito, no debe incluirse en el sprint. Tome otro requisito que sea de alta prioridad y que esté bien definido ... ¡porque entonces sabrá que podrá cumplirlo! Si bien es posible que no solucione el proceso de recopilación de requisitos de inmediato, forzará el cambio requerido para arreglar ese proceso.

Para responder a su primera pregunta, no, no debería haber dos pedidos pendientes por separado. En cualquier momento, es de interés para todos que los desarrolladores y la organización estén trabajando primero en los elementos de mayor prioridad. Las prioridades deben basarse principalmente en el valor comercial, y es muy posible que muchos de los pequeños ajustes y solicitudes agreguen valor comercial. Deje que el dueño del producto decida eso.

He sido Scrum Master durante más de 7 años y ayudé con la introducción de Scrum en muchos equipos y empresas diferentes. En mi humilde opinión y según mis observaciones, siento que si Scrum se está introduciendo en su organización por primera vez, sígalo en el libro. No te desvíes. Scrum requiere disciplina para poder apegarse a las prácticas y procesos. Es demasiado fácil hacer excepciones para ajustarse a ciertas circunstancias, y si se hace demasiado pronto, conducirá a la erosión de los beneficios y valores que trae consigo. Haz lo básico, hazlo realmente bien. Conviértase en un experto en hacer lo básico y comprender por qué están allí, y luego cambie el proceso para adaptarse mejor e impulsar la mejora continua dentro de su organización.

Hay casos muy válidos para decir que esto es "Ágil", por lo que debemos estar dispuestos a cambiar el proceso, pero hay una diferencia significativa entre un equipo autodirigido y autoorganizador que comprende el proceso y discute los cambios que podrían hacerse para el proceso, a diferencia de un equipo que solo está comenzando a caminar por el camino de Agile o Scrum. Es como intentar correr antes de saber gatear ...