Cuando se considera completa una iteración ágil? [cerrado]

Question

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

Una pregunta que nos estamos quedando en contra es decidir cuándo una iteración (Sprint) debe completar.

Supongamos que hemos definido nuestro estado de función, y producido estimaciones historia de punto para ellos, y hemos decidido que el primer sprint de 30 días incluirá características A, B, D y F. ¿Qué debe hacer si por lo que está llegando al final de la carrera y que ha completado a, D, y F - B, pero es sólo el 80% de avance. En caso de que:

1. Completar 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 comenzar el siguiente sprint.

3. Extender el sprint por el tiempo necesario para completar función B y comenzar a trabajar en el siguiente sprint.

4. deja de funcionar completamente el sprint, y el paquete de todo el trabajo de ser parte de una versión futura.

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, puede que no sea capaz de excluir función B sin hacer el comunicado inútil (o al menos sustancialmente menor valor). Se puede hacer que sea difícil para guiar la dirección de la siguiente sprint sin función B.

El problema con la opción 2 es que algunos miembros del equipo pueden estar inactivo durante un período significativo de tiempo - lo que se come en la productividad general. Usted puede ser capaz de añadir más pruebas de la unidad o las características que pulir, pero que no añade valor proporcional. También es políticamente difícil de explicar por qué la mayoría de la gestión de su equipo está inactivo.

La opción 3 parece estar en contra del espíritu de la agilidad - que están poniendo el siguiente sprint en riesgo al no permitir que los resultados de la anterior para guiar a la siguiente iteración del desarrollo

.

Opción 4 parece grave y tiene la mayor parte de los mismos problemas de la Opción 1 y 3. En primer lugar, se está perdiendo por completo un compromiso. En segundo lugar, la agrupación más características en una posterior liberación hace que sea más difícil de probar y verificar con los clientes -. Y de nuevo se opone a la capacidad de guiar la iteración futuro basado en la retroalimentación de los anteriores

Answer 1

Opción 1 por supuesto. Su velocidad para la siguiente iteración va a ser menor, ya que se basa en ayeres tiempo , por lo que la siguiente iteración usted tiene una mejor oportunidad de ser completa.

En scrum son Hora-boxing . Y sólo se ofrecen funciones que funcionan.

planificación del sprint que han hecho una estimación de lo que podría ofrecer. 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 no cumple con la siguiente iteración de nuevo, cambiar a una longitud más corta iteración, y asegúrese de que el tamaño de las características individuales es menor.

Answer 2

haría normalmente la opción 1 - finalizar el sprint . Utilizar el trabajo realizado, que el trabajo no terminado se reflejan en la velocidad de proyecto -. Planificación de lo que el futuro tiene en cuenta las dificultades que experimentó

Sí, la opción 1 significa no terminar lo que nos hemos comprometido a -. Pero si eso es lo que ha pasado, entonces es mejor admitirlo y aprender a afrontar mejor la próxima vez que ocultarlo Cosas malas sucede a todo el mundo -. lo fundamental es cómo mejoramos desde donde estamos

Usted podría hacer la opción 2 - continuar terminar el trabajo pendiente, extendiendo el sprint. Sólo haga esto si el trabajo es super-alta prioridad para el cliente y que explícitamente que desea hacerlo La extensión de la longitud de carreras hace que sean más difíciles de comparar entre sí -.. Porque son diferentes longitudes

Absolutamente nunca, nunca deje que uno de sprint se funden en la siguiente - ya sea que estés extender la edad de sprint, o vas a empezar una completamente nueva. Si deja que dos carreras se funden en uno al otro entonces usted no está realmente haciendo sprints más y planificación se rompe ...

Answer 3

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

Hemos tenido esta situación un par de veces y tratamos de forma diferente dependiendo de las circunstancias.

Por lo que yo recuerdo en dos casos que permiten el sprint falle. Fue en realidad más de una demo-rechazada tipo de fallar. Las características se consideraron a sí mismos completa por el equipo, pero había demasiadas preguntas abiertas, los cabos sueltos y pequeños detalles que apareció durante la demostración. Se habría necesitado un par de días para envolver todo para arriba, así que deje el sprint falle y se llevó todas las partidas abiertas en el siguiente sprint. Todavía había una planificación retrospectiva y Sprint para las nuevas historias de usuario, pero no había integración de líneas de código y el sprint fue marcada oficialmente como fallido.

En otro caso que sólo tenía un par de errores que se convirtió en el último minuto, además de un par de cosas de la historia de usuario. Estimamos el trabajo total de tres días de lo mejor y solo extendió el sprint. Eso fue suficiente para nosotros para corregir el error, hacer un par de cambios y hacer un segundo demo sprint de unos tres días más tarde.

Por lo tanto, era o bien la opción 4 o la opción 2 para nosotros cuando fue llamado para.

Hay algunas cosas a considerar aquí. En primer lugar, (y estoy hablando terminología Scrum aquí, porque estoy acostumbrado a ella, así que no dude sustituirlo con lo que se adecue mejor) obtener el ScrumMaster, propietario del producto y el equipo juntos y discutir las opciones abiertamente. Creo que no hay un camino a seguir. Usted puede pegar a la metodología pura, pero en la vida real, que no siempre es el mejor camino a seguir. A veces romper las reglas un poco ayuda mucho y hace la vida más fácil para todos.

