Scrum: entenda de uma vez por todas o que é, como ele aumenta expressivamente os seus resultados e porquê utilizá-lo

Por Roque Sales, CX & UX Manager da Zappts

O Scrum é um framework para desenvolver e manter produtos complexos. A metodologia foi definida no guia escrito pelos seus criadores, Ken Schwaber e Jeff Sutherland, e intitulado Guia Do Scrum.

Dentro desse framework, pessoas podem tratar e resolver problemas igualmente complexos e adaptativos, enquanto produtiva e criativamente entregam produtos da melhor forma e com o mais alto valor possível. O instrumento para isso é o desempenho de papéis, eventos e artefatos unidos e integrados por regras específicas.

O Scrum está sendo usado desde o início de 1990 e continua relevante até hoje. Isso acontece pois ele foi idealizado para ser inerentemente leve e simples de entender, porém extremamente difícil de dominar, como um jogo de pôquer.

Para explicar isso de forma aprofundada, é necessário entender o paradigma inicial da indústria de desenvolvimento e o como e porquê ele foi modificado. Começaremos conhecendo um pouco mais sobre as metodologias de desenvolvimento.

As Metodologias de Desenvolvimento

A Metodologia Tradicional

No início da indústria de desenvolvimento de software, a metodologia utilizada para gestão de projetos consolidou-se em fases bem definidas. Eram elas:

• levantamento de requisitos,
• análise de requisitos para esboço da arquitetura,
• implementação via código/programação,
• testes,
• lançamento do produto,
• e suporte/manutenção.

Essa metodologia foi posteriormente denominada Cascata (ou Waterfall), pois cada fase é executada hierarquicamente, uma após a outra. Uma fase só começa quando a anterior termina.

A Cascata é planejada em reunião com o cliente. A forma como isso é feito não admite mudanças, pois tudo é estabelecido logo no começo do processo. Todos os requisitos, escopos de produto e de projeto e, consequentemente, planejamento de custos são fixos. Não há análise de riscos ou maior participação do cliente até a entrega do produto finalizado.

Por ser um processo tão baseado em fases, ele acaba sendo demorado e engessado. Essa demora impede que os clientes tenham o desenvolvimento de entregáveis na velocidade que necessitam.

A longo prazo, isso gera sistemas já lançados em tecnologias ultrapassadas ou com carência de funcionalidades específicas para a resolução do problema proposto inicialmente, que pode ter mudado durante o desenvolvimento do sistema.

Além disso, cada profissional do time fica responsável por uma parte do projeto e não se comunica com frequência, sem muita consideração pelas “skills” de cada um. Para neutralizar esses problemas e diminuir a burocracia envolvida, surgiram as metodologias ágeis.

As Metodologias Ágeis

Nas metodologias ágeis (muitas vezes encurtadas para Ágil ou Agile), o time discute e elabora em conjunto a entrega do produto final.

Há distribuição de tarefas conforme o conhecimento técnico e o desempenho de cada integrante. Isso garante a viabilidade do planejamento ao levar em conta as peculiaridades dos indivíduos envolvidos.

A implementação de projetos é feita de forma cíclica e iterativa. Um projeto é composto por vários ciclos. Sempre é considerada sua efetividade na resolução dos problemas e dores propostos pelo cliente. Muitas vezes ele passa por adaptações ao final de cada ciclo de acordo com as demandas que acabam surgindo.

Isso significa que os métodos ágeis são flexíveis e proporcionam entregas constantes para o cliente, sempre levando em conta seu feedback. Contraste ao método tradicional de desenvolvimento de software.

A sinergia da equipe de desenvolvimento é imprescindível para que a Agilidade funcione. Essa sinergia, nesse caso, não é restrita apenas à equipe. Ela deve se estender a todos os indivíduos e setores envolvidos no projeto, para que o time de desenvolvimento possa manter seu foco e performance altos.

Ao identificar falhas de gestão ou de comunicação, a equipe deve utilizar de todos os agentes disponíveis na organização para neutralizá-las. Sendo, assim, autossuficiente no seu gerenciamento de riscos, processos e resultados.

Exemplos e Características de Metodologias Ágeis

O conceito de metodologia ágil foi baseado no Lean Manufacturing. O Lean é um modelo de manufatura utilizado pela Toyota após a Segunda Guerra Mundial. Mas ele só foi formalizado em 2001, pelo Manifesto Ágil.

Semelhanças comuns a todas as Metodologias Ágeis

Algumas das metodologias ágeis mais utilizadas nas empresas atualmente são o Scrum e o Kanban. O que elas têm em comum, além da Agilidade, é um conjunto de práticas baseadas em certos valores, discriminados no Manifesto Ágil como:

• Priorizar indivíduos e interações mais do que processos e ferramentas. Todas as pessoas envolvidas no processo devem trabalhar em conjunto e diariamente, comunicando-se de forma constante e aberta. Todos devem buscar sempre manter um ambiente de trabalho sustentável que propicie suporte, motivação e confiança.
• Valorizar o bom funcionamento do software mais do que a documentação abrangente. Software funcional feito de forma rápida e com qualidade é a medida primária de progresso.
• Colaborar com o cliente mais do que negociar contratos.
• Responder a mudanças mais do que seguir um plano. Avaliar o progresso do projeto a cada ciclo e aceitar mudanças de requisitos mesmo no fim do desenvolvimento. Assim o cliente pode tirar vantagens competitivas.
• Maximizar a quantidade de trabalho que não precisou ser feito ao primar por excelência técnica dos membros do time e por design e usabilidade simples e intuitivos.
• Construir, pela convivência diária, times auto-organizáveis. Os membros do time refletem sobre maneiras de aumentar sua produtividade e efetividade com base nos resultados de cada ciclo. Assim, ajustam seu comportamento a fim de otimizar sua sinergia e aumentar sua frequência de entregas.

