O que é scrum e como começar

As pessoas costumam pensar que Scrum e Ágil são a mesma coisa porque o primeiro é centrado na melhoria contínua, que é um princípio fundamental do segundo. No entanto, o Scrum é uma estrutura para realizar o trabalho, enquanto o Ágil é uma filosofia. A filosofia Ágil gira em torno da melhoria incremental contínua com lançamentos pequenos e frequentes. Ninguém consegue "se tornar ágil" de repente porque isso demanda dedicação de toda a equipe para mudar a forma de pensar sobre como entregar valor aos clientes. Mas você pode usar uma estrutura como o Scrum para começar a pensar dessa forma e a praticar o desenvolvimento de princípios ágeis na sua comunicação e trabalho cotidianos.

Você encontra a diferença entre esses dois conceitos no guia Scrum e no Manifesto Ágil, que define quatro valores:

• Indivíduos e interações acima de processos e ferramentas.

• Software em funcionamento acima de documentação abrangente.

• Colaboração com clientes acima de negociação de contratos.

• Responder a mudanças acima de seguir um plano.

A definição de Scrum é baseada no empirismo e no pensamento enxuto. O empirismo diz que o conhecimento vem da experiência e que as decisões são tomadas com base no que é observado. O pensamento enxuto reduz o desperdício e se concentra no essencial. A estrutura do Scrum é heurística. Ela é baseada no aprendizado contínuo e na adaptação aos fatores variáveis. O Scrum reconhece que a equipe não sabe tudo no início de um projeto e que vai evoluir com a experiência. Ele é estruturado para ajudar as equipes a se adaptarem com naturalidade às alterações nas condições e nos requisitos dos usuários, com a repriorização incorporada ao processo e ciclos curtos de lançamento para que a equipe aprenda e melhore sempre.

Embora o Scrum seja estruturado, ele não é rígido por completo. Ele pode ser adaptado às necessidades de qualquer organização. Há diversas teorias sobre o modo exato de como as equipes do Scrum devem trabalhar para se tornar bem-sucedidas. No entanto, após mais de uma década ajudando as equipes ágeis a concluírem trabalhos na Atlassian, aprendemos que a comunicação clara, a transparência e a dedicação ao aprimoramento contínuo devem sempre ser o foco de qualquer estrutura que você escolher. E o resto é com você.

A estrutura do Scrum descreve um conjunto de valores, princípios e práticas que as equipes do Scrum seguem para entregar um produto ou serviço. Ela detalha os membros de uma equipe do Scrum e suas responsabilidades, “artefatos” que definem o produto e o trabalho para criar o produto, assim como cerimônias de Scrum que orientam a equipe durante o trabalho.

Uma equipe de Scrum é pequena, ágil e dedicada a oferecer incrementos de produtos comprometidos.O tamanho da equipe de Scrum no geral é pequeno, com cerca de 10 pessoas, mas é grande o suficiente para concluir uma parte substancial do trabalho com um sprint. A equipe de Scrum precisa de três funções específicas: proprietário do produto, Scrum Master e equipe de desenvolvimento. Como as equipes de Scrum são multifuncionais, a equipe de desenvolvimento inclui testadores, designers, especialistas em experiência do usuário e engenheiros de operações, além de desenvolvedores.

O proprietário do produto do Scrum

Os proprietários são os principais defensores de seus respectivos produtos. Eles têm como foco compreender os requisitos da empresa, dos clientes e do mercado, para então priorizar e adequar o trabalho a ser feito pela equipe de engenharia. Proprietários do produto eficientes:

• criam e gerenciam o backlog do produto

• estabelecem uma parceria estreita com a empresa e a equipe para garantir que todos compreendam os itens de trabalho no backlog do produto

• orientam claramente a equipe sobre quais funções entregar em seguida

• decidem quando lançar o produto com uma predisposição para entregas mais frequentes

