Entenda mais sobre o método Scrum

Dentre os métodos ágeis, Scrum é um dos mais famosos. Em parte, pela sua simplicidade em endereçar os principais problemas do desenvolvimento de um novo produto, usualmente software, em parte pelas grandes organizações que disseminam esse framework. Uma das características mais marcantes, talvez a chave de seu sucesso, é não ser conhecido como uma metodologia de trabalho, mas sim como um framework. Isso é como assumir a sua incompletude, que necessita ser preenchida com aspectos particulares de cada equipe, projeto ou organização.

Existe divergência entre sobre a sua aplicabilidade: alguns dizem que serve como um excelente ponto de partida para equipes iniciantes; os praticantes defendem que outras metodologias ditas evolutivas resultariam no que hoje é o Scrum ou próximo disso. Semelhante a Kent Schwaber, um dos criadores dessa metodologia, nós defendemos que é uma ferramenta que, como martelos e serrotes, tem momento e aplicação corretos para serem utilizados.

 Projetos com início e fim claros e definidos, com uma visão bem estabelecida de um backlog mínimo que possa ser trabalhado e um time focado no seu desenvolvimento, seria o ambiente ideal para o uso de Scrum com a mais alta performance.

O fluxo do Scrum é simples, com vários pontos de inspeção para garantir que as metas estabelecidas estão sendo perseguidas. É baseadoem timeboxes (janelasdetempo) bemdefinidosparagarantir boa cadência e alinhamento constante entre desenvolvimento e cliente. O principal timebox do Scrum é o sprint. O sprint pode variar entre uma e quatro semanas, de forma geral. Nele estão contidos todos os eventos idealizados para planejamento, revisão e controle do objetivo proposto.

A estrutura do Scrum possui papéis, eventos e artefatos mínimos definidos. Outros podem ser acrescidos sem ferir o que é definido como mínimo no framework.

Papéis

Dono do Produto (Product Owner, ou PO): É o papel responsável pelo sucesso do produto. Cabe a ele as decisões sobre prioridade e garantia de que as alterações de produtos estejam alinhadas com a visão estabelecida no início do projeto. É responsabilidade do PO estar disponível para eventuais dúvidas da equipe e durante as cerimônias.

Scrum Master: Seu principal objetivo é manter o funcionamento do framework, garantindo que as cerimônias funcionem como devem. Seu trabalho diário é garantir que nada atrapalhe o time a alcançar as metas do Sprint. Ou seja, deve atuar em:

· Remover impedimentos;

· Desenvolver o time;

· Assegurar que o Scrum é seguido corretamente;

· Facilitar cerimônias.

Time de Desenvolvimento: ·Responsável pelo desenvolvimento do produto em si. Cabe a ele comunicar-se bem com PO para buscar sempre a melhor maneira de entregar o planejado para cada release. Times de desenvolvimento ágeis são auto-organizados e extremamente comprometidos com o resultado do projeto.

Eventos (Cerimônias)

Reunião de Planejamento: São esclarecidas as dúvidas sobre o escopo que será trabalhado, buscando junto ao PO essas respostas. O time questiona e debate com o PO as melhores maneiras de atender às necessidades presentes no backlog. Ao final saem com um conjunto de histórias em nível de detalhe suficientemente claro para iniciar os trabalhos. Portanto, entra um pedaço do backlog do produto e sai um backlog para o sprint.

Papel do PO:

· Trazer Product Backlog priorizado.

· Trazer Histórias priorizadas para a Sprint.

· Apresentar histórias candidatas a entrar na Sprint.

· Tirar dúvidas do Time de desenvolvimento.

· Ajudar a repriorizar as histórias se necessário.

· Definir critérios de aceite.

Papel do Time de Desenvolvimento:

· Transformar Histórias em Tarefas técnicas.

· Estimar histórias e tarefas.

· Construir Sprint Backlog.

Papel do Scrum Master:

· Manter timebox.

· Facilitar a cerimônia.