Diferenças entre Scrum e Kanban

Já o que as diferencia é:

• O Scrum é sobre autogestão e sobre como os desenvolvedores interagem e o que fazem quando não estão escrevendo código.
• O Kanban é sobre evitar desperdício de recursos e otimizar a produção. Isso acontece ao limitar a carga de trabalho de cada desenvolvedor. É criada uma visualização do fluxo de recursos na linha de produção com post-its em um quadro.

O Kanban é contínuo e o Scrum é iterativo. O Scrum tem ciclos fechados com objetivos definidos que se repetem, enquanto o Kanban é mais adequado para times que possuem trabalho não planejado à vista. Por exemplo, problemas de suporte e funcionalidades requisitadas emergencialmente – pois não possui ciclos.

Agora, após esse conteúdo introdutório, vamos abordar o Scrum. Definiremos o que ele é, mostrando de onde ele veio, e destrinchando todos os seus papéis, eventos, artefatos e regras.

E então, o que é o Scrum?

Origem do termo Scrum

O nome veio do rugby, no esporte, há um movimento chamado Scrum. Ocorre quando os jogadores dos dois times formam um círculo ao redor da bola, encostando suas cabeças e medindo forças para pegá-la.

O Scrum é considerado uma demonstração da força e união da equipe para atingirem seu objetivo.

É por isso que a metodologia ágil abordada aqui adotou esse mesmo nome.

Diferença entre Scrum e Agile

É comum ter a impressão de que esses termos são iguais. Entretanto, Agile é um conjunto de métodos e práticas baseadas nos valores expressos no Manifesto Ágil.

Já o Scrum não é um processo ou uma técnica para construir produtos. Ele é uma estrutura metodológica (ou framework) incremental que é usada para implementar o desenvolvimento Ágil. Você pode empregar vários processos ou técnicas para isso.

O Scrum deixa clara a eficácia das práticas de gerenciamento e desenvolvimento de produtos das empresas em que é implementado, de modo que elas possam melhorar essas práticas.

O framework consiste nos times Scrum associados a papéis, desempenhados por membros da equipe durante eventos, com auxílio de artefatos.

Como descrito no Guia Do Scrum, cada componente dentro do framework serve a um propósito específico e é essencial para o uso e sucesso do Scrum. As regras integram os eventos, papéis e artefatos, administrando as relações e interações entre eles.

De onde o Scrum surgiu?

O criador do Scrum

Jeff Sutherland trabalhou como militar no exército dos Estados Unidos durante 11 anos. Após esse período, ele decidiu estudar Medicina na Universidade do Colorado. Ele acabou se envolvendo com coleta de dados e desenvolvimento de sistemas.

Durante os anos 90, Sutherland enxergou um problema recorrente na sua nova área de interesse. Empresas que demandavam projetos de software com um cronograma apertado e orçamento incompatível. Ele decidiu encontrar uma solução para esse problema.

O grande diferencial do Scrum

Pesquisando, Sutherland acabou chegando ao Lean Manufacturing utilizado na Toyota e em outras empresas japonesas. Com auxílio de Ken Schwaber, criou a metodologia Scrum com base nesse sistema de manufatura.

Depois de provada a eficácia do Scrum por uma série de sucessos, essa nova metodologia popularizou-se rapidamente na indústria de desenvolvimento de produtos.

O Scrum representa a troca da visão algorítmica de projetos para uma visão heurística. As pessoas e a autogestão são a chave para resolver problemas. Eles são priorizados em tarefas individuais e delegados aos membros da equipe mais bem preparados para cada uma delas.

A Equipe Scrum

Times (ou Equipes) Scrum são auto-organizáveis e multifuncionais. Ser auto-organizável significa que os membros é que escolhem a melhor forma de realizar seu trabalho, ao invés de serem dirigidos por pessoas fora da equipe. Ser multifuncional significa que uma equipe tem nela todas as competências necessárias para realizar o trabalho sem depender de agentes externos.

O modelo de equipe do Scrum foi pensado para otimizar a flexibilidade, a criatividade e a produtividade. Geralmente um time possui de três a dez membros. Quando dez pessoas não dão conta do trabalho, o time é dividido em dois. Novos membros são adicionados a cada nova equipe, junto com os membros originais.

Dependendo do tamanho do projeto e da quantidade de times, é aconselhado aplicar o Scrum of Scrums, que abordaremos mais adiante. Os membros do time desempenham papéis específicos.

Product Owner: O Dono do Produto

O papel desta pessoa é representar os interesses do usuário final, sendo a ponte entre o time técnico – representado pelo Scrum Master – e os demais stakeholders. O PO estará sempre balanceando as demandas dessas duas partes.

Esse membro tem autoridade para dizer o que vai fazer parte do produto final ou não. Normalmente ele é um usuário chave do sistema, ou um usuário com boa compreensão dos requisitos e do que ele e outros usuários precisam.

O Product Owner precisa saber Programar?

Ele pode tanto ser alguém com background técnico (alguém que já foi um desenvolvedor front end ou um UX designer, por exemplo) como pode não ser (um analista de negócios, o CEO da empresa ou o próprio cliente).

Apesar de ser listado como parte da equipe Scrum, o Product Owner não é um elemento integrante dela.