Si está trabajando bien juntos que debe encontrar una opción que funciona para todos los involucrados. (Si no puede usted puede haber problemas de todos modos subyacente.) No se limite a dejar algo en el equipo sin por lo menos hablar de ello o al menos explicar las razones por qué.

Opción 3 suena como el más complicado para mí, así que me gustaría descartar eso.

Mucha gente aquí han argumentado que la opción 2 va en contra ágil básica (o Scrum) reglas, pero me gustaría estar en desacuerdo. Scrum dice explícitamente que se puede extender el sprint si se llama a, el mismo que puede reducir historias o añadir recursos. Usted no debe hacerlo hasta que sea absolutamente necesario, pero por lo que sé que no es estrictamente contra el libro. En la base cuando lo hicimos, era la mejor solución para todos, porque todavía tenemos el sprint hecho, sólo tres días después y todo el mundo estaba muy satisfecho con los resultados. Si nos referimos a la semana o más opción 2 no habría sido apropiado.

No me gusta mucho la opción 1. Tomar las cosas a medio hacer-a cabo una aplicación de trabajo puede ser muy desordenado. Usted perder el contacto con el código que se ha hecho y la integración, francamente, puede ser un dolor. Puede ser que sea diferente en función de su forma de trabajar, pero desde mi experiencia, tomando el código de una línea de código no es algo que quieres hacer.

En cuanto a la opción 4, es bastante duro, pero por otra parte, cuando se comunican correctamente debería estar bien. El equipo usualmente sabe cuando es desordenado y no será capaz de ofrecer, por lo que no es como que está rompiendo ninguna noticia de ellos.

Por lo tanto, hay algunas cosas a tener en cuenta.

• ¿Cuánto tiempo se necesita para lograr que se haga hecho? Si se trata de sólo uno o dos días, la ampliación de su carrera podría ser la mejor opción.
• ¿Cuánto esfuerzo será eliminar el código que ya existe? Si es complicado y consume tiempo, resolver a la opción 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? A falta de un resorte podría tener un impacto en la moral del equipo, pero no pudo.

Answer 4

Para un proyecto ágil que es importante contar con un 'Definición de Hecho'. Esta es una pequeña lista de verificación de cosas que hay que hacer con el fin de clase algo tan completo. No es inusual tener diferentes niveles de hecho:

• La 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 la construcción con éxito las pruebas de unidad de paso, pruebas de aceptación se ha completado

• 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.

• Sprint de prensa -. 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. Se habla mucho y se ha escrito sobre lo que debe y no debe hacerse en torno a fallar el sprint, extendiendo el sprint y la exclusión de alguna característica u otra. Me parece que el que con proyectos ágiles se requiere una gran cantidad de pragmatismo, especialmente en las primeras carreras.

Lo importante no es conseguir colgó él. Sólo tienes que aprender de ella, adaptarse y seguir adelante.

Answer 5

Me gustaría tener una variación en la opción 1. Si la función B puede ser dividido en lo que se ha completado y lo que no se ha completado, esto debería conducir a una serie revisada de tareas para completar para el siguiente sprint. Lo que se terminó se entrega, y mientras que la entrega no es perfecto, la idea debe ser intentar lo mejor de uno y luego trabajar en lo que sigue de acuerdo a la prioridad.

Extendiendo el sprint es una receta para el desastre a la mente. Cómo completar la característica significa resolver todos los errores en él, también? Alguna vez has visto un software que tenía cero errores?

A falta el sprint introduce demasiado perfeccionismo en las cosas. Es algo que se hace despreciable 99%? No me lo creo, pero hay algunas personas que tienen estándares muy altos y puede ser bastante exigente.

EDIT: A veces una característica inicialmente se da con los requisitos vagos que quedan aclaradas en el transcurso de la carrera de velocidad. Por ejemplo, una solicitud de función de "Como usuario, me gustaría hacer un pedido", o bien se puede dividirse aún más como parte de la planificación de la carrera o durante el sprint. En cualquier caso, si se hacen algunas historias que implican una característica, los que pueden y deben ser presentados en la demo si uno está hecho. El punto es ser capaz de decir: "Aquí es donde estamos. ¿Qué parte de una prioridad está allí en terminar esto?" como lo que podría haber sido urgente antes puede no ser lo que al final de la carrera de velocidad.

Answer 6

En primer lugar, la regla: iteraciones son de longitud fija de tiempo y cajas que estén completos al final de la caja de tiempo. Así que esto elimina la opción 2 y opción 3. En cuanto a la opción 4, iteración terminación anormal puede ocurrir en circunstancias muy particulares (certeza de que el objetivo no puede lograrse, evento externo invalida el objetivo, ...) pero esto debe seguir siendo un caso excepcional. Y antes de abortar, hay otras opciones generales en: 1. hacer otra cosa / innovar 2. Obtener ayuda / externalizar 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á dando lo que se ha comprometido a. En algunos casos, puede que no sea capaz de excluir función B sin hacer el comunicado inútil (o al menos sustancialmente menor valor). Se puede hacer que sea difícil para guiar la dirección de la siguiente sprint sin función B.

Si esto es cierto, entonces o bien B era más importante que A, D y F y que no funcionaba en los elementos más importantes en primer lugar que está mal, no debería suceder o ... A, D y F son realmente muy valiosa en el que caso de que su suposición no es realmente cierto y posponer B por lo tanto no es un gran problema. Por lo tanto, sólo lo hacen tan pronto como se dé cuenta que no se llevará a cabo y ver si se puede reemplazar con un elemento más pequeño.