Scrum: O que é, Fundamentos e Aplicações Práticas

Scrum é uma Metodologia Ágil de desenvolvimento criada para flexibilizar a produção de softwares, em oposição à metodologias tradicionais que são mais rígidas, como a Waterfall.

Dentre as suas características, uma das principais é a entrega contínua de incrementos de valor com foco nas necessidades dos negócios.

Essa estrutura de trabalho vem se desenvolvendo muito com o passar dos anos e tem se tornado cada vez mais popular no dia a dia de equipes de programadores.

Todo o procedimento é pautado por técnicas e procedimentos. Você pode conferir o documento que determina as boas práticas da metodologia nesse link: O Guia do Scrum.

Aqui nessa publicação, vamos explicar alguns pontos do Scrum, começando pelos seus valores, quem são os envolvidos no processo, quais são os artefatos e quais são as etapas de cada ciclo.

Além disso, compartilharemos algumas boas práticas e formas de aplicar o Scrum em conjunto com outras metodologias de desenvolvimento.

Fundamentos do Scrum

Os fundamentos do Scrum são pautados em três níveis para que o desenvolvimento do projeto sejam cumpridos com sucesso. Sendo eles:

Os papéis e cargos: Scrum Master, Product Owner e Desenvolvedores;
Eventos: Sprint Planning, Daily Meeting, Sprint Review e Sprint Retrospective;
Artefatos: Product Backlog, Sprint Backlog e Incrementos.

Um ponto muito importante para que isso seja alcançado é entender quais são os valores e, então, segui-los fielmente.

Dessa forma, respeitar os fundamentos do Scrum é o que diferencia projetos que utilizam essa metodologia ágil que dão certo dos que dão errado.

Valores do Scrum

Os valores do Scrum são simples e mostram a essência dessa Metodologia Ágil.

Coragem: é preciso que os envolvidos tenham coragem, pois vão lidar com problemas e desafios focados na inovação e entrega de incrementos valiosos para os negócios.
Foco: o Scrum busca trazer foco para a organização e a equipe, tanto na capacidade da equipe, quanto no resultado.
Comprometimento: o trabalho em equipe é indispensável em projetos que utilizam Scrum. Desse modo, o comprometimento é um valor que deve estar ativo no time.
Respeito: ensinar a pescar, não dar o peixe. É dessa forma que todos os envolvidos devem pensar, respeitando a independência e responsabilidades de cada um. Assim, o comprometimento individual nunca é questionado.
Abertura: todos os envolvidos devem estar abertos e disponíveis para a realização do que é necessário. Esse valor deve ser lembrado e estimulado, pois ele é a base para os outros.

Seguindo esses valores, a equipe tem o necessário para ter o sucesso em um projeto Scrum, pois, dessa forma, os conceitos empíricos de inspeção, transparência e adaptação que pautam a metodologia, tomam vida.

Papéis no Scrum

As responsabilidades em um projeto Scrum são sempre bem definidas, pois isso certifica que as fundações da metodologia serão honradas.

Esses são os quatro papéis presentes:

Scrum Master (SM)

É o responsável por cuidar de pessoas, processos e ferramentas.

Ele é o principal facilitador entre o time e os Stakeholders (interessados no desenvolvimento da solução com objetivo comercial).

Também é responsável pelos processos, sendo encarregado por todo o fluxo do Scrum e todas as conexões do mundo exterior com o time.

E, por último, as ferramentas. Ele é o principal facilitador para que o time tenha o necessário para realizar as entregas que foram acordadas.

Product Owner (PO)

Esse é o agente que cuida dos negócios, ouvindo os Stakeholders para que as necessidades comerciais sejam atingidas no final do procedimento.

Ele é quem define o Product Backlog, um dos artefatos mais importantes no Scrum.

Dentre suas responsabilidades, também está o apoio à equipe de desenvolvimento, disponibilizando todos os insumos necessários para que a solução criada atenda as necessidades do negócio, em um ambiente saudável.

Desenvolvedores

Esses são os responsáveis por transformar as necessidades do negócio trazidas pelo Product Owner, em produtos de valor.

Eles trabalham no dia a dia diretamente com o desenvolvimento da solução, focados no comprometimento na entrega daquilo que foi acordado nos eventos iniciais do Scrum.

Artefatos do Scrum

No Scrum, para que tudo siga os fundamentos designados, a utilização de artefatos específicos, como o Product Backlog que já citamos, é necessário.

