Qualquer gerente de produto que tenha entregue um produto com sucesso a um cliente sabe o quão incrivelmente importante é o Planeamento de Release. Apesar de sua importância, o Scrum Guide, publicado a partir de 2011 por Ken Schwaber e Jeff Sutherland, removeu qualquer discussão sobre o Release Planning e o gráfico Release Burndown relacionado. Os formadores profissionais de Scrum Ralph Jocham e Henk Jan Huizer explicam essas mudanças:
Por que remover itens do Scrum Guide?
O Guia do Scrum, o conjunto de conhecimentos para o Scrum, cresceu ao longo dos anos para abordar a gama crescente de perguntas que as pessoas têm sobre o uso bem-sucedido do Scrum. Na recente atualização do Scrum Guide, Ken e Jeff decidiram remover a maioria das dicas e estratégias e manter apenas as regras básicas pelas quais o Scrum deve ser executado. Pode parecer uma escolha estranha, pois ainda existem milhares de perguntas em potencial sobre como usar o Scrum.
Mas há uma boa razão para a remoção de estratégias e dicas de implementação. Simon Sinek argumenta que se deve sempre começar com o ” Por quê ” e só depois passar para o ” Como” para finalmente terminar com o ” O quê “. A versão anterior do Scrum Guide descreveu muito sobre o que deve ser feito. No entanto, descrevendo o que fecha a porta em abordagens alternativas e possivelmente melhores. Por outro lado, descrever o Por que leva as pessoas a pensar por si mesmas sobre como aplicar os conceitos em seu próprio contexto único. Removendo grande parte do que O Guia do Scrum também evita comportamentos de copiar / colar, seguindo cegamente as regras, sem entendê-las, apenas porque foi bem-sucedido em outra situação; criando assim um culto à carga .
Este artigo se concentra na remoção do Release Planning e Release Burndown do Scrum Guide.
Por que temos o Planejamento de Release?
Na indústria de software, os produtos geralmente são entregues aos clientes em releases oficiais. Podem ser grandes lançamentos únicos no final de um projeto ou mais lançamentos incrementais em um ciclo trimestral ou anual, no caso de desenvolvimento de produto. Embora as versões sejam comuns, elas estão em conformidade com os pontos fracos do desenvolvimento de software e não alavancam o processo incremental e iterativo de uma estrutura Agile como Scrum. Quando o Scrum é usado bem, um valor potencial é criado com cada Sprint. Mas se o incremento não for liberado em cada Sprint, não estamos a entregar esse valor aos nossos clientes. Buscamos ativamente o feedback dos usuários. Por que não facilitamos ao liberar o incremento do Sprint para o Sprint?
A prática das versões de software existe porque nem sempre é prático entregar constantemente o que está sendo construído. O Scrum exige que um incremento de produto no final de um Sprint seja potencialmente utilizável . Isso não significa que seja necessariamente útil . Portanto, muitas vezes é necessário agrupar Incrementos utilizáveis dos Sprints subseqüentes em algo potencialmente útil para um cliente.
Infelizmente, algumas organizações usam lançamentos para compensar as práticas inadequadas de desenvolvimento. Um incremento utilizável é aquele sem trabalho “desfeito” associado a ele no final de um Sprint. Se as equipes não conseguirem criar Incrementos realmente utilizáveis, o trabalho restante (teste, documentação, aceitação do usuário etc.) será feito como parte do processo de liberação – às vezes chamado de fase de estabilização . Nesse caso, o plano de liberação codifica a aceitação das práticas inadequadas de desenvolvimento e torna incrivelmente difícil para um Dono do produto planejar efetivamente quando uma liberação ocorrerá.
No entanto, mesmo que uma versão seja construída com Incrementos utilizáveis e seja potencialmente útil para um cliente, muitas coisas precisam ocorrer para que um cliente realmente obtenha valor com isso. Esse processo de integração de uma liberação para extrair valor é chamado de absorção.
Para absorver prontamente uma liberação, os clientes podem precisar passar por extensas instalações, testes, pilotos, lançamentos, treinamento, certificação e uma série de outros processos antes que a liberação possa criar valor. Estar ciente e realmente planejar essas atividades que precisam ser realizadas para ajudar os clientes a extrair valor é o motivo pelo qual o planejamento de liberação é realizado. Essa é a razão pela qual o Scrum Guide anterior incluía o planejamento de lançamentos.
Por que temos Burndowns de Release?
Scrum é uma estrutura empírica construída sobre os três pilares da transparência, inspeção e adaptação. Para nos adaptarmos, precisamos inspecionar, e para inspecionar precisamos de transparência. Usamos uma burndown porque fornece transparência sobre como estamos indo em um determinado período de tempo. Ele permite respostas rápidas a perguntas como: “Estamos no caminho certo, estamos à frente ou estamos muito atrasados?”
O Scrum é usado em ambientes complexos, como desenvolvimento de produtos, onde as circunstâncias mudam diariamente. Os requisitos mudam, os desafios técnicos são encontrados com frequência e o ambiente organizacional muda ainda mais. O Scrum aceita que as mudanças fazem parte do processo de desenvolvimento de software complexo e as abraça. Para lidar com as mudanças, precisamos de informações atualizadas precisas.
O burndown de liberação fornece exatamente essas informações para um objetivo de liberação. A oportunidade de inspeção permitida pela liberação da liberação fornece a preciosa capacidade de adaptação imediata quando as alterações são realizadas. Isso dá à equipe do Scrum a chance de fazer perguntas difíceis mais cedo, em vez de esperar até a semana anterior à data de lançamento planejada.
Por que o Release Planning foi removido do Scrum Guide?
A resposta é curta e simples: é possível usar o Scrum com sucesso sem usar o planejamento de liberação. Não precisar de planejamento de liberação pode realmente ser um indicador positivo da saúde de um produto. O Scrum tem como objetivo agregar valor aos clientes continuamente por meio de iterações curtas. O uso de releases pode realmente atrasar a entrega de valor, o feedback do cliente e o retorno do investimento (ROI). Com práticas de desenvolvimento maduras e excelentes estratégias de lançamento, a entrega de valor pode ocorrer em cada Sprint.
O Planejamento de Release não é mais permitido no Scrum?
O planejamento de liberação ainda é incrivelmente valioso em muitos casos. Muitas vezes, é difícil fornecer uma solução comercial complexa no curto espaço de tempo de um único Sprint. Às vezes, são necessários longos períodos de teste para atender a rigorosos requisitos de qualidade. Às vezes, grandes empresas exigem alterações na infraestrutura. E, às vezes, os clientes não gostam de lançamentos frequentes porque, na verdade, criam mais dor do que valor. Nesses cenários, o planejamento de lançamentos é uma atividade valiosa, uma maneira de elaborar um plano, um roteiro do que pode ser esperado após alguns sprints e o que fará parte do lançamento e o que não será.
Por que o Release Burndown foi removido do Scrum Guide?
Como o Scrum não requer mais planejamento de liberação, não faz sentido exigir uma burndown de liberação. O Scrum se esforça para tornar transparente o processo de desenvolvimento e entrega de software. Um burndown pode ser incrivelmente útil para apoiar isso. Mas, pode haver outras maneiras de alcançar esse mesmo objetivo. Ao remover as diretrizes sobre o que fazer, o Scrum pode se beneficiar de inovações futuras.
O Guia Scrum de 2011 retorna às suas raízes. Menos pode ser mais! Mas não se deixe enganar por 16 páginas de regras; o jogo do Scrum é simples de entender, mas difícil de dominar.
De Scrum.org