Release: o quão curto e frequente for possível.

Em ambientes de projetos ágeis é comum sermos questionados se o resultado de uma Sprint deve automaticamente se tranformar em uma entrega – algo que vai entrar em produção – ou se podemos aguardar um momento mais apropriado para fazê-lo. A resposta padrão é: uma Sprint gera algo potencialmente entregável, algo que está Done, mas se isso vai entrar em produção ou não, vai depender de como você pretende trabalhar com seus Releases. Neste post pretendo explorar um pouco mais esse tema e deixar minha opinião sobre quando e como trabalhar com Releases.

Em ambientes de projetos ágeis é comum sermos questionados se o resultado de uma Sprint deve automaticamente se tranformar em uma entrega – algo que vai entrar em produção – ou se podemos aguardar um momento mais apropriado para fazê-lo. A resposta padrão é: uma Sprint gera algo potencialmente entregável, algo que está Done, mas se isso vai entrar em produção ou não, vai depender de como você pretende trabalhar com seus Releases. Neste post pretendo explorar um pouco mais esse tema e deixar minha opinião sobre quando e como trabalhar com Releases.

O que é um Release?
Um Release é a representação de uma entrega de produto em produção. Ele é comumente planejado através de um cerimônia chamada Release Planning. Releases são planejados principalmente em ambientes onde estas entregas precisam ter uma data fixa, seja por obrigações contratuais, necessidades de mercado, eventos (conferências, product lauch, etc.) ou – principalmente em ambientes largos – para seguir um roadmap de releases corporativos.

Preciso planejar Releases?
As duas mais comuns situações em que o planejamento de Relase não será necessário:

• Um (ou vários) Release(s) por dia: dependendo do tipo de produto que você desenvolve e de quão maduro seu time é em boas práticas ágeis de engenharia de software, você pode conseguir este estado de nirvana. Release diários ocorrem através de uma boa estrutura de build e deploy para que estes possam ser feitor frequentemente. Aqui a sua definição de Done teria a instrução “Release it!” (ou algo do gênero). Além disso seu time precisaria de um Product Owner trabalhando MUITO próximo a eles e  um Product Backlog com itens realmente pequenos.
  Um case com esta característica que ficou bem popular nos eventos de Agile foi o do Flickr, que publicou conseguir uma média de 10 deploys diários através da coperação entre Dev e Ops.
• Um Release a cada Sprint: este cenário é bastante comum, o time trabalha para que o resultado final da Sprint, aquele que será apresentado no Review, já esteja em produção. Empresas que, por exemplo, liberam uma “nova versão” do produto aos seus clientes a cada mês/quinzena provavelmente trabalharão desta forma. Neste caso a Sprint Planning já será suficiente para enxergar o que o cliente receberá em produção e quando, não precisando assim de um Release Planning.

Planejando Release curtos e frequentes
Se o seu cenário não é semelhante aos dois que eu apresentei acima, provavelmente você precisará planejar Release para poder enxergar além de uma Sprint (mesmo que de forma embaçada) e, assim, planejar entregas em produção para seus clientes. Tenha em mente  que, mesmo planejando além de uma Sprint, trabalhar com Releases curtos e frequentes é mais que uma boa prática em Agile, é quase uma obrigação. Releases curtos e frequentes contam com um tempo de resposta menor para colher feedback do cliente, evitando assim o desenvolvimento de funcionalidades desnecessárias ou com um comportamento diferente do esperado pelo cliente. Além disso o retorno sobre o investimento do cliente é acelerado, já que na maioria das vezes o ROI real só será recebido pelo cliente com o produto em produção.

Lembro que quando comecei a trabalhar com Agile alguém me falou que o tamanho ideal de um Release seria 06 meses, lembro que no mesmo momento pensei “Isso é loucura, acho quase impossível isso acontecer!”. Hoje quando escuto falar em Release deste tamanho penso “6 meses? Não, isto é muito tempo!”. Na verdade o tamanho “ideal” de um Release vai depender diretamente do ambiente corporativo que você está inserido. Se a empresa possui uma política de Releases corporativos onde n produtos precisam “entrar” juntos, bem, você pode precisar de Release de 06 meses, ou até mais. O que sugiro nestes cenários é evitar Release BIG-BANG, ao invés disso lance Releases menores para uma base selecionada de usuários (field-beta testers, por exemplo).

