O que são planos de entrega?
À medida que as organizações de desenvolvimento crescem, elas precisam se reorganizar em equipes menores que podem gerenciar com eficiência as unidades de trabalho particionadas. Normalmente, essas equipes têm os cronogramas de trabalho, os painéis e outros processos que atendem às necessidades exclusivas delas dentro do contexto das metas mais amplas da organização. Ao longo do tempo, as organizações podem descobrir que aproveitam os benefícios da rede consolidando os processos em uma estrutura consistente.
Um plano de entrega é uma visualização de uma ou mais agendas de trabalho. Destina-se a fornecer às equipes e à gerência uma visão geral do que cada equipe planeja produzir e quando. Isso permite a tomada de decisões que otimizam os investimentos em toda a organização.
As equipes devem revisar regularmente os planos de entrega para garantir que a agenda de trabalho esteja alinhada com os agendamentos de outras equipes. Essas análises devem abordar perguntas como:
- Temos certeza de que podemos entregar o que confirmamos na nossa agenda atual?
- Estamos confiantes de que as equipes das quais dependeremos entregarão aquilo de que precisamos na agenda atual delas?
- Há folgas em nossa agenda que poderíamos preencher com trabalho?
- Há problemas com dependências dentro de uma equipe ou entre equipes?
Os planos de entrega agregam valor a qualquer ponto no ciclo de vida de um projeto. Como são gerados dinamicamente com base nas listas de pendências da equipe, eles estão sempre atualizados e oferecem os insights mais recentes.
Vamos acompanhar a discussão da equipe Web da Tailspin.
Paulo: Acabei de fazer uma ótima reunião com o gerenciamento de engenharia. Eu demonstrei o trabalho que estamos fazendo com o Azure Boards, e eles estão empolgados com o potencial de integrar outras equipes.
Clara: Incrível! Quando eles vão começar?
Paulo: Essa é a melhor parte. Eles já têm! Na noite passada, o líder do projeto do mecanismo de jogo criou uma equipe com alguns sprints e começou a adicionar itens de trabalho. Eu dei uma olhada rápida nesta manhã, e ela está indo bem. Deixe-me mostrar o que eles estão fazendo.
Paulo navega para o painel do sprint atual do mecanismo de jogo. Ele e Clara examinam os itens de trabalho com grande interesse.
Paulo: Hum... Acabei de observar que eles não estão planejando implantar o beta no final deste sprint. Não estamos esperando integrar nosso placar de líderes com o banco de dados beta no próximo sprint? Não poderemos fazer isso se eles não enviarem a versão beta primeiro.
Clara: Bem lembrado. Dependemos de essa equipe produzir esse resultado para que possamos produzir um dos nossos.
Paulo: Isso poderia realmente prejudicar nossa produtividade no próximo Sprint. Vou dar uma ligada para eles para descobrir o que está acontecendo.
Infelizmente, estruturas de equipe mais sofisticadas podem resultar em lacunas ou atrasos na comunicação. Quando uma equipe é bloqueada, ela pode não conseguir produzir algo que depende de outra equipe. Isso pode não ser um grande problema para um pequeno grupo de equipes que têm reuniões diárias para todos os interessados. No entanto, à medida que as equipes aumentam e se expandem geograficamente, podem se tornar inviável que todos saibam tudo o que está acontecendo em todos os lugares. É nesse momento que as organizações precisam fazer a transição de um modelo de "push" puro (como anúncios de email ou pessoalmente) para um modelo de "pull" (em que as equipes podem examinar e acompanhar as agendas umas das outras).
Paulo: Certo, acabei de falar com a líder de desenvolvimento. Ela me disse que a equipe está bloqueada no envio do beta até que a equipe de arte retorne de Cliffchella.
Clara: O Festival de Música de Mountaintop?
Paulo: Sim, aparentemente, é um grande evento na comunidade de design e toda a equipe sai de cena por uma semana inteira para participar. A equipe do mecanismo de jogo está muito aborrecida, pois adiou a agenda em três semanas. Se soubesse o que estava por vir, teria obtido os artefatos necessários com antecedência. Eles também pediram desculpas por não nos informarem antes. Eles não perceberam que estaríamos esperando a versão beta deles para enviar nossa parte.
Clara: Bem, pelo menos, podemos ficar felizes porque a equipe do mecanismo de jogos vai publicar os planos do sprint. Isso nos ajudou a encontrar esse problema de dependência cedo o suficiente para ajustar nossa agenda.
Paulo: Eu queria apenas que houvesse uma forma de prever esses riscos potenciais com mais facilidade. Nossas equipes têm tantas dependências de toda a empresa que não há como participarmos de todas as reuniões e assinarmos todos os grupos de distribuição.
Clara: Devemos criar um plano de entrega para que possamos ver os sprints da equipe lado a lado. Isso ajudará as duas equipes a identificar com mais facilidade como nossas agendas afetam uma à outra.
Recomendações para gerenciar várias equipes Agile
Uma abordagem Agile, juntamente com o Azure DevOps, pode aprimorar substancialmente a transparência e a previsibilidade de projetos. No entanto, os projetos ainda podem encontrar desafios tradicionais, geralmente relacionados ao pessoal ou a uma comunicação inadequada. Aqui estão alguns aspectos a serem considerados ao dimensionar seus esforços Agile.
Criar confiança em suas pessoas e processos
Os detratores iniciais das implementações Agile geralmente duvidam da própria capacidade de aprimorar o desempenho da equipe. É importante que os líderes de opinião da organização criem confiança ilustrando como as ferramentas e os processos produzem resultados. Às vezes, esses resultados são aprimoramentos de produtividade, e isso é fácil de quantificar. No entanto, não se esqueça de realçar os ganhos da equipe que ocorrem ao contornar possíveis problemas, como desvios de agenda evitáveis ou problemas de qualidade. À medida que as pessoas começam a associar os benefícios ao processo que possibilitou alcançá-los, você conseguirá mais entusiasmo.
Eleve a organização acima da equipe (e dos indivíduos)
Algumas equipes e indivíduos se tornam territoriais quando novos processos ou políticas são propostos. Em vez de enquadrar novas políticas como expondo negativamente o desempenho de equipes ou pessoas específicas, realce como a nova transparência na organização informa as expectativas a todos. Ter um só lugar em que qualquer pessoa possa acompanhar como o trabalho se relaciona à organização atingir as metas deixará clara a importância do compromisso da pessoa com o processo.
Estimular uma cultura de transparência
Infelizmente, o termo "transparência" tem uma má reputação. Ninguém pede mais transparência quando tudo está indo bem. Em vez disso, a transparência (ou a falta dela) geralmente é culpada quando as equipes estão com dificuldades. Mesmo com todas as oportunidades de transparência proporcionadas pelas equipes Agile, ela ainda está sujeita à honestidade das pessoas e das equipes. Enfatize que uma das razões para a transparência é poder identificar e resolver possíveis problemas antes que seja tarde demais. Todos compreendem que às vezes as pessoas encontram circunstâncias que as impedem de cumprir aos prazos da agenda. Porém, se elas não se sentirem seguras em dar notícias decepcionantes até o último momento possível, isso poderá causar um impacto muito mais destrutivo. Criar um nível de conforto com a transparência pode começar com agradecer as pessoas por relatarem atrasos esperados o quanto antes.