Scrum

Saiba como usar o Scrum da melhor forma

Buscar tópicos

O que é o scrum?

O Scrum é uma estrutura que ajuda as equipes a trabalhar juntas. Como em uma equipe de rugby (de onde vem o nome) treinando para o grande jogo, o Scrum estimula as equipes a aprender com as experiências, se organizar para resolver um problema e refletir sobre suas conquistas e fracassos para melhorar sempre.

Embora o Scrum do qual estamos falando seja mais usado pelas equipes de desenvolvimento de software, os princípios e as lições dessa estrutura podem ser aplicados a todos os tipos de trabalhos em equipe. Esse é um dos motivos pelos quais o Scrum é tão popular. Muitas vezes considerado uma estrutura ágil para o gerenciamento de projetos, o Scrum descreve um conjunto de reuniões, ferramentas e funções que atuam juntos para ajudar as equipes a organizar e gerenciar seu trabalho.

Neste artigo, vamos discutir como uma estrutura de Scrum tradicional é formada com a ajuda do Guia do Scrum e de David West, CEO da Scrum.org. Vamos também incluir exemplos de como vemos os clientes se desviarem desses fundamentos para adaptar suas necessidades específicas. Para isso, a gerente de produtos do grupo para o Jira Software e ex-coach da metodologia ágil, Megan Cook, vai dar dicas e ensinar truques na nossa série de vídeos Agile Coach:

Artigos do Scrum

[CONTINUAÇÃO]

A estrutura

As pessoas costumam pensar que Scrum e metodologia ágil são a mesma coisa porque o Scrum é centrado na melhoria contínua, um princípio fundamental da metodologia ágil. No entanto, o Scrum é uma estrutura para aumentar a produtividade, enquanto o método ágil é uma forma de pensar. Você não consegue “virar ágil” assim, do nada, pois isso exige dedicação de toda a equipe para mudar a forma de pensar sobre como agregar valor aos clientes. Contudo, é possível usar uma estrutura como o Scrum para ajudar você a começar a pensar dessa forma e a praticar o desenvolvimento dos princípios ágeis na comunicação e no trabalho do seu dia a dia.

A estrutura do Scrum é heurística e exercita a aprendizagem contínua e adaptação a fatores variáveis. O Scrum reconhece que a equipe não sabe tudo no início de um projeto e que ela vai evoluir de acordo com a experiência. Assim, ele é estruturado para ajudar as equipes a se adaptar com mais facilidade às mudanças nas condições e necessidades do usuário, com a reorganização de prioridades integrada ao processo e ciclos curtos de lançamento para que elas possam sempre aprender e melhorar.

A estrutura do Scrum | Instrutor de agilidade da Atlassian

O Scrum tem sua estrutura, mas não é totalmente rígido e pode ser adaptado às necessidades de qualquer organização. Há diversas teorias sobre como as equipes do Scrum devem trabalhar exatamente para serem bem-sucedidas. No entanto, após mais de uma década ajudando equipes ágeis a ter mais produtividade na Atlassian, a gente viu que a comunicação clara, transparência e dedicação ao aprimoramento contínuo devem estar sempre no centro de qualquer estrutura que você escolher. O restante fica a seu critério.

Artefatos do Scrum

Vamos começar identificando os três artefatos do Scrum. Um artefato é algo produzido, como uma ferramenta para resolver problemas. No Scrum, os três artefatos são um backlog do produto, um backlog do sprint e um incremento com a sua definição de "concluído". Essas são as três constantes em uma equipe do Scrum que continuam sendo revisitadas e trabalhadas nas horas extras.

  • Backlog do produto é a lista principal de trabalho que precisa ser feito, administrada pelo proprietário ou gerente do produto. É uma lista dinâmica de recursos, requisitos, melhorias e correções que serve como fonte para o backlog do sprint. É, acima de tudo, a lista de “tarefas a fazer” da equipe. O backlog do produto é revisitado, tem suas prioridades alteradas e é administrado pelo proprietário do produto com frequência porque, conforme a equipe aprende mais ou de acordo com as mudanças do mercado, os itens podem não ser mais relevantes ou os problemas podem ser resolvidos de outras maneiras.
  • Backlog do sprint é a lista de itens, histórias de usuários ou correções de bugs, selecionada pela equipe de desenvolvimento para implementação no ciclo de sprint atual. Antes de cada sprint, na reunião de planejamento do sprint (que vai ser discutida mais adiante), a equipe escolhe em quais itens do backlog do produto vai trabalhar nesse sprint. O backlog do sprint pode ser flexível e evoluir durante um sprint. No entanto, o objetivo fundamental do sprint – aquilo que a equipe quer conseguir com o sprint atual – não pode ser prejudicado.
  • Incremento (ou objetivo do sprint) é o produto final útil de um sprint. Na Atlassian, o “incremento” costuma ser apresentado durante a demonstração do final do sprint, quando a equipe mostra o que foi feito no sprint. Você pode não ouvir a palavra “incremento” por aí, já que ela é mencionada muitas vezes como a definição da equipe de “concluído”, um marco, o objetivo do sprint ou mesmo a versão completa ou um epic enviado. Depende apenas de como sua equipe define “concluído” e como você define seus objetivos do sprint. Por exemplo, algumas equipes optam por entregar um produto a seus clientes no final de cada sprint. Então, sua definição de "concluído" seria "entregue". No entanto, isso pode não ser viável para outros tipos de equipes. Digamos que você trabalhe em um produto hospedado em servidor que só pode ser enviado a seus clientes a cada três meses. Você ainda pode escolher trabalhar em sprints de 2 semanas, mas sua definição de "concluído" pode ser finalizar parte de uma versão maior que você planeja entregar completa. Mas, sem dúvida, quanto maior a demora para lançar o software, maior o risco de ele perder seu propósito.

