Num projeto de desenvolvimento de software, falar de release significa falar sobre a entrega do produto. Ou melhor, de parte dele.

O processo de produção de software é uma espécie de investimento realizado pelo cliente. Este investe os seus recursos e cria uma expectativa de recebimento de retorno de qualidade em determinado prazo.

O Scrum procura valorizar o produto em desenvolvimento, de forma que ele possa atender, ao máximo, as expectativas do PO. Por esse motivo, é importante que cada release tenha uma duração curta, como por exemplo duas ou três semanas.

A prática de releases curtos, liberando frequentemente uma nova versão do sistema em produção, costuma ser vista com bons olhos pelo cliente. Afinal, “clientes gostam de entregas rápidas” e uma entrega rápida confere maior flexibilidade no desenvolvimento de software.

As releases costumam ser feitas no final de uma Sprint. Como já foi mencionado em posts anteriores do blog scrumhalf, no Scrum cada Sprint constitui um ciclo completo de desenvolvimento, sendo iniciado com a reunião de planejamento e finalizado com a entrega de uma release, juntamente com a reunião de retrospectiva. Durante as reuniões que envolvem a participação do PO, é possível receber dele um feedback sobre as funcionalidades que foram desenvolvidas durante a Sprint. Ou seja, releases curtos significa mais feedback, que por sua vez significa uma maior confiabilidade de que as funcionalidades que estão sendo desenvolvidas estão de acordo com o desejo do PO.

Ao trabalhar com releases curtos a equipe procura assegurar que os primeiros releases gerem a maior parte do valor do sistema. A priorização das histórias, realizada durante a fase de planejamento, garante que as funcionalidades com maior valor para o projeto sejam implementadas primeiro.

Olhando pelo lado do cliente, a prática de releases curtos funciona como uma estratégia de gestão de risco. O PO acompanha de perto o processo de desenvolvimento e consegue notar a evolução do projeto em intervalos pequenos de tempo, assim ele pode decidir cedo (quando ainda não gastou muito) se o projeto deve ou não continuar, dependendo do cumprimento de sua expectativa.

Até o próximo post!