O Scrum (pronunciado [skɻʌm]) é um framework de gerenciamento de projetos (conjunto de técnicas/processos de gerenciamento não linear de projetos em equipe), da etapa da organização ao desenvolvimento ágil de produtos complexos e adaptativos buscando o valor máximo, criado na década de 1990. No State of Agile Report de 2021, o scrum era a metodologia ágil mais utilizada, sendo adotada por 66% dos participantes do relatório.[1][2]
 |
Embora muito utilizado por equipes de desenvolvimento de software, os princípios desse conjunto podem ser aplicados a todos os tipos de trabalhos em equipe.[3]
Em função de não ser linear, pode empregar vários outros processos ou técnicas, de modo que você possa melhorá-los. Também não é um processo prescritivo, ou seja, não descreve o que fazer em cada situação, pois em trabalhos complexos é impossível predizer tudo o que irá ocorrer. É um conjunto de valores, princípios e práticas que fornecem a base para que a sua organização adicione suas práticas particulares de engenharia e gestão e que sejam relevantes para a realidade da sua empresa. O resultado será uma versão de Scrum que é exclusivamente sua.[4]
Scrum possui seu foco no gerenciamento e projeto da organização onde é difícil planejar à frente. Mecanismos do Controle de Processo Empírico, onde ciclos de feedback constituem o núcleo da técnica de gerenciamento que são usadas em oposição ao tradicional gerenciamento de comando e controle.[5] É uma forma de planear e gerenciar projetos trazendo a autoridade da tomada de decisão a níveis de propriedade de operação e certeza.[6]
Apesar da palavra não ser um acrônimo, algumas empresas que implementam o processo a soletram com letras maiúsculas como SCRUM.[7] Isto pode ser devido aos primeiros artigos de Ken Schwaber que capitalizava SCRUM no título.[8][9]
Apesar de ser criado para gerenciamento de projetos de software, também pode ser utilizado em equipes de manutenção de software ou como uma abordagem geral de gerenciamento de projetos/programas.
Atualmente, as técnicas de DevOps são utilizados por programadores no desenvolvimento de software em conjunto com técnicas de gestão e desenvolvimento ágil de software, como o Scrum.[10][11][12]
História
Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de produtos em empresas de fabricação de automóveis e produtos de consumo, por Takeuchi e Nonaka no artigo "The New Product Development Game" (Harvard Business Review, Janeiro-Fevereiro 1986). Eles notaram que projetos usando equipes pequenas e multidisciplinares cross-functional produziram os melhores resultados, e associaram estas equipes altamente eficazes à formação Scrum do Rugby - utilizada para reinício do jogo em certos casos.[13] Jeff Sutherland,[14] John Scumniotales e Jeff McKenna conceberam, documentaram e implementaram o Scrum, conforme descrito abaixo, na empresa Easel Corporation em 1993, incorporando os estilos de gerenciamento observados por Takeuchi e Nonaka.
Ken Schwaber e Jeff Sutherland fizeram a primeira co-apresentação do Scrum na conferência OOPSLA de 1995.[15] Esta apresentação essencialmente documentou o aprendizado que Ken e Jeff tiveram ao longo dos anos anteriores na aplicação do Scrum e ajudaram a implantá-lo no desenvolvimento de softwares em todo o mundo.[16]
Scrum junta conceitos de Lean, desenvolvimento iterativo e do estudo de Hirotaka Takeuchi e Ikujiro Nonaka.
A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de software. Ele tem sido usado com sucesso para isso, assim como Extreme Programming e outras metodologias de desenvolvimento. Porém, teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola pequena, projetos de pesquisa científica, ou até mesmo o planeamento de um casamento.[1]
Mesmo que idealizado para ser utilizado em gestão de projetos de desenvolvimento de software ele também pode ser usado para a gerência de equipes de manutenção, ou como uma abordagem para gestão de programas: Scrum de Scrums.
O Guia do Scrum
O Guia do Scrum é o documento oficial que documenta o Scrum, suas regras e definições conforme desenvolvido e sustentado por mais de 20 anos por Jeff Sutherland e Ken Schwaber.
O documento é mantido por duas instituições, a Scrum.org e seus Professional Scrum Trainers (PSTs) e a Scrum Alliance. Ambas oferecem o cursos preparatórios para certificações relacionadas ao Scrum.[17]
Manutenção e evolução do Guia do Scrum
Os criadores do Scrum Ken Schwaber e Jeff Sutherland são os responsáveis primários por toda e qualquer alteração direta ao documento do Guia do Scrum. Além disso os Professional Scrum Trainers, ou PST's, também atuam na evolução do Framework Scrum e no fornecimento de sugestões de melhorias para o documento e sua aplicação no mundo real. Sua atuação em empresas e com a comunidade é imprescindível para a evolução dos métodos, processos e ferramentas ágeis e no uso e adoção do Scrum.
O Professional Scrum Trainer (PST) é um título concedido pela Scrum.org a profissionais que demonstram profundos conhecimentos práticos e teóricos sobre o Framework Scrum e que são aprovados em um rigoroso e extenso processo seletivo para tal. O título de PST representa a mais alta honraria e reconhecimento dentro da comunidade Scrum e seus portadores são reconhecidos como verdadeiras autoridades na adoção, implementação e uso do Scrum e suas práticas complementares em empresas, governos e organizações.[18]
Atualmente existem 6 diferentes tipos de PST, cada um com uma diferente especialidade dentro do universo Scrum. Um PST pode ter uma ou mais especialidades e ser reconhecido por elas, que são:
- Professional Scrum Master: PST especializado nos processos e ferramentas relacionados ao papel de Scrum Master;
- Professional Scrum Product Owner: PST especializado nos processos e ferramentas relacionados ao papel de Scrum Master;
- Professional Scrum Developer: PST especializado nos processos e ferramentas relacionados ao papel de Scrum Master;
- Scaled Professional Scrum: PST especializado nos processos e ferramentas relacionados ao papel de Scrum Master;
- Professional Scrum with Kanban: PST especializado nos processos e ferramentas relacionados ao papel de Scrum Master;
- Professional Agile Leadership: PST especializado nos processos e ferramentas relacionados ao papel de Scrum Master;
Características do Scrum
- Clientes tornam-se parte da equipe de desenvolvimento (os clientes devem estar genuinamente interessados na saída);
- Entregas frequentes e intermediárias de funcionalidades 100% desenvolvidas;
- Planos frequentes de mitigação de riscos desenvolvidos pela equipe;
- Discussões diárias de status com a equipe de desenvolvimento;
- A discussão diária na qual cada membro da equipe de desenvolvimento responde às seguintes perguntas:
- O que fiz desde ontem em direção a meta?
- O que estou a pensar fazer até amanhã em direção a meta?
- Existe algo que me impede de atingir a meta?
- Transparência no planejamento e desenvolvimento;
- Reuniões frequentes com os stakeholders (partes interessadas no projeto) para monitorar o progresso;
- Problemas não são ignorados e ninguém é penalizado por reconhecer ou descrever qualquer problema não visto;
- Locais e horas de trabalho devem ser energizadas, no sentido de que "trabalhar horas extras" não necessariamente significa "produzir mais".
- Um princípio chave do Scrum é o reconhecimento de que, durante um projeto, os clientes podem mudar de ideia sobre o que eles querem e precisam (muitas vezes chamados requisitos churn), e que os desafios imprevisíveis não podem ser facilmente tratados de uma maneira preditiva ou planeada tradicional. Como tal, o Scrum adota uma abordagem empírica, aceitando que o problema não pode ser totalmente entendido ou definido, focando na maximização da habilidade da equipe para entregar rapidamente e responder às necessidades emergentes.
Gerenciamento ágil de projetos com Scrum
Scrum não só reforçou o interesse em gerenciamento de projetos de software, mas também desafiou as ideias convencionais sobre essa gestão. Scrum é voltado para instituições de gerenciamento de projetos, onde é difícil planear o futuro com mecanismos de controle de processos empíricos, como loops de feedback, onde constituem o elemento central do desenvolvimento do produto em comparação com a gestão de comando e controle tradicionais orientado. Ela representa uma abordagem radicalmente nova para o planeamento e gerenciamento de projetos de software, trazendo poder de decisão ao nível das propriedades operação e certezas. Scrum reduz defeitos e torna o processo de desenvolvimento mais eficiente, bem como reduzindo os custos de manutenção a longo prazo.
Sprint
A sprint é o principal evento do Scrum, é a unidade básica de desenvolvimento. É um período curto, que pode ir de uma semana até o máximo de quatro semanas. O mais importante é entregar um incremento de produto, algo concreto que possa ser testado, ao final da sprint, e não apenas análises teóricas, por exemplo.[19]
Antes de começar a sprint, deve ocorrer uma reunião de planejamento, chamada de Sprint Planning (Planejamento da Sprint). Nessa reunião, são definidos os itens a serem realizados durante o ciclo, que são retirados do Product Backlog. É importante que tanto o time de desenvolvimento quanto o Product Owner estejam nessa reunião. Os itens da sprint compõem o que é chamado de Sprint Backlog. Nesse momento, estes itens devem ser refinados e expandidos pelo time de desenvolvimento, com as informações técnicas e o tempo necessários para a conclusão de cada item.[19]
Depois da definição do Sprint Backlog, é chegado o momento da execução, que irá de uma a quatro semanas, de acordo com o tempo definido para a Sprint. Durante esse período, devem ocorrer as Scrum Daily Meetings, que são pequenas reuniões diárias do time de desenvolvimento. A não ser que o time exiga a presença do Product Owner, é importante que o time consiga se auto-organizar sozinho. Além disso, as pautas das reuniões diárias normalmente envolvem a parte mais técnica do produto, logo a presença do Product Owner é pouco relevante. Essas reuniões podem durar, em média, 15 minutos apenas, e nesse momento o time pode revisar o que fez no dia anterior e se organizar para o dia atual. Ao fim do período de execução, é importante que o time entregue um incremento de produto concreto.[19]
Ao fim da Sprint, ocorre a Reunião de Revisão, para inspecionar o incremento e adaptar o Product Backlog com os itens concluídos. Nesse momento, pode-se colher feedbacks de partes interessadas, apresentando-lhes o que foi feito. Um erro comum é tornar essa reunião um momento de apresentar ao Product Owner o que o time de desenvolvimento fez. Na verdade, na reunião de revisão, o Product Owner já deve estar ciente de tudo que foi feito e já ter aprovado, pois ele deve acompanhar a execução da Sprint.[19]
Há, por fim, a Retrospectiva. Enquanto a reunião de revisão tem foco no produto, a reunião de retrospectiva tem foco no processo de trabalho. Aqui, o time pode comentar e refletir sobre os pontos fortes e fracos do seu trabalho em equipe, o que foi bom e o que foi ruim durante a execução, para aprimorar na próxima sprint.[19]
Papéis
Scrum é um esqueleto de processos que contém grupos de práticas e papéis pré-definidos. Os três papéis definidos no Guia Scrum[16] são:
- O Scrum Master, que mantém os processos normalmente no lugar de um gerente de projeto;
- O Dono do Produto, ou Product Owner, que representa os stakeholders e o negócio;
- A Equipe de desenvolvimento, ou DevTeam, um grupo multifuncional entre 3 a 9 pessoas e que fazem a análise, projeto, implementação, teste etc.
Papéis principais
Os papéis principais em equipes Scrum são aqueles comprometidos com o projeto no processo do Scrum - são os que produzem o produto (objetivo do projeto).
Product Owner (dono do produto)
O Product Owner representa a voz do cliente e é responsável por garantir que a equipe agregue valor ao negócio. O Product Owner escreve centrado nos itens do cliente (histórias tipicamente do usuário), os prioriza e os adiciona para o product backlog. Equipes de Scrum devem ter um Product Owner, e, embora esse possa também ser um membro da equipe de desenvolvimento, recomenda-se que este papel não seja combinado com o de ScrumMaster.
Equipe de Desenvolvimento (Development Team)
A equipe de desenvolvimento é responsável pela entrega do produto. A equipe é tipicamente composta de 5-9 pessoas com habilidades multifuncionais que fazem o trabalho real como analisar, projetar, desenvolver, testar técnicas de comunicação, documentos e outros. Recomenda-se que a equipe seja auto-organizada e auto-conduzida, mas que muitas vezes trabalhem com alguma forma de projeto ou gestão de equipe.
Scrum Master
Scrum é facilitado por um Scrum Master, que é responsável pela remoção de impedimentos à capacidade da equipe para entregar o objetivo da sprint / entregas. O Scrum Master não é o líder da equipe, mas age como um tampão entre a equipe e qualquer influência ou distração. O Scrum Master garante que o processo Scrum seja usado como pretendido. O Scrum Master é o responsável pela aplicação das regras. Uma parte fundamental do papel do Scrum Master é proteger a equipe e mantê-la focada nas tarefas em mãos. O papel também tem sido referido como um líder-servo para reforçar essa dupla perspectiva.
O Scrum é facilitado por um Scrum Master, que tem como função primária remover qualquer impedimento à habilidade de uma equipe de entregar o objetivo da sprint. O Scrum Master não é o líder da equipe (já que as equipes são auto-organizadas), mas atua como um mediador entre a equipe e qualquer influência desestabilizadora. Outra função extremamente importante de um Scrum Master é o de assegurar que a equipe esteja utilizando corretamente as práticas de Scrum, motivando-os e mantendo o foco na meta da Sprint.
Papéis auxiliares
Os papéis auxiliares em equipes Scrum são aqueles com nenhum papel formal e envolvimento frequente no processo de Scrum, mas, ainda assim, devem ser levados em conta.
Partes interessadas (clientes, fornecedores)
Estas são as pessoas que permitem o projeto e para quem o projeto vai produzir o acordado benefício, que justifica a sua produção. Eles só estão diretamente envolvidos no processo durante as revisões sprint.
Gerentes (incluindo gerentes de projeto)
Pessoas que irão configurar o ambiente para desenvolvimento de produtos.
Artefatos oficiais do Scrum
O Scrum Guide define os seguintes artefatos obrigatórios como necessários para o sucesso de um projeto que utilize Scrum:[5]
Product Backlog
O Product Backlog é mantido pelo Product Owner e é uma lista de requisitos que tipicamente vêm do cliente. O Product Backlog pode ser alterado a qualquer momento pelo Product Owner ou por decisão deste.
Um backlog é uma lista de itens priorizados a serem desenvolvidos para um software. Este artefato é a principal fonte de informação para o Planeamento de sprint (Sprint Planning). No decorrer da sprint, o Product Owner, o Scrum Master e a Equipe decidem no que a equipe irá trabalhar. O Product Owner mantém uma lista priorizada de itens de backlog, o backlog do produto, o que pode ser repriorizado durante o planeamento da sprint. A Equipe seleciona itens do topo do backlog do produto. Eles selecionam somente o quanto de trabalho eles podem executar para terminar. A Equipe então planeia a arquitetura e o design de como o backlog do produto pode ser implementado. Os itens do backlog do produto são então destrinchados em tarefas que se tornam o backlog da sprint.
Sprint Backlog
O Sprint Backlog é uma lista de itens selecionados do Product backlog e contém tarefas concretas que serão realizadas durante a próxima sprint para implementar tais itens selecionados.
O Sprint Backlog é uma representação em tempo real do trabalho que o Development Team planeia concluir na sprint corrente, e ele pertence unicamente ao Development Team.
Artefatos complementares ao Scrum
Além dos artefatos oficiais estabelecidos no Scrum Guide,[5] existem artefatos complementares que podem ser utilizados para melhorar a qualidade das entregas e a eficiência do time. Alguns deles são:
Burndown Chart
O Burndown é um simples gráfico, com dois eixos X e Y, baseado nas atividades que não ultrapassem um dia de trabalho. O eixo Y indica o número de tarefas existentes na sprint e o eixo X os dias que representam o tamanho da sprint.
Eventos Scrum
Daily Scrum Meeting
Cada dia durante a sprint, uma reunião de status do projeto ocorre. Isso é chamado de scrum diário, daily scrum ou stand up meeting (reunião em pé). Esta reunião tem diretrizes específicas:
- A reunião começa precisamente no horário marcado.
- Todos são bem-vindos, mas apenas "poucos" podem falar.
- O encontro tem duração determinada (Time-Box) e dura no máximo 15 minutos.
- A reunião deve acontecer no mesmo local e mesma hora todos os dias
- Durante a reunião, cada membro da equipe responde a três perguntas:
- O que você tem feito desde ontem em direção a meta?
- O que você está planeando fazer hoje em direção a meta?
- Você tem algum problema impedindo você de realizar seu objetivo em direção a meta?
- É papel do Scrum Master facilitar a resolução desses impedimentos. Normalmente, isso deve ocorrer fora do contexto do Daily Scrum para que a reunião possa durar menos de 15 minutos.
Reunião de planeamento da Sprint (Sprint Planning Meeting)
No início do ciclo de sprint, um Sprint Planning Meeting é realizado.
- Selecione o trabalho que está a ser feito.
- Prepare o Sprint Backlog que detalha o tempo que levará para fazer esse trabalho, com toda a equipe.
- Identificar e comunicar o quanto o trabalho é susceptível de ser feito durante a sprint atual.
- Dividida em duas partes:
- Parte 1 (Primeiras quatro horas): Team Product Owner: diálogo para priorizar o Product Backlog.
- Parte 2 (Próximas quatro horas): Team apenas: hash de um plano para a Sprint, resultando na Sprint Backlog.
No final de um ciclo de sprint, são realizadas duas reuniões: a "Sprint Review" e do "Sprint Retrospective".
Reunião de Revisão da Sprint (Sprint Review)
- Rever o trabalho que foi concluído e não concluído.
- Apresentar o trabalho realizado para os stakeholders (ou "a demo"). Um trabalho incompleto não pode ser demonstrado.
Retrospectiva da Sprint (Sprint Retrospective)
- Todos os membros da equipe refletem sobre a sprint passada.
- Faça melhorias contínuas de processos.
Duas questões principais são feitas na retrospectiva da sprint: O que correu bem durante a corrida? O que poderia ser melhorado na próxima sprint?
Scrum Solo
Scrum é baseado em pequenas equipes e permite a comunicação entre os membros da equipe. Entretanto, há uma grande quantidade de softwares desenvolvidos por programadores solos - isto é, sozinhos, sem um time para transformar os itens do backlog em itens em desenvolvimento.
Um software sendo desenvolvido por um só programador pode ainda se beneficiar de alguns princípios do Scrum, como: um backlog de produto, um backlog de sprint, um sprint e uma retrospectiva de sprint, tendo isso em mente uma metodologia baseada no Scrum original foi elaborada com o nome de Scrum Solo.[20]
Ferramentas
Como outras metodologias de desenvolvimento ágil, o Scrum pode ser implementado através de uma ampla gama de ferramentas. Muitas empresas utilizam ferramentas de software universais, como planilhas para construir e manter artefatos como o backlog da sprint.
Há também pacotes de software open-source e proprietários dedicados à gestão de produtos no âmbito do processo Scrum. Outras organizações implementam o Scrum sem o uso de quaisquer ferramentas de software, e mantêm seus artefatos na forma de cópias impressas, como papel, quadros e notas.
Desempenho da equipe e escopo de utilização
O desempenho da equipe será definido com base no histórico de entregas e conclusões de projetos anteriores, ações que iram definir o quanto em pontos a equipe consegue atingir. Através de um sistema de pontuação cada desenvolvedor atinge em média 20 pontos por sprint de duração de duas semanas.
Tal desempenho pode ser afetado por diversos fatores, os quais que devem ser trazidos para discussão na reunião de retrospectiva e planeamento. Nesta reunião, deve-se abordar a apresentação de problemas e dificuldade encontrados, buscando assim resoluções, melhorias no processo 16 de desenvolvimento de software e conseqüentemente objetivando a velocidade de conclusão dos próximos sprints.[21]
O Scrum é uma metodologia destinada a pequenas equipes com menos de dez pessoas[22][23] sugerem que a equipe seja composta de cinco a nove integrantes, se mais pessoas estiverem envolvidas no projeto, devem-se formar múltiplas Equipes Scrum.[24]
Uso de Scrum além do desenvolvimento de software
Algumas das áreas onde o Scrum é comumente usado fora do desenvolvimento de software incluem: [25]
- Marketing
- Design
- Recursos Humanos
- Vendas
- Educação
- Saúde
Referências
- «Scrum: o Framework Mínimo Viável». Linkedin. Consultado em 30 de setembro de 2019
- «15th Annual State of Agile Survey». CollabNet VersionOne. Consultado em 1 de outubro de 2019
- Atlassian. «Scrum — o que é, como funciona e por que é incrível». Atlassian. Consultado em 27 de setembro de 2021
- «Quero usar o Scrum. Por onde começo?». linkedin.com. Consultado em 25 de setembro de 2019
- «Home | Scrum Guides». www.scrumguides.org (em inglês). Consultado em 1 de junho de 2017
- Schwaber, Ken (1 de fevereiro de 2004). Agile Project Management with Scrum. [S.l.]: Microsoft Press. ISBN 978-0-7356-1993-7
- «SSW.Rules | Grammar - Do you know "Scrum" should be capitalized?». SSW.Rules (em inglês). Consultado em 11 de agosto de 2022
- Schwaber, Ken (2004). Agile project management with Scrum. Internet Archive. [S.l.]: Redmond, Wash. : Microsoft Press
- Schwaber, Ken. «SCRUM Development Process» (PDF). Advanced Development Methods. SCRUM Development Process. Consultado em 11 de agosto de 2022
- «The New New Product Development Game» (https://web.archive.org/web/20210209210402/http://agilix.nl/resources/TheNewNewProductDevelopmentGame.pdf). Harvard Business Review. 1986. Arquivado do original (PDF) em 9 de fevereiro de 2021
- Jeff Sutherland (2014). Scrum - a arte de fazer o dobro de trabalho na metade do tempo. [S.l.: s.n.]
- Sutherland, Jeffrey Victor; Schwaber, Ken (1995). «usiness object design and implementation: OOPSLA '95 workshop proceedings». Universidade de Michigan: 18. ISBN 978-3-540-76096-2
- «Scrum Guide | Scrum Guides». scrumguides.org. Consultado em 11 de agosto de 2022
- «Become a Professional Scrum Trainer». Scrum.org (em inglês). Consultado em 1 de outubro de 2019
- Magno, Alexandre (2019). Tire seu projeto do papel com SCRUM : atitudes e praticas para realizar seus projetos no trabalho e na vida. São Paulo: [s.n.] OCLC 1314871017
- Pagotto, Tiago; Fabri, João Augusto; L'Erário, Alexandre; Gonçalves, José Antônio (1 de junho de 2016). «Scrum solo: Software process for individual development». IEEE. 2016 11th Iberian Conference on Information Systems and Technologies (CISTI): 1–6. doi:10.1109/CISTI.2016.7521555
- Faoro, Mariana Wentz; Olinto, Maria Teresa Anselmo; Paniz, Vera Maria Vieira; Macagnan, Jamile; Henn, Ruth Liane; Garcez, Anderson; Pattussi, Marcos Pascoal (2018). «Dor musculoesquelética relacionada ao trabalho e sua associação com transtornos mentais comuns em trabalhadores de um frigorífico do Sul do Brasil». Revista Brasileira de Medicina do Trabalho. 16 (2): 136–144. ISSN 1679-4435. doi:10.5327/z1679443520180200
- Julnes, G (2001). «Evaluation (2nd Edition), by Carol Hirshon Weiss, Upper Saddle River, NJ: Prentice Hall, 1998, 372 pp.». The American Journal of Evaluation. 22 (2): 265–268. ISSN 1098-2140. doi:10.1016/s1098-2140(01)00123-0
- «Scrum (desenvolvimento de software)». Wikipédia, a enciclopédia livre. 7 de maio de 2019
- «O que é Scrum? - Synergyc». www.synergyc.co. Consultado em 27 de fevereiro de 2023
Ligações externas
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
