¿Cuál es la mejor manera de manejar elementos sin terminar en una twig de sprint ágil?

Si trabajas de manera ágil y tienes una twig para cada sprint y también tienes una política que solo los elementos terminados y probados pueden volver al tronco, ¿cómo puedes manejar mejor los objects sin terminar?

¿Debería mantenerse activa la twig y cambiarle el nombre a la nueva twig de sprint y continuar trabajando en estos temas allí? ¿Qué pasa si estos problemas no deberían formar parte del próximo sprint?

Actualización :

Después de las respuestas de Alex Pereira entre otros, siento que he omitido mi pregunta, o más bien, he entendido mal mis propios pensamientos. No me refiero a una twig por sprint. Más bien una twig por lanzamiento / set de características. Y dado que esa twig puede continuar viviendo, el problema inicial es realmente inexistente.

Combine eso con las twigs de características y el problema con los elementos sin terminar se vuelve aún más fácil de manejar.

Quiero señalar que aunque el desarrollo hacia el tronco (o cualquier otra twig pnetworkingeterminada) y luego marcar los lanzamientos en el path es una manera factible que he usado antes, quiero un sistema que pueda escalar de 1 a 100 de desarrolladores con un mínimo cambios que se necesitan. Por lo tanto, es necesario que UNA twig se considere la más estable en la que se realizan las cosas y que haya varios paralelos para que diferentes equipos trabajen en funciones al mismo time sin interferir entre sí.

Las ideas que tenía para facilitar todo esto antes de que formulara así

enter image description here

No estoy seguro de que su configuration sea la más óptima aquí. Estoy en una tienda donde también hacemos Agile, y no ramificamos por Sprint, sino que lo ramificamos por Release. Creo que no es necesario tener twigs de Sprint, cuando podrías, de hecho twig por Release y aplica Labels si lo deseas para cada Sprint. Tampoco estoy de acuerdo con los otros comentarios en los que sugieren que los desarrolladores creen su propia sucursal, están pidiendo un desastre allí.

Sin embargo, en tu caso, dado que ya estás usando esa configuration, diría que pasas el "hang around" a la siguiente twig de Sprint, y fusionas la twig de Sprint actual al Troncal. Si los desarrolladores ya comenzaron a trabajar en la twig actual de Sprint, entonces mueva el código manualmente o realice una combinación sin base (si su control de origen lo permite) a la siguiente twig de Sprint.

Actualización 4/17/2012 12:43 PM:

Tuvimos muchas discusiones aquí en mi trabajo con respecto a esto. Básicamente, tenemos tres equipos ágiles que trabajan en tres productos distintivos, dos .NET y un VB6 (legado).

Queríamos encontrar una forma estándar para que todos nuestros equipos trabajasen, y esto es lo que pensamos: quizás te pueda ayudar a:

Estructura de carpeta / ramificación:

  • Desarrollo ( bifurcado principal – contendrá twigs de publicación para desarrollo futuro – siempre actualizado por cambios en Principal – solo se fusiona con Main cuando es hora de publicación y el código pasa las testings iniciales de aceptación )
    • Versión 1
    • Versión 2
  • Principal ( este es el tronco principal – contiene un código candidato de liberación relativamente estable – donde se crean las comstackciones finales )
  • Release (se bifurca principal cuando la versión aprobada por QA – nunca actualizada por cambios es Main – Solo se actualiza por Service Packs para abordar defectos críticos o mejoras urgentes, luego los cambios se fusionan nuevamente en main )
    • Versión 1
      • Service Pack 1
      • Service Pack 2
    • Versión 2

Personalmente, si el trabajo no terminado no se va a llevar al siguiente sprint, tiraría el trabajo inacabado.