¿Qué tan relajado (o no) debe ser un sprint?

12

¿Cuál debería ser la actitud hacia la realización de historias asignadas a un sprint? Obviamente, desea priorizar que se realicen en el sprint, pero para mí, el punto de agile es ser dinámico: no desea posponer deliberadamente o hacer que sea "correcto" omitir las historias de usuarios finales en un sprint, pero en Al mismo tiempo, cuando surgen cosas inesperadas, y esas historias no se completan y pasan al siguiente sprint, no quieres tener la sensación de que hiciste algo mal. Eso no debería ser una experiencia aterradora o negativa, ¿verdad?

¿Las experiencias negativas / de miedo son aceptables para los compromisos de sprint perdidos? ¿Deberían los desarrolladores ser responsables de los compromisos de sprint perdidos cuando surgen tareas inesperadas que deben ser tratadas (por ejemplo, soporte de producción)?

    
pregunta void.pointer 01.05.2012 - 17:31

9 respuestas

7

Debes absolutamente apuntar a que los elementos se realicen dentro de un sprint.

Uno de los principales beneficios de SCRUM es que le da al proyecto un 'latido'.

Usted prioriza, selecciona artículos de una lista, los entrega, los demuestra, refleja cómo fueron y luego lo hace de nuevo en ciclos predecibles.

Toda la planificación, las estimaciones y la priorización se basan en este concepto. Que podemos y vamos a comprometer hacer X puntos dentro del sprint, y podemos, con el tiempo, establecer una velocidad a partir de la cual podamos usar para una mejor planificación.

Si eres demasiado informal con el contenido y los compromisos de tus sprints, SCRUM simplemente se descompone en mi opinión y pierdes mucho sus beneficios.

Por supuesto, el mundo real a veces tendrá algo que decir al respecto, pero esa debería ser la excepción y no la regla ...

    
respondido por el Benjamin Wootton 01.05.2012 - 17:43
5

La clave es que debe haber responsabilidad para no completar las historias.

Eso significa que debe haber una razón sólida por la cual una historia no se completó, y que esta razón se explica en el plan del proyecto en el futuro, por lo que no se repite.

Esta razón debe ser más que un vago "surgieron cosas".

Por ejemplo, si una historia no estaba completa porque un miembro del equipo tuvo que trabajar en un problema de producción, entonces esta posibilidad debe abordarse en futuras iteraciones, ya sea planificando menos horas de este miembro del equipo o preparando otras cobertura.

Si la razón podría haberse evitado con más diligencia o trabajo duro desde el principio, entonces, esta responsabilidad puede ser un poco dolorosa. Con suerte, el dolor es de la variedad "Esto es lo que necesitamos para mejorar la próxima vez" en lugar de la variedad "No estás haciendo tu trabajo".

    
respondido por el JohnMcG 01.05.2012 - 17:56
4
  

Eso no debería ser una experiencia aterradora o negativa, ¿verdad?

Si sucede una o dos veces, no, entonces no debería ser una experiencia negativa. Si sucede regularmente, tienes un problema. Entonces el equipo siempre está exagerando. Mejore la estimación y piense dos veces en lo que comete para un sprint, pero no se ponga ansioso.

Los sprints relajados significan que tuvo un compromiso insuficiente.

Los sprints no vinculados significan que tuvo un compromiso excesivo.

Acabo de entregar lo que me comprometo y trato de mejorar en el compromiso. Solo en circunstancias especiales movería una historia al siguiente sprint. Prefiero tener una ligera presión todos los días que tener un infierno de presión poco antes de algunos plazos.

    
respondido por el Falcon 01.05.2012 - 17:42
4

Basado en mi experiencia - Como cualquier otra cosa ágil, nos adaptamos a un sistema de retroalimentación continua que incluye la estimación.

Está bien perder una fecha límite para el primer sprint (inicio del proyecto) pero APRENDE de lo que salió mal (subestimación, no saber las fortalezas del equipo, etc.). Luego toma el feedback y lo envía al siguiente sprint y obtiene una mejor estimación.

Desde mi experiencia, han pasado 11 meses en mi nuevo proyecto ágil rara vez perdemos el plazo actual si es que lo echamos de menos. Pero nos perdimos la fecha límite para el primer sprint porque no sabíamos el ritmo y la fuerza de los miembros de nuestro equipo.

