Entenda de vez a Metodologia SCRUM!

A competitividade acirrada, as exigências de mercado e a busca incessante por diferenciais estratégicos fazem com que as empresas tenham uma postura cada vez mais proativa, correndo contra o tempo, para lançar soluções inovadoras a todo instante. A Metodologia SCRUM pode te ajudar com esses desafios.

Para ter uma entrega satisfatória é necessário escolher a  metodologia de gerenciamento ideal para o seu projeto. E é nesse contexto que nasceu o Scrum, um framework que tem o objetivo de conduzir projetos inseridos em um ambientes de alta complexidade.

 Mas então, o que é Scrum? O que são os termos técnicos mencionados no Scrum? Como ele se aplica à gestão de projetos?

OBS: Os termos em inglês do Scrum serão mantidos a fim de preservar os “jargões” que são comumente utilizados na metodologia.

O que é Scrum?

Metodologia SCRUM é um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto valor possível. Scrum é:

• Leve

• Simples de entender

• Difícil de dominar

Ele foi desenvolvido para a gestão de projetos de software, mas que, cada vez mais, vem sendo aplicado a outros setores. O método é de autoria do ex-piloto da aeronáutica americana Jeff Sutherland.

Em seu livro “Scrum: a arte de fazer o dobro do trabalho na metade do tempo”, ele faz um paralelo entre gestão de projetos e pilotar um avião. Um piloto não pousa o mesmo avião da mesma forma todas as vezes, sempre há a necessidade de fazer alguns ajustes de rota. Trabalhar com a possibilidade de fazer ajustes é o que torna a Metodologia Scrum perfeita para projetos de grande complexidade.

O  termo “Scrum” já é bem popular no mundo da tecnologia, sendo largamente utilizado por times de desenvolvimento de software. Mas de onde vem esse nome? O nome foi pego emprestado do jogo rugby, já que ambos são formados por um time, colaborativo, buscando sinergia e engajamento em torna de metas e objetivos comuns. Assim, conseguem resolver os problemas mais complexos com qualidade.

        Esse time é formado por:

Scrum Master

O Scrum Master procura assegurar que a equipe respeite e siga os valores e as práticas do Scrum.

Ele é um servo-líder para o Time Scrum. O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações com o Time Scrum são úteis e quais

Também protege a equipe, assegurando que ela não se comprometa excessivamente com relação àquilo que é capaz de realizar.

O Scrum Master atua como facilitador do Daily Scrum (que será explicado mais à frente neste artigo) e torna-se responsável por remover quaisquer obstáculos que sejam levantados pela equipe durante essas reuniões.

Esse papel de Scrum Master é normalmente exercido por um gerente de projeto ou um líder técnico, mas em princípio pode ser qualquer pessoa da equipe.

Product Owner

É o responsável por definir quais recursos e funcionalidades serão utilizados e construídos, além de definir a prioridade de cada um. O Product Owner também estabelece as expectativas em relação ao produto final e comunica à equipe os objetivos do projeto.

Ele é a única pessoa responsável por gerenciar o Backlog do Produto. O gerenciamento do Backlog do Produto inclui:

• Expressar claramente os itens do Backlog do Produto;

• Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões;

• Otimizar o valor do trabalho que o Time de Desenvolvimento realiza;

• Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai trabalhar a seguir; e,

• Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário.

Development Team

O Development Team ou Time de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar um incremento potencialmente liberável do produto “Pronto” ao final de cada Sprint. Um incremento “Pronto” é requerido na Revisão da Sprint. Somente integrantes do Time de Desenvolvimento criam incrementos.Eles são auto-organizados. Ninguém diz ao Time de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente liberável;

Vale destacar as características que um Time de Desenvolvimento deve ter.

• Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto.

• O Scrum não reconhece sub-times no Time de Desenvolvimento, independente dos domínios de conhecimento que precisam ser abordados, tais como teste, arquitetura, operação ou análise de negócios; e,

• Individualmente os integrantes do Time de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence ao Time de Desenvolvimento como um todo;

Um Scrum Team típico tem de 6 a 10 pessoas, embora haja relatos de projetos Scrum com equipes maiores.

Figura extraída do livro Essential Scrum de Addison Wesley.

Você pode até usar outros papéis em conjunto com o Scrum, mas o framework padrão requer apenas os três listados aqui.

Como funciona o framework Scrum

Sprints

No Scrum, o planejamento acontece por iterações, ou Sprints, que são os períodos de tempo em que o conjunto de atividades definidas no Product Backlog devem ser colocadas em prática. São ciclos com duração de 2 a 4 semanas. Fazendo um paralelo com o desenvolvimento de software, cada sprint refere-se a uma funcionalidade, que deve ser entregue ao cliente em perfeitas condições de usabilidade ao final de cada ciclo.