Assim, a equipe tem de forma palpável o que está sendo utilizado em cada etapa, facilitando a compreensão de como cada passo deve ser executado.

Product Backlog

O primeiro artefato é o Product Backlog. Nele estão contidas as características necessárias para que a solução desenvolvida atinja os requisitos do negócio.

Ele é formulado pelo Product Owner, que interpretou as exigências dos Stakeholders e as traduziu em itens que devem ser criados pela equipe de desenvolvedores.

A cada Sprint, itens do Product Backlog são selecionados pela equipe para serem desenvolvidos no Sprint Backlog, o próximo artefato.

Porém, em alguns casos, através de refinamentos (uma etapa extra do Scrum), a equipe pode chegar a um Product Backlog pronto para seleção.

No decorrer do conteúdo você entenderá como isso funciona.

Sprint Backlog

Aqui, como citamos logo acima, é onde os itens do Product Backlog são selecionados pela equipe do projeto.

Na maioria dos casos não são todos os itens que são desenvolvidos, a não ser em casos de Product Backlogs prontos para seleção.

O Sprint Backlog é um artefato que, segundo o Guia do Scrum, deve ser criado pela equipe de desenvolvedores.

Nele está decidido tudo que deve ser realizado naquela Sprint (outro termo que você logo entenderá).

Incremento

Esse é o nome dado para o resultado de cada Sprint. Basicamente, é com o acúmulo dos esforços da equipe que o Incremento é alcançado.

Eventos do Scrum

Como abordado no tópico anterior, cada artefato é importante para uma etapa específica do processo em um projeto de Scrum.

A separação em eventos, ou etapas, facilita a organização das equipes e assegura que cada envolvido continuará comprometido com as suas funções de maneira direcionada.

Sprint Planning

Esse é o evento inicial, onde o time cria um plano para atingir um determinado incremento.

A duração dessa reunião está diretamente ligada com a duração da Sprint, assim como os demais eventos.

Nesse caso, podem ser designadas até 8 horas, caso a Sprint chegue à sua duração máxima, que é de um mês.

Agora, seguem as responsabilidades de cada envolvido no projeto:

Product Owner (PO): irá se preocupar em entregar um Product Backlog coeso com as necessidades do negócio, para que o time de desenvolvedores produza o Sprint Backlog.
Scrum Master (SM): é o responsável por cuidar do fluxo do Scrum e atua como um facilitador, caso os desenvolvedores necessitem, para que o Sprint Backlog cumpra seu objetivo.
Desenvolvedores: são os responsáveis por formar o Sprint Backlog, através dos itens do Product Backlog. As informações podem ser mais desenvolvidas e detalhadas durante a execução do Sprint.

Daily Scrum

Aqui é onde a equipe se alinha sobre o status do projeto, com objetivo da sincronização do trabalho. É o momento para definir e entender onde a equipe está na Sprint e para onde ela está indo, mirando no objetivo final.

A reunião deve durar, no máximo, 15 minutos e ser realizada sempre no mesmo local, para diminuir a complexidade.

Durante a reunião, são levantados em consideração bloqueios, riscos e possíveis adaptações, sempre com foco na entrega do incremento final do time. E para que a Daily Scrum funcione, o Sprint Backlog precisa ser transparente.

Aqui, idealmente, os únicos envolvidos são os desenvolvedores, visto que existe a necessidade de clareza entre a equipe que está construindo o incremento. A interferência de outras partes pode ser danosa.

Sprint Review

Nessa etapa ocorre a interação mais importante entre os desenvolvedores e os Stakeholders. Aqui é apresentado tudo que foi desenvolvido até o final da Sprint e são destacados os desafios enfrentados para chegar até aquele ponto.

Quem facilita o evento é o Scrum Master, garantindo a execução no tempo certo, com no máximo 4 horas.

E o Product Owner tem o papel de colher os feedbacks dos Stakeholders, juntando as informações apresentadas pelos usuários que serão utilizadas nos próximos Sprints.

Sprint Retrospective

Com as informações coletadas pelo Product Owner, é criada uma discussão para definir quais são as melhorias para o incremento para ser desenvolvido na próxima Sprint.

Enquanto o Scrum Master reflete sobre a interação da equipe, como foram pautados os processos e se as ferramentas utilizadas atingiram o que era desejado.

Esse evento deve ser executado em, no máximo, 3 horas.

Refinamento

