Apresentação do Scrum

Como tudo começou

Durante muito tempo, empresas de desenvolvimento de software conviveram com uma série de problemas relacionados ao gerenciamento de projetos, como prazos não cumpridos, custos estourados, baixa qualidade nos recursos entregues para o cliente e, consequentemente, descrédito por parte do cliente em relação às equipes de desenvolvimento.

O manifesto ágil

Diante desse cenário, um grupo de profissionais veteranos no desenvolvimento de software se reuniu e, em 2001, criou o Manifesto para o Desenvolvimento Ágil de Software (frequentemente chamado apenas de Manifesto Ágil), que compilava um conjunto de princípios que, de acordo com a experiência de todos, sempre pareciam ter sido respeitados quando um projeto de software alcançava o sucesso.

O Scrum

Dentre os profissionais que criaram o manifesto ágil, estavam Ken Schwaber e Jeff Sutherland que desenvolveram o Scrum. São eles também quem escrevem e fornecem o Guia do Scrum.

Segundo os autores, o Scrum “é um framework para desenvolver e manter produtos complexos”.

O Scrum trabalha com ciclos curtos de desenvolvimento e entrega de software. Dessa maneira, o feedback sobre o resultado é obtido rapidamente, o que garante a qualidade do produto e a satisfação do cliente, que passa a fazer parte do processo e a perceber os resultados rapidamente.

O Scrum se apoia em 3 pilares fundamentais: Transparência, Inspeção e Adaptação.

Transparência

Todos os responsáveis pelo resultado devem ter a visão de tudo o que está acontecendo, além de um mesmo entendimento do que está sendo visto.

Inspeção

Os artefatos e o progresso em direção ao objetivo devem ser inspecionados frequentemente por todos os usuários do Scrum, de maneira a detectar desvios indesejáveis.

Adaptação

As coisas mudam. O Scrum aceita essa verdade e prega a adaptação a mudanças no lugar de tentar evitá-las. Trabalhando com ciclos curtos, as mudanças são melhor aceitas e menos dolorosas, uma vez que não existem planos extensos que deverão ser mudados para adequar-se a elas.

Papéis

Um time Scrum apresenta 3 papéis distintos, que serão melhor explicados a seguir: Scrum Master, Product Owner e Time de Desenvolvimento.

Scrum Master

O Scrum Master ou SM é o Mestre do time Scrum. No entanto, ele não é um gerente ou coisa que o valha, uma vez que o time Scrum é autogerenciável.

As principais tarefas do Scrum Master são:

• Garantir que os membros do time entendam e apliquem as regras do Scrum;
• Remover todos os impedimentos que possam atrapalhar o bom andamento do time;
• Realizar o treinamento de pessoas / equipes que não sejam familiarizadas com o Scrum;
• Ser o facilitador de todos os eventos do Scrum.

O Scrum Master deve ser uma pessoa capaz de inspirar os demais membros do time a serem autogerenciáveis e interdisciplinares, além de mostrar a importância dos valores ágeis. Deve ser uma pessoa com influência na organização e apoio da alta gerência, uma vez que caberá a ele resolver os impedimentos.

Product Owner

O Product Owner ou PO representa o cliente dentro do time Scrum. É sabido que um alto grau de envolvimento do cliente representa mais assertividade nos resultados. No entanto, normalmente o cliente não pode estar disponível para o Time de Desenvolvimento toda vez que seja necessário tirar uma dúvida ou validar um requisito, por exemplo. Por isso esse papel no Scrum cabe ao Product Owner.

O Product Owner é o responsável por priorizar os requisitos a serem desenvolvidos, aceitar os requisitos entregues e fazer a interface entre o Time de Desenvolvimento e o cliente.

O foco do Product Owner é maximizar o valor do produto entregue, visando sempre o desenvolvimento dos requisitos mais importantes para o negócio.

As principais tarefas do Product Owner são:

• Manter o Product Backlog;
• Aceitar ou rejeitar o trabalho realizado pelo Time de Desenvolvimento;
• Priorizar os requisitos a serem implementados;
• Estar presente para auxiliar o Time de Desenvolvimento durante a execução do trabalho;
• Auxiliar o cliente na descoberta de novos requisitos;
• Ser o centralizador de demandas que chegarão ao Time de Desenvolvimento;

Caso o Product Owner não possua alguma informação necessária, é papel dele realizar esse levantamento junto ao cliente.

Time de Desenvolvimento

