Si ya lanzas de forma continua, ¿cuáles son los beneficios de un Scrum Sprint de duración constante?

Sprint : un período de tiempo arbitrario durante el cual implementa y lanza funciones de software.

Por lo que he leído aquí y en otros lugares, parece que los beneficios de un sprint de Scrum son que al final de un sprint liberas el software, recibes comentarios del cliente, etc.

Pero en un producto basado en la web, donde yo soy el propietario (el usuario final es el cliente) y comunicamos pequeñas mejoras justo cuando las hacemos en lugar de esperar a que finalice algún Sprint, y el cliente obtiene las nuevas funciones justo cuando las necesita. se implementan, ¿cuáles son los beneficios de "finalizar" un sprint ?
(aparte de una autopsia, que no hacemos)

¿Quizás este es un elemento de mejora de procesos que debería discutir con su equipo en su retrospectiva?
@NathanCooper no parece que el equipo de OP tenga retrospectivas. (Sin embargo, recomendaría encarecidamente que comiencen)
Si no tiene Retrospective, entonces ese es un problema un poco más serio que hacer preguntas sobre el valor de un Sprint IMO, pero parece que la pregunta ha sido respondida.
Está tratando de elegir una herramienta para solucionar un problema que no conoce; tal vez usar Sprint se convierta en un martillo muy bueno y poderoso... para sus tornillos.

Respuestas (3)

TL;RD

  • Un Sprint consagra su proceso empírico proporcionando una máxima cadencia de entrega
  • Aumenta la comunicación y la alineación.
  • Agrega cierta previsibilidad a la naturaleza impredecible del software al igualar los tamaños de los lotes.

¡Un Sprint es un contenedor para la planificación!

Si bien la Guía Scrum dice que debe entregar software que funcione al menos cada 30 días, no hay nada que le impida hacerlo con más frecuencia. De hecho, la entrega continua y Scrum van muy bien juntos en mi experiencia.

Un Sprint consagra la inspección y la adaptación al contener sus otros circuitos de retroalimentación:

  1. Planificación de Sprint - Inspeccione el Backlog y adapte el plan para el próximo Sprint
  2. Daily Scrum : inspeccione el progreso y adapte el plan para las próximas 24 horas.
  3. Sprint Review - Inspeccionar el Incremento y adaptar el Backlog
  4. Retrospectiva de Sprint - Inspeccione el Sprint y adapte el proceso.

Sin un Sprint, ¿cuándo reunirías todo esto? Les hace esfuerzos obligatorios como deben ser. Si eres un equipo increíblemente disciplinado, entonces haz algo que se parezca un poco más a Kanban, pero si no tienes la disciplina para seguir las reglas de Scrum, ¿cómo esperas que funcione Kanban?

Comunicación y Alineación

Un beneficio adicional de Sprinting es que brinda una cadencia que su gerencia y otros equipos dependientes pueden seguir fácilmente. Si está coordinando el trabajo, tener un marco de referencia común, Sprint 231, ayudará en la comunicación.

Crea previsibilidad

Dado que el software es un esfuerzo creativo y la desviación estándar de un lote es tan amplia e impredecible, la adición de un contenedor de tiempo fijo creó artificialmente cierta previsibilidad en sus lotes.

Diría que hay mucho valor en un Sprint.

En resumen, establece una cadencia y un ritmo para su trabajo. ++
Scrum Guide no dice eso en absoluto. Dice "El Incremento es la suma de todos los elementos del Product Backlog completados durante un Sprint y el valor de los incrementos de todos los Sprints anteriores. Al final de un Sprint, el nuevo Incremento debe estar "Terminado", lo que significa que debe estar en condiciones utilizables y cumplir con la definición de "Terminado" del Equipo Scrum. Debe estar en condiciones de uso, independientemente de si el propietario del producto decide lanzarlo". En ninguna parte dice que el software DEBE publicarse cada 30 días. En algunas entregas (por ejemplo, automotriz o aeroespacial) esto sería imposible.
Edite su respuesta para reflejar la Guía Scrum real. Todo lo demás era perfectamente válido.
De hecho, la Guía de Scrum dice: "El corazón de Scrum es un Sprint, un cuadro de tiempo de un mes o menos durante el cual se crea un Incremento de producto "Terminado", utilizable y potencialmente liberable". <-- Un mes o menos...
... ¿te estás saltando a propósito la parte "potencialmente"? Y simplemente ignorar la cita real de la Guía Scrum V3 que publiqué.
Y en ninguna parte de mi respuesta dije que necesita 'liberarse', de ahí mi confusión. "La guía Scrum dice que debe entregar software que funcione al menos cada 30 días, no hay nada que le impida hacerlo con más frecuencia".
+1 a @MrHinsh y Venture2099 con respecto a 'liberable'. La distinción más importante en la guía Scrum con respecto al Incremento de Producto es que en menos de 30 días, debe ser liberable. Esto permite que la publicación se convierta en una decisión comercial en lugar de una decisión técnica, es decir, ¿podemos publicar esto?

