teorico 2

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

<p>Conteudista: Prof. Me. Erwin Alexander Uhlmann</p><p>Revisão Textual: Pérola Damasceno</p><p>Objetivo da Unidade:</p><p>Apresentar a estrutura de trabalho do Scrum, seus papéis e artefatos e tornar o aluno capaz de aplicar seu modelo em situações do</p><p>dia a dia.</p><p>˨ Material Teórico</p><p>˨ Material Complementar</p><p>˨ Referências</p><p>Scrum: Estrutura de Trabalho, os Papéis da Equipe, Fluxo e seus Artefatos</p><p>Scrum</p><p>O Scrum é uma estrutura de gerenciamento de equipes de trabalho que tem o objetivo de torná-las mais eficientes (Figura 1), ou seja, para que</p><p>gastem menos energia, menos tempo, menos trabalho, menos pessoas, entre outros recursos, e para alcançar o objetivo do projeto com um</p><p>mínimo de necessidades de correções, isto é, fazer com que a equipe também seja mais eficaz. Este framework é um dos mais amplamente</p><p>difundidos e utilizados, pois facilita a definição clara dos objetivos dos projetos tornando clara a visão das pessoas que estão trabalhando no</p><p>projeto e auxilia no cumprimento das metas de prazos e entregas</p><p>Figura 1 – Estrutura do Scrum</p><p>Fonte: Adaptada de scrum.org</p><p>Como o Scrum privilegia a gestão da equipe, podemos entender sua estrutura de trabalho como dividida em três partes: Scrum Master, Product</p><p>Owner e Developers, sendo, respectivamente: o gestor do projeto, facilitador e solucionador de conflitos da equipe; o segundo é o dono do projeto,</p><p>que direciona os objetivos, atua em conjunto com os desenvolvedores nas definições de escopo e suas mudanças; e, por fim, o último, que são os</p><p>desenvolvedores do projeto. Estas são as pessoas que realizam ou participam da realização do projeto.</p><p>A mentalidade dos valores do Scrum são:</p><p>1 / 3</p><p>˨ Material Teórico</p><p>Disciplina na priorização das entregas: Muitas alterações ocorrem com o atraso na entrega, e melhor que</p><p>alterar durante o desenvolvimento é incrementar depois da entrega. Até para documentar é</p><p>importante a alteração;</p><p>Responsabilidade ao assumir compromissos: Uma vez assumido, cumpra. Simples e direto. Cada membro</p><p>da equipe depende do trabalho de todos. Ao declinar um trabalho, outro terá de fazer e isto</p><p>A Estrutura de Trabalho</p><p>O Scrum é uma estrutura de procedimentos para desenvolvimento de projetos em diversas áreas, mas que, diferente de outros padrões (como o</p><p>PMI, extensamente documental), ele é Ágil. Mas não por ser Ágil ele deixa de ter documentação ou o PMI não é adequado. Todo framework tem</p><p>seus pontos fortes e fracos.</p><p>O Termo “Scrum” vem do Rugby, em alusão ao movimento que todos estão prontos para atacar, de forma rápida, um ponto de avanço.</p><p>E o que é um projeto?</p><p>Para o Project Management Institute (PMI), é um esforço temporário para entregar um produto ou serviço único. Temporário, pois deve ter datas</p><p>definidas para entrega; único, pois não é rotina.</p><p>Em desenvolvimento de programas, o modelo cascata é um dos mais utilizados, como já vimos na primeira Unidade, mas o Scrum, no entanto,</p><p>adota um modelo que permite adaptações, como o Throwaway igual ao movimento Ágil.</p><p>Product Backlog</p><p>comprometerá o planejamento, a entrega e, muitas vezes, a própria qualidade, ao acelerar para</p><p>cumprir a data com uma tarefa a mais;</p><p>Alinhamento à medida que o projeto progride: Durantes as sprints reviews, todos podem e devem ter ciência</p><p>do andamento de todo o projeto e da própria contribuição. Se segmentar o projeto em funções e</p><p>se atribuir um peso a cada função é possível estabelecer o progresso geral, veja:</p><p>Página de apresentação – 10%;</p><p>Login e senha – 20%;</p><p>Página do produto – 20%;</p><p>Página de edição – 30%;</p><p>Página de relatórios – 20%.</p><p>Se o item em desenvolvimento for o 3, o andamento geral do projeto é 50%.</p><p>O ponto crucial é definição do peso de cada parte;</p><p>Autonomia para realizar o trabalho: Se mais uma vez recorrermos aos valores do manifesto Ágil,</p><p>“Pessoas mais que processos”, a forma, o a IDE, o sistema operacional, o método de trabalho</p><p>do desenvolvedor não importa; a entrega é a prioridade;</p><p>Foco na melhoria contínua: As sprints reviews é o momento certo para se discutir o que dificultou e</p><p>como se fez algo de forma melhor para que no próximo ciclo se melhore.</p><p>Com isto, é importante a equipe de desenvolvimento ter sempre em mente o que pode ser melhorado.</p><p>O Product Backlog (Figura 2) é o escopo do projeto. Nele, se define os pontos a se desenvolver, o que deve ser entregue, funções, formas e tudo</p><p>mais. É com base no Product Backlog que se avalia o realizado, se planeja as sprints e se anotam as adaptações.</p><p>Figura 2 – Product Backlog</p><p>Fonte: Adaptada de scrum.org</p><p>Sprint Planning</p><p>O Scrum Planning (Figura 3) tem um funcionamento que permite a identificação de erros e acertos ao longo do desenvolvimento do projeto,</p><p>permitindo, assim, correções e adaptações comuns. Cada dia é uma Sprint (corrida, carreira, esforço) com duração de uma a quatro semanas (7 a</p><p>22 dias) e suas reuniões são de 15 minutos (daily scrums) para compartilhar o progresso obtido, planejar (a partir deste progresso) o próximo dia</p><p>de trabalho e identificar os obstáculos que dificultaram o avanço do trabalho. Estes obstáculos são discutidos na retrospectiva e alternativas de</p><p>melhoria são propostas para que isto não ocorra novamente. Ao final, é realizada a revisão da Sprint para avaliar qual o sucesso dos objetivos</p><p>(definidos no dia anterior) foram alcançados.</p><p>Figura 3 – Sprint Planning</p><p>Fonte: Adaptada de scrum.org</p><p>O Scrum se baseia em três pilares empíricos (baseados na experiência):</p><p>Transparência</p><p>Todos os aspectos do processo de desenvolvimento do produto/serviço a ser entregue pelo projeto devem estar visíveis para toda a equipe.</p><p>Quem desenvolve, quem inspeciona e quem avalia deve ter as mesmas definições de requisitos. O termo pronto deve ser comum a todos, ou seja,</p><p>o que foi passado para ser feito é o mesmo que será avaliado.</p><p>Durante as Sprints e mesmo da definição do Backlog do Produto, o Scrum Master, em conjunto com o Dono do Produto, devem definir as funções</p><p>do que será entregue e todos da equipe de desenvolvimento devem ter acesso a essas definições.</p><p>Ex.: no backlog do Produto consta sistema de login e senha. O Scrum Master apresenta como login o e-mail e a senha definida pelo sistema com</p><p>possibilidade de trocar a qualquer momento e de recuperação de forma autônoma. Desta forma, fica definido que “pronto”’ ou “entregue” é um</p><p>sistema de login e senha com recuperação pelo usuário, de forma autônoma, pelo e-mail e link que expira em 30 minutos, e, se logado, pode</p><p>alterar a senha da forma que desejar.</p><p>Viu quantos detalhes a mais que um simples login e senha?</p><p>Isto tudo deve constar na ata da reunião, juntamente com a engenharia de software.</p><p>Para se adequar ao modelo Ágil, é importante não definir muito mais itens além disso, deixando outros</p><p>elementos do login e senha para a próxima reunião. Isto é, é importante que se pense num ciclo de entregas</p><p>de uma a quatro semanas!</p><p>Inspeção</p><p>Os participantes do projeto devem frequentemente avaliar as entregas definidas na Sprint para certificar a correta entrega e o progresso do</p><p>objetivo a ser entregue para que se detecte (anote) os obstáculos enfrentados.</p><p>Quais obstáculos dificultaram o desenvolvimento de ontem? Quanto da entrega já realizamos? Um método interessante é a anotação de todos os</p><p>pontos de desenvolvimento e marcar como feito, em andamento e por fazer, a verificação da porcentagem entregue.</p><p>Ex.: a imagem clássica dos Post-Its em que se anota: o que fizemos, o que estamos fazendo e o que falta fazer. Separados em três colunas com a</p><p>ação e a função escrita no Post-It (Figura 4).</p><p>Figura 4 – Controle de desenvolvimento e entregas</p><p>Adaptação</p><p>Do que foi definido na Sprint, quais itens tiveram seu escopo alterado? Para que atendesse às necessidades do projeto,  quanto do objetivo foi</p><p>alterado? Isto implica em custos? Tempo? Para tanto, é importante manter em mente e de forma viva na equipe. Isto permite retornos acerca do</p><p>andamento do projeto e inspeção mais rápidos.</p><p>Sprint Backlog</p><p>Na fase de Sprint Backlog (Figura 5) o Scrum Master define os pontos de desenvolvimento da Sprint</p>
<p>com base na entrega da Sprint anterior. Ele</p><p>incentiva a equipe (Desenvolvedores [Developers]) a discutir e a definir a melhor forma de trabalhar. Todos os pontos são documentados e</p><p>distribuídos.</p><p>Figura 5 – Sprint Backlog</p><p>Fonte: Adaptada de scrum.org</p><p>Daily Scrum</p><p>As Daily Scrum (Figura 6) poderiam facilmente ser interpretadas como alinhamento de ataque diário, isto é, são reuniões diárias, rápidas, com</p><p>duração de 15 minutos em que se definem os pontos de solução para todos na equipe.</p><p>Trocando Ideias...</p><p>As reuniões de Scrum são famosas por terminarem em, no máximo, 15 minutos e todos ficarem de pé, ao</p><p>ponto de retirarem as cadeiras da sala para provocar ou incentivar tal comportamento. É claro que, como o</p><p>próprio modelo Ágil emprega, a adaptação é crucial. E fica a reflexão: é, de fato, primordial ao modelo que</p><p>se retirem as cadeiras da sala? Ou este é só mais um anglicismo? As reuniões devem terminar abruptamente</p><p>ao 15º minuto? Qual a real razão de se delimitar o tempo? Reuniões são fundamentais, mas produzir é o</p><p>objetivo!</p><p>Figura 6 – Daily Scrum</p><p>Fonte: Adaptada de scrum.org</p><p>Sprint Review</p><p>A Sprint Review (Figura 7) tem por objetivo verificar o que conseguiu desenvolver, o que será aceito como entregue e o que faltou. Neste ponto, se</p><p>determinam também os impeditivos. Estes impedimentos são, então, passados ao Scrum Master para que ações sejam realizadas e não ocorram</p><p>novamente.</p><p>Figura 7 – Sprint Review</p><p>Fonte: Adaptada de scrum.org</p><p>Além disto, o Scrum permite uma melhoria contínua dos processos, fazendo com que o processo como um todo melhore continuamente.</p><p>Increment</p><p>O trabalho a ser realizado na Sprint é organizado durante o evento “planejamento” da Sprint, que é criado de forma colaborativa (Figura 8). O time</p><p>box para este evento é de 8h, conforme a tabela. O Scrum Master precisa participar para garantir a manutenção do tempo.</p><p>O que pode ser entregue como resultado ou incremento da Sprint?</p><p>Como será realizado o trabalho para entregar este incremento?</p><p>Figura 8 – Increment</p><p>Fonte: Adaptada de scrum.org</p><p>Sprint Retrospective</p><p>A Sprint Retrospective (Figura 9) procura determinar o que funcionou e não para melhorar o processo de desenvolvimento. O que fizemos ontem</p><p>que não deveríamos fazer hoje? O que fizemos que poderia ser melhor? Como fazer mais rápido?</p><p>Nesse momento, o Scrum Master verifica com o Product Owner se o que está sendo entregue será aceito. Se for rejeitado um novo ciclo de Sprint,</p><p>deve ser realizado para que a entrega seja garantida com a qualidade desejada. Caso seja aceito, os itens de melhoria serão revisados e anotado o</p><p>progresso geral do projeto.</p><p>Figura 9 – Sprint Retrospective</p><p>Fonte: Adaptada de scrum.org</p><p>Transparência! O progresso geral, os itens discutidos de melhoria, falhas, erros, acertos e tudo que foi apresentado na Sprint Retrospective deve</p><p>estar disponível a todos, principalmente, em caso de rejeição da entrega, o que foi rejeitado, para que o erro não seja cometido novamente, para</p><p>que o entendimento do que é “pronto” seja para o Product Owner para o Scrum Master e para os Desenvolvedores.</p><p>Os Papéis na Equipe do Scrum</p><p>O Scrum conta com papéis centrais, compostos pelo Dono do Produto, Scrum Master e Time Scrum (ou equipe de desenvolvimento).</p><p>Nos papéis não essenciais estariam os usuários, gestores, fornecedores, parceiros, entre outros. Importante frisar que o projeto só terá êxito se</p><p>todos participarem, de acordo com seus papéis e seus valores, sem interferências, nem sobreposições. Um papel tido como não essencial</p><p>influencia diretamente o resultado do projeto.</p><p>A equipe (Figura 10) dos times Scrum não são grandes, variam entre cinco e nove pessoas. Para Pastore de Lima (2011, p. 25 apud COHEN, 2010):</p><p>1. Menor sossego: Em um grupo pequeno, o sentimento de "não preciso fazer o trabalho, alguém irá fazê-lo" é menor do</p><p>que em equipes maiores;</p><p>2. Interação construtiva: O sentimento de confiança e responsabilidade mútua com equipes pequenas é maior;</p><p>3. Menor tempo para coordenar os esforços: Times pequenos gastam menos tempo coordenando os esforços de seus</p><p>membros. Até algo simples como organizar uma reunião com uma equipe grande se torna mais estressante;</p><p>Figura 10 – Equipe Scrum</p><p>Fonte: Adaptada de scrum.org</p><p>Product Owner</p><p>O dono do produto (Figura 11) é o representante do cliente. Ele é o responsável por priorizar as necessidades do cliente, fazer as medições</p><p>contínuas, colher os requisitos e define o critério de aceitação e o critério de pronto do produto.</p><p>4. Ninguém fica de lado: Em equipes menores a chance de alguém ficar de fora das atividades de grupo e discussões é</p><p>menor que em uma equipe grande;</p><p>5. A satisfação entre os integrantes de uma equipe pequena é maior: Como em uma equipe menor as contribuições de uma</p><p>só pessoa ficam mais visíveis e significantes, a satisfação dessa pessoa é maior;</p><p>6. Indivíduos especializados em uma só área: Em equipes grandes os integrantes estão mais propensos a trabalhar</p><p>somente em uma área, assim, reduzindo o nível de aprendizado.</p><p>Figura 11 – Product Owner</p><p>Fonte: Adaptada de scrum.org</p><p>Características do dono do produto:</p><p>Scrum Master</p><p>O Scrum Master (Figura 12) é o responsável por remover os impedimentos do desenvolvimento, é o facilitador. Além disso, é dele a</p><p>responsabilidade de escolher seus integrantes de forma a ter uma equipe auto-organizada para que saibam se completar sem a necessidade de</p><p>dependerem de terceiros. Estes integrantes também devem ser multifuncionais para que não dependam de outras pessoas fora do time que</p><p>conheçam a solução necessária para o projeto.</p><p>Representa o cliente e as partes interessadas;</p><p>Define os requisitos do produto;</p><p>Determina a data de entrega e o conteúdo;</p><p>Mantém priorizado o backlog (lista de requisitos) do produto;</p><p>Aceita ou rejeita as entregas.</p><p>Figura 12 – Scrum Master</p><p>Fonte: Adaptada de scrum.org</p><p>Características do scrum master:</p><p>Time Scrum (Developers)</p><p>Os desenvolvedores (Developers) (Figura 13) são os responsáveis pelo desenvolvimento do produto a ser entregue.</p><p>Responsável por fazer o Scrum funcionar;</p><p>Remover os impedimentos;</p><p>Zelar pelos princípios, os pilares do Scrum e o fluxo do modelo;</p><p>Responsável pela aplicação das práticas e dos processos;</p><p>Impedir interferências externas;</p><p>Capacidade de resolver problemas.</p><p>Figura 12 – Desenvolvedores (developers)</p><p>Fonte: Adaptada de scrum.org</p><p>Características do time scrum:</p><p>O Fluxo Scrum – Dinâmica de Funcionamento</p><p>Time Box</p><p>A Time box (Caixa de tempo) define o limite de tempo necessário para execução de um trabalho. Cada evento do Scrum tem sua time box – sua</p><p>caixa de tempo já predefinida.</p><p>Cada um dos eventos do Scrum tem um tempo de duração, os chamados time box, e a duração dos eventos é de extrema importância para dar</p><p>ritmo e consistência à rotina de trabalho de uma equipe Scrum. Desta forma, todo evento tem sua time box definida e sua duração máxima</p><p>estabelecida, garantindo, assim, a previsibilidade da entrega.</p><p>Responsáveis pelo desenvolvimento do produto;</p><p>Disposição, companheirismo, colaboração e proatividade;</p><p>Estimar o esforço necessário para criar o produto;</p><p>Aprovar a lista de necessidades para cumprimento do Sprint;</p><p>Auto-organizados.</p><p>O Scrum Master deve ficar atento ao cumprimento das caixas de tempo, orientando e guiando a equipe para que atue dentro do período máximo</p><p>estabelecido pelo framework do Scrum.</p><p>Veja, na Tabela 1, todos os eventos do Scrum e seus respectivos tempos máximos de duração:</p><p>Tabela 1 – Tempo das Caixas de Tempo</p><p>Evento Scrum</p><p>Duração máxima para uma</p><p>Sprint de 4 semanas</p><p>Planejamento da Sprint 8 horas</p><p>Reunião Diária 15 minutos</p><p>Revisão da Sprint 4 horas</p><p>Retrospectiva da Sprint 3 horas</p><p>Declaração de Visão do Projeto</p><p>A visão é formalizada na declaração de visão do projeto, onde são esboçados os requisitos. O documento de visão precisa ter:</p><p>Artefatos do Scrum</p><p>Backlog do Produto</p><p>Título;</p><p>Objetivo;</p><p>Justificativa (razão do projeto existir);</p><p>Descrição geral;</p><p>Equipe essencial;</p><p>Equipe não essencial;</p><p>Premissas (“O que está</p>
<p>fora de controle?”, ”espera-se que isto esteja funcionando”, “que foi feito...”);</p><p>Restrições (tempo e recurso restritos, estrutura, etc.);</p><p>Escopo;</p><p>Riscos preliminares (o que pode afetar direta ou indiretamente o projeto).</p><p>É no Backlog do Produto que se estruturam os requisitos e as características do produto que será criado. O que o produto deve ter para atender ao</p><p>desejo do cliente. Deve se definir as prioridades de entrega nos ciclos do Scrum.</p><p>Exemplos:</p><p>Desta forma, se estabelece o que foi acertado e poderá ser entregue e cobrado.</p><p>Backlog da Sprint</p><p>A partir do Backlog da Sprint, as prioridades são executadas dentro de um determinado período da Sprint (uma a quatro semanas).</p><p>Exemplos:</p><p>Entrega do Produto</p><p>Com as prioridades realizadas, o Product Owner verifica, no Backlog do Produto, se o que foi entregue corresponde ao que foi definido, requisitado</p><p>no início da Sprint, destaques a seguir para relembrar.</p><p>O sistema deve ter uma página de apresentação com até 10 produtos disponíveis e um botão “mais produtos”. Ao clicar em</p><p>“mais produtos”. A página “Todos os Produtos” deve ser aberta com carregamento por demanda a cada 10 produtos,</p><p>conforme a rolagem da página;</p><p>O sistema deve ter uma página de login e senha para o que os administradores entrem e gerenciem. O sistema deve permitir a</p><p>recuperação autônoma, por meio do e-mail, com página ativa por apenas 30 minutos antes de expirar;</p><p>Somente um administrador cadastrado pode inserir outro administrador.</p><p>Desenvolver um sistema de login e senha demora duas semanas;</p><p>Desenvolver a interface gráfica do usuário;</p><p>Desenvolver o sistema com as regras de negócio;</p><p>Entrar no sistema caso login e senha sejam corretos;</p><p>Atrasar 3 segundos o carregamento da página de login (em caso de login errado) a fim de evitar robôs de força bruta (este item</p><p>da razão do tempo de carregamento é importante para a transparência!).</p><p>No backlog do produto: O sistema deve ter uma página de login e senha para o que os administradores entrem e gerenciem. O</p><p>sistema deve permitir a recuperação autônoma por meio do e-mail com página ativa por apenas 30 minutos antes de expirar;</p><p>No backlog da sprint:</p><p>O sistema deve ter uma página de apresentação com até 10 produtos disponíveis e um botão</p><p>“mais produtos”. Ao clicar em “mais produtos” a página Todos Produtos deve ser aberta</p><p>com carregamento por demanda a cada 10 produtos, conforme a rolagem da página;</p><p>Claramente são textos de exemplo e incompletos, mas pretende-se demonstrar que o pedido é o que é entregue.</p><p>O sistema deve ter uma página de login e senha para o que os administradores entrem e</p><p>gerenciem. O sistema deve permitir a recuperação autônoma por meio do e-mail com</p><p>página ativa por apenas 30 minutos antes de expirar;</p><p>Somente um administrador cadastrado por inserir outro administrador.</p><p>Em Síntese</p><p>O Scrum é o mais difundido entre os modelos de trabalho ou frameworks, pois permite, de forma simples,</p><p>para todos compreenderem seu funcionamento, uma boa documentação e entregas rápidas, mesmo para</p><p>projetos um pouco maiores. A equipe possui liberdade de trabalho e a gestão a confiança da entrega nos</p><p>prazos por trabalhar com períodos curtos.</p><p>O Scrum permite ainda que uma empresa grande ou pequena possua este método de trabalho com a</p><p>fragmentação de grandes equipes em equipes menores, e empresas pequenas possam com a mesma</p><p>qualidade e agilidade assumir contratos maiores.</p><p>Indicações para saber mais sobre os assuntos abordados nesta Unidade:</p><p>Sites</p><p>Scrum</p><p>Saiba mais sobre cursos e certificações. Acesse o site de se aprofundar no assunto.</p><p>Clique no botão ao lado para conferir o conteúdo.</p><p>ACESSE</p><p>Leitura</p><p>Metodologias Ágeis para o Desenvolvimento de Software: Aplicação e o Uso da  Metodologia</p><p>Scrum em Contraste ao Modelo Tradicional de Gerenciamento de Projetos</p><p>Um comparativo entre o Scrum e a metodologia tradicional de forma científica. Muito importante para</p><p>entender  a metodologia e suas vantagens.</p><p>Clique no botão ao lado para conferir o conteúdo.</p><p>ACESSE</p><p>Gerenciamento de Projetos de Software com Scrum</p><p>Como funciona o scrum e suas características. Leitura importante para entender os aspectos do método.</p><p>Clique no botão ao lado para conferir o conteúdo.</p><p>ACESSE</p><p>2 / 3</p><p>˨ Material Complementar</p><p>https://bit.ly/37LlA8n</p><p>https://bit.ly/3vfkIBJ</p><p>https://bit.ly/3ELWWQY</p><p>Genesis and Evolution of the Agile Movement in Brazil – Perspective from Academia and Industry</p><p>Neste artigo é fácil entender como está a evolução da adoção do SCRUM no Brasil. Importante para saber</p><p>sobre o futuro desta metodologia no mercado de trabalho.</p><p>Clique no botão ao lado para conferir o conteúdo.</p><p>ACESSE</p><p>https://bit.ly/3rSmBSW</p><p>ALMEIDA, G. A. M. Fatores de escolha entre metodologias de desenvolvimento de software tradicionais e ágeis. Prelo – Escola Polítécnica, USP.</p><p>São Paulo, 2017. Disponível em: <https://www.teses.usp.br/teses/disponiveis/3/3136/tde-11042017-143311/en.php>. Acesso em: 04/04/2022.</p><p>DUNCAN, W. A Guide to the Project Management Body of Knowledge. Project Management Institute. 2005.</p><p>LIMA, F. A. O. Gerenciamento de projetos de software com Scrum. 2011. Trabalho de Conclusão de Curso. Universidade Tecnológica Federal do</p><p>Paraná.</p><p>MELO, C. O.; FERREIRA, G. R. M. Adoção de métodos ágeis em uma Instituição Pública de grande porte - um estudo de caso.</p><p>In: Workshop Brasileiro de Métodos Ágeis–WBMA, p. 104-117, 2020. Disponível em:</p><p><http://agilcoop.org.br/files/WBMA_Melo_e_Ferreira.pdf>. Acesso em: 04/04/2022.</p><p>SCHWABER, K; SUTHERLAND, J. Scrum. The O�cial Guide. 2010.</p><p>________.; SUTHERLAND, J. Guia do Scrum. Um guia definitivo para o Scrum: as regras do jogo. 2017. Disponível em:</p><p><https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Portuguese-Brazilian.pdf>. Acesso em: 04/04/2022.</p><p>3 / 3</p><p>˨ Referências</p>