Scrum Release do Produto – Planejando a Cadência das Entregas do Produto

 hoje falaremos sobre o processo de geração de Release.  Scrum Release do Produto apresenta a importância do planejamento sobre o mesmo, quem são os responsáveis e os favorecidos da mesma.  Apesar de não ser prescrita oficialmente pelo Scrum, a Release é parte fundamental do sucesso de projetos baseados sobre o mesmo.

Scrum Release do Produto

Vamos iniciar entendendo o conceito de Releases:

O que é a Release do Produto

Scrum Release do Produto é a entrega de um ou mais Incrementos do Produto prontos, gerados pelo Time de Desenvolvimento em um ou mais Sprints sucessivos, para que sejam utilizados.

Projetos com Scrum realizam Releases frequentes, com intervalos máximos de alguns poucos Sprints entre elas.

A realização de Releases ao longo do projeto tem três objetivos principais: obter feedback frequentemente, prover retorno ao investimento dos clientes e dar um senso de progresso a eles.

Obter feedback

Quando pensamos em Scrum Release do Produto devemos sempre levar em consideração que, uma vez realizada a Release, o Product Owner busca, principalmente junto a usuários do produto, impressões e opiniões sobre o que foi recebido e utilizado, e o que se espera da próxima Release.

A partir desse feedback, mudanças serão realizadas no Product Backlog e, assim, o produto é construído incrementalmente;

Prover retorno ao investimento dos clientes

Busca-se realizar Releases frequentemente para usuários finais do produto, pois em cada entrega é gerado um retorno ao investimento realizado pelos clientes do projeto.

No entanto, dependendo de características do produto e de sua estratégia de negócios, pode fazer sentido entregar para quem de fato irá utilizar o produto apenas ao final do projeto ou, ao menos, com pouca frequência.

Produtos de prateleira, por exemplo, em geral não são oferecidos ao público antes do final de seu projeto;

Dar um senso de progresso do projeto

Ao receber uma Release, os clientes do projeto e demais partes interessadas têm visibilidade do estado atual do projeto, isto é, o que já está pronto e o que vislumbram que ainda há a ser feito em direção à Visão do Produto.

A estratégia de Releases do projeto é de inteira responsabilidade do Product Owner, que deve defini-la e, sempre que necessário, modificá-la.

Essa estratégia estabelece, por exemplo, quais dos objetivos entre os descritos acima cada Release busca alcançar, o que inclui a frequência das Releases e quem irá recebê-las.

A estratégia de Releases também garante que as Releases estejam alinhadas com a estratégia de negócios do produto e que sejam tecnicamente viáveis.

Como é a Scrum: Release do Produto

Consideram-se dois pontos essenciais em uma estratégia de Release:

• Quando ou com que frequência serão realizadas;
• Quem irá recebê-las.

Assim, classificamos as Releases de um projeto quanto à frequência e quanto a quem as recebe.

Frequência da Release

Com relação a quando ou com que frequência deverão ser realizadas, as Releases podem ser classificadas em Release por valor, por Sprint, por Item e por Plano.

Por Valor

Dependendo da natureza do negócio, a Release pode ser realizada quando o Product Owner julgar que os Incrementos do Produto já gerados pelo Time deDesenvolvimento nos Sprints representam valor de negócio suficiente para que valha a pena entregá-los para usuários a utilizarem.

Dessa forma, o Time de Desenvolvimento segue gerando Incrementos do Produto prontos Sprint a Sprint até que o Product Owner julgue que o que foi produzido é suficiente para se realizar uma Release.

Por Sprint

Em outros casos, pode fazer sentido realizar uma Release ao final de cada Sprint. Nesse cenário, a reunião de Sprint Planning já é suficiente para que os clientes e demais partes interessadas enxerguem, por meio do Product Owner, o que será recebido e quando.

Assim, o Time de Desenvolvimento trabalha para que o resultado final do Sprint seja imediatamente entregue, dependendo apenas da aprovação do Product Owner ao final do Sprint.

Realizar a Release em cada Sprint é extremamente Ágil, pois antecipa o feedback dos usuários sobre o que foi produzido e maximiza as chances de melhorias no produto.

Por Item

Em um cenário ainda mais Ágil, os itens desenvolvidos pelo Time de Desenvolvimento são entregues durante o próprio Sprint, como parte de sua Definição de Pronto utilizada, o que pode envolver uma aprovação imediata do Product Owner.

Esse tipo de abordagem muitas vezes não é viável e funciona em casos muito específicos, como por exemplo no desenvolvimento de sistemas disponíveis na Internet.

Por Plano

Pode-se, para cada Release, criar um plano de alto nível do que será desenvolvido. Pode-se realizar, nesse caso, uma reunião de Release Planning para cada Release, antes de seu início.

