¿Es la aceptación 'a mitad de sprint' un concepto válido en Agile/SCRUM?[cerrado]

Question

Cerrado.Esta pregunta es basado en opiniones.Actualmente no acepta respuestas.

---

¿Quieres mejorar esta pregunta? Actualice la pregunta para que pueda responderse con hechos y citas por editando esta publicación.

Cerrado Hace 2 años.

Soy parte de un equipo de Agile scrum que trabaja en el lanzamiento de un producto de software.La duración del sprint es de 2 semanas (~10 días).

Aquí se utiliza una métrica peculiar, llamada 'aceptación a mitad del sprint'.Esencialmente, la expectativa es que la mitad de los puntos de la historia del usuario comprometidos y planificados por un equipo scrum en un sprint deben completarse a la mitad de ese sprint.Esto, dicen, da como resultado una quema lineal de puntos, lo que es un fuerte indicador de que el sprint va bien.

Como equipo, nuestras aceptaciones a mitad del sprint suelen ser malas, pero se sabe que completamos todos los puntos comprometidos de la historia del usuario al final del sprint.

Tengo las siguientes preguntas:

1) ¿Es la aceptación a mitad de sprint una práctica ágil/SCRUM válida?¿Se está utilizando en algún otro lugar?

2) Esperar que la mitad del trabajo se complete en la mitad del tiempo es similar a tratarlo como un trabajo de "fábrica", donde la naturaleza y complejidad del trabajo en cuestión es completamente determinista.Dado que el desarrollo de software es un proceso "creativo", métricas tan rígidas en una metodología altamente flexible como Agile son irrelevantes.¿Qué opinas?

3) Aunque mi equipo scrum completa todos nuestros compromisos justo a tiempo para el sprint, nos cuestionan por nuestras malas métricas de aceptación a mitad del sprint.¿Es completamente normal en los equipos scrum de cualquier otro lugar cumplir con sus compromisos sólo hacia el final de sus sprints?

Muchas gracias de antemano.

Answer 1

1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?

No había oído hablar antes de la aceptación a mitad de sprint.No creo que sea una práctica válida de Agile/Scrum. Este sitio parecería estar de acuerdo "Una vez que el equipo se compromete con el trabajo, el propietario del producto no puede agregar más trabajo, alterar el rumbo a mitad del sprint o microgestionar."

2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?

Por lo general, no es una buena idea utilizar métricas rígidas con los desarrolladores por las razones que usted menciona.También es probable que los desarrolladores estén más interesados ​​en obtener una calificación aprobada en lo que se esté midiendo y no en producir un producto de calidad.Este es uno de los ositos de Joel Spolsky. aquí, aquí y aquí

3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?

Un equipo Scrum exitoso debería completar todo lo que se ha comprometido a hacer al final del sprint.El gráfico de avance debe ser visible para guiar el progreso hacia este objetivo y ciertamente en la segunda mitad del sprint indicará si es probable que el sprint sea un éxito.En los sprints exitosos en los que he participado, es normal lograr un progreso constante para completar las historias de los usuarios, pero esto no se puede reflejar en completar la mitad de las historias de los usuarios en la mitad del tiempo y desaconsejaría una métrica de este tipo.

Answer 2

¿Ha intentado limitar la cantidad de trabajo que tiene en progreso?Si consigue que todo el equipo se centre en un par de historias y no continúe hasta que lleguen esas historias, debe ver que su incurturación se vuelva mucho más lineal.

También podría valer la pena mirar el tamaño de las historias.Personalmente, no me gusta ver una historia que demore más de un par de días para completar el principio a terminar.

Answer 3

No es una práctica de Scrum.Podría interpretarse como una métrica, pero la mala.En cuanto a tus dudas, tienes razón.

Scrum tiene una herramienta perfecta para seguir la progresión: la tabla quemada.No hay necesidad de agregar ningún hito arbitrario.

Parece que su administración no entiende el concepto básico de un Sprint, deberían obtener un asesoramiento o seguir un entrenamiento básico.Si entonces sigue siendo importante para su administración, lo que se hace dentro de una semana, intente sugerir para reducir la longitud del sprint en la mitad.

Answer 4

1) Is mid-sprint acceptance a valid Agile/SCRUM practice? Is it being used anywhere else?

sí, es.

2) Expecting half of the work to be completed in half the time is akin to treating it as a 'factory-floor' job, where the nature and complexity of the work at hand is completely deterministic. Since software development is a 'creative' process, such rigid metrics in a highly flexible methodology such as Agile is irrelevant. What do you think?

Si rompe las tareas en las realmente pequeñas, puede lograr una buena métrica de evolución de trabajo.Por lo tanto, las tareas de diseño deben completarse en un día laboral y puede lograr un buen uso métrico de Burndown.Si tiene tareas largas de larga duración impredecible, la métrica de Burndown es irrelevante, como lo dijiste.

3) Although my scrum team completes all our commitments just in time for the sprint, we are being questioned for our bad mid-sprint acceptance metrics. Is it completely normal in scrum teams everywhere else to meet their commitments only towards the end of their sprints?

El problema no es el equipo, sino las tareas de diseño.El tema considera la granularidad de la tarea.Su equipo puede realizar el trabajo en la métrica de tiempo Sprint, pero ahora necesita refinar las tareas al 50% de ellos, se completarán a la métrica de tiempo de sprint Mid-Sprint.Rompe las tareas en tareas más pequeñas y puede lograr la tabla de Burndoown deseada (lineal).

Answer 5

Es terminología no estándar, pero hay algo para lo que su administrador está diciendo.

Una tabla de quemadurdo que es final (es decir, permanece alta para una gran parte de la tabla, luego las colas de repentina al final) es indicativo de una práctica donde las tareas son de grano grueso, es decir, un La tarea probablemente tomará un sprint completo para completar, y logró los desarrolladores individuales. Con este patrón, todas las tareas permanecen incompletas hasta justo antes del final del Sprint.

Esa es realmente la forma en que se supone que funciona: si el backlog está en orden de prioridad, ¿por qué son los problemas que no tienen la mayor prioridad que se está trabajando? Además, esto establece el "número de bus" para cada tarea muy baja, lo que puede aumentar significativamente el riesgo de que las tareas permanecen incompletas al final del Sprint.

Para solucionar esto, las tareas deben desglosarse en trozos mucho más pequeños. Si está haciendo la planificación del póker, y se estima una tarea en 8 puntos o más, es probable que la tarea esté subrayada. Debe ser desglosado. Trate de mantenerlo a 2s y 3s (o más pequeño!) Si es posible. De esta manera, puede tener varios desarrolladores que trabajan de forma independiente en el mismo objetivo general, y su tabla de incurturación debe comenzar a parecer más suave y menos riesgoso, incluso cuando se está haciendo el mismo trabajo.

Answer 6

La aceptación de MID Sprint no es una práctica ágil o no funciona en realidad.Si tiene una estimación correcta para cada historia y tarea de usuario (E.G en Rally), la tabla de incendios muestra claramente si el trabajo de Sprint está en alineación con el plan y se puede completar a tiempo o no.La aceptación se realiza solo al final del desarrollo y las pruebas de la historia del usuario, no las tareas.