5 diretrizes para um planejamento eficaz de releases

Embora a maioria das equipes ágeis costume fazer um pouco de planejamento de releases, muitas vezes sem perceber —por exemplo, equipes Scrum costumam fazer isso nas revisões de sprint—, essa prática é frequentemente deixada de lado. Isso ocorre principalmente porque equipes com diferentes trajetórias ou níveis de experiência não sabem bem como abordá-la ou simplesmente não veem o valor que ela oferece. Mas toda vez que sua equipe conversa sobre quais funcionalidades serão entregues aos usuários em uma próxima versão do produto ou em qualquer versão futura, está fazendo pelo menos um planejamento de releases muito básico.
Se quiséssemos defini-lo de maneira geral, o planejamento de releases é a prática de garantir que o produto em construção evolua na direção certa, conectando sua estratégia —determinar quais resultados desejados queremos alcançar por meio de um ou mais releases— às táticas —equilibrar o trabalho a fazer com restrições como capacidade, prazos e orçamento, permitindo práticas de acompanhamento do progresso—. Isso possibilita tomar decisões informadas sobre o produto, maximizar o aprendizado validado, organizar como entregar mais valor e estabelecer expectativas adequadas.
O planejamento de releases costuma reunir equipes ágeis, partes interessadas e especialistas no assunto, e todos devem colaborar intensamente. Geralmente, um Product Manager ou um Product Owner de Scrum garante a eficácia e os resultados do planejamento. Para facilitar o caminho do PM/PO rumo a um planejamento eficaz e ajudar as equipes a lidar com suas complexidades, reunimos algumas diretrizes importantes:
O planejamento de releases não trata de certezas absolutas, mas de decisões informadas e previsões.
É importante desmistificar a ideia de que o planejamento de releases é uma solução mágica que garantirá que “tudo” seja concluído no prazo. Na verdade, ele não consiste em garantir a conclusão de todo o trabalho previsto no escopo. Trata-se de assegurar que o trabalho seja priorizado adequadamente, que os itens mais valiosos —segundo o PM ou PO— estejam no topo do backlog e que os resultados desejados para cada release sejam alcançados.
Um cenário típico seria uma equipe ter uma data fixa para um grande release em um mês, incluindo muitas funcionalidades documentadas detalhadamente no backlog. E se o PM ou PO disser que quer incluir TODAS essas funcionalidades no próximo release? A equipe pode cumprir esse acordo com confiança? Neste momento, não sabemos, mas, em princípio, tentar fixar prazo e escopo ao mesmo tempo é uma abordagem de alto risco. Faz muito mais sentido ter um prazo fixo e determinar quantas funcionalidades podem ser concluídas dentro dele, ou ter apenas um escopo fixo e determinar uma data aproximada para entregar tudo. Em qualquer caso, muitos fatores estão envolvidos. As equipes ágeis podem recorrer a técnicas e ferramentas baseadas em dados empíricos para elaborar previsões bastante precisas dentro de suas restrições e condições específicas.
Comece pela visão do produto e por como representá-la em um roteiro.
O primeiro grande passo para um planejamento eficaz é estabelecer objetivos claros, específicos e, acima de tudo, mensuráveis. Um quadro de visão do produto bem trabalhado pode ajudar a definir seus objetivos estratégicos, e uma árvore de oportunidades e soluções pode adiantar alguns passos, permitindo estruturar seu trabalho e os problemas a resolver enquanto define resultados-chave mensuráveis. Todos esses objetivos estratégicos concretos podem ser incluídos em um roteiro do produto para orientar seus esforços.
Embora existam várias boas ferramentas para criar roteiros eficazes, gostamos especialmente do roteiro de produto orientado a objetivos (GO), criado por Roman Pichler. Ele reúne os fatores que precisam ser considerados em um formato prático e organizado.
Prepare os elementos para determinar como e quando os objetivos do seu roteiro podem ser cumpridos.
Agora você tem um roteiro estratégico do produto. Já identificou os objetivos de um ou vários releases e tem uma ideia geral das funcionalidades que ajudarão a alcançá-los. Mas, para avançar um passo, será muito útil priorizar os objetivos e as funcionalidades de maneira sensata. Por exemplo, determinar quais são os mais críticos para o sucesso do produto e garantir que seus esforços estejam sempre concentrados em entregar o próximo item mais valioso.
Uma forma prática de fazer essa priorização é, além de priorizar os objetivos, considerar o impacto de não cumprir outras restrições importantes de entrega, como uma data desejada ou um orçamento fixo. Pense assim: o que tem o maior impacto no seu produto?
- Não cumprir totalmente os objetivos propostos?
- Não lançar na data desejada?
- Ultrapassar o orçamento destinado ao release?
Idealmente, você deve tentar manter aberta pelo menos uma dessas três restrições. Assim, estará em uma boa posição para definir prioridades claras.
A razão é bastante simples: embora o ideal seja que uma equipe entregue absolutamente todo o trabalho previsto dentro do prazo exigido e do orçamento, isso raramente acontece. Criar um produto valioso não é um processo linear, e imprevistos surgem pelo caminho. As condições de mercado ou as prioridades podem mudar e afetar nossas suposições.
Use práticas de estimativa que permitam prever o custo de alcançar seus objetivos.
Com uma visão clara do produto e um conjunto de objetivos mensuráveis definidos e priorizados de maneira geral, o próximo grande passo é ter uma ideia aproximada do custo —orçamento real ou alocação de recursos— associado a cada possível release. A melhor maneira de chegar lá? Estimar o trabalho previsto para esses releases. A estimativa é um elemento essencial de um planejamento eficaz. Ela pode trazer uma nova perspectiva sobre as prioridades e ajudar você a reavaliar o que implementar, como e quando, ou até se vale a pena fazer algo.
No início, as estimativas podem se apoiar na colaboração da equipe adequada —especialistas no assunto, arquitetos, especialistas de produto, analistas de negócios e a própria equipe de desenvolvimento— para aproveitar experiências anteriores com esforços semelhantes e elaborar estimativas gerais. As práticas de estimativa também enriquecem o ciclo de aprendizado das equipes de produto, ao revisar suas percepções iniciais sobre a quantidade de trabalho prevista para concluir uma funcionalidade em comparação com o esforço real.
Equipes bem-sucedidas encontram formas eficazes de reutilizar o aprendizado validado dos resultados de releases anteriores para ajustar o horizonte do plano e garantir que todos os fatores contribuam para uma satisfação duradoura dos usuários.
Valide continuamente suas suposições sobre a viabilidade do release com dados empíricos para orientar o progresso.
O planejamento de releases não é um processo que você faz uma vez e depois esquece. Para ser eficaz, exige compromisso com uma abordagem iterativa e incremental. As equipes que aplicam boas práticas de release devem saber que o planejamento acontece em dois níveis diferentes:
No nível da iteração, muito provavelmente durante uma revisão de sprint. Isso ocorre porque, nesse momento, há mais certeza e clareza sobre quais funcionalidades estariam concluídas e poderiam ser lançadas. É importante lembrar que, embora o Scrum defenda a produção de incrementos potencialmente entregáveis ao final de cada sprint, cabe ao Product Owner decidir se o incremento será lançado.
No nível do roteiro, de natureza mais estratégica. Aqui você costuma considerar os resultados de releases anteriores e o aprendizado que trouxeram, enquanto organiza como serão os próximos releases ou se serão necessárias uma ou várias iterações. Como mencionado, são fortemente recomendadas sessões de planejamento do roteiro muito colaborativas, envolvendo todas as partes interessadas e especialistas no assunto.
Também vale mencionar que o Scrum favorece lotes menores e releases mais frequentes em vez de releases grandes e menos frequentes. Isso ocorre porque a complexidade aumenta significativamente à medida que mais funcionalidades são incluídas, além de o aprendizado ser drasticamente desacelerado por um ciclo de feedback mais longo. Uma excelente maneira de acompanhar o progresso é usar gráficos de trabalho restante do release, ou Release Burn-down. Depois, você pode usar esses resultados para alimentar e refinar continuamente o roteiro do produto enquanto avança.
Esperamos que essas diretrizes ofereçam uma estrutura para definir a melhor maneira de planejar releases de forma eficaz para suas equipes. Uma prática disciplinada e fiel aos valores subjacentes pode melhorar seus resultados. Você pode garantir uma abordagem tão segura quanto possível introduzindo apenas as mudanças necessárias de cada vez, para que as equipes as assimilem em sua microcultura como mudanças positivas e duradouras.