Nessa reunião, é estabelecido o Plano da Release, que contém uma data aproximada para a Release, uma Meta a ser atingida e um conjunto de itens selecionados a partir do alto do Product Backlog.

O progresso em direção à data da Release e, portanto, ao cumprimento da Meta da Release deve ser inspecionado em cada Sprint, e as ferramentas mais utilizadas com esse propósito são o Gráfico de Release Burndown e o Gráfico de Release Burnup.

É comum medir o tamanho da Release pelo número de Sprints que acontecerão até a entrega.

É igualmente comum nesses casos chamar-se também de Release todo o período de trabalho realizado desde o início do primeiro Sprint planejado para a Release até a entrega propriamente dita.

Dizemos, por exemplo:

• Essa Release durará cinco Sprints;
• Estamos trabalhando na quinta Release.

Planejamento da Release

Em projetos que utilizam o Scrum Releases do Produto por plano como parte de sua estratégia de Releases, podem-se realizar as reuniões de Release Planning.

Product Owner e Time de Desenvolvimento, facilitados pelo Scrum Master, encontram-se para criar o Plano da Release, que indica qual o objetivo a ser alcançado pela Release e quando será alcançado.

O Plano da Release

O Plano da Release contém:

• Sua Meta, que é um objetivo de negócios a ser alcançado por meio da entrega;
• A Meta da Release é um passo em direção à Visão do Produto;
• A data exata ou aproximada em que a entrega será realizada;

Um conjunto de itens selecionados do Product Backlog para a Release. Visando se alcançar a Meta da Release, esses itens serão desenvolvidos do mais importante ao menos importante, até se chegar à data da Release.

A abordagem de uso de um Plano de Release somente é viável se o Time de Desenvolvimento atribuir estimativas para os itens do Product Backlog.

Agendamento e duração

Como o Time de Desenvolvimento trabalha continuamente dentro de Sprints, um atrás do outro, não existe um intervalo entre dois Sprints que possa ser utilizado para realização da reunião de Release Planning.

Assim, a Reunião de Planejamento é geralmente realizada durante o último Sprint da Release anterior, preferencialmente perto do seu final.

Ouso desse tempo reduz um pouco o quanto o Time de Desenvolvimento será capaz de produzir nesse último Sprint, e assim pode ser levado em consideração em seu planejamento.

Caso se trate da primeira Release do projeto, em geral a reunião de Release Planning é realizada antes do início dos Sprints, ou seja, antes do início do desenvolvimento do produto.

No entanto, como nesse momento se conhece pouco sobre a capacidade de produção do Time de Desenvolvimento, é também comum esperarem se dois ou três Sprints para se adquirir mais parâmetros, e então realizar o planejamento da primeira Release do projeto.

Alternativamente, alguns times preferem realizar a reunião de Release Planning imediatamente antes da reunião de Sprint Planning do primeiro Sprint da Release a ser planejada.

Não há duração oficial estabelecida para a reunião de Release Planning.  Recomenda-se, no entanto, que se estabeleça um tempo máximo de duração para ela (timebox) e que esse tempo não ultrapasse um dia.

A Reunião

Podemos identificar dois diferentes cenários para uma reunião de Release Planning.  No primeiro cenário, é dada uma data para a Release, mas não se sabe qual a Meta a ser alcançada.

É o caso em que é necessário fazer uma entrega até uma determinada data.

No segundo cenário, é dada uma necessidade de negócios (que será a própria Meta da Release) e pergunta-se quando será possível alcançá-la.

Em ambos cenários, itens suficientes do Product Backlog devem estar estimados para que seja possível realizar o planejamento.

A partir da data da Release, dados um Product Backlog estimado, o tamanho constante do Sprint e a Velocidade do Time de Desenvolvimento, é possível se determinar o resto do plano:

• Um conjunto de itens selecionados do Product Backlog para a Release;
• Meta da Release.

Vamos explicar com um exemplo.

Digamos que o Product Owner estabeleça, a partir de questões de negócios, a necessidade de uma entrega a ser realizada daqui a dois meses.

Digamos também que o tamanho do Sprint utilizado pelo Time de Desenvolvimento seja de duas semanas.

Assim, podemos calcular quantos Sprints serão executados até a data dessa Release:

n. Sprints = (Tempo Total / Tam. do Sprint) = (8 semanas / 2 semanas)

= 4 Sprints

Sabemos, portanto, que quatro Sprints serão executados até a data dessa Release.  Também podemos pode estimar quantos pontos o Time de Desenvolvimento entregará nessa Release:

