O que são os planos de entrega?
Delivery Plans é um hub no Azure DevOps que ajuda as organizações a planejar e examinar agendas de trabalho entre várias equipes. A equipe da Tailspin pode usar esse hub para ter uma ideia melhor de como o próprio trabalho está relacionado ao trabalho de outras equipes.
Clara criou um plano de entrega e adicionou os sprints para a sua equipe e para a equipe do mecanismo de jogo. Entusiasmada em exibir o potencial, ela convida Paulo para uma demonstração rápida.
Clara: Após nossa última conversa, analisei nossas opções de gerenciamento de planos de entrega. Encontrei o hub Delivery Plans, que parece nos dar tudo de que precisamos.
Paulo: Estou interessado em ver o que você criou. Há muito estresse em toda a organização quanto à folha beta, portanto, tudo o que pudermos fazer para aprimorar a eficiência da agenda será muito bem-vindo.
Clara: Ok, aqui está. Veja esses ícones vermelhos. Eles indicam que temos alguns problemas com dependências entre itens de trabalho.
Clara: O Delivery Plans nos permite criar um "plano de entrega". Depois de criarmos isso, poderemos adicioná-lo à lista de pendências das equipes na organização. Elas são mostradas em paralelo para que possamos ver o que cada equipe planeja entregar em um pano de fundo de calendário.
Paulo: Esta exibição está ótima! Agora sabemos quando algo de que dependemos não estará disponível a tempo. Podemos até medir a probabilidade de atraso com base na quantidade de trabalho e de dependência que essas equipes assumiram. Isso deve ajudar a mitigar parte do comportamento de "amarelamento de agenda", que às vezes acontece por aqui.
Observação
Amarelamento de agenda é quando duas ou mais equipes correm o risco de não cumprir os prazos, mas nenhuma delas quer admitir. Em vez disso, cada um espera que o outro entregue a agenda primeiro e usa a entrega da outra equipe como pretexto para atrasar a própria entrega.
Clara: Sim e podemos usar isso como uma oportunidade para permitir que outras equipes saibam se formos atrasar algo de que elas dependem. Isso nos ajudará a desenvolver a confiança nas pessoas e nos processos.
Paulo balança a cabeça concordando. Seria bom as equipes terem mais fé umas nas outras.
Paulo: Bem, agora que sabemos sobre a folha beta, precisamos mover nosso trabalho associado para um sprint futuro. Pelo lado positivo, nos dá uma oportunidade de efetuar pull de um novo trabalho para substituí-lo. Vamos trocar o trabalho de integração com esses dois bugs do placar de líderes.
Clara arrasta o item de trabalho de integração para o sprint a seguir. Em seguida, ela arrasta os dois bugs do placar de líderes de volta para preencher a capacidade disponível.
Clara: Também adicionei a data do beta atual como uma etapa. Agora, sempre o colocaremos como ponto de referência para o trabalho que estamos planejando.
Paulo: Também devemos adicionar eventos como o Cliffchella e a festa anual da empresa.
Clara: Por que a festa da empresa? Isso afeta o cronograma?
Paulo: Talvez. Todos os anos, os DBAs entram na competição de comer pizza e todos acabam passando mal e ficando em casa no dia seguinte. Não estou dizendo que devemos esperar que isso aconteça novamente este ano, mas acho que devemos estar preparados. E agora temos as ferramentas para isso.