Esse não é exatamente um evento, mas age como um. Aqui são discutidas melhorias nos procedimentos, eventos e interações durante as Sprints. A diferença está no foco em aplicar o que foi discutido no próximo ciclo de desenvolvimento.

Essa atribuição é realizada pelos desenvolvedores, com informações colhidas durante as Dailys em trocas com os Product Owners.

Não há a necessidade de reuniões para que o refinamento seja realizado. Tudo pode ser feito através de um canal de comunicação assíncrona, onde a atualização das documentações seja constante.

Realizar um processo como o refinamento assegura que as próximas Sprints terão inputs práticos e próximos da realidade dos desenvolvedores.

Isso facilita a entrega de um incremento com possibilidade de ser desenvolvido dentro das capacidades da equipe e também atende todas as necessidades do negócio.

Scrum na prática

Bom, agora que você já sabe sobre os fundamentos do Scrum, nada melhor do que entender um pouco sobre como ele funciona na prática.

Nesse tópico, falaremos um pouco sobre ferramentas e boas práticas que podem ser aplicadas em projetos de Scrum e também mostraremos como realizamos as Sprints aqui na Gateware.

Ferramentas

Para que um projeto Scrum continue funcionando, é preciso que o motor dele não pare.

E o “motor” de todo o projeto é o Scrum Master, o responsável pelas pessoas, processos e ferramentas.

Por isso, contar com boas ferramentas ou formas de medir o ritmo de trabalho da equipe é fundamental.

Aqui estão alguns exemplos de ferramentas utilizadas no mundo da Gestão de Projetos Ágeis:

Ao utilizar uma ferramenta ou gerenciar planilhas manuais, o Scrum Master tem acesso à indicadores sobre:

Como está o ritmo da execução;
Capacidade da equipe em relação ao volume de trabalho;
Adoção da equipe quanto às ferramentas necessárias.

Em posse dessas informações, ele terá segurança para tomar decisões estratégicas em prol do projeto. Por exemplo:

O ritmo está abaixo do esperado: ele pode conversar com o time de desenvolvedores para entender a situação, fornecer infraestrutura ou até mesmo facilitar a conversa com o Product Owner e os Stakeholders para uma melhor compreensão sobre as necessidades do negócio.
Capacidade da equipe inferior ao volume de trabalho: ele pode apresentar as informações para os Stakeholders, com dados estatísticos comprovando que a equipe precisa de aprimoramento.
Adoção da equipe quanto às ferramentas necessárias: caso perceba que estão faltando dados nos logs das ferramentas, ele pode entrar em contato com a equipe para explicar a importância da adoção, com foco no comprometimento ao objetivo final que foi acordado nos eventos iniciais.

Dessa forma ele afirma os valores do Scrum, aumentando a probabilidade do incremento estar de acordo com as necessidades do negócio.

E nada facilita mais a vida de uma equipe de Scrum do que Stakeholders felizes, hehe! 🙂

Boas práticas

Passando para as boas práticas, é importante que as atitudes sejam pautadas em técnicas de comunicação que valorizem a empatia.

Os resultados do projeto desenvolvido com o Scrum dependem do trabalho em equipe. Até porque, no final, o valor do trabalho em conjunto é maior do que o individual.

Por isso, vale olhar com cuidado para os papéis no projeto e entender como cada um deve contribuir.

O trabalho com frameworks ágeis tira todos de suas zonas de conforto e a empatia é peça chave para que a colaboração ocorra da melhor forma possível.

E sabe quem é o grande responsável? O Scrum Master, aquele que representa a engrenagem do projeto.

A harmonia nas interações entre os desenvolvedores e o Product Owner só é alcançada a partir da atuação dele.

Aqui vão algumas boas práticas que podem ser aplicadas pelo Scrum Master:

1. Dailys com a participação apenas dos desenvolvedores

Em projetos de Scrum, a participação dos Product Owners nas reuniões diárias pode causar interferências.

Visto que a reunião que tem como objetivo a transparência e comunicação entre a equipe de desenvolvedores, se torna uma reunião de relatório para os Product Owners, com possibilidade de causar ansiedades e ferir as linhas do Guia do Scrum, criado pela Scrum.org.

Em algumas situações, a presença pode ser benéfica. Porém, é necessário que os desenvolvedores tenham um ambiente seguro para falar sobre todos os detalhes do projeto.

2. Crie estimativas de tempo com um pouco de sobra

Em projetos de desenvolvimento de software é normal que ocorram diversos imprevistos:

Necessidade de refatoração do código;
Novas infraestruturas;
Tempo para documentação;
Problemas na equipe;
Entre outros.

Para o desenvolvimento de qualquer aplicação bem sucedida, é necessário que haja um tempo específico para que as melhorias sejam aplicadas.

Os Stakeholders precisam estar dispostos a investir na infraestrutura e testes de qualidade. Sem isso, a equipe estará desenvolvendo algo que, assim que estiver pronto, nunca mais será melhorado. Algo completamente contra as linhas do Manifesto Ágil.

Por isso, vale a pena organizar o tempo necessário para cada atividade com cautela, de modo que, mesmo com imprevistos, os objetivos ainda possam ser alcançados.

Dessa forma, a equipe se certifica que terá tempo hábil para honrar os compromissos realizados inicialmente.

3. Tome cuidado com métricas de produtividade

Em projetos Scrum, existem diversas informações que, se interpretadas erroneamente, podem se tornar em métricas de produtividade tóxicas.

Por exemplo, se a Burndown Chart (documentação que mostra quais itens do backlog estão sendo realizados), chega até os Stakeholders e eles percebem uma diminuição no ritmo de entregas após a entrada de um novo desenvolvedor, o primeiro instinto será querer fazer alterações para que tudo volte ao “normal”.

Porém, os Stakeholders não participam da rotina no desenvolvimento e não têm todas as informações necessárias para entender o porquê da diminuição no ritmo das entregas.

É bom lembrar que o desenvolvimento com frameworks ágeis nem sempre é ligado apenas em entregar tudo quanto antes, mas sim em entregas de valor com uma constância.

Se a equipe precisou diminuir o ritmo, definitivamente há algum motivo e as informações analisadas pelas pessoas erradas podem levar a decisões equivocadas para a entrega do que foi acordado inicialmente.

Por isso, saiba quais informações devem ser analisadas por cada envolvido nas Sprints e tente ao máximo criar um ambiente saudável para que todos possam exercer as suas responsabilidades e trabalhar em prol do melhor produto possível.

Aplicação Híbrida do Scrum

Como falamos logo no início da publicação, o Scrum não é a única metodologia de desenvolvimento.

Metodologia Híbrida (Agile e Waterfall)

O Scrum foi criado para contrastar com a Waterfall, utilizada inicialmente para a produção em fábricas.

As Metodologias Ágeis foram criadas para introduzir novos conceitos ao mundo de Gestão de Projetos, principalmente quando estamos falando no desenvolvimento de softwares.

Um software pode ser atualizado e corrigido a qualquer momento. Por isso, ter flexibilidade e colaboração é algo valorizado nessas modalidades de trabalho.

Porém, o ponto fraco é: menor previsibilidade.

Vamos combinar que, para os Stakeholders, isso é um fator importantíssimo. Cada decisão deve ser feita com assertividade, de modo que o modelo de negócio não seja comprometido.

Por isso, para que ambos sejam atendidos até certo ponto, existe a Metodologia Híbrida entre Agile e Waterfall!

Conheça mais sobre as diferenças e benefícios dela nestes conteúdos:

Scrumban

Se você conhece o Scrum, imaginamos que também saiba do que se trata a Kanban, outra Metodologia Ágil.

Apesar do contraste, também possuem algumas similaridades, principalmente quanto aos seus objetivos finais. Então, que tal aproveitar o melhor dos dois mundos?

Utilizando a Metodologia Híbrida Scrumban, o seu projeto pode se tornar mais visual e colaborativo, o que facilita a tomada de decisões em todos os níveis.

Saiba mais sobre as diferenças entre essas Metodologias Ágeis e a sua aplicação conjunta neste conteúdo:

Scrum vs Kanban: quais as diferenças?

Conclusão

Ufa! Agora sim você está introduzido ao Scrum!

Com essa publicação, você entendeu quais são os valores, papéis, artefatos, eventos, ferramentas e boas práticas necessárias para um projeto que utiliza o Scrum.

Sem contar no insight sobre as Metodologias Híbridas, né?

Agora, se você quer fazer parte de projetos com resultados incríveis, nossa recomendação é que continue se aprofundando no assunto. Sempre existem novas metodologias e ferramentas que podem ser aprendidas e aplicadas.

Obrigado por ler até aqui. Para tirar dúvidas sobre como a aplicação do Scrum em projetos pode ser benéfica para você, entre em contato com a gente.

Basta preencher o formulário logo abaixo. 🙂