Algunas personas argumentan que "asigna" más tiempo para que el primer sprint pueda superar el primer problema del sprint.

    
respondido por el java_mouse 01.05.2012 - 17:47
2

Es interesante ver las respuestas / comentarios aquí. En cada proyecto (tipo) ágil en el que he trabajado, la principal ventaja era distribuir la presión de la fecha límite en muchos mini plazos, en lugar de una marcha de la muerte al final del proyecto. OMI, los sprints deben tomarse en serio. Todos los resbalones en la fecha límite o la funcionalidad entregados deben verse como problemas potenciales en la gestión o desarrollo del proyecto.

    
respondido por el tzerb 01.05.2012 - 17:57
2

Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deberían poder para mantener un ritmo constante por tiempo indefinido. - Principios detrás del Manifiesto Ágil

Si es una experiencia aterradora o negativa, y sucede todo el tiempo, tienes un problema. El desarrollo de software debe ser divertido. No es negativo ni da miedo.

Sin embargo, si el equipo se compromete a terminar algunas historias en un sprint y no entregarlas, también tiene un problema. Este problema es casi seguro que no se resolverá agregando más presión al equipo para completar las historias. Si el problema se debe a factores externos, estos deben ser gestionados. Si el equipo está comprometiendo en exceso, ScrumMaster puede guiar al equipo a comprometerse con menos puntos de historia. Puede haber muchas razones y cada una debe ser tratada de manera diferente. Un equipo enérgico y motivado debe tener mucha motivación para seguir adelante.

Idealmente, sea cual sea el problema, se plantea durante la retrospectiva y se soluciona.

No debería ser tan complicado para el equipo averiguar qué pueden lograr durante el período relativamente corto del sprint y luego lograrlo (una historia ocasional que se empuja al siguiente sprint está bien, la velocidad puede fluctuar, las cosas cambian etc.). Si no puede hacerlo razonablemente bien después de algunos sprints, está haciendo algo mal.

    
respondido por el Guy Sirton 02.05.2012 - 08:51
1

Realmente depende de tu línea de tiempo.

A veces, NECESITARÁS hacer todas las historias, o la mayoría de ellas de todos modos. Si bien Agile proporciona cierta flexibilidad, también deberá completar el proyecto, posiblemente en una línea de tiempo ajustada. Por lo tanto, tener la mayoría de las historias listas le permitirá terminar su proyecto a tiempo.

Con eso dicho, sin embargo, van a surgir cosas que evitarán que termines cada historia, cada sprint.

Si el producto está en una línea de tiempo y se pierden las historias clave, eso podría hacer que el producto llegue tarde. La demora del producto en algunos casos puede perjudicar la posición competitiva de una empresa. Entonces, en ese caso, QUIERES que sea una experiencia negativa tener historias que faltan, podría hacer que lo hagas todo la próxima vez.

    
respondido por el Alan Delimon 01.05.2012 - 17:39
1

Cuando se dosifica correctamente, el estrés es bueno. No desea eliminar todo el estrés, solo desea distribuirlo de manera más uniforme a tiempo. Incluso cuando juegues tu juego favorito, tendrás un poco de estrés y sentimientos negativos. De hecho, obtienes más energía de esto.

Un equipo debería sentirse mal por las historias perdidas. Les dará energía para cambiar algo la próxima vez (trabajar de manera diferente o planificar menos historias, ambas son buenas). También deben sentirse orgullosos cuando hacen sus historias, por supuesto.

También menciona tareas inesperadas (soporte de producción). Eso levanta una bandera roja conmigo. Debería haber un espacio de tiempo acordado para todas las cuestiones no relacionadas con las historias. De lo contrario, el juego no es justo, el equipo se siente impotente y los sentimientos negativos no se utilizan para mejorar.

    
respondido por el Kris Van Bael 02.05.2012 - 08:22
1

Debes ver los factores que hacen que tus compromisos fracasen y tratar de solucionarlos. Grandes cantidades de eventos aleatorios mantendrán en desorden tus sprints haciendo que tu velocidad sea impredecible. Corrija las causas de esto o introduzca slack en sus sprints. Prefiero arreglarlo.

De cualquier manera, el equipo no puede ser responsabilizado si su trabajo está perturbado por factores externos. Use retrospectivas para ver esto.

    
respondido por el Martin Wickman 02.05.2012 - 09:31

Lea otras preguntas en las etiquetas