Daily Scrum: Diariamente o time se reúne para verificar e validar o progresso do sprint. Nesse evento são levantadas as dificuldades e barreiras para atingir a meta proposta na reunião de planejamento. Esse é mais um ponto de verificação e planejamento constante dentro do sprint. O resultado desse evento é um plano informal para o próximo dia de trabalho.

Papel do PO:

· Tirar dúvidas sobre o produto.

· Ajudar na priorização das histórias.

· Manter o time alinhado a visão do produto.

· Acompanhar andamento do produto.

Papel do Time de Desenvolvimento:

· Construir o incremento do produto.

· Compartilhar informações do sprint backlog a todos os membros do Time de Desenvolvimento.

· Realizar inspeção e adaptação da sprint backlog com foco no atingimento da meta da Sprint.

Papel do Scrum Master:

· Manter timebox (15 minutos).

· Facilitar a cerimônia.

· Ajudar o Time de Desenvolvimento a tratar impedimentos.

Reunião de Revisão: Ocorre ao final de cada sprint, quando o time de desenvolvimento entrega efetivamente o incremento de produto ao PO, buscando o seu feedback e validação. Embora durante todo o sprint exista o contato entre PO e time, essa apresentação formal pode ajudar outras partes interessadas a compreender o andamento do projeto. Através dessa cerimônia, o PO evolui o backlog do produto para a próxima iteração.

Papel do PO:

· Validar as histórias entregues.

· Verificar se o software está de acordo com os critérios de aceite.

· Aceitar ou rejeitar as histórias da sprint.

Papel do Time de Desenvolvimento:

· Apresentar histórias feitas na sprint.

· Anotar feedback do PO e Stakeholders.

Papel do Scrum Master:

· Manter timebox.

· Facilitar a cerimônia.

Retrospectiva: Todo o time de desenvolvimento repensa seu trabalho e como pode melhorar o seu processo de desenvolvimento. Essa cerimônia pode ser facilitada por um Agile Coach. O objetivo é aprimorar os métodos de trabalho, a fim do time ser mais efetivo a cada novo sprint.

Papel do PO e Time de Desenvolvimento:

· Apresentar pontos positivos e negativos do processo.

· Ajudar no plano de ação para a próxima sprint.

Papel do Scrum Master:

· Manter timebox.

· Facilitar a cerimônia.

Artefatos

* Vamos falar aqui dos mais importantes:

Product Backlog: O backlog do produto é o repositório central de todo o trabalho que será desenvolvido. É composto por PBIs (Product Backlog Items) que podem ser escritos usando qualquer formato. Pode-se usar Casos de Uso (Use Cases) do UML, Histórias de Usuário (User Stories), etc. O Scrum não prescreve como deve ser feita essa documentação, só determina que deve existir. Esse artefato tem os itens com maior prioridade no topo e os com menor prioridade abaixo. Uma exigência para que um item suba em prioridade é que seu entendimento esteja claro passível de ser trabalhado no próximo sprint.

Sprint Backlog: Representa todo o volume de trabalho que será executado no sprint. É o resultado da reunião de planejamento do sprint e é composto por tarefas de trabalho, quase sempre, de natureza técnica. Essas tarefas possuem estimativas e critérios bem definidos de aceitação, portanto o time Scrum pode determinar exatamente quando uma dessas está concluída. Somente são apresentadas na reunião de revisão do sprint as tarefas que estiverem completamente feitas. Todas as parciais não são consideradas.

Incremento do Produto: A soma de todo o trabalho efetivamente concluído ao final de um sprint recebe o nome de Incremento de Produto. É definido como sendo algo potencialmente entregável. Isso significa que ao final de um sprint, o time apresenta o seu trabalho e esse deve ser possível de ser colocado em produção, cabendo ao PO a decisão se faz ou não sentido naquele momento para o negócio.

Espero ter contribuído com sua jornada de aprendizado, e isso é sempre possível quando fazemos uso da agilidade:

#Comunicar #Colaborar #Decidir

Abraços, bye!