n. pontos = (Velocidade x n. Sprints) = (30 pontos/Sprint x 4 Sprints)

= 120 pontos

Para determinar o escopo provável da Release, parte-se do topo do Product Backlog e se desce, somando-se as estimativas de cada item dadas pelo Time de Desenvolvimento até se chegar em algo próximo (um pouco mais ou um pouco menos) que esses 120 pontos.

É importante, no entanto, entender que essa extrapolação traz uma previsão de baixa precisão, e assim gera um planejamento que deve ser revisto Sprint a Sprint.

Em outro caso, digamos que, ao invés de fornecer uma data, o Product Owner deseja saber em quanto tempo uma determinada necessidade de negócios poderá ser atendida.

Essa necessidade de negócios é a própria Meta da Release.

Estimativas

Primeiramente, o Product Owner deve garantir que o Product Backlog esteja ordenado e comos itens adequados para atender a essa necessidade.

O Product Owner partirá então do topo do Product Backlog e descerá, somando as estimativas de cada item dadas pelo Time de Desenvolvimento, até considerar que já percorreu os itens necessários para atender a essa necessidade de negócios.

Assim, digamos que a soma dessas estimativas seja 184 pontos.

Se o Time de Desenvolvimento produz, em média, 30 pontos por Sprint (Velocidade), poderemos então estimar em quantos Sprints ele será capaz de queimar esses pontos:

n. Sprints = (n. pontos / Velocidade) = (184 pontos / 30 pontos/Sprint)

= aprox. 6 Sprints

Podemos prever, portanto, que o Time de Desenvolvimento será capaz de queimar esses pontos em seis Sprints (parte inteira), ou seja, daqui a três meses.

É sempre importante lembrar que essa estimativa é de baixa precisão e deve ser revista em cada Sprint.

Granularidade dos itens da release

Como resultado da reunião de Release Planning, um conjunto de itens terá sido selecionado a partir do alto do Product Backlog.

Na realidade, esses itens não são separados do Product Backlog, de forma que não existe um Release Backlog.

Faz-se apenas algum tipo de marcação nos itens que pertencem à Release planejada, como uma etiqueta.

Como são parte do Product Backlog, esses itens prováveis para a Release têm diferentes níveis de granularidade.

Os itens que estão no alto do Product Backlog e que assim, de acordo como plano, serão desenvolvidos nos primeiros Sprints da Release, devem ser menores e representar mais detalhes. Possuem, portanto, granularidade mais fina.

Os itens que supostamente serão desenvolvidos nos Sprints seguintes da Release, por tanto mais abaixo no Product Backlog, serão maiores e mais vagos, com granularidade mais grossa.

À medida que o trabalho de desenvolvimento avança Sprint a Sprint em direção à Release, os itens do alto vão sendo retirados do Product Backlog para desenvolvimento.

Desta forma os itens seguintes que chegam ao alto do Product Backlog serão gradativamente detalhados, refinando-se a sua granularidade.

Escopo da Release

Embora persiga-se uma meta de negócios clara, o escopo da Scrum Release do Produto é aberto. Assim, novos itens irão surgir durante a Release e outros irão desaparecer.

Itens existentes irão evoluir, ganharão mais detalhes, serão divididos em itens menores e serão reordenados.

Os itens menos importantes, resultados dessa evolução, serão relegados a partes mais baixas do Product Backlog.

Assim, ao se atingir a data prevista para a Release, os itens que restarão na lista de itens prevista inicialmente para a Release serão os de menor importância e, assim, há uma maior chance da Meta da Release ter sido alcançada.

É importante destacar que a reunião de Release Planning de forma alguma substitui as reuniões de Sprint Planning.

O escopo de um Sprint futuro da Release está em aberto até que se realize a sua reunião de Sprint Planning, ou seja, conjunto de itens que entrará em cada Sprint Backlog será definido na sua reunião de Sprint Planning respectiva, e não na reunião de Release Planning.

Gráfico Burndown

O gráfico de Burndown demonstra a performance da equipe comparando o que foi planejado ao que foi entregue.

Através desse gráfico, é possível verificar se a equipe está à frente ou atrás do cronograma para que sejam tomadas as medidas necessárias para adaptação, se necessário.

O gráfico possui um eixo X que representa o tempo, que pode ser medido em dias, semanas, Sprints, entre outros.

Enquanto o eixo Y demonstra a entrega planejada, que pode ser em horas de trabalho ou em pontos de histórias.

Este gráfico terá uma linha ideal que representa uma meta de entregas conforme o tempo que irá declinando ao longo do tempo e uma linha que representará a entrega real da equipe.

Quanto mais próxima a linha de entrega estiver próxima à linha ideal, melhor foi o planejamento/execução da equipe.