En su situación, puede encontrar que un modelo Scrum Sprint no se ajusta bien. Es solo una forma de hacer las cosas. Quizás esté buscando más un enfoque Kanban

En cuanto a la utilidad de un sprint en sí, si un equipo de personas puede trabajar en conjunto para completar una parte de la funcionalidad que cumple con el objetivo del sprint, entonces puede ser muy gratificante para ellos liberar los límites del sprint.

Scrum no exige un lanzamiento en cada sprint, eso depende del propietario del producto y del equipo. Pero es extremadamente importante que el producto se encuentre en un estado " potencialmente enviable ", lo que significa que el software de buena calidad y funcional está disponible para ser lanzado de forma regular.

No, no @MrHinsch. Deja de decir esta basura. Aquí está el comunicado oficial. El Incremento es la suma de todos los elementos del Product Backlog completados durante un Sprint y el valor de los incrementos de todos los Sprints anteriores. Al final de un Sprint, el nuevo Incremento debe estar "Terminado", lo que significa que debe estar en condiciones de uso y cumplir con la definición de "Terminado" del Equipo Scrum. Debe estar en condiciones de uso, independientemente de si el propietario del producto decide lanzarlo. Fuente: Guía Scrum V3

La principal razón para apegarse a una duración de sprint consistente sería tener previsibilidad. Dado que la velocidad es el promedio del trabajo que ha realizado en un período de tiempo determinado, sería inutilizable si la duración de los sprints fuera inconsistente. Una velocidad útil puede dar más confianza a un equipo que se compromete a entregar una función en un período de tiempo determinado y también ayuda al equipo a estimar y pronosticar un hito a más largo plazo para su proyecto.

Las razones para apegarse a la duración constante de los sprints dependen en gran medida del tipo de entorno en el que se encuentre. Scrum no prescribe que los lanzamientos ocurran al final de cada sprint, y la entrega continua es sin duda una de las razones más comunes para renunciar a esta práctica. Kanban puede ser algo que valga la pena revisar si se encuentra en un entorno con un flujo continuo de tareas.

No existe tal cosa como una velocidad precisa, es una falacia, y su búsqueda es una pérdida de tiempo. La Guía Scrum estipula que debe obtener un software que funcione frente a sus clientes al menos cada 30 días.
@MrHinsh La precisión y la exactitud son muy diferentes. Es imposible obtener una estimación precisa basada en la velocidad, pero ciertamente es posible obtener una estimación precisa basada en la velocidad. Uno puede usar fácilmente la velocidad para estimar que se alcanzará un hito en 9-12 meses (exacto) versus una fecha específica (preciso).
Estoy en desacuerdo; ya que la desviación estándar de la velocidad de la mayoría de los equipos, sprint tras sprint, es tan alta que el promedio (media) está demasiado alejado de la realidad para ser utilizado de manera realista.
@MrHinsh quizás "velocidad útil" sería un mejor término para evitar esta confusión. Actualizado.
@MrHinsh bueno, supongo que debería tirar todas las pruebas de mi equipo que muestran una velocidad estable. Anécdota no es el plural de dato. El hecho de que no hayas visto una velocidad estable no significa que no exista y que no sea una aspiración. Tampoco he visto nunca que una operación militar vaya según lo planeado, pero no dejamos de planear. La velocidad también solo es útil como medida a lo largo del tiempo. Entonces, según esa velocidad estándar, SIEMPRE es precisa. Al igual que el promedio de goles marcados por partido, solo es útil durante una temporada. Ayuda a la toma de decisiones pero no lo usamos como un punto fijo.
Le sugiero humildemente que aplique un pensamiento un poco más flexible a las declaraciones absolutas que está haciendo. Es la antítesis de Scrum (y los valores ágiles) y puedo probar que su declaración absoluta es incorrecta con un solo estudio de caso.
Útil es mucho mejor que preciso.
No se necesita ningún calificador en absoluto. La velocidad es la velocidad y puede ser precisa.
@MrHinsh siendo la velocidad es una medida rezagada, siempre es precisa. Si es o no un indicador útil del rendimiento futuro es otra cuestión completamente diferente... IME no lo es.
@RubberDuck Puedo estar de acuerdo con eso. Aunque la precisión generalmente viene con una advertencia "¿precisa para ...?" qué... Estaba tratando de insinuar que el grado de precisión es tan amplio que lo hace completamente inútil como medida.
Si ya lanzas de forma continua, ¿cuáles son los beneficios de un Scrum Sprint de duración constante?
RespuestasAquíPolítica de privacidad1y, 0v