Como você pode perceber, a sua equipe tem muitas alternativas na hora de fazer as escolhas, inclusive em relação aos artefatos. Por isso, é importante manter a disposição para desenvolver o modo como você gerentica até mesmo seus artefatos. Talvez, a sua definição de "concluído" cause um estresse irreversível à sua equipe e você precise retroceder para escolher uma nova definição.

Dica profissional

Você deve ter com sua estrutura a mesma agilidade que tem com seu produto. Invista o tempo necessário para verificar o andamento do processo, faça ajustes se for preciso e não force algo apenas por uma questão de constância.

Cerimônias ou eventos do Scrum

Um dos componentes mais conhecidos da estrutura do Scrum é o conjunto de eventos, cerimônias ou reuniões sequenciais que as equipes do Scrum realizam com frequência. Nas cerimônias, está a maior parte das variações entre as equipes. Por exemplo, algumas equipes acham que essas cerimônias todas são uma tarefa penosa e repetitiva, enquanto outras acreditam que é uma verificação necessária. Sugestão: comece fazendo todas as cerimônias em dois sprints para ver o que funciona para a sua equipe. Depois, faça uma avaliação rápida e veja o que precisa ser ajustado.

Abaixo está uma lista de todas as principais cerimônias das quais uma equipe do Scrum pode participar:

  1. Organizar o backlog: às vezes conhecido como revisão de tarefas, este evento é de responsabilidade do proprietário do produto. As principais tarefas dele são fazer o produto corresponder à visão do produto e ter contato constante com o mercado e o cliente. Portanto, ele mantém esta lista usando o feedback de usuários e da equipe de desenvolvimento para ajudar a priorizar e manter a lista limpa e pronta para ser trabalhada a qualquer momento. Leia mais sobre como manter um backlog saudável aqui.

  2. Planejamento do sprint: o trabalho a ser executado (escopo) durante o sprint atual é planejado nessa reunião por toda a equipe de desenvolvimento. A reunião é conduzida pelo scrum master e é onde a equipe decide o objetivo do sprint. Histórias de uso específicas são, então, adicionadas ao sprint a partir do backlog do produto. Essas histórias sempre se alinham ao objetivo e são possíveis de implementar durante o sprint, segundo a equipe do scrum.

    No final da reunião de planejamento, cada membro do scrum tem que saber o que pode ser entregue no sprint e como o incremento pode ser alcançado.

  3. Sprint: um sprint é o período em que a equipe do scrum trabalha em conjunto para finalizar um incremento. Duas semanas é um período típico para um sprint, embora algumas equipes achem que uma semana seja mais fácil para fazer o escopo ou um mês seja mais fácil para entregar um incremento de valor. Dave West, da Scrum.org, informa que, quanto mais complexo o trabalho e quanto mais incógnitas houver, menor deve ser o sprint. Mas depende mesmo da equipe e você não deve ter medo de mudar essa duração se ela não estiver funcionando. Durante este período, o escopo pode ser renegociado entre o proprietário do produto e a equipe de desenvolvimento, se necessário. Isso forma o núcleo da natureza empírica do Scrum.

    Todos os eventos — do planejamento à retrospectiva — acontecem durante o sprint. Depois que um determinado intervalo de tempo é estabelecido para um sprint, ele deve permanecer consistente durante todo o período de desenvolvimento. Isso ajuda a equipe a aprender com as experiências passadas e aplicar esse insight a sprints futuros.

  4. Scrum diário ou Stand Up: é uma reunião diária muito curta que acontece no mesmo horário (em geral, de manhã) e lugar para simplificar. Muitas equipes tentam terminar a reunião em 15 minutos, mas essa é apenas uma orientação. Essa reunião também é chamada de "stand-up diário", enfatizando que deve ser uma reunião rápida. O objetivo do Scrum diário é que todos os membros da equipe estejam de acordo, alinhados com o objetivo do sprint, e façam um plano para as próximas 24 horas.

    O stand up é o momento de expressar todas as suas preocupações com relação à possibilidade de atingir o objetivo do sprint ou a quaisquer obstáculos.

    Uma maneira comum de conduzir um stand up é que cada membro da equipe responda três perguntas no contexto de atingir o objetivo do sprint:

    O que eu fiz ontem?
    O que planejo fazer hoje?
    Existe algum obstáculo?

    No entanto, pode ser que as pessoas fiquem lendo suas respectivas listas de tarefas do dia anterior ou posterior durante a reunião. A teoria por trás do stand up é de que ele serve para concentrar a conversa em uma reunião diária, para que a equipe possa se concentrar no trabalho o resto do dia. Então, se ela se tornar apenas uma leitura da lista de tarefas do dia, não tenha medo de mudá-la e de ser criativo.

  5. Revisão do sprint: ao final do sprint, a equipe se reúne para uma sessão informal na qual é feita uma demonstração do incremento ou para o inspecionar. A equipe de desenvolvimento mostra os itens do backlog que agora estão "concluídos" para que os interessados e os colegas de equipe deem um feedback. O proprietário do produto pode decidir se lança ou não o incremento, embora, na maioria dos casos, o incremento seja lançado.

    Essa reunião de revisão também serve para quando o proprietário do produto retrabalha o backlog do produto com base no sprint atual, que pode ser lançado na próxima sessão de planejamento do sprint. Para um sprint de um mês, considere definir o tempo de revisão do sprint para no máximo quatro horas.

  6. Retrospectiva do sprint: a retrospectiva é onde a equipe se reúne para documentar e discutir o que funcionou e o que não funcionou em um sprint, um projeto, pessoas ou relações, ferramentas, ou até mesmo para determinadas cerimônias. A ideia é criar um lugar em que a equipe possa focar o que deu certo e o que precisa ser melhorado, menos o que deu errado.

