Proyecto de cierres en Scrum

En un entorno de desarrollo de software típico, los cierres de proyectos marcan el final de un proyecto.

1. Los registros del proyecto se completan y archivan,
2. recursos liberados,
3. los problemas y las lecciones están documentados, y
4. Una cena / fiesta formal celebrada para la celebración.

El último paso es opcional, aunque es muy motivador para los participantes. :-)

Contrasta esto con Scrum. Sé que scrum se ejecuta en historias de atrasos . Entonces, técnicamente, cada iteración cierra ciertas historias. Entonces, hay dos preguntas aquí.

1. Para un grupo que trabaja en múltiples proyectos simultáneos , ¿cómo encajan los cierres de proyectos?
2. Para un proyecto que involucra múltiples grupos , ¿cómo se aplica este concepto?

¿O el plazo de cierre del proyecto no se aplica a los proyectos de T&M ?

Para un grupo que trabaja en múltiples proyectos simultáneos, ¿cómo encajan los cierres de proyectos?

Primero, "múltiples proyectos simultáneos" se considera una muy mala idea. El punto de scrum es correr y terminar. Cambiar de proyecto para comenzar otro sprint es disruptivo. Hacer dos proyectos a la vez no es un sprint. Es un desastre.

Sin embargo, Scrum no es diferente de un método no ágil (cascada). Cuando el trabajo atrasado se reduce a aproximadamente cero, aún está listo. Tan hecho como si tuviera un enfoque de cascada en lugar de un enfoque ágil.

A veces, la cartera de pedidos no es cero, pero el cliente está encantado y no quiere más. Así que ya terminaste. Por lo general, se hace antes y es más barato que una cascada (que tiene que construir todo, incluso las ideas que resultaron inútiles).

Para un proyecto que involucra múltiples grupos, ¿cómo se aplica este concepto?

Igual que un proyecto sin scrum con múltiples grupos. Nada cambia sobre la gente. Todavía les gusta una buena fiesta.

¿O el plazo de cierre del proyecto no se aplica a los proyectos de T&M?

¿Por qué la facturación cambiaría algo sobre la naturaleza del trabajo o la ceremonia al final?

Por lo general, veo métodos ágiles como prácticas scrum dentro de un marco de gestión de proyectos más estructurado. Esto no es una contradicción en absoluto. Agile trabaja para la entrega, su objetivo es entregar el software adecuado más rápido. Ayuda con las interacciones entre los desarrolladores y las partes interesadas. Se puede usar como parte de un programa de período fijo o para mejoras abiertas.

Entonces, con eso en mente, no hay ninguna razón por la cual el resto de la administración del proyecto no se pueda administrar de manera tradicional, ya que un PM administra la línea de tiempo, los costos y otras dependencias. Al finalizar, tiene sus eventos de cierre como de costumbre.

Trabajo en finanzas, a veces ocurren nuevas regulaciones, o aparece un nuevo intercambio y tenemos una fecha de inicio para lo que está escrito en piedra. Todavía utilizamos un método ágil para la entrega, pero dentro de un marco de gestión de proyectos más tradicional, por lo que lo entregamos a tiempo.

La estimación de las unidades de trabajo y la selección de una solución que se pueda lograr en el marco de tiempo disponible es lo que nos hace buenos desarrolladores (una de las cosas que debo decir).

En Scrum, como en todas las técnicas ágiles, los proyectos son cosas menores que van y vienen, mientras el equipo se mantiene unido. Por lo tanto, no existe un ritual de "proyecto-clojure" como tal. Más bien, el proyecto disminuye mientras que otro crece. El flujo de elementos acumulados gradualmente cambia de uno a otro. El equipo apenas sabe la diferencia.

De hecho, el equipo puede estar trabajando en dos o tres proyectos diferentes al mismo tiempo. De nuevo, apenas saben la diferencia. Los elementos acumulados ingresan al equipo al comienzo de cada sprint, y el equipo los implementa. Todos pueden pertenecer a un proyecto, o pueden dividirse equitativamente entre varios. Al equipo no le importa. El equipo solo implementa los elementos de la cartera de pedidos que se les dan.

Si la empresa necesita cambiar la prioridad de los proyectos, simplemente cambian el flujo de los elementos atrasados ​​en los equipos.

Algunas de las cosas que está discutiendo aquí serían subsumidas por la mayoría de los procesos ágiles, con cosas como documentación y lanzamientos que ocurren con frecuencia como una cuestión de rutina, en lugar de esperar algún desencadenante externo. Ese no siempre será el caso, por supuesto, dependiendo de qué tipo de clientes tenga y en qué tipo de negocio se encuentre. Por ejemplo, si está creando una sola parte de un sistema más grande propiedad de una entidad externa, generalmente hay una fecha que impulsa el proceso, y esa fecha sería un momento apropiado para realizar tareas adicionales de limpieza y, por supuesto, fiesta. Otras veces, incluso cuando el cliente es interno, la empresa aún puede reconocer la finalización de un hito comercial / entrega importante / otro que nuevamente exige la finalización de la contabilidad / fiesta del proyecto. Si su empresa se dedica a la planificación del lanzamiento, eso le dará puntos de interrupción naturales, pero incluso si no lo hace, es perfectamente apropiado tener medidas de éxito impulsadas por el negocio. Es decir, es posible que los proyectos ya no sean una característica de su proceso de ingeniería, pero ciertamente pueden ser parte de su negocio y celebrar y tratar con ellos puede y debe ser parte de la cultura de su empresa.