Nem sempre o proprietário do produto é o gerente do produto. Os proprietários do produto têm como prioridade garantir que a equipe de desenvolvimento agregue o máximo de valor aos negócios. Além disso, é importante que o proprietário do produto seja apenas uma pessoa. Além disso, é importante que exista apenas um proprietário do produto. Até porque nenhuma equipe de desenvolvimento quer orientações discrepantes de vários proprietários.

O Scrum Master

Os Scrum Masters são defensores do Scrum dentro de suas respectivas equipes. Eles orientam as equipes, os proprietários do produto e a empresa sobre o processo de Scrum, além de buscar maneiras de melhorar a prática.

Um Scrum Master eficiente entende a fundo todo o trabalho que está sendo feito pela equipe e a ajuda a otimizar a transparência e o fluxo de entrega. Como facilitador principal, essa pessoa reserva os recursos necessários (humanos e logísticos) para as reuniões de planejamento, stand-up, revisão e retrospectiva do sprint.

A equipe de desenvolvimento do Scrum

As equipes de Scrum fazem acontecer. Elas são as defensoras das práticas de desenvolvimento sustentáveis. As equipes de Scrum mais eficientes são unidas, compartilham o mesmo local e costumam ser compostas por 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 dividir duas pizzas).

Os membros da equipe têm diferentes conjuntos de habilidades, que são passadas de um para o outro para que nenhum deles se torne um obstáculo para a entrega do trabalho. Equipes de Scrum fortes se organizam e abordam os projetos com uma nítida atitude coletiva. Todos os membros da equipe se ajudam para garantir a conclusão bem-sucedida do sprint.

A equipe de Scrum conduz o plano de cada sprint. Ela prevê quanto trabalho acredita que pode concluir durante a iteração se guiando pelo próprio histórico de velocidade. Ao manter fixa a duração da iteração, a equipe de desenvolvimento tem um feedback importante sobre seu processo de estimativa e entrega, o que, por sua vez, torna suas previsões cada vez mais precisas com o passar do tempo.

Os

artefatos do Scrum são informações importantes usadas pela equipe de Scrum que ajudam a definir o produto e o trabalho a ser feito para criar o produto. No Scrum, os três artefatos são o backlog do produto, o backlog do sprint e o incremento com a definição de "concluído". São as três constantes sobre as quais a equipe de Scrum deve refletir durante os sprints e ao longo do tempo.

• Backlog do produto é a lista principal de trabalho que precisa ser feito e administrado 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 de 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, ou seja, 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 duas 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 é possível perceber, há muitas variações, mesmo dentro dos artefatos, que sua equipe pode escolher definir. Por isso, é importante manter abertura para mudanças na maneira como você mantém até mesmo seus artefatos. Talvez sua definição de "concluído" estresse sua equipe e você precise voltar e escolher uma nova definição.

A estrutura do Scrum inclui práticas, cerimônias e reuniões de Scrum que as equipes fazem com regularidade. É nas cerimônias ágeis que a gente vê as maiores diferenças entre as equipes. Por exemplo, algumas consideram todas essas cerimônias como tarefa complexa e repetitiva. Em outras, são usadas como verificação necessária. A gente aconselha a, no começo, usar todas as cerimônias em dois sprints e, então, ver no que deu. Você pode fazer uma retrospectiva rápida e ver o que precisa ser ajustado.

Veja abaixo uma lista de todas as principais cerimônias de que uma equipe de Scrum pode participar:

1. Organização do backlog: às vezes chamado de revisão de tarefas, este evento é de responsabilidade do proprietário do produto. As principais funções do proprietário são alinhar o produto à sua visão e estar sempre de olho no mercado e no cliente. Por isso, ele se baseia no feedback dos usuários e da equipe de desenvolvimento para ajudar a priorizar a lista e a manter organizada e pronta para ser trabalhada a qualquer momento. Leia mais sobre como manter um bom backlog aqui.