Três funções essenciais para o sucesso do scrum

Uma equipe de Scrum precisa de três funções específicas: proprietário do produto, Scrum master e equipe de desenvolvimento. E, como as equipes de Scrum são multifuncionais, a equipe de desenvolvimento inclui testadores, designers, especialistas em experiência do usuário, engenheiros de operações e, acima de tudo, de desenvolvedores.

O proprietário do produto do Scrum

Os proprietários do produto são os defensores de seu produto. Eles se concentram em entender as necessidades dos negócios, dos clientes e do mercado, para então e priorizar o trabalho a ser feito pela equipe de engenharia. Proprietários do produto efetivos:

  • criam e gerenciam o backlog do produto;
  • os proprietários do produto trabalham em estreita colaboração com o negócio e com a equipe para garantir que todos entendam os itens de trabalho no backlog do produto;
  • eles dão à equipe uma orientação clara sobre quais recursos devem ser entregues a seguir;
  • eles decidem quando lançar o produto com uma predisposição para a entrega mais frequente.

Nem sempre o proprietário do produto é o gerente de produto. Os proprietários do produto focam a garantia de que a equipe de desenvolvimento vai entregar o valor máximo para o negócio. Além disso, é importante que exista apenas um proprietário do produto. Até porque nenhuma equipe de desenvolvimento quer orientação discrepante de vários proprietários.

O Scrum master

Os Scrum masters são os campeões do Scrum dentro de suas equipes. Eles treinam equipes, proprietários do produto e o negócio no processo de Scrum e buscam maneiras de ajustar sua prática.

Um Scrum master eficiente entende todo o trabalho que está sendo feito pela equipe e a ajuda a otimizar sua transparência e fluxo de entrega. Como facilitador chefe, ele planeja os recursos necessários (humanos e logísticos) para o planejamento do sprint, stand-up, revisão do sprint e retrospectiva do sprint.

A equipe de desenvolvimento do Scrum

