¿Qué pasa entre sprints?

Estoy trabajando en un proyecto que sigue libremente el modelo scrum. Estamos haciendo sprints de dos semanas. Algo que no tengo claro (y no tengo un libro para consultar) es exactamente lo que se supone que debe suceder entre sprints: debe haber algún proceso de "envoltura", donde el producto se construye y se entrega, pero:

• ¿Cuánto tiempo lleva esto típicamente?
• ¿Debería participar todo el equipo?
• ¿tiene que terminar estrictamente antes de que los desarrolladores comiencen a trabajar en los próximos artículos de sprint?
• ¿Es esto cuando se realiza la revisión y prueba del código?

Hay tres desarrolladores, que suman aproximadamente 1 FTE. Entonces los sprints son de hecho muy cortos.

Estoy trabajando en un proyecto que sigue libremente el modelo scrum.

Para que quede claro: es probable que sus gerentes le hayan contado sobre Scrum, pero lo que usted realiza no es Scrum.

¿Cuánto tiempo suele llevar esto?

La reunión de revisión de Sprint + la reunión retrospectiva de Sprint finaliza el sprint actual. En carreras cortas, deben tomar algo entre 30 minutos y 1 hora juntos. El próximo día hábil comienza un nuevo sprint al realizar las reuniones 1 y 2 de planificación de Sprint. Según el tamaño del equipo y la duración del sprint, esta reunión puede llevar de 2 a 4 horas.

¿Debería participar todo el equipo?

Todo el equipo debe participar en las reuniones mencionadas en la respuesta anterior.

¿Tiene que terminar estrictamente antes de que los desarrolladores comiencen a trabajar en los próximos artículos de sprint?

Sí, porque hasta que finalice la reunión de revisión, no sabe si el cliente acepta el resultado del sprint anterior y no sabe qué historias de los usuarios se comprometerán en la planificación de las reuniones.

¿Es esto cuando se realiza la revisión y prueba del código?

No. La revisión y prueba del código es parte del sprint. Los desarrolladores deben hacer todo lo necesario para entregar un código de trabajo que satisfaga los requisitos. Esto puede incluir revisiones de código y siempre debe incluir algún tipo de pruebas automatizadas que validen que el código funciona y hace lo que se supone que debe hacer; de lo contrario, la historia del usuario no puede considerarse como hecha.

El cambio mental principal es con QA. Muchos desarrolladores piensan que QA está ahí para validar que el código funciona y hace lo que se supone que debe hacer. Definitivamente no. Ese es el trabajo de desarrollador.

El control de calidad debe participar en el desarrollo de productos. Su principal responsabilidad en el sprint debe ser la comunicación con el propietario del producto y la creación de pruebas de aceptación automatizadas para los criterios de aceptación (definición de hecho) que validarán que la historia del usuario esté realmente hecha y que la aplicación pase todos los requisitos nuevos. En equipos pequeños, esto también puede ser responsabilidad de los desarrolladores.

El control de calidad también debe hacer algunas pruebas manuales para mantener la coherencia del producto y descubrir características faltantes, validar la experiencia del usuario con la interfaz de usuario, etc. El control de calidad no está allí para buscar errores y pruebas de regresión: las pruebas de regresión deben ser altamente automatizadas.

En mi experiencia, aquí es donde la mayoría de las empresas que cambian a ágil falla.

Desde mi experiencia, no hay tiempo entre sprints, excepto el fin de semana. Hacia la mitad del sprint, los equipos de los que he sido miembro trabajan con el propietario del producto para hacer un arreglo de la historia o tamaños preliminares basados ​​en los requisitos. Es responsabilidad del propietario del producto mantener la cartera de pedidos completa: esas historias son en las que trabajará el equipo, con algunas aportaciones del propietario del producto con respecto a las prioridades. Una vez que se realiza el sprint actual, comenzará el siguiente, utilizando el trabajo que hemos realizado para preparar historias y tareas para el próximo sprint.

Hay algunos gastos generales (muchas reuniones, preguntas y respuestas y evaluaciones de requisitos), pero en general funciona: avanzamos constantemente con poco tiempo de inactividad. Los sprints generalmente han durado dos o tres semanas. El control de calidad generalmente tiene lugar una vez que se completan las historias. Sin embargo, el equipo de control de calidad puede tener otras tareas que pueden hacer. Con respecto al arreglo de la historia, las tareas pueden recaer en los miembros principales del equipo o en todo el equipo. Puede variar según el tamaño del equipo y el proceso acordado. Las revisiones de código generalmente tienen lugar mientras ocurre el control de calidad, o al final del sprint si el tiempo está comprimido. Y si no hay tiempo suficiente para terminar las historias, en la práctica, estas historias pasan al siguiente sprint. El tamaño y la estimación adecuados son muy importantes aquí.

... y cuando es la estimación? ¿planificación?

Las historias deberían ser realmente fáciles de no tener tiempo entre sprints.

Y no sé de qué tipo de prueba estás hablando, pero los desarrolladores harán pruebas de unidad e integraciones, nada más.

Estaba trabajando en un proyecto con a veces 2 o 3 días entre sprints y se siente bien. Ahora estoy trabajando en un proyecto donde no hay tiempo y todo está borroso. La última vez del sprint tenemos un despliegue de producción y eso lleva un tiempo de mi último día de sprint.