2. Planejamento de sprint: durante esta reunião, toda a equipe de desenvolvimento planeja o trabalho a ser executado (escopo) no sprint atual. Ela é conduzida pelo Scrum Master e é onde a equipe decide a meta do sprint. Histórias de usuários específicas são então adicionadas ao sprint a partir do backlog do produto.  Essas histórias sempre se alinham à meta e são acordadas pela equipe de Scrum para viabilizar a implementação durante o sprint.

   No final da reunião de planejamento, o que pode ser entregue no sprint e como o incremento pode ser entregue precisa estar claro para todos os membros do Scrum.

3. Sprint: um sprint é o período real em que a equipe de Scrum trabalha em conjunto para concluir um incremento. Duas semanas é uma duração bastante comum para um sprint, embora algumas equipes considerem mais fácil analisar em uma semana e oferecer um incremento valioso em um mês. Dave West, do Scrum.org, diz que quanto mais complexo o trabalho e quanto mais incógnitas, menor deve ser o sprint. Mas fica a cargo da sua equipe, e você não precisa ter medo de mudar isso se não estiver dando certo. Durante esse período, o escopo pode ser renegociado entre o proprietário do produto e a equipe de desenvolvimento, se necessário. Isso é a base da natureza empírica do Scrum.

   Todos os eventos, do planejamento à retrospectiva, acontecem durante o sprint. Uma vez estabelecido um determinado intervalo para um sprint, ele deve permanecer consistente durante todo o período de desenvolvimento. Isso ajuda a equipe a aprender com experiências passadas e aplicar essa visão em sprints futuros.

4. Scrum diário ou reunião rápida diária: esta é uma reunião diária bem curta que acontece sempre no mesmo horário (geralmente de manhã) e tem por objetivo simplificar as coisas. Muitas equipes tentam concluir a reunião em 15 minutos, mas isso é apenas uma referência. Como o próprio nome já diz, ela deve ser rápida. O objetivo do Scrum diário é que todos na equipe estejam na mesma página, alinhados com a meta do sprint, e elaborem um plano para as próximas 24 horas.

   Esta é a hora de expressar qualquer preocupação relacionada ao cumprimento da meta do sprint ou a algum obstáculo.

   Uma forma comum de conduzir uma reunião diária é pedir que cada membro da equipe responda a três perguntas sobre a conquista da meta do sprint:
   
   • O que eu fiz ontem?
   • O que pretendo fazer hoje?
   • Há algum obstáculo?
   
   Porém, reparamos que a reunião logo se transforma em uma recitação do que está na agenda do dia anterior e do seguinte. Na teoria, o objetivo dessa reunião é jogar conversa fora para que a equipe possa se concentrar no trabalho pelo resto do dia.  Então, se ela se transformar em uma leitura diária da agenda, não tenha medo de mudá-la. Solte a criatividade!

5. Revisão de sprint: no final do sprint, a equipe se reúne em uma sessão informal para ver uma demonstração do incremento ou inspecioná-lo. A equipe de desenvolvimento mostra os itens do backlog que agora estão concluídos às partes interessadas e colegas de equipe para obter feedback. O proprietário do produto pode decidir se quer ou não lançar o incremento, mas na maioria dos casos ele é lançado.

   Essa reunião de revisão também ocorre quando o proprietário do produto retrabalha o backlog com base no sprint atual, o que pode contribuir para a próxima sessão de planejamento do sprint. Para um sprint de um mês, considere ajustar o tempo da revisão de sprint para no máximo quatro horas.

6. Retrospectiva do sprint: na retrospectiva, a equipe se reúne para documentar e discutir o que funcionou ou não em um sprint, um projeto, pessoas ou relacionamentos, ferramentas ou até mesmo determinadas cerimônias. A ideia é criar um ambiente onde a equipe possa se concentrar mais no que foi bem e no que precisa melhorar na próxima vez, e menos no que deu errado.