Sua presença e disponibilidade para a equipe são constantes mas ele não faz parte do processo de desenvolvimento. O que ele faz é mais ligado a estratégias de negócio e entrega de valor. Sua função é muito mais “política” do que técnica.

O Product Owner é responsável pelo Product Backlog, que é uma lista de tarefas descrevendo as funcionalidades necessárias do produto final e ordenadas por prioridade. Quem determina o grau de prioridade de cada tarefa é o Product Owner, baseando-se no valor de negócio e no ROI previsto delas.

Para isso, ele deve ter entendimento claro e profundo da visão do produto, ter autonomia para tomada de decisões, e ser comunicativo o suficiente para poder transmiti-las claramente para o resto do time.

Scrum Master: O Dono do Processo

O papel do Scrum Master é garantir que os valores e regras do Scrum sejam seguidos cotidianamente pelo resto do time. Ele é responsável por decidir o tamanho dos ciclos de desenvolvimento de software. No Scrum, esses ciclos são chamados de Sprints. Cada Sprint pode durar de uma a quatro semanas.

Além disso, ele é o intermediário entre a equipe de desenvolvedores e o Product Owner. O Scrum Master serve de “alívio” para que o Product Owner possa focar nas estratégias de negócio e na entrega de valor com os demais stakeholders. Enquanto isso, o Scrum Master lida diretamente com o time de desenvolvedores e gerencia o Sprint Backlog.

Por quê Dono do Processo?

O Scrum Master pode ser chamado informalmente de Dono do Processo pois ele é o membro que equilibra as relações internas e externas da equipe Scrum. Ele lida diretamente com o Product Owner e com o time de desenvolvimento, mas pode transitar entre outros setores da empresa ou entre outros stakeholders, por exemplo.

Isso acontece pois a outra responsabilidade do Scrum Master, além do Sprint Backlog, é blindar os desenvolvedores. Ele filtra quais informações chegam aos “devs” e evita interferências no Sprint, trabalhando sempre para resolver qualquer impedimento ao progresso da equipe.

Durante o Sprint, este membro age como mentor e gestor dos desenvolvedores, conversando com eles constantemente para resolver possíveis impedimentos. “Minha máquina está com problema e por isso não consigo programar”, “não tenho conhecimento suficiente nessa tecnologia para executar essa tarefa”, “o colega que senta ao meu lado está me irritando”, “sou interrompido muitas vezes durante o dia”, entre outros obstáculos técnicos ou pessoais, por exemplo.

O SM sempre mantém o Sprint Backlog atualizado para analisar a performance individual e coletiva. Além disso, ele vê quais tarefas são completadas e em quanto tempo, assim prevendo e ordenando quais tarefas terão de ser adiadas para o Sprint seguinte.

A estimativa do trabalho que não pode ser adiado para o próximo Sprint é calculada todos os dias, e colocada em um gráfico chamado de Sprint Burndown Chart (ou apenas Burndown Chart — Gráfico de Queima, em tradução livre).

Mentor e Facilitador para os Desenvolvedores

Sendo mentor dos desenvolvedores, o SM precisa mantê-los motivados e certificar-se de que as tarefas do Sprint estão sendo executadas do jeito certo. Ele faz isso levando os pedidos do PO e dos demais stakeholders em consideração.

Entretanto, a autoridade e autonomia do SM são menores do que as do PO, já que seu escopo de ação é restringido ao time de desenvolvedores.

As medidas de blindagem que ele pode tomar acabam dependendo da colaboração de agentes externos à equipe Scrum. Por isso, é importante que o SM seja um bom negociador e saiba conversar com os stakeholders de forma amigável.

O Scrum Master precisa saber Programar?

O background técnico do Scrum Master na área de software, assim como o do Product Owner, é opcional. Porém, é interessante que ele entenda ao menos o básico dos conceitos de desenvolvimento e das tecnologias aplicadas ao projeto da sua equipe. Isso lhe trará mais segurança ao garantir a qualidade dos entregáveis.

O Scrum Master não é responsável pela execução das tarefas do Sprint, mas precisa assegurar que essa execução é feita da melhor maneira possível dentro das capacidades, limitações e acordos do time.

Desenvolvedores

Quando se fala de Time Scrum, os primeiros membros a serem mencionados geralmente são os desenvolvedores de software.

Na equipe de desenvolvedores, é necessário que os membros sejam alocados de forma que qualquer problema no software possa ser solucionado por eles em sua totalidade, sem ajuda externa.

Não existe necessariamente uma divisão dos membros por funções desempenhadas individualmente. Como, por exemplo, designer, front end, back end, arquiteto, analista de testes…

No Scrum, todos os membros trabalham juntos para entregar ao final de um Sprint aquilo que foi prometido no início dele. Por isso, todos acabam sendo fullstack em maior ou menor grau.

O Scrum é baseado em refletir sobre o desempenho passado com transparência e comprometimento. Todos os integrantes sabem o que cada um está fazendo e como cada tarefa está progredindo. Todos se comprometem em mudar o que for necessário para melhorar o desempenho da equipe.

É importante que a equipe permaneça ágil, integrada e comunicativa. Fazer parte de um time sinérgico acaba naturalmente ajudando todos os membros a se manterem motivados e empenhados em criar um processo mais eficiente.

Artefatos Scrum

Os Artefatos Scrum são disseminadores de informação que representam trabalho ou valor. Eles fornecem transparência ao dar oportunidades de inspeção e adaptação do processo de desenvolvimento.

Eles são projetados especificamente para maximizar a transparência de informações, para que todos os stakeholders tenham o mesmo entendimento do conteúdo de cada artefato.

