¿Es una mala práctica trabajar en múltiples historias al mismo tiempo?

Question

En un equipo de scrum, ¿qué tan importante es completar una historia antes de continuar?

Nuestro scrum master es bastante dogmático acerca de completar una historia antes de continuar. Puedo ver que el desarrollo parecería estar más "controlado" en este escenario, además el scrum master tendría una imagen muy precisa de en qué miembros del equipo estaban trabajando en un momento dado ... pero estoy interesado en lo que esto realmente compra ¿nos?

Está claro que el scrum master quiere minimizar la divergencia entre la realidad y la realidad para evitar un choque al final del sprint, pero seguramente si el sprint dura dos semanas, el burndown se actualiza constantemente y los bloqueadores se comunican en standups. cualquier divergencia de este tipo se verá limitada por la longitud del sprint, y se hará visible a mitad de carrera a través de los canales habituales (es decir, el standup o hablando con el scrum master de forma individual). Cualquier problema restante puede tratarse en la retrospectiva quincenal.

El motivo de la pregunta es que parece que funciono de la manera más eficiente al mantener 2 (o 3 si es particularmente fácil) historias en progreso en un momento dado en el que trabajo como mejor me parezca. Esto parece ayudar con el pensamiento de fondo subconsciente que ayuda a completar la tarea. También me permite comprender mejor el panorama general si un par de historias están relacionadas.

Nuestras historias suelen ser de uno o dos días de trabajo.

Por lo tanto, está trabajando en un par de historias a la vez desaprobadas y, en caso afirmativo, ¿qué compra de una historia por vez?

Answer 1

Creo que realmente le corresponde al equipo decidir. Creo que lo tocas en tu escrito sobre el burndown, lo más importante es cumplir con tus compromisos de sprint de manera consistente. cómo eso sucede realmente debería depender del equipo si realmente se autogobiernan. el equipo ahora, nuestra norma es trabajar en múltiples historias a la vez; es la naturaleza de nuestra configuración, dado que tratamos de difundir realmente la propiedad de las historias en todo el equipo. puede ser una norma diferente para los suyos si tiene historias más cortas y más de un estilo de propiedad individual.

Answer 2

Personalmente creo que una historia a la vez funciona bien porque te mantiene enfocado en una tarea. El costo del cambio de contexto entre varias historias puede ser alto. Esta es una preferencia personal para mí, pero diferentes personas trabajan de manera diferente. Aunque creo que su maestro de scrum es correcto en su metodología, si ha encontrado razones muy convincentes para contar varias historias a la vez y puede demostrar que de hecho está ayudando al progreso, sería un buen ejemplo.

Answer 3

IMO, hay una pregunta subyacente aquí. A veces, cuando trabajo en una historia, necesitaré algo de otro departamento/equipo, por ejemplo. aclaración sobre un requisito o un gráfico para una página, y esto significa que no terminaré una historia antes de pasar a otra historia. Si bien mencionas esto al hablar sobre los bloqueadores en el stand-up, esto puede suceder donde le corresponde a alguien externo que me ayude a terminar una historia, por lo que puede haber varias en mi plato. Por lo tanto, puedo tener múltiples historias debido al bloqueo en algo y todavía quiero ser productivo.

En general, no me gusta tratar de administrar varias copias del código base o cambiar mi código mucho, por lo que prefiero hacer una historia a la vez, suponiendo que no haya bloqueadores. El tamaño de la base de código con la que estoy trabajando es de aproximadamente 1,1 GB de datos repartidos en más de 82,000 archivos, por lo que tener varias copias podría ser más que un poco doloroso, supongo.

Mi opinión personal sobre esto es que depende del equipo establecer el estándar y ver si funciona para ellos. Si a algunos les gusta una historia a la vez y otros hacen múltiples y todo está bien, genial.Si a todos les gusta tener varias historias en varios puntos de finalización, eso también puede funcionar.

Answer 4

