Escritório de Projetos

O maior e melhor conteúdo gratuito de gerenciamento de projetos do Brasil

Uma vez que o time esteja definido e com cada um dos três papéis devidamente representados (Scrum Master, Product Owner e Time de Desenvolvimento), é hora de estudarmos como que a dinâmica de desenvolvimento iterativo-incremental acontece dentro de times utilizando o Scrum.

O coração do Scrum é a sprint. Uma sprint é um período que varia de duas a quatro semanas durante o qual o time desenvolve um Incremento de software potencialmente entregável, com o objetivo principal de entregar valor ao cliente o mais rápido possível. Enquanto um projeto pode necessitar de várias sprints para serem entregues, ao invés de seguir o modelo Waterfall de entregar tudo de uma vez só no final do projeto, no Scrum entregamos uma parte do que o cliente precisa ao final de cada sprint, permitindo que o cliente valide ou até mesmo use o software em uma velocidade maior que a habitual.

A figura abaixo mostra o desenrolar de uma sprint a partir do Product Backlog, que é o artefato que contém os requisitos do software a ser desenvolvido (que falarei em mais detalhes em outro artigo), culminando no software entregável.

 

Cerimonias do ScrumDurante uma sprint acontecem uma série de cerimônias, responsáveis por garantir a transparência (geralmente através da comunicação, mas também envolvendo artefatos) e proporcionar momentos de inspeção e adaptação tal qual pregam os pilares do Scrum. Estas cerimônias são: a Sprint Planning, a Daily Meeting, a Sprint Review e a Sprint Retrospective.

Na Sprint Planning o Product Owner apresenta o Product Backlog priorizado, explicando ao time quais são os objetivos de curto prazo do projeto e o que eles deveriam entregar primeiro para gerar valor ao cliente o mais rápido possível. Em cima dessas explicações, o Time de Desenvolvimento detalha os itens mais prioritários que estarão especificados a nível de negócio, em nível técnico, que permita com que eles consigam gerar estimativas de tempo e facilitar seu desenvolvimento posterior. Quando as estimativas do time parecerem preencher todo o tempo que terão de desenvolvimento na sprint, o time fecha o escopo, apresenta ao Product Owner e não havendo objeções, o desenvolvimento começa. O Scrum Master é o responsável por garantir e geralmente conduzir esta cerimônia, fazendo com que as responsabilidades entre "porcos e frangos" seja respeitada (conforme expliquei no último artigo).

Da Sprint Planning até a entrega vários dias vão passar e, para que o alinhamento não se perca ao longo da sprint, o Scrum Master deve garantir que diariamente o time se reúna para conversar brevemente, por até 15 minutos, sobre o que cada um está fazendo em prol do objetivo da sprint e se tem algo o impedindo de avançar. Os impedimentos levantados nesta cerimônia devem ser a prioridade do Scrum Master, enquanto que um desvio do objetivo pode ser consertado fácil e rapidamente pelo Product Owner. Essa reunião é chamada de Daily Meeting ou Daily Scrum, e acontece em pé para que termine rapidamente.

Ao término do período da sprint, no último dia, acontece a Sprint Review. A Review é uma cerimônia de prestação de contas, onde o time apresenta os avanços desta sprint para o Product Owner e demais stakeholders do projeto. Nessa apresentação o time irá receber feedback que corrigirá qualquer desvio de curso ou comumente também irá gerar melhorias no projeto não previstas inicialmente na planning, o que torna o Scrum um excelente método para produtos inovadores e complexos, pois o time ajusta-se constantemente às mudanças.

Após a Review (cerimônia de inspeção), é hora da Sprint Retrospective, a cerimônia de adaptação do processo de desenvolvimento do time, promovendo a melhoria contínua. Aqui o time irá discutir pontos bons e ruins que aconteceram na última sprint no que tange pessoas, práticas, ferramentas e tudo mais que vier à sua cabeça e que tenha margem para melhora. Diversas são as dinâmicas que o Scrum Master pode usar para conduzir esta cerimônia, mas todas elas culminarão em melhorias no processo ao final.

Terminando uma sprint, outra começa, em um ciclo virtuoso até que o projeto seja finalizado.

Nem sempre é possível entregar software funcionando em produção a cada sprint, mas esta mentalidade deve ser sempre perseguida pois apenas o software em produção gera realmente valor para o cliente. A entrega constante de software funcionando em pequenas entregas é que dá a sensação de velocidade de métodos ágeis como Scrum, mesmo que o time desenvolva na mesma velocidade de codificação de sempre.

No próximo artigo falaremos mais dos artefatos que auxiliam os times na condução do dia a dia do Scrum.

 

 

 

Sobre o Autor

 

luizfernandoduartejunior

Agile Coach no Agibank, autor do blog LuizTools e programador nas horas vagas.

Autor dos livros:

 

 

 

 

 

Login

Faça a diferença nos projetos

Adquira o livro acima por R$9,99 e saiba como