O Time de Desenvolvimento é composto por todos os responsáveis pelo desenvolvimento dos requisitos (programadores, testers, DBA's, etc.). Dentro do time, independente de seu cargo na organização, todos são conhecidos como Desenvolvedor.

O Time de Desenvolvimento é auto gerenciável, ou seja, ninguém pode dizer ao time o que fazer, exceto o próprio time.

De acordo com o Guia do Scrum, o Time de Desenvolvimento idealmente deve ter entre 3 e 9 membros.

Artefatos

O Scrum possui alguns artefatos definidos que têm como principal objetivo possibilitar a sustentação dos três pilares do Scrum durante o trabalho, fornecendo transparência e oportunidades para inspeção e adaptação durante todo o processo.

A seguir, uma definição dos artefatos definidos no Guia do Scrum

Product Backlog

É uma lista priorizada de todos os requisitos necessários no produto.

O Product Backlog é a origem única de todos os requisitos para qualquer mudança a ser feita no produto, e é mantido pelo Product Owner.

Os primeiros itens do Product Backlog, que são os prioritários, serão os primeiros a serem desenvolvidos. Por isso, precisam estar em um nível tal de detalhe que possibilite o seu entendimento por todos os envolvidos.

Já os itens menos imediatos têm um nível de detalhe menor, uma vez que não serão desenvolvidos imediatamente.

A medida que um item vai subindo no backlog, seu nível de detalhe aumenta.

O Product Backlog nunca está pronto. Uma vez que o Scrum aceita as mudanças, a cada ciclo de desenvolvimento, novos requisitos são descobertos, e esses devem ser incluídos no backlog de acordo com sua prioridade.

Da mesma maneira, durante o ciclo de vida de um produto pode-se perceber que determinados itens do backlog deixaram de fazer sentido, não sendo mais necessários. Esses itens devem ser removidos do Product Backlog tão logo se perceba essa necessidade.

Sprint Backlog

É uma lista priorizada de tudo que será desenvolvido na Sprint atual.

Durante toda a Sprint, o Time de Desenvolvimento modifica o backlog, adequando-o as mudanças ocorridas durante o desenvolvimento.

Somente o Time de Desenvolvimento pode alterar o Sprint Backlog.

Incremento

Ao final de uma sprint, todos os itens que foram finalizados formam um incremento do produto. Esse incremento deve ser entregável e utilizável, de maneira que o cliente perceba valor no produto a cada final de sprint.

A decisão de liberar ou não o incremento pertence ao Product Owner.

Definição de Pronto

Todos os itens que serão implementados devem possuir uma definição de pronto clara e que faça sentido para todos os envolvidos.

É através da definição de pronto que se assegura a transparência de quando determinada parte do trabalho estará realmente finalizada.

Somente itens com definição de pronto clara são considerados aptos para terem sua estimativa realizada e seu desenvolvimento iniciado, uma vez que sem essa informação é impossível para o Time de Desenvolvimento estimar e realizar o trabalho.

Eventos

O Guia do Scrum descreve alguns eventos, usados para criar uma rotina e diminuir a ocorrência de reuniões não planejadas.

Os eventos no Scrum são time-boxed, ou seja, possuem um tempo pré-determinado. Isso força que o evento seja realizado no tempo estabelecido, evitando desperdícios.

Todos os eventos do Scrum são oportunidades para inspecionar e adaptar algo. A ocorrência dos eventos aumenta a transparência do processo para todos os envolvidos.

Sprint

Com um time-box que varia entre duas e quatro semanas, a sprint é o coração do Scrum. É durante a sprint que o trabalho é efetivamente realizado pelo Time de Desenvolvimento e, ao seu final, espera-se obter um incremento potencialmente utilizável do produto.

A sprint serve como container para todos os outros eventos (como apresentado na Figura 1).

Toda sprint possui uma meta. A meta é definida pelo Product Owner e deve refletir um objetivo do negócio. Durante a sprint, o Time de Desenvolvimento se guia pela meta, para saber qual tarefa é mais importante de ser concluída. A meta é a grande responsável por manter todos os membros do time em sintonia, uma vez que guia o trabalho de todos durante a sprint.

Sprints não podem durar mais do que quatro semanas. Isso porque em quatro semanas as coisas podem mudar e a meta da sprint deixar de fazer sentido.

Scrum aceita muito bem mudanças, no entanto, durante uma sprint certas coisas não podem ser alteradas:

• A composição do Time de Desenvolvimento;
• Critérios de qualidade;
• A meta da Sprint.

Caso o aprendizado durante a sprint force alguma alteração no escopo combinado previamente, isso deve ser negociado entre o Product Owner e o Time de Desenvolvimento.

Durante a sprint, é papel do Scrum Master manter o Time de Desenvolvimento isolado de problemas externos, eliminando todos os impedimentos à realização do trabalho que possam surgir.

O Product Owner deve estar disponível durante a sprint o maior tempo possível. Um Product Owner ausente costuma ser um grande problema, uma vez que algumas dúvidas relacionadas a regras de negócio só podem ser esclarecidas por ele.

Reunião de Planejamento da Sprint

Com um time-box que varia entre quatro e oito horas, a reunião de planejamento é o evento onde são definidos e discutidos os itens que farão parte da sprint.

Basicamente a reunião de planejamento deve responder duas questões:

• O que será entregue como incremento ao fim da próxima sprint?
• Como o trabalho será realizado para que esse incremento seja entregue?

A reunião de planejamento é dividida em duas partes, cada uma com metade do time-box da reunião, dedicada a responder uma das questões.

O que será entregue ao fim da sprint?

A entrada para essa parte da reunião é o Product Backlog. O Product Owner apresenta ao Time de Desenvolvimento os itens ordenados, que são entendidos com a colaboração de todos.

Com base em seu desempenho passado, o Time de Desenvolvimento projeta sua capacidade durante a sprint e avalia quais os itens do backlog podem ser completados durante a sprint. Essa avaliação é preliminar nesse momento, e cabe somente ao Time de Desenvolvimento.

Após a definição dos itens que serão completados na sprint define-se a meta da sprint. A meta é definida pelo Product Owner, no entanto o time colabora para sua elaboração.

Como o trabalho será realizado?

Após selecionar os itens que serão completados na sprint, o Time de Desenvolvimento passa a discutir como construir as funcionalidades durante a sprint, de maneira que sejam consideradas completadas (de acordo com a definição de pronto).

Os itens que serão realizados na sprint, junto com seu plano de entrega, compõem o Sprint Backlog.

Feito isso, o Time de Desenvolvimento estima todos os itens do backlog da sprint. Nesse momento, o Product Owner pode estar presente, para esclarecer alguma dúvida que possa surgir ou mesmo realizar algum ajuste no escopo da sprint, caso o Time de Desenvolvimento julgue esse ajuste necessário.

Se sentir necessidade, o Time de Desenvolvimento também pode convidar outras pessoas a participarem da reunião, como especialistas técnicos, por exemplo.

As estimativas são feitas sempre por todos os membros do Time de Desenvolvimento. Existem diversas técnicas de estimativa, mas o mais importante nesse momento é que os itens sejam discutidos por todos até que o Time se sinta confortável a se comprometer com uma estimativa.

Ao final da reunião, o Time de Desenvolvimento possui o Sprint Backlog e metas definidos, além de um plano de trabalho determinado para a entrega dos requisitos.

Reunião diária

Com um time-box de quinze minutos, a reunião diária deve ser realizada sempre no mesmo local e horário, contando com a presença de todos os membros do Time de Desenvolvimento.

Somente os membros do Time de Desenvolvimento participam dessa reunião. Alguns sustentam que essa reunião seja feita com os participantes em pé, de maneira a evitar que o time-box seja desrespeitado.

Nessa reunião, cada membro do Time de Desenvolvimento deve responder três questões:

• O que foi feito desde a última reunião?
• O que será feito até a próxima reunião?
• Existe algum impedimento para a conclusão das tarefas?

A reunião diária é uma reunião chave para inspeção e adaptação, uma vez que, a cada 24 horas, todos os membros do Time de Desenvolvimento tem oportunidade de se reunir, inspecionar o andamento do trabalho e adaptá-lo a alguma necessidade que tenha surgido.

Com a reunião diária, todos os membros do Time de Desenvolvimento são capazes de reportar o andamento da sprint para o Scrum Master ou Product Owner, por exemplo.

O Scrum Master deve ficar atento aos impedimentos levantados durante a reunião diária, uma vez que será sua responsabilidade removê-los para que o trabalho do time possa ser executado.

Revisão da Sprint

Com um time-box entre duas e quatro horas, a reunião de revisão da sprint é realizada ao final da sprint e tem o propósito de inspecionar o incremento e atualizar o Product Backlog, se necessário.

Nessa reunião, o Time de Desenvolvimento e as partes interessadas discutem sobre o que foi feito na sprint e também sobre os próximos itens a serem entregues.

Essa reunião tem o intuito de promover ao Time de Desenvolvimento um feedback sobre o trabalho realizado durante a sprint, motivando-o e promovendo a colaboração.

Durante essa reunião, o Product Owner identifica o que foi pronto e o que não foi pronto, de acordo com a definição estabelecida. Além disso, discute e revisa o Product Backlog, projetando as prováveis datas de conclusão de acordo com o andamento até o momento.

O Time de Desenvolvimento levanta o que foi bem durante a sprint, além dos problemas ocorridos e como foram resolvidos. Além disso, o Time de Desenvolvimento apresenta o que está pronto e também responde questões sobre o incremento.

Retrospectiva da Sprint

Com um time-box entre uma e três horas, a reunião de retrospectiva da sprint serve para o Time de Desenvolvimento promover sua melhoria contínua.

Nessa reunião o Scrum Master, como facilitador, deve incentivar o Time de Desenvolvimento a levantar os seguintes pontos:

• Como a sprint transcorreu em relação às pessoas, aos processos, às ferramentas, etc;
• Levantar os pontos positivos da sprint e os pontos a melhorar;
• Montar um plano para implementar melhorias no trabalho do Time de Desenvolvimento.

Ao final dessa reunião, o time possui uma lista de melhorias a serem realizadas para a próxima sprint, além de uma lista do que deu certo e deve ser repetido.

Encerro aqui esse artigo introdutório sobre Scrum. Espero que ele tenha sido claro o bastante. Abraços e até próxima.