No hog el retraso ... En mi experiencia, cuando las historias son entre 1 y 2 días en tamaño, tienden a ser implementado por un único promotor. Si trabajas 2 o 3 historias al mismo tiempo, eso puede reducir la cantidad de cosas en la cartera de pedidos que otros desarrolladores pueden elegir y poner en peligro el sprint.

... pero el plan de bloqueo Por otra parte, trabajar 2 o 3 historias a la vez significa que si usted está momentáneamente bloqueado en una historia que puede ser productivo inmediatamente en el otro. Me parece que hay algo de sobrecarga cada vez que comienzo una nueva historia. Esta sobrecarga hace que sea difícil llenar una "brecha" de una hora en mi día con una nueva historia , mientras que es mucho más fácil cambiar el contexto a una historia que ya he comenzado.

En pocas palabras, deje que el equipo decida ... y luego revise los resultados durante una retrospectiva. Si sus historias, tareas y procesos de trabajo respaldan un entorno en el que los miembros del equipo puedan trabajar 2 (tal vez 3) historias a la vez sin sacrificar la productividad o la previsibilidad, entonces su SM debería respetar eso. Pero al mismo tiempo, debe revisar honestamente los resultados durante cada retrospectiva y estar preparado para cambiar si el SM no cree que esté funcionando.

Answer 5

Por lo general, creo que la decisión de cómo trabajar mejor debe tomarla casi exclusivamente el equipo. El rol de ScrumMaster es ayudar y apoyar al equipo, no cuestionar la forma de trabajar del equipo durante un sprint.

Para ser justos, a veces puede ser una buena idea que el ScrumMaster señale posibles fallas o riesgos, que entrarían en la categoría "ayuda y soporte". Ser dogmático sobre tu idea personal acerca de cómo debería verse un sprint internamente no es algo en lo que quisiera que actúe ScrumMaster. Suena un poco como malinterpretar el papel como el papel del gerente, que simplemente no es el caso.

En cuanto a cómo lo hacemos: casi siempre trabajamos en varias historias a la vez. Por el momento tenemos un equipo de scrum de cuatro personas con tres desarrolladores y un probador y casi siempre tenemos al menos dos o tres historias al mismo tiempo. En el último sprint intentamos comenzar con todas las historias al principio del sprint para llegar al punto en el que tenemos un diseño básico y una buena idea sobre cuáles podrían ser los problemas potenciales. Por supuesto, después de eso no estábamos trabajando en todas las historias al mismo tiempo.

Entiendo que en términos de gestión de riesgos, es posible que desee asegurarse de que todo esté hecho para una historia antes de abordar la siguiente. Sin embargo, la desventaja es que cuando te encuentras con problemas imprevistos más adelante, es posible que no tengas tiempo suficiente para solucionarlos. Por lo general, los problemas muestran sus rostros feos durante la fase de implementación y con frecuencia bastante temprano. Entonces, básicamente intercambias un riesgo por otro.

¿Qué riesgo es más fácil de manejar? Dependerá del equipo. Es su carrera después de todo y aunque creo que es perfectamente justo para el ScrumMaster mencionar las preocupaciones sobre la forma en que se desarrolla el sprint, no debería forzar su idea de la mejor manera de trabajar en el equipo.

Al final, creo que se reduce a estas dos cosas:

1. Sí, lo hacemos, trabajamos en varias historias a la vez y que ha funcionado bien hasta ahora .

2. Recuerde que el ScrumMaster es de trabajo para el equipo, no al revés manera.

Tenga en cuenta que sobre todo estoy hablando de todo el equipo trabajando en varias historias a la vez, no un desarrollador. El problema que vería allí es que debe asegurarse de no bloquear las historias manteniéndolas abiertas, para que nadie más pueda continuar el trabajo. Una vez más, esta es una cuestión de circunstancia y preferencia. En lo que respecta a las pruebas, nuestro verificador a menudo tiene un par de tareas de prueba para diferentes historias, por lo que puede cambiar fácilmente a una tarea diferente, si algún error le impide seguir probando una función.