Em 2016, cinco valores foram incluídos no Guia do Scrum. Esses valores orientam o trabalho, as ações e o comportamento da equipe de Scrum e são considerados essenciais para o sucesso dela.

Compromisso

Como as equipes de Scrum são pequenas e ágeis, cada membro desempenha um papel importante para que tudo dê certo. É por isso que todos os membros precisam se comprometer em executar as tarefas que eles conseguem concluir, sem se sobrecarregar. Deve haver uma comunicação frequente sobre o progresso do trabalho, quase sempre em reuniões rápidas.

Coragem

A coragem para a equipe de Scrum é a ousadia de questionar o status quo ou qualquer coisa que prejudique a chance de sucesso. Os membros da equipe de Scrum devem ser corajosos e seguros o suficiente para experimentar coisas novas. A equipe de Scrum precisa ter coragem e segurança para ser transparente com relação aos obstáculos, progresso do projeto, atrasos e assim por diante.

Foco

No coração do fluxo de trabalho das equipes de Scrum está o sprint, um período específico e direcionado em que a equipe conclui uma determinada quantidade de trabalho. O sprint proporciona uma estrutura e o foco para concluir o trabalho planejado.

Abertura

A reunião rápida diária permite que as equipes falem com clareza sobre trabalhos em andamento e bloqueadores. Na Atlassian, as equipes de Scrum costumam responder a estas questões:

• No que eu trabalhei ontem?

• No que vou trabalhar hoje?

• Quais problemas são obstáculos?

Isso ajuda a destacar o progresso e a identificar os bloqueadores. Além disso, quando todos compartilham seus progressos, a equipe fica mais forte.

Respeito

A força da equipe ágil está na colaboração e no reconhecimento de que cada membro contribui para trabalhar em um sprint. Eles celebram suas conquistas e respeitam uns aos outros, o proprietário do produto, as partes interessadas e o Scrum Master.

O Scrum é uma estrutura ágil tão popular que, muitas vezes, o Scrum e o ágil são confundidos. No entanto, há outras estruturas, como o Kanban, que é uma alternativa conhecida. Algumas empresas ainda optam por seguir um modelo híbrido de Scrum e Kanban, que levou o nome "Scrumban" ou "Kanplan," que é o Kanban com backlog. 

O Scrum e o Kanban usam métodos visuais, como o quadro Scrum ou o quadro Kanban para monitorar o progresso do trabalho. Os dois enfatizam a eficiência e a divisão de tarefas complexas em partes menores de trabalho gerenciável, mas as abordagens em direção a essa meta são diferentes.

O Scrum foca iterações menores de duração fixa. Assim que o período do sprint é finalizado, as histórias ou as entradas de backlog do produto que podem ser implementadas durante esse ciclo de sprint são, então, determinadas. No Kanban, entretanto, o número de tarefas ou de trabalho em andamento (limite de WIP) a ser implementado no ciclo atual é fixado desde o início. O tempo que se leva para implementar essas funções é, então, calculado de trás para frente.

O Kanban não é tão estruturado como o Scrum. Além do limite de WIP, ele é bastante aberto a interpretações. No entanto, o Scrum tem diversos conceitos categóricos aplicados como parte da implementação, tais como análise de sprint, retrospectiva, Scrum diário etc. Ele também insiste na multidisciplinaridade. Isto é, a equipe do Scrum consegue não depender de membros externos para alcançar os objetivos. Montar uma equipe multidisciplinar não é tarefa simples. Nesse sentido, o Kanban é mais fácil de adaptar, ao passo que o Scrum pode ser considerado uma mudança fundamental no processo de reflexão e no funcionamento da equipe de desenvolvimento.

A estrutura do 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 faz dele 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 pouco tempo.

No entanto, pode levar tempo para entender o Scrum por completo, especialmente 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.

Para aprender Scrum com o Jira, consulte este tutorial.