Parece o início de uma piada à lá Tio do Pavê, mas (spoiler alert) o Scrum é muito mais que isso.
Dentro das Metodologias Ágeis existem diversas estruturas e processos que se baseiam em seus valores e princípios. Entre elas está o Scrum, uma das mais populares, que visaprocessos simples, adaptáveis e com foco no essencial.
Neste material, vamos apresentar um breve resumo do Agile, o que é o Scrum dentro do Agile, assim como conceitos e estrutura do Scrum. Se preferir ler um resumo, basta pular para o final do artigo.
Metodologias Ágeis
Tecnicamente, o Agile é um conjunto de frameworks, não uma metodologia. A grosso modo, significa que não há um passo-a-passo definido mas sim uma coleção de orientações para nortear os processos.
Para o Agile essas orientações vêm na forma de 4 valores e 12 princípios que cobrimos em um material dedicado, mas que podemos resumir em: foco nas pessoas, na entrega de valor e na adaptabilidade.
Apresentamos as Metodologias Ágeis em maior detalhe no nosso post “Como montar móveis, fazer sanduíches e desenvolver softwares”.
Scrum
A palavra “Scrum” foi emprestada do rugby: um método de reinício de jogada, onde os times se juntam com a cabeça abaixada e se empurram com o objetivo de ganhar a posse de bola. A ideia do Scrum no Agile é parecida: juntar as cabeças para definir quem vai tomar conta de o quê. Só que menos competitivo.
Scrum é, em si, um framework alinhado aos princípios do Agile. Ele prega a adaptabilidade empírica das equipes ao longo do processo através de suas ferramentas e estrutura. Isto é, busca-se aprender com a experiência, com o processo e com as ferramentas disponibilizadas para encontrar a melhor solução no momento. Com isso, objetiva-se a entrega de valor para o cliente de forma eficiente, estabelecendo prioridades nas entregas e realizando-as de forma incremental. Incremento, como veremos adiante, é uma espécie de adição ao projeto, algo que o leve mais um passo em direção à conclusão.
O Guia do Scrum ainda reforça que ele é “propositalmente incompleto, definindo somente as partes necessárias para implementar a teoria Scrum” (tradução nossa). Isto é, quem faz o Scrum acontecer são as pessoas que o utilizam, que aplicam seu conhecimento e inteligência para fazer acontecer, ao invés de seguir instruções detalhadas e engessadas.
Em suma, o Scrum entrega uma série de ferramentas para que o trabalho de desenvolvimento siga os princípios Agile. Mesmo assim, os autores do Guia do Scrum reforçam que o framework Scrum é imutável, e variações ou implementações parciais – exceto no seu uso como contêiner para outras práticas – não são consideradas “Scrum”.
Estrutura e Recursos do Scrum
Para que o Scrum cumpra com seu propósito não são necessárias grandes reestruturações, uma vez que a intenção é uma mudança de processos. É possível – e incentivado – que o Scrum faça uso dos recursos já existentes dentro das organizações. Lembre: um dos seus objetivos é ser eficiente!
Dito isso, vamos ver qual a estrutura que o Scrum propõe. Podemos organizá-las em três categorias: Scrum Team, Artefatos e Eventos.
Scrum Team
O Scrum Team (Time Scrum) é a unidade fundamental do Scrum, constituída por um número pequeno de pessoas: geralmente, um Scrum Master, um Product Owner (PO) e Desenvolvedores. Novamente: a proposta do Scrum é ser eficiente, isto é, fazer mais com menos. Por isso, recomenda-se manter as equipes enxutas ou dividi-las em grupos menores, sem prejudicar a organização e coesão do trabalho.
Não existem hierarquias em um Scrum Team, cada profissional está lá para doar sua expertise e trazer mais valor ao projeto. Pode parecer estranho à primeira vista, especialmente quando estamos habituados aos modelos tradicionais de trabalho: “manda quem pode, obedece quem tem juízo”. Enquanto no Scrum, equipes são consideradas auto-gerenciáveis: seus participantes são responsáveis por definir quem faz o quê, como e quando, junto à equipe de negócios (geralmente o cliente ou um representante).
A seguir, vamos conhecer um pouco mais sobre os papéis dentro do Scrum Team.
O PO é a pessoa “responsável por maximizar o valor do produto resultante do trabalho do Scrum Team” (Guia do Scrum, tradução nossa), representando os clientes dentro da equipe e garantindo que as entregas tragam valor palpável. Para tanto, o PO é encarregado de gerenciar backlog (que descrevemos mais adiante), priorizar tarefas e definir requisitos. Claro, como representante do cliente, todas as suas decisões devem estar alinhadas às necessidades do cliente sem perder de vista os recursos do Scrum Team.
O SM é o líder do Scrum Team, responsável por manter o time dentro do framework do Scrum e pela eficácia do trabalho realizado. Como bom líder, seu papel é o de guiar os membros da equipe sem limitar seu autogerenciamento individual, estimular a interação entre as diferentes partes, remover impedimentos, auxiliar no planejamento e execução das tarefas. É o facilitador para os recursos humanos (membros) do Scrum Team.
No desenvolvimento de softwares, a maior parte dos membros da equipe são… bem, desenvolvedores. Mas nem só de dev vive um projeto! De acordo com a estrutura e recursos da empresa, podemos incluir profissionais como Analistas de Requisitos, Analistas de Qualidade (QA) e Designers UX/UI. Os Desenvolvedores são os responsáveis pela criação de qualquer aspecto de um incremento, ou seja, são estas mãos que serão colocadas na massa! (Não que o SM e o PO não o façam também, não se engane.)
As habilidades da equipe no Scrum variam, mas em essência suas responsabilidades são: a criação de um plano de Sprint (já vamos chegar nela!), manter a qualidade do trabalho ao longo de todo o seu desenvolvimento, adaptar o plano quando necessário para atingir o objetivo da Sprint e/ou do projeto, responsabilizar-se pelo resultado final.
Eventos Scrum
Cada evento no Scrum foi criado com a transparência em mente, a fim de instaurar um processo realmente eficiente. Além de estabelecer regularidade e minimizar a necessidade de reuniões além das estipuladas, os eventos Scrum são uma oportunidade de análise e adaptação. O principal deles é a Sprint, dentro da qual todos os demais eventos acontecem.
Sprint
“Sprints são o coração do Scrum, onde ideias são transformadas em valor” (Guia do Scrum, tradução nossa). A palavra “sprint”, no inglês, diz respeito a uma corrida de curta duração e/ou distância em máxima velocidade – ou ainda, um breve período de grande atividade. Ou seja, é fazer muito em um curto espaço de tempo. Eficiência que chama.
O objetivo da Sprint no Scrum é produzir um incremento pronto ao final de cada ciclo de entrega. Estes ciclos duram de 1 a 4 semanas, nos quais o planejamento, execução e análise do desenvolvimento são realizados. Sua duração varia dependendo do escopo, das prioridades e da equipe, mas não deve estender-se por mais de um mês.
O ciclo mais curto confere à Sprint maior consistência, previsibilidade e melhor foco nas entregas. Além disso, ciclos mais longos podem dificultar a adaptação – um dos princípios do Scrum e do Agile – e torná-los complexos demais. Isso também colabora para menor risco para o custo e esforço do projeto como um todo.
Conhecer o ritmo de trabalho da equipe, ter um backlog organizado e priorizado, e entender a complexidade das tarefas a serem realizadas colaboram para a organização e estrutura do projeto. Resumindo: ter e manter uma visão empírica garante o bom andamento do desenvolvimento.
Sprint Planning
Literalmente “Planejamento de Sprint”, a Planning é uma reunião que marca o início de uma nova Sprint, com o objetivo principal de criar um plano de trabalho concreto e realista para a Sprint, baseado nas prioridades e no backlog do produto. Nesta etapa, o PO é encarregado de garantir que o Scrum Team esteja preparado para discutir o trabalho a ser realizado, mapear os itens mais importantes e montar um plano para a entrega. Existem diferentes estratégias para priorizar e mapear as tarefas para que se encaixem na Sprint, porém o principal da Planning está em responder:
Qual o valor desta Sprint?
Como já estabelecemos, um dos pilares do Scrum e do Agile é a entrega de valor. Isso é verdade para o projeto e para as Sprints que o compõem. Ou seja, cada Sprint precisa ter como objetivo uma entrega que agregue valor para o projeto, e consequentemente para o cliente. Algo que seja palpável e mensurável, como uma nova funcionalidade ou melhoria na experiência do usuário, ou ainda a correção de eventuais bugs. Caso contrário, qual seria o propósito de fazê-la, não é mesmo?
O que pode ser feito nesta Sprint?
A Sprint média dura em torno de 2 semanas. Dependendo da complexidade do projeto, não há muito a se encaixar nesse curto espaço de tempo. Já vimos o porquê de ser assim, mas também devemos reconhecer que mensurar quantos recursos cada item dos backlogs pode tomar não costuma ser muito fácil. Por isso é importante a visão empírica que falamos: entender o desempenho da equipe (nos níveis coletivo e individual), qual a carga de trabalho por vir e estabelecer uma definição de Done (“pronto”, que abordaremos mais adiante) comum a todos. Assim, as previsões podem ser mais assertivas e a equipe, mais confiante na sua planning.
Como o trabalho escolhido pode ser realizado?
Outro ponto importante no Scrum é o auto gerenciamento, que significa que os membros da equipe são responsáveis por analisar, planejar e desenvolver cada etapa do projeto. Para o Scrum, o que mais importa é que ao final da Sprint, a equipe entregue um incremento pronto. Ou seja, tudo o que acontece entre a Planning e a entrega está à critério da equipe de desenvolvimento e pode – e deve – ser refinada ao longo do processo, se necessário.
Daily Scrum ("Scrum Diário")
Relembrando: “scrum” é uma jogada no rugby onde os times se juntam com o objetivo de ganhar a posse de bola. A famosa Daily no desenvolvimento de softwares é uma reunião diária breve – geralmente não mais que 15 minutos em um único projeto – onde a equipe mede o progresso da Sprint. A forma como a Daily é conduzida fica à critério dos participantes, contanto que o foco esteja no andamento das tarefas estabelecidas na Planning.
Esse é também o momento para expor impedimentos e avaliar a necessidade de adequação do plano. Discussões aprofundadas são encorajadas quando necessário, mas o ideal é que a Daily seja sucinta.
Sprint Review
A Sprint Review – ou “Revisão de Sprint” – é o momento em que o Scrum Team apresenta os resultados da Sprint e como estes colaboraram para o progresso do projeto. Aqui também podem ser discutidas oportunidades de melhorias e ajustes ao Backlog do projeto, tornando a Review mais que meramente uma apresentação. Esta reunião oficializa a entrega, coleta o feedback dos stakeholders (as partes interessadas, como os clientes e o PO) e marca o início do fim da Sprint.
Ainda há mais um rito para fechar o ciclo: a Retrospectiva.
Sprint Retrospective
Embora os nomes se pareçam, a Review e a Retrospectiva possuem funções diferentes. Enquanto a Review foca na entrega da Sprint aos stakeholders, a “Retro” (como é carinhosamente apelidada) é uma reunião do Scrum Team para analisar e planejar formas de melhorar a qualidade e eficiência da Sprint. São levantados todos os elementos que contribuíram positiva e negativamente para o resultado da Sprint para que a equipe possa ter uma discussão transparente sobre o processo. Com isso, é possível e incentivada a adaptação para os ciclos e/ou projetos seguintes. A Retro é a última etapa da Sprint, marcando o fim do ciclo.
Artefatos Scrum
Artefato, no Scrum, diz respeito a tudo o que pode ser mensurado e entregue para atingir um objetivo – seja da Sprint ou do projeto. Eles representam trabalho feito/a fazer e valor entregue/a entregar. Há três artefatos principais no Scrum: o Backlog de Produto/Projeto, o Backlog da Sprint e os Incrementos.
Backlog de Produto
Um “backlog” é essencialmente um registro de estoque ou reserva de atividades para abordagem futura. No Scrum, temos dois: um para a Sprint em andamento e outro para o projeto como um todo. Comumente chamado de Backlog de Produto, é uma lista priorizada de entregas a serem desenvolvidas – sejam funcionalidades, requisitos, melhorias, bugs, etc. O Backlog de Produto compromete-se com objetivo final do projeto, estabelecendo os passos necessários para atingi-lo.
Esta lista pode – e deve – ser revista e adaptada sempre que necessário, seja com a chegada de novas informações ou mudanças nos requisitos do projeto. Por exemplo, se um item do backlog for entendido como grande demais para uma única entrega, cabe ao time discutir e quebrar este item em entregas mais precisas e gerenciáveis para que não comprometa o andamento das Sprints e, consequentemente, do projeto. Os responsáveis por mensurar o trabalho são os membros da equipe de desenvolvimento, enquanto o PO pode influenciar esse processo por meio de esclarecimentos e reorganização das prioridades.
Backlog de Sprint
Assim como o Backlog de Produto contém as entregas para atingir o objetivo do projeto, o Backlog de Sprint contém as entregas para atingir o objetivo da Sprint. Ele é essencialmente um plano estabelecido pelos Desenvolvedores durante a Sprint Planning composto pelos “Por quê”, “O quê” e “Como” de cada entrega. Para criar um backlog, é preciso analisar a performance do time e as prioridades definidas pelo PO, para assim ter suas atividades distribuídas e priorizadas em cada Sprint.
Esse plano, como todo o restante do Scrum, é flexível e deve ser revisitado ao longo do processo para melhor refletir a situação atual e as expectativas do Scrum Team. Isso não significa que ele deve mudar a todo tempo, não! Significa que, caso novas informações surjam que possam comprometer a entrega e/ou o andamento da Sprint, deve-se haver espaço para adaptar o plano. O Backlog da Sprint estabelece aquilo que é necessário para o sucesso da entrega à qual a equipe está comprometida. O objetivo da Sprint continua o mesmo estabelecido na Planning e não deve ser comprometido.
Incremento e a Definição de “Done”
Assim como o nome sugere, “incremento” é uma adição incremental e tangível ao projeto. Na prática, um incremento pode ser um novo recurso, funcionalidade ou melhoria no produto, entregue pelo Scrum Team ao final de cada Sprint. É importante destacar que cada incremento deve atender à definição de “Done“, que é um conjunto de critérios pré-estabelecidos pelo time, indicando que o incremento está finalizado e pronto para ser entregue.
A definição de “Done” pode variar de equipe para equipe, mas geralmente envolve critérios como testes, revisão de código e aprovação do PO. Com essa definição clara, o Scrum Team tem uma visão compartilhada do que é esperado de cada incremento e pode trabalhar para que haja sempre uma entrega de valor.
Cada incremento deve se integrar com os que o precedem, agregando valor ao produto e colaborando para atingir o objetivo geral do projeto. Dessa forma, a entrega contínua de incrementos tangíveis ao longo das Sprints permite que o produto evolua de forma que permite ajustes e adaptações ao longo do caminho.
Resumindo...
- Scrum é um framework alinhado às Metodologias Ágeis que visa otimizar os processos de desenvolvimento de software, aproveitando a estrutura organizacional existente para torná-los mais eficientes;
- Para cumprir com seu propósito, o Scrum depende de uma estrutura composta por um Scrum Team enxuto, encarregado de realizar os Eventos Scrum e fazer uso dos seus Artefatos para entregar valor aos stakeholders;
- O Scrum Team é geralmente composto por:
- um PO que atua como representante do cliente e é responsável pelos backlogs;
- um SM servindo de facilitador da equipe; e
- os Devs, que são os membros da equipe que realizam o desenvolvimento propriamente dito;
- Os Eventos do Scrum giram em torno da Sprint: um ciclo de 1 a 4 semanas, nos quais o planejamento, execução e análise do desenvolvimento são realizados. Estes são:
- Sprint Planning: Planejamento da Sprint;
- Daily Scrum: reuniões diárias de 15 minutos para alinhamento da equipe;
- Sprint Review: entrega do resultado e coleta de feedback da Sprint para os stakeholders;
- Sprint Retrospective: reunião da equipe para análise e adaptação das Sprints futuras;
- Os Artefatos do Scrum são:
- Backlog de Produto: estoque de atividades restantes para finalização do projeto, também pode ser chamado de Backlog de Projeto;
- Backlog de Sprint: entregas para atingir o objetivo da Sprint;
- Incremento: adição ao projeto, uma entrega tangível de valor;
- Definição de Pronto (“Done”): critérios para considerar um incremento como pronta para entrega.
