¿Cuándo se considera completa una iteración ágil?

Question

Estoy trabajando en un equipo que está explorando la posibilidad de adoptar prácticas de desarrollo ágiles.

Una pregunta con la que nos topamos es decidir cuándo debe completarse una iteración (sprint).

Digamos que hemos definido nuestra acumulación de funciones y producido estimaciones de puntos de historia para ellas, y hemos decidido que el primer sprint de 30 días incluirá las características A, B, D y F. ¿Qué debería hacer? hazlo si llegas al final del sprint y completaste A, D y F, pero B solo se ha completado en un 80%. En caso de que:

1. completa el sprint a tiempo, pero excluye función B (difiriendo el trabajo restante a un sprint futuro)

2. Extender el sprint por el tiempo necesario para completar característica B, pero no comienza el próximo sprint.

3. Extienda el sprint por el tiempo necesario para completar la función B y comience a trabajar en el siguiente sprint.

4. Falla todo el sprint, y agrupa todo el trabajo para ser parte de una futura versión.

El problema que veo con la opción 1 es que el equipo no está dando lo que se ha comprometido a. En algunos casos, es posible que no pueda excluir la función B sin hacer que la versión completa sea inútil (o al menos sustancialmente menos valiosa). Puede dificultar la dirección del próximo sprint sin la característica B.

El problema con la opción 2 es que algunos miembros del equipo pueden estar inactivos durante un período de tiempo significativo, lo que consume productividad general. Es posible que pueda agregar más pruebas de unidad o funciones de pulido, pero no agrega valor proporcional. También es políticamente difícil explicarle a la gerencia por qué la mayoría de su equipo está inactivo.

La opción 3 parece estar en contra del espíritu de agilidad: está poniendo en riesgo el próximo sprint al no permitir que los resultados del anterior guíen la próxima iteración de desarrollo.

La opción 4 parece ser grave y tiene la mayoría de los mismos problemas de la Opción 1 y 3. En primer lugar, te falta un compromiso por completo. En segundo lugar, la combinación de más características en una versión posterior hace que sea más difícil probar y verificar con los clientes, y de nuevo impide la capacidad de guiar la iteración futura en función de los comentarios de los anteriores.

Answer 1

Opción 1, por supuesto. Su velocidad para la próxima iteración va a ser menor, ya que se basa en el tiempo de ayer, por lo que la próxima iteración tendrá una mejor oportunidad de completarse.

En el scrum está time-boxing. Y solo entregas funciones que funcionan.

En el sprint planning ha hecho una estimación de lo que podría entregar. El cliente tiene que aceptar un cierto nivel de incertidumbre en la estimación o estar preparado para tener demasiados recursos en el equipo.

Si pierde la siguiente iteración nuevamente, cambie a una longitud de iteración más corta y asegúrese de que el tamaño de las características individuales sea más pequeño.

Answer 2

Tomaría una variación en la opción 1. Si la característica B se puede desglosar en lo que se completa y lo que no se completa, esto debería conducir a un conjunto revisado de tareas para completarlo en el siguiente sprint. Lo que está terminado se entrega, y aunque la entrega no es perfecta, la idea debería ser intentar lo mejor posible y luego trabajar en lo que viene según la prioridad.

Extender el sprint es una receta para el desastre en mi mente. ¿Completar la función significa resolver todos los errores en ella también? ¿Has visto software que no tenga errores?

Fallar el sprint introduce demasiado perfeccionismo en las cosas. ¿Algo está 99% hecho sin valor? No lo creo, pero hay algunas personas que tienen estándares realmente altos y pueden ser bastante exigentes.

EDITAR: A veces, una característica se da inicialmente con requisitos vagos que se aclararán en el transcurso del sprint. Por ejemplo, una solicitud de función de "Como usuario, me gustaría hacer un pedido" puede desglosarse aún más como parte de la planificación del sprint o durante el sprint. En cualquier caso, si se realizan algunas historias que involucran una característica, pueden y deben presentarse en la demostración si se hace una. El punto es poder decir: "Aquí es donde estamos. ¿Cuánta prioridad hay en terminar esto?" como lo que podría haber sido urgente antes puede no ser así al final del sprint.

