¿Qué son los planes de entrega?
Los planes de entrega son un hub de Azure DevOps que ayuda a las organizaciones a planear y revisar las programaciones de trabajo en varios equipos. El equipo de Tailspin usará este concentrador para tener una idea más clara de cómo se relaciona su trabajo con el trabajo que pueden producir otros equipos.
Mara creó un plan de entrega y agregó los sprints de su equipo y del equipo del motor de juegos. Entusiasmada por mostrar el potencial, invita a Andy a una demostración rápida.
Mara: Después de nuestra última conversación, he examinado nuestras opciones para administrar los planes de entrega. He encontrado el hub de planes de entrega que parece darnos todo lo que necesitamos.
Andy: Me interesa ver qué se le ha ocurrido. Hay mucho estrés en la organización por la versión beta, así que cualquier cosa que podamos hacer para mejorar la eficacia de la programación será bienvenido.
Mara: Bien, aquí está. Mirad esos 
iconos rojos. Indican que tenemos algunos problemas con las dependencias entre los elementos de trabajo.
Mara: Los planes de entrega nos permiten crear un "plan de entrega". Una vez creado, podemos agregar los trabajos pendientes de los equipos de la organización. Se muestran en paralelo para poder ver lo que cada equipo planea ofrecer sobre un fondo de calendario.
Andy: ¡Esta vista es genial! Ahora sabemos cuándo algo de lo que dependemos no estará disponible a tiempo. Incluso podemos calibrar la probabilidad de que se produzcan retrasos en función de la cantidad de trabajo y de las dependencias que hayan asumido esos equipos. Esto debería ayudar a mitigar algunos de los comportamientos de tipo "programación cobarde" (schedule chicken) que a veces se dan aquí.
Nota:
Schedule chicken es cuando dos o más equipos corren el riesgo de no cumplir los plazos, pero ninguno de ellos lo quiere admitir. Cada uno espera a que el otro tenga un desfase en su programación primero y, luego, usa el desfase del otro equipo como pretexto para retrasar su propia entrega.
Mara: Sí, y también podemos aprovecharlo como una oportunidad para que otros equipos sepan si vamos a tener un desliz de algo de lo que dependen. Nos ayudará a crear confianza en nuestro personal y nuestros procesos.
Andy asiente para mostrar su acuerdo. Sería bueno que los equipos tuvieran más fe en los demás.
Andy: Bueno, ahora que sabemos del desfase de la versión beta, tenemos que trasladar nuestro trabajo asociado a un sprint futuro. El lado positivo es que nos da la oportunidad de hacer un trabajo nuevo para reemplazarlo. Intercambiemos el trabajo de integración con esos dos errores de la tabla de clasificación.
Mara arrastra el elemento de trabajo de integración hasta el sprint siguiente. A continuación, vuelve a arrastrar los dos errores de la tabla de clasificación para rellenar la capacidad disponible.
Mara: También he agregado la fecha de la versión beta actual como hito. Ahora lo tendremos siempre como punto de referencia para el trabajo que estamos planeando.
Andy: También debemos agregar eventos como Cliffchella y la fiesta anual de la compañía.
Mara: ¿Por qué la fiesta de la compañía? ¿Eso afecta a la programación?
Andy: Podría ser. Todos los años, los DBA se presentan al concurso de comer tartas y todos acaban llamando al día siguiente para decir que están enfermos. No digo que tengamos que esperar que se repita este año, pero creo que deberíamos estar preparados. Y ahora tenemos las herramientas necesarias para ello.