Os artefatos obrigatórios do Scrum são apenas o Product Backlog, o Sprint Backlog e o Product Increment. Porém, além deles ainda existem artefatos opcionais, cujo uso é decidido pela equipe. Os artefatos, tanto obrigatórios quanto opcionais, são:

Product Backlog: a lista de desejos

O Product Backlog — a Reserva do Produto, em tradução livre — representa uma listagem das funcionalidades desejadas pelo cliente. Em acordo entre o Product Owner e o cliente, elas precisam ser desenvolvidas com maior urgência.

Os itens discriminados neste backlog são priorizados, adiados ou descartados por valor de negócio pelo Product Owner, e podem ser tarefas técnicas ou não.

O Product Backlog não precisa estar completo desde o início do projeto. No começo os desenvolvedores podem trabalhar só com o que for mais simples ou óbvio ao sistema projetado. Depois, à medida que os Sprints são concluídos e o software é incrementado, pode-se adicionar mais coisas ao backlog.

Assim, com negociação entre os stakeholders e análise contínua das funcionalidades entregues, esse backlog pode crescer e mudar, sempre levando em conta o que se aprende sobre o produto e sobre a jornada do usuário.

Sprint Backlog: os afazeres desse ciclo

Durante o Sprint Planning, que abordaremos no tópico de Eventos Scrum, o PO prioriza os itens do Product Backlog e os descreve para o SM e para a equipe.

A equipe então determina quais dos itens descritos ela poderá completar durante o próximo Sprint. É disso que surge o Sprint Backlog, que nada mais é do que uma lista de tarefas ou afazeres.

Esses afazeres são divididos entre os integrantes do time pelo Scrum Master, de acordo com a percepção da equipe sobre as habilidades de cada membro e sobre o tempo que será empregado para completá-los.

Mudanças de escopo nos itens do Sprint Backlog após o início do Sprint devem ser evitadas ao máximo. Elas atrapalham o andamento do Sprint e tiram o foco da equipe no trabalho. Se for necessário modificar algo, o Scrum Master deve negociar com os desenvolvedores e com o Product Owner sobre como e o que mudar e quais são os motivos para essa mudança.

User Stories: Histórias do Usuário

Até agora, nós nos referimos aos itens dos backlogs como tarefas, mas nem todas as equipes Scrum falam assim. Algumas preferem falar de User Stories, ou Histórias do Usuário.

“Tarefa” é uma palavra genérica para os itens dos backlogs e que pode ser usada isolada ou conjuntamente com “Histórias”.

O cérebro humano funciona melhor quando escuta histórias. Temos maior entendimento e empatia quando um interlocutor nos transmite os motivos das suas escolhas e descreve sua trajetória. Nesse contexto, o interlocutor é o usuário do sistema.

Assim, resumidamente, as User Stories são descrições simples e curtas de uma funcionalidade a ser implementada no software.

Elas são contadas do ponto de vista do usuário, apontando por qual motivo ele deseja que o software seja capaz daquela função. Geralmente, as Stories são escritas nesse padrão:

“Como USUÁRIO, eu quero FUNCIONALIDADE para que RAZÃO”.

Por exemplo: “Como gerente de estoque, eu quero poder adicionar ou remover produtos do cadastro de estoque, para que haja maior controle do fluxo de vendas”.

As User Stories geralmente são escritas em cartões ou em post its. Eles podem ser dispostos em paredes, lousas ou mesas para facilitar o planejamento e a discussão. Essa disposição também pode ser feita em ferramentas digitais, como o Trello.

Isso ajuda na visualização das funcionalidades. O foco muda da escrita sobre recursos para a discussão ativa e coletiva sobre eles. Assim, o time está exercendo os princípios Scrum de comunicação e transparência.

Como detalhar as User Stories?

Se necessário, detalhes podem ser adicionados às Histórias de duas maneiras:

• quebrando uma História mais complexa em outras menores e mais simples,
• ou adicionando condições de conclusão ao cartão que a descreve.

No primeiro cenário, já é presumido que as novas Stories criadas contém detalhamento adicionado a elas.

No segundo cenário, as condições de conclusão são apenas um obstáculo colocado ali para garantir maior cuidado no desenvolvimento daquela funcionalidade. É natural que todas elas sejam cumpridas por consequência desse cuidado.

Qualquer um no Scrum pode escrever User Stories. Cabe ao Product Owner aceitá-las na fila de prioridades que é o Product Backlog. Ao longo do ciclo de vida do projeto, é esperado que todos os membros do time acabem escrevendo uma História em algum momento.

A identidade do autor da User Story é irrelevante. O que realmente importa é quem vai discutir sobre ela e trabalhar em cima dela no decorrer do projeto.

Da mesma forma, não é obrigatório que todos os itens dos backlogs sejam escritos no formato de História. Às vezes, é muito mais fácil, rápido e intuitivo simplesmente escrever palavras chave, escrever casos de uso ou desenhar diagramas ou layouts simples. O Scrum descreve o que precisa ser feito, mas não há regra sobre como fazer.

Story Points: a unidade de medida do progresso

Um Story Point é uma medida abstrata do esforço necessário para implementar uma User Story. Assim como User Stories, o uso de Story Points e de Burndown Charts é opcional.

Resumindo, é um número que informa a equipe sobre o nível de dificuldade da História. Nível esse que está relacionado a particularidades, riscos e esforços envolvidos na execução de cada História específica.

Na maioria dos casos, um Story Point usa uma das seguintes dimensões:

• A Sequência de Fibonacci: 1, 2, 3, 5 ,8, 13, 21;
• Tamanhos análogos aos tamanhos de camiseta: PP, P, M, G, GG;
• Ou a sequência simples do 1 seguido de múltiplos de 2: 2, 4, 8, 16.

Os Story Points representam estimativas de alto nível e geralmente são feitos após o Sprint Planning. O PO, o SM e o time de desenvolvimento fazem uma estimativa grosseira onde checam se:

• o planejamento foi conduzido de forma eficiente;
• há informação suficiente para cumprir tudo que foi designado para aquele Sprint; e
• se as User Stories foram divididas de forma razoável entre os membros da equipe.

Estimativas baseadas em medidas de tempo como horas ou dias, em contrapartida, são estimativas de baixo nível. Elas representam o esforço palpável (relação hora/homem da mão de obra) demandado para completar aquela User Story.

Story Points são Medidas de Tempo?

Na verdade, Story Points e medidas hora/homem têm propósitos diferentes para situações diferentes e não devem ser comparados ou utilizados de forma exclusiva. O certo é evitar relacioná-los para que o Sprint e o lançamento do produto sejam melhor executados.

A hora/homem não é igual para todos os desenvolvedores, mas os Story Points sim. Isso permite que pessoas com velocidades diferentes e níveis de habilidade diferentes consigam chegar num consenso.

Atribuir determinada quantidade de Story Points para uma User Story é mais flexível do que atribuir uma quantidade de horas ou dias. Assim, a janela de entrega da Story acaba sendo a mesma para todos os membros do time.

Cada Story Point representa uma distribuição normal de tempo. Por exemplo: um Story Point pode representar um intervalo de 4 a 12 horas, dois Story Points seriam de 10 a 20 horas e assim por diante.

Essa distribuição de tempo é desconhecida durante a estimativa, pois ao usar Story Points, não é necessário saber quanto tempo leva, só é necessário ter uma indicação aproximada de quanto tempo vai demorar para aquilo ser concluído. O Planning Poker é utilizado para designar os Story Points.

Burndown Charts: uma visão geral do projeto

O monitoramento do progresso do projeto, no Scrum, geralmente é feito com um gráfico chamado Burndown Chart ao final de cada Sprint.

Existem várias formas de Burndown Chart. A forma utilizada é determinada pelo Scrum Master em conversa com os desenvolvedores.

O trabalho que ainda resta pode ser mostrado na unidade preferencial da equipe, que usualmente são Story Points. Sua finalidade é permitir que o projeto esteja no caminho para entregar a solução esperada dentro do cronograma desejado.

O Burndown não é obrigatório de forma alguma. Ele é apenas uma ferramenta para visualizar o progresso no projeto e no Sprint, e esse progresso é que deve ser medido obrigatoriamente. O ideal é que o SM meça isso diariamente.

A equipe pode escolher o método que quiser, inclusive outros tipos de gráficos ou outras métricas, desde que haja uma forma consistente de inspecionar o progresso do produto.

Product Increment: as funcionalidades ou entregáveis

Ao encerrar o primeiro Sprint de um projeto, a equipe Scrum precisa, mesmo que de forma rudimentar, resolver o problema do usuário final. Daí vem o conceito de MVP (Minimum Viable Product — Mínimo Produto Viável, em tradução livre).

O MVP é muito utilizado no mundo do empreendimento e das startups, já que a maioria dessas pequenas empresas inovadoras surge justamente com um MVP.

A grande diferença do Scrum para o Cascata está nesse conceito, já que as iterações têm por base entregar incrementos do produto ao longo do tempo. Isso é contrário ao paradigma antigo onde havia uma única grande entrega ao final do projeto.

Para que o Sprint termine com sucesso, é necessário que seu objetivo tenha sido atingido. Esse objetivo é definido pela equipe e geralmente envolve a entrega de pelo menos um incremento de software que esteja funcionando.

Por isso é que “incremento”, “entregável” e “funcionalidade” acabam sendo palavras intercambiáveis nesse contexto. O incremento precisa ser validado pelos analistas de testes e pelo PO para que seja incorporado ao produto final.

Eventos Scrum

Os Eventos são usados no Scrum para criar regularidade e minimizar a necessidade de reuniões imprevistas. Todos os eventos são timeboxed, o que significa que eles têm um tempo mínimo e um tempo máximo de duração.

Todos os Eventos são ligados ao Sprint, que é o principal deles, e todos se repetem cada vez que um Sprint acaba e outro começa. Daí a natureza iterativa do Scrum.

Antes do Sprint começar, idealmente na primeira Sprint Planning do projeto, sua duração é fixada pelo Scrum Master. Ela não pode ser reduzida ou aumentada.

Os eventos restantes também têm timeboxes mas podem terminar antes do previsto caso o objetivo proposto para cada um deles for alcançado mais rápido. Assim há garantia que uma quantidade apropriada de tempo seja gasta sem permitir desperdício no processo. Os Eventos Scrum são:

Sprint Planning: o planejamento

Antes de iniciar um Sprint, o Product Owner apresenta para o Scrum Master e para os desenvolvedores os itens mais prioritários do Product Backlog. O time seleciona os itens que farão parte do Sprint Backlog.

Depois disso, o SM e o PO se retiram da reunião para que o time “dev” defina tecnicamente como serão desenvolvidos os itens do Sprint Backlog. Essa definição é auxiliada pelo Planning Poker, que veremos mais à frente no artigo. Essas são as duas etapas do Sprint Planning.

Durante a primeira etapa, o Product Owner apresenta os itens do Product Backlog sob a ótica de negócios, mostrando o raciocínio utilizado por ele para definir quais itens têm maior prioridade. O time pode tirar dúvidas com o PO e já idealizar quais são as possíveis soluções técnicas para cada item, uma vez que esses itens formarão o Sprint Backlog.