Release Planning Meeting – Agenda
Abaixo segue uma sugestão de algumas práticas comuns que procuro utilizar em reuniões para planejamento de um release. Muito provavelmente parte destas práticas não servirão para você, remova-as e adapte a agenda para que esta gere o resultado e visibilidade que seu ambiente precisa para um Release.

1. Abertura: ScrumMaster revisita o propósito da reunião, sua estrutura, agenda, etc.
2. Visão do Produto e Roadmap: Product Owner revista a Visão do Produto com o propósito de trazer todos novamente para o foco e alinhar expectativas.
3. Status atual do projeto: Product Owner apresenta gráficos e Status Reports onde possam ser visualizados resultado das últimas Sprints e momento atual do projeto.
4. Meta/tema da Release: Product Owner propõe a meta para o Release. Normalmente esta meta é expressa em objetivo de negócio alinhado à data de entrega.
5. Estimativa de velocidade: Time estima sua velocidade para esta Release baseando-se no resultado de Sprints anteriores. Caso esta seja a primeira Sprint de um primeiro Release, sugiro que execute duas ou três Sprints antes de planejar um Release.
6. Agenda da Release e número de Sprints: ScrumMaster facilita um trabalho colaborativo entre Time e Product Owner para enxergar Milestones, definir tamanho de Sprints, etc.
7. Estimativa de itens do Product Backlog: Time estima itens do Product Backlog caso estes não estejam estimados. Só deverão ser estimados uma quantidade de itens suficiente para planejar o Release e, talvez, para deixar uma “sobra”.
8. Mapear itens nas Sprints do Release: seguindo a priorização do Product Owner o Time irá mapear quais itens “cabem” em quais Sprints. Como o Plano de Release será revisto ao fim de cada Sprint, não aconselho tentar encaixar item a item em cada Sprint. Se você está planejando, por exemplo, um Release de 05 Sprints, mapeie itens para as 02 primeiras Sprints apenas, e deixe o restante selecionado sem posicionar na Sprint 03, 04 ou 05.
9. Riscos, dependência e preocupações: de forma colaborativa Time, ScrumMaster e Product Owner trabalham com práticas para identificar riscos, dependências, impedimentos arquiteturais, desafios, etc. Caso necessário será elaborado um plano de riscos, impediments backlog e/ou um simples plano de ação.
10. Comprometimento: ScrumMaster provoca Time e Product Owner para que haja um comprometimento com esta Meta. É importante todos estarem confiantes e entusiasmados com a Meta.
11. Plano de comunicação e logística da Sprint: principalmente em ambientes largos, a comunicação do Release (e consequentemente do projeto) perante a organização não podem falhar. Se necessário montar plano de ação para este trabalho.
12. Montar gráfico(s): montar Release Burndows e/ou Parking Lot e/ou qualquer gráfico que ajude a comunicar o andamento do Release.
13. Retrospectiva: Por fim, como de costume em qualquer cerimônia do Scrum, considero uma boa prática ser feita uma Retrospectiva para avaliar pontos positivos e de melhoria desta reunião.

Muitos me perguntam sobre o tempo que normalmente leva uma Release Planning Meeting. Minha resposta é: não mais que dois dias. Talvez você diga “Dois dias trancados em uma sala fazendo planejamento? Isso é desperdício, um tédio, rg$5sfga!” Bem, tudo depende do quão bom facilitador seu ScrumMaster for. Faço uma analogia destas cerimônias ágeis a um treinamento…dependendo da dinâmica aplicada, do conteúdo e do instrutor, 02 horas podem ser uma tortura – ou 32 horas podem ser extremamente proveitosas e você nem sentir o tempo passar.

Atualizando e revisando o Plano de Release
Por fim é importante ficar claro que o Plano de Release é um artefato vivo e que a cada Review deve ser atualizado, revisado e comunicado pela organização. O Product Owner é o responsável por fazer esta comunicação e, caso tenha sido elaborado uma plano de comunicação, este deverá ser seguido.