project-management - tener - medidor de meta description
Longitud de Sprint: 2 semanas frente a 30 días (8)
Estaba pensando en sprints de 1 semana, pero esto parece Scrum Micro Management.
Sí, pero esto hará que hagas más Scrum: harás una planificación de sprints, una demo de iteración y una retrospectiva cada semana. La desventaja es la sobrecarga, sin embargo, pasas menos tiempo planificando, haciendo demostraciones y "revisando" una iteración de una semana que una iteración de un mes.
Cuanto más corta es la iteración, más rápido el equipo aprende el proceso.
Ahora, dependiendo del tipo de proyecto, podría ser difícil lograr algo valioso en un retraso de una semana.
Antes de que me olvidara, no hago una iteración de tres semanas: o)
En caso de ir con iteraciones de cuatro semanas, también tiene la posibilidad de reemplazar tareas que no se han iniciado con tareas estimadas para la misma cantidad de tiempo.
Quiero implementar Scrum, pero no puedo decidir sobre la longitud de Sprint. Ken Schwaber parece relatar que hace 30 días que es el defacto ... pero no me puedo imaginar esperando 30 días sin la posibilidad de cambiar de dirección o volver a priorizar.
Nuestros proyectos usualmente duran de 1 a 3 meses usando el método de la cascada y mudarse a Scrum probablemente significaría menos oportunidad de afinar.
Estaba pensando en sprints de 1 semana, pero esto parece Scrum Micro Management.
Tener carreras de 2 semanas probablemente sería ideal, pero quiero saber si otros pudieron implementarlo con éxito. ¿Cuáles son los inconvenientes? ¿Es más trabajo / menos trabajo / lo mismo sobre el trabajo para administrar un equipo con sprints más cortos?
Por cierto ... los sprints de 3 semanas me parecen raros, ¿quién hace un sprint de 3 semanas? ¿Por qué no hacerlo solo 4 semanas? ;)
2 semanas (10 días hábiles estándar, si es un equipo de MF o 12 si es un equipo de MS) es de medio mes (un mes generalmente tiene aproximadamente 20 días hábiles, más o menos). Además, la semana es más vaga que el día pero menos vaga que el mes, por lo que mejora la unidad de medida en semanas para proyectos de desarrollo más ágiles (más dar / recibir).
Sin embargo, la última vez que hice algo parecido al scrum, fue en un proyecto de la escuela y no fue realmente scrum. Entonces fueron 7 días de semanas en un trimestre de 10 semanas. Me gustó mucho el bloque de 2 semanas para esa situación. Sentí que podía hacer mucho, pero podíamos ajustar los plazos y los planes con frecuencia.
El propietario del producto siempre debe tener la oportunidad de cambiar las prioridades y las indicaciones. Uno de los propósitos de SCRUM es aceptar los cambios y dejar que el propietario del producto sea el responsable de la prioridad al analizar las necesidades del negocio y el equipo de desarrollo responsable de la entrega a tiempo.
Entonces, incluso si tiene un sprint de 3 semanas, no es necesario que el dueño del producto tenga que esperar 3 semanas si descubre algo que (posiblemente) va a romper el sprint.
En algunos casos excepcionales, debe detener un sprint en el medio y crear uno nuevo debido a nueva información o nuevas prioridades.
En este momento estamos haciendo sprints de 30 días y consiguiendo pilas. Una razón por la cual los sprints de 30 días nos funcionan bien es que nuestra planificación y estimación generalmente demora 2 días (reuniendo y decidiendo qué tareas de alto nivel tomar de la acumulación, tomando las tareas de alto nivel y descomponiéndolas, poniendo estimaciones sobre la descomposición tareas, y luego asignarlas). También reservamos 2 o 3 días para corregir errores y realizar pruebas.
Ya estamos en 5 días allí, por lo que hacer carreras de 2 semanas solo nos dejaría 5 días de I + D. 30 días han sido un gran equilibrio para nosotros hasta ahora.
He trabajado en equipos que realizan sprints de 1, 2 y 4 semanas. Realmente depende de tu organización. Prefiero sprints de 1 o 2 semanas. El equipo actual que estoy ejecutando está en los sprints de 4 semanas porque estamos coordinando esfuerzos de 12 productos diferentes. Estoy buscando moverlos a iteraciones de 2 semanas pronto.
La clave para definir la longitud es llegar a "hecho, hecho". Para algunos equipos, esto significa en producción. Para otros, puede significar que el negocio los verifique para satisfacer sus necesidades utilizando una versión interna. Comenzaría por definir hecho, hecho, y luego mirar cómo estructurar tus sprints alrededor de eso. Idealmente, todas las historias se están haciendo al final del sprint, y no solo estás haciendo Scrummerfall.
Las longitudes de Sprint pueden variar de un proyecto a otro, pero deben permanecer constantes a lo largo del mismo proyecto. Lo mejor que puedes hacer es tratar de encontrar la longitud de sprint más cómoda para tu equipo, he estado usando Scrum durante dos años y ahora nos hemos conformado con veinte sprints de días de trabajo.
Mi experiencia me dice que en los proyectos que necesitan entregas rápidas y una programación relativamente simple (operaciones CRUD, cuadrículas y formularios simples, etc.) es más prudente ir a sprints más cortos, como dos semanas. Para cosas con mayor complejidad (como frameworks) probablemente sea mejor ir a sprints más largos, como sprints de cuatro semanas. Mi proyecto actual se inclina hacia la última opción.
Pero lo importante es elegir la longitud cómoda para el equipo y el propietario del producto.
Me gustan dos semanas. Obliga a una caja de tiempo razonable sobre los problemas pero le permite ver los resultados a un ritmo reforzante. 30 días es para siempre Una semana podría ser fácilmente el ritmo adecuado para un producto en rápido movimiento como un sitio web.
Trabajé en sprints de 1,2,3 y 4 semanas. El sprint de 1 semana es demasiado corto para completar los compromisos del equipo, 2 es ideal, cuando traté de implementar un sprint de 3 o 4 semanas no podemos utilizar el equipo de QA de manera efectiva. (El control de calidad tendrá más tiempo de holgura en la primera semana)