Após formado o Sprint Backlog, a equipe Scrum completa irá definir um objetivo para o Sprint, descrevendo de forma sucinta o que o time deve ter como foco para essa iteração.

Já durante a segunda etapa, os desenvolvedores se reúnem para que possam traçar o planejamento técnico de cada item do Sprint Backlog. Cada item é quebrado em tarefas menores ou transformado em User Stories caso necessário. Estima-se o tempo que será despendido neles. Essa estimativa geralmente é feita com o Planning Poker.

A análise da efetividade do Sprint Planning acontecerá no Sprint Review.

É importante que os membros da equipe lembrem-se de qualquer folga, período de férias, feriados, viagens, ou qualquer outro detalhe de programação que ocorrerá durante o Sprint e que possa afetar o seu andamento. Assim, poderão estimar com a maior precisão possível qual será a quantidade de trabalho realizada.

Planning Poker: o jogo e suas regras

Equipes que utilizam Story Points também costumam usar um exercício parecido com um jogo de pôquer. As cartas de baralho são utilizadas para estimar o esforço que será despendido em cada tarefa.

A equipe de desenvolvedores pegará um item do backlog e discutirá brevemente sobre ele. Cada um dos integrantes pensará em uma quantidade de Story Points que considera adequada para a execução dele. Todos pegam e mostram aos demais uma carta de baralho com o número equivalente à sua estimativa.

Se todos estiverem de acordo, o exercício acaba aqui. Se houver discordância, cada desenvolvedor deve entender a lógica por trás das diferentes estimativas.

A estimativa deve ser uma atividade de alto nível. Isso significa que as discordâncias não podem ser muito gritantes. Se alguns membros estimaram 1 Story Point enquanto outros estimaram 5, conversem mais um pouco, até que esses números se aproximem.

A equipe deve ter um consenso sobre o número máximo de Story Points, horas de trabalho, ou qualquer que seja a medida escolhida pelos integrantes.

As Sprint Retrospectives são o momento do time refletir sobre a precisão e eficácia de iterações anteriores daquele projeto. Essa reflexão inclui a precisão de suas estimativas.

O Quão Preciso é Preciso Ser?

Em uma sessão de Planning Poker, imagine que metade da equipe estimou 3 Story Points e a outra metade estimou 5 Story Points para uma História.

É fácil aceitar 4 Story Points como a estimativa e seguir para a próxima tarefa, mas a equipe deve ter sinergia e maturidade suficientes para entender que não é produtivo fazer isso. Isso só gera uma falsa sensação de precisão. Não há necessidade de ser 100% preciso. O que é necessário é ser preciso o suficiente para garantir o bom andamento do Sprint e planejar tudo com antecedência.

Além disso, pode haver perda de transparência no processo caso a decisão mais fácil seja tomada. Essa decisão gera uma diminuição na comunicação do time. Talvez 5 Story Points seja uma estimativa melhor e vocês nunca saberão se não conversarem sobre isso.

Sprint e seus Estados (To Do, Doing, Done)

Um Sprint é um ciclo com começo e fim, com uma duração de tempo pré-determinada pelo Scrum Master. O Sprint é o centro do Scrum. Todos os outros eventos e artefatos giram em torno dele e da sua execução.

Ao final de cada Sprint, há uma nova funcionalidade a ser validada ou barrada pelo Product Owner. Depois, implementada em definitivo ou modificada até que fique dentro das regras e valores de negócio propostos por ele.

A Duração dos Sprints

O SM precisa analisar a estabilidade dos escopos de produto e de projeto antes de definir a duração dos Sprints. Se um deles for muito mutável e essas mudanças estiverem relacionadas a tempo de entrega, é mais prudente que os Sprints tenham uma ou duas semanas de duração. Se os recursos disponíveis aos escopos são mais estáveis, Sprints de duas a quatro semanas podem funcionar melhor.

Como já mencionado neste artigo, não é comum e nem recomendável que os Sprints de um projeto variem de tamanho, pois isso gera instabilidade e imprevisibilidade na velocidade de execução do mesmo.

O Sprint termina quando o tempo de duração definido para ele se esgotar ou quando o objetivo definido durante o Sprint Planning for atingido. Para que o Sprint termine com sucesso, é necessário que haja entrega de um incremento de software.

Durante o Sprint, cada tarefa tem um estado. Esse estado serve para indicar a que pé está sua execução.

Estados do Sprint

Algo comum, e semelhante ao que é feito no Kanban, é dividir as tarefas do Sprint por colunas em um quadro físico ou virtual. Cada uma delas equivale ao estado de um cartão. Esse cartão transita pelas colunas à medida que o que está descrito nele é implementado. Os Estados mais comuns são:

• Backlog. Designa o Product Backlog.
• Blocked (Bloqueado). Contém tarefas que não poderão ser inseridas em To Do por algum impedimento.
• To Do (Por Fazer). Designa o Sprint Backlog.
• Doing ou Work in Progress (Fazendo). Lista tarefas que estão sendo feitas, com indicação do desenvolvedor responsável por fazê-las em cada cartão.
• Verify (Verificar). Onde estão as tarefas já desenvolvidas que precisam ser testadas.
• Done (Feito ou Pronto). São tarefas já concluídas.

Os Estados obrigatórios são apenas To Do, Doing e Done.

Para que todos os stakeholders estejam alinhados sobre o que significa a conclusão de uma tarefa, existe um documento chamado Definition of Done (Definição de Pronto). Nele há a descrição genérica de quais são os passos mínimos para a conclusão de entregáveis.