Answer 3

Para un proyecto ágil es importante tener una 'Definición de hecho'. Esta es una pequeña lista de verificación de cosas que deben hacerse para clasificar algo tan completo. No es inusual tener diferentes niveles de hecho:

• historia de usuario - Esto podría incluir cosas tales como todas las tareas asociadas con los EE.UU. debe ser completa, todo el código se registró y construcción con éxito con el paso de las pruebas unitarias, La prueba de aceptación ha sido completada.

• Sprint - Esto podría incluir cosas tales como todas las historias para el sprint se 'hace' (véase más arriba, una retrospectiva ha ser celebrada, el dueño del producto ha sido testigo de una demostración de la funcionalidad, etc, etc

• de velocidad de lanzamiento - el desarrollo de la serie anterior de carreras se ha integrado con éxito y probado de regresión, la funcionalidad ha sido liberado en el medio ambiente en vivo

En términos de las 4 opciones es menos clara A.. Se dice mucho y se ha escrito sobre lo que debe y no debe hacerse. nd fallando el sprint, extendiendo el sprint y excluyendo alguna característica u otra. Encuentro que con proyectos ágiles se requiere mucho pragmatismo, especialmente en los primeros sprints.

Lo importante es no colgarlo. Solo aprenda de eso, adaptarse y seguir adelante.

Answer 4

Normalmente haría la opción 1 - termine el sprint. Use el trabajo completo, deje que el trabajo sin terminar se refleje en la velocidad del proyecto, de modo que la planificación futura tenga en cuenta las dificultades que experimentó.

Sí, la opción 1 significa que no terminamos con lo que nos hemos comprometido, pero si eso es lo que sucedió, entonces es mejor admitirlo y aprender a sobrellevar mejor la próxima vez que ocultarlo. Todo lo malo sucede a todos: lo fundamental es cómo mejoramos desde donde estamos.

Puede hacer la opción 2 - continuar terminando el trabajo pendiente extendiendo el sprint. Solo haga esto si el trabajo tiene una prioridad muy alta para el cliente y lo elige explícitamente. Extendiendo la longitud de los sprints hace que sea más difícil compararlos entre sí, porque son longitudes diferentes.

NUNCA NUNCA dejes que un sprint se fusione en el siguiente, ya sea que estés extendiendo el sprint antiguo o que estés comenzando uno nuevo. Si dejas que dos sprints se combinen entre sí, entonces ya no estás realmente haciendo sprints y planeando interrupciones ...

Answer 5

Primero, la regla: las iteraciones son casillas de tiempo de longitud fija y se completan al final de el cuadro de tiempo. Esto elimina la Opción 2 y la Opción 3. Con respecto a la Opción 4, la terminación anormal de la iteración puede ocurrir bajo circunstancias muy particulares (la certeza de que el objetivo no se puede alcanzar, el evento externo invalida la meta, ...) pero debe seguir siendo un evento excepcional. Y antes de abortar, en general hay otras opciones: 1. Hacer otra cosa/innovar 2. Obtener ayuda/subcontratar 3. Reducir el alcance. Y esto te deja con la Opción 1, la opción obvia.

El problema que veo con la opción 1 es que el equipo no está cumpliendo con lo que se comprometió. En algunos casos, es posible que no pueda excluir la función B sin hacer que la versión completa sea inútil (o al menos sustancialmente menos valiosa). Puede hacer que sea difícil guiar la dirección del próximo sprint sin la característica B.

Si esto es cierto, entonces B era más importante que A, D y F y no trabajó en lo más importante primero, lo que está mal, no debería suceder o ... A, D y F son realmente muy valiosos, en cuyo caso su suposición no es verdadera y posponer B no es un gran problema. Entonces, solo hazlo tan pronto como te des cuenta de que no se hará y ve si puedes reemplazarlo con un objeto más pequeño.

Answer 6

¿Puedo responder con "Depende"? Además, me gustaría lanzar un "Definir completo".

Hemos tenido esta situación un par de veces y hemos lidiado con ella de manera diferente según las circunstancias.

Por lo que recuerdo, en dos casos dejamos que el sprint falle. En realidad, fue más un tipo de fracaso demo-rechazado. El equipo consideró que las funciones en sí mismas eran completas, pero había demasiadas preguntas abiertas, cabos sueltos y pequeños detalles que aparecieron durante la demostración. Habría tardado un par de días en cerrar todo, de modo que dejamos que el sprint falle y llevamos todos los elementos abiertos al siguiente sprint. Todavía teníamos una planificación retrospectiva y sprint para nuevas historias de usuarios, pero no había integración de líneas de código y el sprint se marcó oficialmente como fallido.

En otro caso, solo tuvimos un par de errores que aparecieron en el último minuto, más un par de cosas de la historia del usuario. Calculamos el trabajo total a tres días como máximo y simplemente extendimos el sprint. Eso fue suficiente para solucionar el error, hacer un par de cambios y hacer una segunda demostración de sprint unos tres días después.

Por lo tanto, era la opción 4 o la opción 2 para nosotros cuando se solicitó.

Hay algunas cosas a considerar aquí. Antes que nada, (y estoy hablando de la terminología de Scrum aquí, porque estoy acostumbrado, así que siéntanse libres de sustituirlo por lo que mejor se adapte), junten ScrumMaster, el propietario del producto y el equipo y discutan las opciones abiertamente. No creo que haya una manera de hacerlo.Puede apegarse a la metodología pura, pero en la vida real ese no es siempre el mejor camino a seguir. A veces, doblar las reglas un poco ayuda mucho y hace la vida más fácil para todos.

Si trabajas bien juntos, deberías encontrar una opción que funcione para todos los involucrados. (De lo contrario, puede tener problemas subyacentes de todos modos). No solo deje caer algo en el equipo sin al menos discutirlo o al menos explicar las razones.

La opción 3 me parece la más desordenada, así que descartaría eso.

Mucha gente aquí ha argumentado que la opción 2 va en contra de las reglas ágiles básicas (o Scrum), pero estoy en desacuerdo. Scrum dice explícitamente que puede extender el sprint si así lo solicita, lo mismo que puede reducir historias o agregar recursos. No deberías hacerlo hasta que sea absolutamente necesario, pero hasta donde yo sé, no es estrictamente contrario al libro. En la base, cuando lo hacíamos, era la mejor solución para todos, porque aún había que completar el sprint, solo tres días después y todos estaban muy contentos con los resultados. Si estuviéramos hablando de una semana o más, la opción 2 no hubiera sido apropiada.

Realmente no me gusta la opción 1. Llevar a cabo tareas a medio terminar una implementación en funcionamiento puede ser realmente complicado. Pierdes contacto con el código que se ha hecho y la integración, francamente, puede ser un dolor. Puede ser diferente según la forma en que trabaje, pero según mi experiencia, sacar el código de una línea de código no es algo que desee hacer.

En cuanto a la opción 4, es bastante dura, pero una vez más, cuando se comunique correctamente, debería estar bien. El equipo generalmente sabe cuándo se dañó y no podrá entregar, por lo que no es como si les estuvieras dando noticias.

Por lo tanto, hay algunas cosas que considerar.

• ¿Cuánto tiempo necesitará para hacerlo? Si solo son uno o dos días, la extensión de su sprint podría ser la mejor opción.
• ¿Cuánto esfuerzo será eliminar el código que ya está allí? Si está desordenado y toma tiempo, resuelve las opciones 2 o 4. Si es fácil, tal vez la opción 1 es el camino a seguir.
• ¿Qué piensa el equipo? ¿Qué piensa el dueño del producto? ¿Qué piensan los demás? Fallar un manantial puede tener un impacto en la moral del equipo, pero puede que no.