A metodologia Scrum é um framework do conjunto de metodologias ágil para gerenciamento de projetos. Usada principalmente para projetos de desenvolvimento de software com o objetivo de fornecer uma nova atualização de software a cada 2-4 semanas.
É uma das abordagens que influenciaram o Manifesto Ágil, que articula um conjunto de valores e princípios para orientar decisões sobre como desenvolver software de alta qualidade mais rapidamente.
O Scrum é amplamente utilizado por equipes de desenvolvimento de software. De fato, é a metodologia ágil mais popular. De acordo com o esse relatório, sobre desenvolvimento ágil nas empresas, cerca de 70% das equipes de desenvolvimento usam Scrum ou um híbrido.
Scrum começou na indústria de software e desde então se espalhou para as universidades, setores militares, a indústria automotiva e outros.
Mesmo que as vantagens da metodologia Scrum sejam bem conhecidas (agilidade, feedback rápido, melhor comunicação, flexibilidade, etc.), às vezes podemos enfrentar a incerteza de se usar esse framework ou seguir um caminho tradicional para o desenvolvimento.
Os 7 aspectos a seguir podem ser considerados para determinar quando é conveniente usar Scrum em seu projeto.
O scrum se encaixa em diversos tipos de projetos com diferentes propósitos, mas especialmente se ele encaixar em uma ou mais características citadas acima, é um forte indicativo que você deveria usar a metodologia Scrum para gerir o projeto.
Scrum é definido por um grupo de princípios (ou valores) que devem ser entendidos como diretrizes simples para trabalhar juntos à equipe. Eles são:
Ao incorporar os valores de Scrum, uma equipe assume a responsabilidade compartilhada pelo sucesso ou por um possível fracasso do projeto. E a menos que cada membro da equipe Scrum se agarre a esses valores, a equipe não terá a base necessária para ser bem sucedida.
Existem três papéis essenciais para o sucesso do scrum. O proprietário do produto (Product Owner), Scrum Master e a equipe de desenvolvimento. E como as equipes scrum são multifuncionais, a equipe de desenvolvimento inclui testadores, designers, especialistas em UX e engenheiros de operações, além dos desenvolvedores. Vamos falar sobre cada papel.
Mesmo que você nunca tenha trabalhado com Scrum, é bem provável que que você tenha ouvido falar no termo Scrum Master. O Scrum Master é o orientador da equipe, ele deve ajudar os membros da equipe com o planejamento e execução das tarefas.
O scrum master é a pessoa da equipe responsável pela gestão do processo, e somente do processo. Ele não está envolvido na tomada de decisões, mas atua como um guia para orientar a equipe durante o processo do scrum.
O Scrum Master protege a equipe de distrações externas, como feedback de clientes ou outros projetos, permitindo que os membros da equipe se concentrem durante a sprint e no objetivo selecionado.
Enquanto o Scrum Master se concentra em ajudar a equipe a produzir os melhores resultados, o proprietário do produto trabalha para direcionar a equipe para o objetivo certo.
Project owner ou Product Owner é normalmente um dos principais interessados no projeto. Parte das suas responsabilidades é ter uma visão do que ele ou ela deseja construir, e transmitir essa visão para a equipe. Isto é a chave para iniciar com sucesso qualquer projeto ágil de desenvolvimento de software. O project owner faz isso em parte através do backlog do produto, que é uma lista de características consideradas prioritárias para o produto.
O Project Owner é responsável por priorizar o backlog durante o desenvolvimento do projeto, para garantir que o resultado, ao final de cada iteração (Sprint), esteja mais perto do que ele espera ao final do projeto.
O Project Owner é geralmente um usuário líder do sistema ou alguém do marketing, gerenciamento de produtos ou qualquer pessoa com um sólido entendimento dos usuários, do mercado, da concorrência e das tendências futuras para o domínio ou tipo de sistema que está sendo desenvolvido.
Isto, naturalmente, varia conforme a equipe esteja desenvolvendo um software de uso comercial, software para uso interno, hardware ou algum outro tipo de produto. O ideal é que a pessoa no papel de proprietário do produto tenha uma visão do produto final que deve ser construído. Para que a equipe então posso trabalhar com um visão clara do que deve ser construído.
O terceiro e último papel no gerenciamento do Scrum é a própria equipe Scrum. Embora os indivíduos que fazem parte da equipe, possam ter títulos tradicionais como engenheiro(a) de software, programador, designer, tester ou arquiteto, a metodologia Scrum estabelece que cada pessoa deve contribuir de todas as maneiras possíveis para completar o trabalho de cada sprint.
Ao se tornar um membro de uma equipe Scrum, aqueles que no passado cumpriam papéis específicos, tendem a manter alguns desses aspectos, mas a eles, podem ser acrescentados novas responsabilidades.
Uma equipe Scrum típica é composta de três a nove pessoas. E ao invés de escalar e formar uma equipe gigante, Scrum prefere por ter “equipes dentro de equipes”. Desta forma, é mais fácil administrar a equipe para completar a Sprint com sucesso.
Um sprint é um curto período de tempo, quando a equipe trabalha para completar uma determinada quantidade de trabalho. As sprints são o núcleo da metodologia Scrum e das metodologias ágeis.
Escolher os itens certos que serão trabalhados durante à sprint é um esforço de colaboração entre o proprietário do produto (Product Owner), o Scrum Master e a equipe de desenvolvimento. O proprietário do produto define o objetivo que a sprint deve atingir.
Como todos os eventos do scrum, a Sprint também tem uma duração máxima. Normalmente, uma Sprint tem duração de um mês ou menos. A duração de cada sprint é decida durante uma das reuniões para o inicio projeto.
A metodologia scrum estabelece cinco tipos de reuniões realizadas em intervalos regulares:
Uma reunião que faz parte, não só da metodologia Scrum, mas de grande parte das outras metodologias ágeis. Ela é realizada pela equipe de Desenvolvimento, Scrum Master e Product Owner. Ela acontece sempre no início de um novo sprint, com o objetivo de estabelecer uma lista de trabalho, com a correta prioridade para cada tarefa, e também para alinhar e motivar a equipe para o sucesso durante a sprint.
O Project Owner discutirá o backlog com a equipe de desenvolvimento, apresentando a quantidade de esforço que será envolvido. A equipe decide então quanto do trabalho do backlog pode ser concluído nesta iteração. Seguindo as melhores práticas de planejamento de Sprint, a duração desse planejamento da sprint pode ser mantida dentro das 4-6 horas.
Uma reunião de sincronização essencial tanto nas metodologias Scrum como Kanban. É uma cerimônia ágil realizada para a equipe de desenvolvimento facilitada pelo Scrum Master. O proprietário do produto e as partes interessadas podem participar desta reunião para responder às questões levantadas pela equipe de desenvolvimento. Esta reunião acontece todos os dias de preferência no mesmo local, e normalmente é realizada pela manhã. O objetivo do Stand-up é manter todos atualizados do andamento geral do projeto.
Cada membro da equipe é solicitado a responder 3 perguntas:
O stand-up diário deve ser considerado uma reunião informal e não deve durar mais do que 15 minutos.
Como descrito no Guia Scrum, a Revisão da Sprint é realizada no final de cada Sprint para avaliar as atualizações feitas no software e adaptar o Backlog do Produto, se necessário.
Esta também é uma reunião informal, tem como objetivo obter feedback e estabelecer a colaboração. E como um projeto pode ter uma ou várias sprints, o número de revisões também vai variar.
Durante a revisão da sprint, a equipe e as partes interessadas avaliam o que foi feito na Sprint. Com base nessa avaliação e em quaisquer mudanças no Backlog do Produto durante a Sprint, os participantes contribuem com ideias para as próximas implementações para otimizar o valor do produto final.
Essa reunião não deve demorar muitos mais do de quatro horas durante um mês de Sprint. Para Sprints mais curtas, a reunião é geralmente mais curta. O Scrum Master deve assegurar que o evento ocorra e que os participantes entendam seu propósito.
A Retrospectiva da Sprint é uma oportunidade para a equipe Scrum se auto avaliar e criar um plano de melhorias para ser posto em prática durante a próxima Sprint.
A retrospectiva do sprint é geralmente a última coisa a ser feita em um sprint. Muitas equipes fazem essa reunião imediatamente após a revisão da sprint. Toda a equipe, incluindo tanto o Scrum Master quanto o Product Owner, devem participar.
Essa sessão é basicamente uma reunião de “lições aprendidas” para identificar potenciais armadilhas, erros passados e buscar novas maneiras de evitar esses erros.
Em outras palavras, essa reunião serve para descobrir quais atividades e “coisas” a equipe está fazendo bem, quais atividades devem ser continuadas e o que pode ser feito para melhorar.
Esta é no máximo uma reunião de três horas durante um mês de Sprints.
A metodologia Scrum é um processo ágil mais utilizado para o desenvolvimento de produtos, especialmente o desenvolvimento de software. Scrum é um framework para gerenciamento de projetos, aplicável a qualquer projeto com prazos agressivos, requisitos complexos e um certo grau de exclusividade. Na metodologia Scrum, os projetos avançam através de uma série de iterações chamadas sprints. Cada sprint tem normalmente de duas a quatro semanas de duração conduzidas pelo Scrum Master.
Antes, durante e depois de cada sprints são realizadas reuniões com todos os envolvidos no projeto incluindo o Project Owner, Scrum Master e a equipe de desenvolvimento para estabelecer novas atividades, prioridades e metas.
Escreva nos comentários como você usou a metodologia Scrum em algum dos seus projetos.
Deixe um comentário