Esse documento é como uma garantia da qualidade dos incrementos. Ele pode ser modificado ao longo das iterações, à medida que é revisado em cada Sprint Review.

É obrigatório que todos os stakeholders estejam de acordo com a Definição de Pronto para que haja transparência e confiança entre eles durante o projeto.

Daily Scrum: as reuniões diárias

Todos os dias, a equipe se reúne para conversar sobre o andamento do Sprint atual. O objetivo aqui é promover o alinhamento contínuo entre todos os membros do time e ajudar o Scrum Master a prever o que poderá realmente ser entregue ao final do Sprint.

Essa reunião diária é chamada de Daily Scrum ou apenas Daily. Ela costuma durar por volta de 15 minutos. Pode ser estendida com membros específicos do time dependendo do que for conversado e de possíveis impedimentos que podem surgir.

A participação do time completo é obrigatória. Para esse evento, isso sempre inclui o Scrum Master mas nem sempre o Product Owner. A participação de outros stakeholders, como os gerentes de outros setores ou o cliente, é menos comum mas pode ocorrer, porém eles serão apenas ouvintes.

A Daily não deve se aprofundar em discussões técnicas. Qualquer questão que surja durante ela deve ser estendida apenas com os membros diretamente envolvidos ou afetados por essa questão. Se necessário, o que foi discutido nessa etapa é passado de forma resumida para os membros que não estavam envolvidos.

As questões que devem ser respondidas pelos desenvolvedores na Daily, assim reportando seu progresso ao Scrum Master, são:

• “O que eu fiz ontem” ou “o que eu fiz desde a última Daily”;
• “O que pretendo fazer hoje” ou “o que pretendo fazer até a próxima Daily”; e
• “Existem os seguintes impedimentos para que eu possa concluir minhas tarefas” ou “não existem impedimentos para as minhas tarefas”.

Tendo em conta o que foi respondido, o Scrum Master deve trabalhar para eliminar os impedimentos. Caso eles não existam, deve trabalhar para que o que ainda falta nesse Sprint seja concluído com qualidade e dentro do prazo.

Sprint Review: revisando o ciclo

Após o final do Sprint, o time mostra como aconteceu o desenvolvimento dos entregáveis. Normalmente estão presentes no Sprint Review o Product Owner, o Scrum Master e o cliente ou os stakeholders que o representam. O foco da reunião é demonstrar as novas funcionalidades com o mínimo possível de bugs e funcionando relativamente bem. O ideal é que a duração do Review não seja maior do que duas horas.

Os incrementos devem ser revisados de acordo com o objetivo do Sprint que foi acordado no Sprint Planning. A equipe deve sempre se esforçar para alcançar esse objetivo.

Sprint Retrospective: refletir para melhorar

O último Evento Scrum é a Retrospectiva. A equipe analisa o rendimento do Sprint que acabou e conversa sobre maneiras de melhorar seus processos de trabalho para o próximo Sprint. Há discussão e exposição de dificuldades e como a equipe acha que pode evitá-las.

Isso está relacionado com alguns fatores. São eles:

• o empenho de cada desenvolvedor,
• a divisão de tarefas feita no Sprint Planning,
• e os impedimentos apontados na Daily, além das decisões do SM para resolvê-los.

A equipe decide como agir dali em diante para melhorar sua eficiência no próximo Sprint. Os integrantes devem visar o aumento da sua produtividade sem perda de qualidade.

Assim como a Daily, a Retrospectiva também tem uma duração ideal. Nesse caso é de uma hora, mas os envolvidos em alguma questão mais complexa podem continuar conversando após a reunião.

Uma das técnicas de Retrospectiva é o start-stop-continue:

• “Devemos começar a fazer…” (start)
• “Devemos parar de fazer…” (stop)
• “Devemos continuar a fazer…” (continue)

Scrum of Scrums: a solução para projetos grandes

Scrum of Scrums ou Meta Scrum é um mecanismo de escalabilidade criado na IDX Systems (atual GE Healthcare).

É definido pela Agile Alliance como “uma técnica para escalar Scrum até grandes grupos (mais de uma dúzia de pessoas), consistindo em dividir os grupos em equipes ágeis de 5 a 10 integrantes”.

Ainda, é definido por Jeff Sutherland como “responsável por adequar o software de todas as equipes à Definição de Pronto no final do Sprint, ou a lançamentos durante o Sprint”. Quando trabalhavam na IDX, Jeff Sutherland e Ken Schwaber implementaram-no como uma técnica para dimensionar equipes Scrum individuais para o nível corporativo.

O Gerenciamento de um Scrum of Scrums

A coordenação das várias equipes é feita em uma reunião do Scrum of Scrums. Essa reunião pode ser realizada diariamente, duas vezes por semana ou, no mínimo, uma vez por semana.

Cada equipe Scrum tem seu representante. Ele pode ser o Scrum Master ou outro membro da equipe escolhido pelos outros integrantes. Se o assunto que uma das equipes quer discutir é muito técnico, tanto o membro da equipe tecnicamente qualificado quanto o Scrum Master podem querer participar.

A reunião do Scrum of Scrums é executada de forma muito semelhante à Daily Scrum. Apesar de não ter uma duração de tempo predeterminada, é comum que ela dure 15 minutos, assim como a Daily de Scrums comuns. Na reunião do Scrum of Scrums, cada “embaixador” de cada time Scrum deve responder:

• O que sua equipe realizou desde a última reunião;
• Quais problemas ocorreram (se ocorreram) e como afetaram negativamente sua equipe;
• O que sua equipe deseja realizar antes da próxima reunião;
• Quais ações da sua equipe em futuros Sprints podem interferir nos Sprints das outras equipes;
• E se sua equipe vê alguma interferência proveniente de outras equipes.

O propósito da reunião do Scrum of Scrums é assegurar a coordenação e integração dos resultados das várias equipes, eliminando todos os impedimentos. Para isso, pode haver envolvimento de duas ou mais equipes trabalhando juntas por um tempo ou renegociando responsabilidades.

Isso precisa ser gerenciado com um Product Backlog próprio do Scrum of Scrums e mantido pelo Scrum Master eleito como chefe desse processo. Ou, ainda, por um Gerente de Projetos que tenha o Product Backlog do Scrum of Scrums como sua principal demanda.

Como Organizar o Scrum of Scrums

Um framework Scrum of Scrums pode ser eficaz mesmo em organizações maiores com múltiplas equipes. Ou em projetos com Scrums distribuídos em locais diferentes. Desde que as reuniões próprias dele sejam conduzidas adequadamente.

A ênfase deve estar na coordenação das várias equipes e na resolução de impedimentos. O objetivo é garantir que as equipes individuais cumpram suas metas. Assim, o objetivo geral do projeto de todas as equipes será atingido.

O desperdício de tempo, trabalho e recursos é diminuído ao máximo por um time formado especificamente para ajudar o Scrum Master ou Gerente de Projetos encarregado do Scrum of Scrums. Os membros são selecionados de cada Scrum ou são integrantes exclusivos.

Isso garante a manutenção da transparência e boa comunicação entre todas as equipes Scrum. Ken Schwaber chamou isso de Integration Scrum (Scrum de Integração) em seu livro The Enterprise and Scrum (“As Empresas e o Scrum”, em tradução livre). Ter pelo menos um lançamento a cada três meses é a meta.

Como implementar o Scrum na sua empresa

A implementação do Scrum tem muito a ver com a implementação da Transformação Digital. Além do Scrum ser uma ferramenta de Transformação Digital, ambos os processos dependem diretamente de mudanças na cultura organizacional.

Essas mudanças só podem ocorrer de forma efetiva se forem feitas gradualmente e com muito engajamento dos líderes da empresa e dos colaboradores. Os líderes sempre terão que balancear os prós e contras com transparência diante de suas equipes, visando integrar todos os setores da empresa.

Metodologias Ágeis para Organizações

O que acontece em implementações organizacionais de métodos ágeis não é o uso do Scrum propriamente dito, mas sim de frameworks modificados.

Eles também são baseados nos princípios do Manifesto Ágil, porém com essa integração de setores já considerada desde a sua concepção.

Um exemplo desses frameworks é o SAFe, que aborda todas as camadas de uma organização. Dean Leffingwell, o criador do SAFe, o define como “uma estrutura para implementar práticas ágeis em escala corporativa”.

Transição para o Scrum

A transição de tradicional para ágil deve ser cuidadosa e muito bem alinhada internamente. Assim como qualquer outra mudança de cultura organizacional, devido ao impacto que isso trará aos colaboradores.

As equipes de cada setor devem ser multidisciplinares. Os silos organizacionais devem ser diminuídos ao máximo para que a sinergia entre setores seja sempre priorizada.

Essa sinergia e multidisciplinaridade ajudarão na Agilidade, já que colaboradores proficientes em várias frentes poderão auxiliar uns aos outros e trazer visões diversas para a empresa.

É esperado que alguns dos colaboradores demonstrem resistência ao processo de transição. Aí é que se encaixa o papel principal dos líderes dos setores. Eles devem alinhar expectativas de forma sempre transparente e explicar quais serão as melhorias obtidas para cada setor com a implementação do Scrum – ou de qualquer outra metodologia ágil.

Scrum Cases de sucesso

O Scrum é uma das ferramentas que podem fazer parte da Transformação Digital. Por esse motivo, alguns dos cases de sucesso do Scrum foram citados no nosso artigo de Transformação Digital.

Dois dos cases mais simbólicos são o da GE Healthcare (antiga IDX Systems) e o do FBI. O case da GE foi citado na seção de Scrum of Scrums deste artigo. Ele está disponibilizado traduzido na íntegra aqui no nosso blog.

Na Zappts, os times de desenvolvimento são geridos com Scrum. Cada time é dedicado para cada projeto, não recebendo demandas de projetos paralelos. Isso garante a agilidade e o bom andamento dos Sprints. A qualidade das soluções que oferecemos aos clientes é assegurada dessa forma.

Trackbacks/Pingbacks

1. Gestão de Squads Remotas | Zappts Blog – […] mencionei, optar por um modelo de trabalho ágil como o Framework Scrum nos permite uma série de ferramentas, como…
2. Desvendando o Serverless – Cloud Computing | Zappts Blog – […] acompanhando os conteúdos do nosso blog. Temos artigos sobre UX, Scrum e muitos outros assuntos da área de […]
3. Scrum x Kanban. E o vencedor é… | Zappts Blog – […] entender mais sobre o que é Scrum, indico a leitura deste artigo, disponível em nosso […]
4. Management 3.0 – Zappts Blog – […] o blog da Zappts para saber mais sobre gestão de times e aproveite também nossos conteúdos sobre Scrum, Transformação…
5. Planejamento de Sprint: Como minimizar os riscos envolvidos? – Zappts Blog – […] 💙 Quer aprender mais? Confira nossa publicação Scrum: entenda de uma vez por todas o que é, como ele…

‍