As equipes de Scrum fazem as coisas acontecer. Elas são as defensoras das práticas de desenvolvimento sustentáveis. As equipes de Scrum mais eficazes são coesas, co-localizadas e têm, em média, de cinco a sete membros. Uma maneira de decidir o tamanho da equipe é usar a famosa "regra das duas pizzas" cunhada por Jeff Bezos, CEO da Amazon (a equipe deve ser pequena o suficiente para compartilhar duas pizzas).

Os membros da equipe têm conjuntos de habilidades diferentes, que são compartilhados entre eles para que ninguém prejudique a entrega do trabalho. As equipes de Scrum fortes são auto-organizáveis e abordam seus projetos impondo uma atitude "coletiva" bem clara. Todos os membros da equipe se ajudam para garantir a conclusão bem-sucedida do sprint.

A equipe de Scrum direciona o plano para cada sprint. Ela prevê quanto trabalho acredita que pode concluir durante a iteração usando sua velocidade histórica como guia. Manter fixa a duração da iteração dá à equipe de desenvolvimento um feedback importante sobre seu processo de estimativa e entrega, que, por sua vez, torna suas previsões cada vez mais precisas com o passar do tempo.

Scrum, Kanban e agilidade

O Scrum é uma estrutura do Agile tão popular que o Scrum e o Agile são quase sempre confundidos um com o outro. Mas há outras estruturas, como o Kanban, que é uma alternativa popular. Algumas empresas optam até mesmo por seguir um modelo híbrido de Scrum e Kanban, que recebeu o nome de "Scrumban" ou Kanplan, que é o Kanban com um backlog.

Tanto o Scrum quanto o Kanban usam métodos visuais, como o painel do Scrum ou o painel do Kanban, para controlar o progresso do trabalho. Ambos enfatizam a eficiência e dividem tarefas complexas em partes menores de trabalho gerenciáveis, mas suas abordagens em relação ao objetivo são diferentes.

O Scrum foca em iterações menores, de duração fixa. Depois de finalizado o prazo de um sprint, as histórias ou as entradas do backlog do produto que podem ser implementadas durante esse ciclo do sprint são, então, determinadas. No Kanban, no entanto, o número de tarefas ou o trabalho em andamento (limite WIP) a ser implementado no ciclo atual é fixo no início. O cálculo do tempo que leva para implementar esses recursos é retroativo.

O Kanban não é tão estruturado quanto o Scrum. Diferente do limite WIP, ele é bem aberto à interpretação. Já o Scrum tem vários conceitos categóricos aplicados como parte de sua implementação, como a revisão do sprint, a retrospectiva, o scrum diário, etc. Ele também insiste na multifuncionalidade, que é a capacidade de uma equipe do Scrum de não depender de membros externos para atingir seus objetivos. Reunir uma equipe multifuncional não é simples. Nesse sentido, o Kanban é mais fácil de ser adaptado, enquanto o Scrum pode ser considerado como uma mudança fundamental no processo de reflexão e no funcionamento de uma equipe de desenvolvimento.

Mas por que o Scrum?

O Scrum em si é simples. As regras, os artefatos, os eventos e as funções são fáceis de entender. Na verdade, a abordagem semiprescritiva do Scrum ajuda a eliminar as ambiguidades no processo de desenvolvimento e, ao mesmo tempo, fornece espaço suficiente para as empresas incluírem suas próprias preferências.

A organização de tarefas complexas em histórias de usuário gerenciáveis o torna ideal para projetos difíceis. Além disso, a demarcação clara de funções e de eventos planejados garante que haja transparência e propriedade coletiva durante todo o ciclo de desenvolvimento. Lançamentos rápidos mantêm a equipe motivada e os usuários felizes, pois eles podem ver progresso em um pouco tempo.

No entanto, pode levar tempo para dominar o uso do Scrum, em especial, se a equipe de desenvolvimento não estiver familiarizada com um modelo em cascata típico. Os conceitos de iterações menores, reuniões de Scrum diárias, revisões de sprint e identificação de um Scrum master podem ser uma mudança cultural desafiadora para uma equipe nova.


Mas os benefícios de longo prazo superam a curva de aprendizagem inicial. O sucesso do Scrum no desenvolvimento de produtos complexos de hardware e software em diversos setores e verticais fazem dele uma estrutura atraente que sua organização deve adotar.

Claire Drumond
Claire Drumond

Claire Drumond é estrategista de marketing, palestrante e redatora da Atlassian. É autora de diversos artigos publicados nos blogs do Trello e da Atlassian e sempre contribui para várias publicações do Medium, que incluem a HackerNoon, a Art+Marketing e a PoetsUnlimited. Ela dá palestras em conferências de tecnologia no mundo todo sobre método ágil, quebra de silos e desenvolvimento de empatia.

a seguir
Sprints