¿Cómo se estructura un sprint de desarrollo?[cerrado]

Question

Tengo una acumulación de funciones y estamos a punto de comenzar con un proyecto importante.Estoy trabajando en definir la estructura de nuestros sprints y me interesan los comentarios de las comunidades.

Lo que estoy pensando es:

• Planificación de sprint de un día
  • Complete el trabajo pendiente y descubra qué hará cada desarrollador después de este sprint
• Tres semanas de desarrollo
  • ¡IR!¡IR!¡IR!
• Reunión diaria de pie
  • Verifique si alguien necesita ayuda o se siente desviado
• Dos días de revisión de sprint
  • Aquí se realizan revisiones de código, presentaciones de partes interesadas.
• Retrospectiva de sprint de un día
  • ¿Qué hicimos en el último sprint?¿Cómo podemos hacerlo mejor la próxima vez?

Los sprints siempre deben terminar en martes (para evitar demasiado estrés el fin de semana).

¿Algo más?Obviamente, lo ágil es mucho más que esto.Quiero brindarle al equipo un esquema simple de cómo vamos a operar mientras iniciamos este proyecto.

Answer 1

Consideraría experimentar con sprints que duren menos de un mes.

Personalmente, encuentro que las iteraciones de una o dos semanas son más efectivas para obtener comentarios efectivos rápidamente.También evita que cualquier problema que pueda estar causando problemas en el nivel de iteración se acumule hasta niveles que se vuelven más difíciles de administrar.

Incluso para el sprint de 30 días: dos días suena como un día demasiado largo para la revisión del sprint...y un día parece medio día demasiado largo para la retrospectiva.Descubrí que si necesita mucho más que eso, ha habido problemas de comunicación mientras se realizaban las iteraciones, por lo que es posible que desee considerar la necesidad de revisiones largas como una posible señal de alerta.

Por supuesto, esa ha sido solo mi experiencia: principalmente desarrollando aplicaciones web con equipos pequeños (4-12) personas.Tu experiencia puede variar.

Dicho esto, definitivamente probaría los sprints más cortos.Al igual que las compilaciones de integración, muchas cosas se vuelven más fáciles si las haces con más frecuencia.

Answer 2

Apague el correo electrónico, el teléfono celular y las aplicaciones de mensajería instantánea para disfrutar del código central.De 10 a. m. a 1 p. m. y de 2 p. m. a 5 p. m. podrían ser buenos bloques para esto.

Pida comida y bebidas para el equipo cuando estén en "la zona".

Cancelar todas las demás reuniones para los días anteriores y posteriores a la sesión de planificación y los días de revisión.

Answer 3

• Asegúrese de que el "stand-up" siga siendo un STAND-up.Es muy fácil pasar a reuniones cada vez más largas.
• Un día de planificación del sprint y tres días al final puede ser demasiado.Programe solo el tiempo que necesite.
• +1 a la idea de iteraciones más cortas.Personalmente, cuatro iteraciones de una semana dentro de un sprint han funcionado bien.Las personas son excelentes para estimar tareas a corto plazo;más allá de eso, se vuelve cada vez más conjetura.

Answer 4

Parece un buen enfoque.Apoyo lo que dijeron adrianh y jedidja sobre iteraciones posiblemente más cortas.A mí me gustan las semanas 1.Además de una mejor estimación, también mantiene la idea de "software en funcionamiento" en un ciclo mucho más corto.

Unas cuantas preguntas:

¿Por qué las revisiones de código se dejan para el final?O programa en pareja o haz tus revisiones sobre la marcha.

¿3 semanas de desarrollo significan "desarrollo, pruebas, documentación, instaladores, etc."?Es decir.¿Todo lo que realmente necesitas hacer?

Answer 5

Estructuramos nuestros sprints de manera muy similar a su esquema, excepto que nuestras revisiones de sprints son el último día del sprint y generalmente duran aproximadamente una hora.La revisión del sprint es el momento en el que exhibes tu trabajo a los clientes y otras partes interesadas, no el momento para realizar revisiones de código.Las revisiones de código, si decide realizarlas, deben realizarse periódicamente durante todo el sprint.Solíamos tener un bloque de una hora cada semana donde repasábamos el código nominado por los desarrolladores, lo que significa que no perdíamos tiempo revisando cada LOC escrito.

También finalizamos nuestros sprints un martes y comenzamos un jueves, dejando el miércoles para terminar los cabos sueltos y abordar la deuda técnica creada durante el sprint.

Answer 6

No recomiendo posponer las revisiones de código hasta después del sprint, deberían ser una parte integral del proceso de desarrollo.En otras palabras, una tarea no se realiza a menos que el código haya sido revisado (y probado, y documentado, y...).

Answer 7

Es importante mantenerse alejado de gestionar por gestionar.SCRUM sólo requiere 1 reunión al día, y es corta.Además, durante cada sprint, las únicas otras reuniones son la retrospectiva de primavera y la planificación del sprint.Esto nos permite implementar ROWE, o un Entorno de Trabajo Orientado a Resultados.Deje que sus desarrolladores decidan cómo, dónde y cuándo realizarán su desarrollo.Utilice sus reuniones diarias para realizar un seguimiento de si están haciendo su trabajo.Aparte de eso, retroceda y sorpréndase de su productividad.

Ideas como "apagar teléfonos móviles, desactivar aplicaciones de mensajería instantánea, etc. durante la codificación" son malas ideas.Cuando contratas a tu equipo, lo haces con la confianza de que saben cómo hacer su trabajo correctamente.Si los contrató con ese entendimiento, ¿por qué querría limitar su capacidad para realizar su trabajo de la mejor manera posible?Si estás usando SCRUM, entonces cada desarrollador habrá elegido el trabajo que siente que es capaz de hacer, tu trabajo como Scrum-Master es eliminar obstáculos, no crearlos.

Revisiones de código:Absolutamente necesario.Las revisiones de código por pares son una excelente herramienta de enseñanza para los desarrolladores junior que asisten a reuniones y para las personas que revisan su código.

Documentos de diseño:Personalmente creo que los documentos de diseño detallados que cubren lo que el desarrollador pretende hacer son muy importantes, y también creo que son una parte importante del proceso de desarrollo.Ahora bien, esto no está específicamente en línea con el desarrollo ágil, pero personalmente consulto periódicamente los documentos de diseño creados hace años para ver qué estaba pensando el desarrollador original cuando codificaron sus módulos.