O trabalho realizado em cada sprint deve criar algo de valor tangível para o cliente ou usuário. Sprints são timeboxed (duração fixa) para que tenham sempre um início e fim data fixa, e, geralmente, todos eles devem estar com a mesma duração.

Product Backlog

No início do projeto são definidas as ideias e funcionalidades iniciais do produto. Essas ideias são denominadas histórias. O conjunto dessas histórias formam o Product Backlog, que é a lista de funcionalidades a serem desenvolvidas ao longo do projeto. Essas funcionalidades são classificadas por ordem de prioridade pelo Product Owner, visando entregar primeiro aquelas funcionalidades que geram maior valor de negócio para o cliente.

Sprint Backlog

Depois de definido o Product Backlog, no início de cada sprint, as atividades inerentes a cada funcionalidade são transportadas para o chamado Sprint Backlog. Este é uma lista de tarefas que o Scrum Team se compromete a fazer em um Sprint. Os itens do Sprint Backlog são extraídos do Product Backlog, pela equipe, com base nas prioridades definidas pelo Product Owner e a percepção da equipe sobre o tempo que será necessário para completar as várias funcionalidades.

Cabe a equipe determinar a quantidade de itens do Product Backlog que serão trazidos para o Sprint Backlog, já que é ela quem irá se comprometer a implementá-los.

Durante um Sprint, o Scrum Master mantém o Sprint Backlog atualizando-o para refletir que tarefas são completadas e quanto tempo a equipe acredita que será necessário para completar aquelas que ainda não estão prontas.

Sprint Review

No final de cada Sprint, é feita uma Sprint Review, ou seja, uma reunião de validação das histórias desenvolvidas.Os participantes do Sprint Review tipicamente incluem o Product Owner, o Scrum Team, o Scrum Master, gerência, clientes e engenheiros de outros projetos.

Durante o Sprint Review, o projeto é avaliado em relação aos objetivos do Sprint, determinados durante o Sprint Planning Meeting. Idealmente, a equipe completou cada um dos itens do Product Backlog trazidos para fazer parte do Sprint, mas o importante mesmo é que a equipe atinja o objetivo geral do Sprint.

Daily Scrum

No Scrum, é obrigatório que haja uma reunião diária da equipe. Nessa reunião, o Scrum Master valida o que foi feito, e busca resolver qualquer problema que a equipe tenha no desenvolvimento do produto.

Todos os membros da equipe devem participar do Daily Scrum. Outras pessoas também podem estar presentes, mas só poderão escutar. Isso torna os Daily Scrums uma excelente forma para uma equipe disseminar informações sobre o estado do projeto.

É importante ressaltar que essa reunião não deve ser usada como uma reunião para resolução de problemas. Questões levantadas devem ser levadas para fora da reunião e normalmente tratadas por um grupo menor de pessoas que tenham a ver diretamente com o problema ou possam contribuir para solucioná-lo.

Durante o Daily Scrum, cada membro da equipe provê respostas para cada uma destas três perguntas:

O que você fez ontem?  
O que você fará hoje?
Há algum impedimento no seu caminho?

Concentrando-se no que cada pessoa fez ontem e no que ela irá fazer hoje, a equipe ganha uma excelente compreensão sobre que trabalho foi feito e que trabalho ainda precisa ser feito.

A fim de resumir o framework Scrum, criamos a imagem abaixo: Definition of Done (Definição de Pronto)

Para saber quando, e como, uma parte do produto ou funcionalidade deve ser considerada concluída deve ser definido qual é a definição de “pronto””

Todos os integrantes devem ter um entendimento do que significa o trabalho estar completo, assegurando a transparência. Esta é a “Definição de Pronto” para o Time Scrum e é usado para assegurar quando o trabalho está completado no incremento do produto.

Assim como o Scrum é uma ferramenta de produtividade, existem outras estratégias para deixar sua empresa ainda mais eficiente e reduzir os custos. A AD&M Consultoria Empresarial pode diagnosticar sua empresa GRATUITAMENTE para saber qual estratégia é a mais adequada para o seu negócio. Clique aqui para marcar um diagnóstico gratuito.

Referências:

SCRUM: a arte de fazer o dobro do trabalho na metade do tempo. [S. l.]: Leya Brasil, 2014.

GUIA do Scrum MR: Um guia definitivo para o Scrum: As regras do Jogo. [S. l.]: Versão Brasileira, 2017.

Deixe uma resposta