Quanto mais distante ou com maior variações, significa que houveram problemas durante a Sprint que comprometeram a entrega.

Vejamos alguns exemplos de Burndown e análises que podemos fazer com base nos resultados:

A linha em preto mostra a linha ideal do Burndown, enquanto a linha em vermelho mostra o que foi entregue pela equipe ao longo dos dias.

Na primeira situação, vemos que a linha vermelha não chegou ao zero, o que significa que a equipe não conseguiu entregar o que foi planejado.

Gráfico Burnup

O gráfico de Burnup é apresentado de uma maneira bem próxima ao Burndown.

A diferença é que ele exibe o total que foi planejado e o quanto a equipe já progrediu para alcançar esse objetivo.

Ele é mais utilizado para medir a entrega do projeto como um todo, permitindo prever se a entrega será feita na data estimada.

Assim como no Burndown, o gráfico de Burnup possui um eixo X que representará o tempo (em dias, semanas, etc) e o eixo Y que representará o total do esforço que foi planejado.

Nesse gráfico, a linha ideal se mantém constante enquanto a linha da entrega irá se estender em direção à meta.

Abaixo apresentamos imagens indicando o sucesso e o possível fracasso das Sprints.

Quem recebe a Release do Produto

A Scrum Release do Produto deve idealmente ser realizada para os usuários finais, de forma a se obter feedback sobre os Incrementos do Produto gerados e proporcionar retorno ao investimento para os clientes do projeto.

Quando esse cenário não é possível, a Scrum Release do Produto pode ser feita para um grupo de usuários intermediários ou de usuários selecionados, e assim, no mínimo, garante-se um feedback para reduzir os riscos do projeto.

Em um mesmo projeto pode aparecer, em momentos distintos, qualquer um dos três cenários definidos em seguida, mas uma Release para os usuários finais obrigatoriamente ocorrerá no final do projeto.

Release do Produto para os usuários finais

O Incremento ou Incrementos do Produto são disponibilizados para os usuários finais do produto.

Tendo as funcionalidades que mais necessitam em suas mãos, esses usuários as utilizarão, gerando retorno ao investimento feito pelos clientes do projeto.

Sempre que é possível de ser adotado, esse cenário representa o menor risco, pois Releases frequentes para usuários reais os permitem dar feedback a partir do uso real do produto.

Release do Produto para usuários intermediários

Quando não é possível realizar a Scrum Release do Produto para os usuários finais do produto, um grupo de pessoas pode ser escolhido para representá-los.

Esses usuários intermediários são geralmente selecionados ou na própria organização que gera o produto, ou nos clientes.

Podem ser especialistas no negócio do produto ou em seus usuários finais, especialistas em usabilidade ou quaisquer pessoas capacitadas a utilizar o produto e a verificar o que é necessário para atrair os usuários e satisfazer suas necessidades.

Eles receberão essa Release interna e serão responsáveis por prover feedback sobre o que lhes foi entregue.

Esse cenário é comum nos produtos em que os usuários reais são anônimos e não há sentido ou não é interessante disponibilizar um produto parcial. Exemplos incluem produtos de prateleira e determinados softwares de jogos.

Release do Produto para usuários selecionados

Em produtos comum grande número de usuários, um grupo menor e representativo desses usuários reais pode ser escolhido para receber a Release.

Esse grupo utilizará cada conjunto de Incrementos do Produto entregue com a consciência de que se trata de um produto parcial e será responsável por prover feedback sobre ele.

Em muitos casos, o benefício e estímulo para que continuem usando o produto e provendo feedback é a possibilidade de experimentar o produto antes de todos ou a possibilidade de utilizá-lo de graça, por exemplo.

Os usuários selecionados com esse propósito são geralmente chamados de betatesters, beta-users ou grupos de foco.

Referências

• Rafael Sabbagh – Scrum – Gestão ágil para projetos de sucesso
• http://blog.acelerato.com/agile/graficos-burndown-x-burnup/
• Scrum Product Owner (Published on Mar 28, 2010)
• http://www.slideshare.net/Ridlo/scrum-product-owner

Sobre o autor:

Jefferson Duarte – Gerente de Programas e Projetos na empresa Claro Brasil. Certificaçação PMP®, ITIL® e MCTS® em Microsoft Project. MBA Executivo Internacional em Gerenciamento de Projetos pela FGV e Gestão de Projetos de T.I. pelo IBTA. Pós-Graduado em Tecnologia WEB para Sistemas de Gestão Empresarial. Graduado em Ciências da Computação. Atuação profissional na área de T.I. com Processos e Projetos por mais de 15 anos. E-mail: contato@gp4us.com.br e site: https://www.gp4us.com.br