SABRINA SOUZA

Estudo bibliográfico de aprofundamento na Metodologia ágil Scrum.

INTRODUÇÃO

Devido à falta de recurso suficiente das em especifico pequenas e medias fábricas de software para seguirem algum processo, na procura de meio alternativo para reduzir a quantidade de projetos fracassados, eliminando gastos com documentação excessiva, nasceu os processos ágeis como uma nova tendência de desenvolvimento para melhorar a qualidade dos sistemas.

Os processos tradicionais gastam grande parte do tempo planejando o software antes de iniciar a implementação. A demora para ser disponibilizado ao cliente faz o software ficar defasado, o cliente também pode mudar de ideia, para seguir o passo no mesmo tempo é necessário atualizações ou melhor dizendo mudanças, porem para os métodos tradicionais não é algo simples devido a fase de planejamento ter sido concluída.

A falta de adequação aos processos tradicionais de desenvolvimento de software devido a ligeira distancia da realidade de algumas organizações de médio e pequeno porte, trouxe a necessidade da melhoria e desburocratização dos processos tradicionais de criação de software, desta forma maximizando o potencial de evolução com menos burocracias e um acréscimo de custo benefício.

A metodologia ágil Scrum foi criada em 1996 por Ken Schwaber e Jeff Sutherland e destaca-se das demais metodologias ágeis pela maior ênfase dada ao gerenciamento do projeto. Reúne atividades de monitoramento e feedback, em geral, reuniões rápidas e diárias com toda a equipe, visando a identificação e correção de quaisquer deficiências e/ou impedimentos no processo de desenvolvimento. [SCHWABER 2008]

Veremos mais entusiasticamente a Metodologia Ágil Scroll que faz parte do pacote das metodologias ágeis, vamos lembrar que veio como uma alternativa aos processos tradicionais na tentativa de reduzir os problemas e custos dos projetos de software, scroll enfatiza a comunicação, mais flexível a mudanças e privilegia as atividades que de maior valor  ao cliente tornando parte da equipe de desenvolvimento.

1.1 COMPREENSÃO DO SCRUM

A pesar do scrum não ser uma Metodologia por mais que popularmente conhecido como tal, isso se dá pelo fato dele não seguir um processo padronizado onde metodicamente é seguido uma série de etapas sequenciais garantindo a produção, etc. Ele na realidade é um framework para organizar e gerenciar trabalhos complexos usado para a gestão dinâmica de projetos, o scroll na procura da maximização e eficácia do trabalho é uma excelente ferramenta de controle, atuando em times auto-organizados e fazendo uso da inteligência coletiva potencializando as equipes de trabalho com o mesmo objetivo em comum.

De acordo com [SCHAWABER & BEEDLE 2002], Scrum trata-se de uma abordagem empírica de lidar com o caos, em detrimento a um processo bem definido. Focado em pessoas para ambientes em que há requisitos voláteis, resultando em uma abordagem que reintroduz as ideias de flexibilidade, adaptabilidade e produtividade. O foco da metodologia é encontrar uma forma de trabalho dos membros da equipe para produzir o software de forma flexível e em um ambiente em constante mudança.

Dentre equipes pequenas e multidisciplinares, requisitos instáveis ou desconhecidos e interações curtas a metodologia o scroll baseasse em princípios um deles é ao invés de esperar que o projeto final esteja concluído, o mesmo é dividido em etapas entregáveis atuante para que seja entregue ao cliente mesmo incompleto já pode ser utilizada temporariamente cada uma das etapas.

O scroll baseia-se em ciclos de desenvolvimento sucessivos denominados sprint, então no início de cada sprint a equipe faz Sprint Planning Meeting para priorizar  Product Owner  as funcionalidades do projeto que estão no product backlog, de acordo com a capacidade de execução do Time, define quais funcionalidades Product Backlog serão implementadas naquele ciclo Sprint Backlog. Veremos mais exemplificado os conceitos relacionados a esse framework ágil scrum, de maneira que o assunto se tornar mais elucidado na parte de Artefatos Scrum onde será explicado com mais detalhes a função de cada um.

O Sprint denomina cada ciclo do Scrum, possui intervalos de tempo reduzido de 15 a 30 dias, demorando possivelmente entre uma a quatro semanas, mas o tamanho de cada sprint é adequado à empresa em questão, o resultado entrega uma parte funcional do produto ou serviço que já pode ser testado de cada Sprint. Deixando compreendido que a metodologia scroll enfatiza o planejamento e gerenciamento dos projetos, não requer ou fornece qualquer técnica ou método especifico para desenvolvimento de software.

1.2 PAPEIS SCRUM

É impreterível o entendimento claro dos princípios do Scrum por todos os Stakeholders, para se aproximar da excelência e alcançar o sucesso de cada Sprint e é claro na totalidade do projeto.

Os Papéis do Scrum dividem-se em duas categorias que são Papeis Centrais onde existe três papéis principais conhecido como Time Central do Scrum que são: Product Owner; Scrum Master; Time Scrum. E não esquecendo dos Papéis não-essenciais que tem seu valor, e existe 3 papeis principais que são: Stakeholders que é composto por clientes, usuários e patrocinadores ; Fornecedores; Scrum Guidance Body.

1.     Papéis Centrais: Os papeis centrais são obrigatórios e necessários para produzir o produto do projeto, os envolvidos nos papeis principais são totalmente responsáveis pelo sucesso em suma da totalidade do projeto. Veremos o Time Central do Scrum logo a baixo descrito.

·        Product Owner: O Product Owner (PO) tem poderes de liderança sobre o produto, existindo 4 escalas trabalho, por exemplo: Sendo necessário ser o PO chefe em grades projetos; PO Programa maximizando o valor de negócio para um programa; PO Portifólio organizando a empresa para atender a visão refinando o Backlog dos Produtos do Portfólio e também sendo o voz do cliente (VOC) representando a voz do cliente. Com responsabilidade em 17 processos scrum, é a pessoa responsável por maximizar o valor do negócio sendo o único responsável por decidir qual a ordem que devem ser feitos e quais recursos e funcionalidades serão construídos. Representante de todos os stakeholders articula as necessidades tornando-se o porta Voz do Cliente, colaborando ativamente com o Scrum Master e o Time garantindo a agilidade na construção no que o PO precisa.

·        Scrum Master: O Scrum Master (SM) assumindo um papel de liderança e com responsabilidades em 16 processos scrum, existente 3 escalas de trabalho, por exemplo: SM chefe e necessário em grades projetos e com vários Times proporcionando a comunicação entre os Times; SM do Programa direciona, facilita e ensina as práticas do Scrum a todos envolvidos no programa; SM Portifólio que atende somente as necessidades do portfólio ou unidade de negócios. O SM age na remoção de impedimentos das interferências externas que podem atrapalhar a produtividade da equipe garantindo que todos do time sigam as regras e práticas do Scrum, adequando a metodologia scrum à cultura da organização no gerenciamento do processo. O SM age como um líder, mas não como um gerente, desta forma um facilitador para o Time e Product Owner garantindo o fornecimento de um ambiente propício para concluir com sucesso o projeto facilitando a criatividade e a capacitação, mantendo e divulgando intra-time as informações sobre os progressos da equipe.

·        Time: O time é definido em um ambiente de pessoas com diferentes habilidades interagindo coletivamente com Time buy-in contendo todas as habilidades necessárias, e juntas formam uma equipe multidisciplinar e de autogerenciamento, com autoridade de decidir as ações que serão realizadas e priorizá-las organizando-as sendo responsável por entregar e implementar as funcionalidades ao final de cada Sprint.

2.     Papéis não-essenciais: Os papeis não-essenciais não são obrigatórios e necessários para o projeto, mesmo sem papel formal no time do projeto membros interessados podem desempenha um papel significativo nos projetos Scrum, apesar de não está diretamente ligado ao sucesso do projeto.

·        Stakeholder(s): Termo coletivo que inclui clientes, usuários e patrocinadores, frequentemente fazem interface com o Time Central do Scrum, trazendo para o projeto produzir os benefícios colaborativos.

·        Fornecedores: Fora das competências essenciais da organização do projeto os Fornecedores incluem indivíduos externos ou organizações que fornecem produtos e serviços.

·        Scrum Guidance Body: Este Scrum Guidance Body (SGB) orienta o trabalho realizado pelo Product Owner, Scrum Master e Equipe Scrum. Sendo uma função opcional, geralmente consiste em um conjunto de documentos e / ou um grupo de especialistas que estão envolvidos na definição de objetivos relacionados com a qualidade, dentre parâmetros-chave da organização e outros.

1.3 PRINCÍPIOS SCRUM

O scrum é o framework ágil provavelmente mais conhecido no mundo do desenvolvimento, podem ser aplicados em qualquer tipo de projeto ou organização, os aspectos e os processos do scrum podem ser modificados para atender às exigências do projeto, porem os princípios do Scrum que são a base do framework Scrum, devem ser respeitados e aplicados mantendo os princípios framework Scrum intactos. De acordo com o Guia SBOK (Scrum Body of Knowledge) veremos os princípios Scrum logo a baixo.

1.3.1 Controle de processos empíricos

No princípio do controle de processos empíricos o fluxo de informação fácil e transparente é promovido em toda a organização criando uma cultura de trabalho aberta, a transparência permite que todos os ângulos de qualquer processo Scrum sejam observados, compreendendo que este princípio mostra que todas as decisões dentro de um projeto Scrum devem ser tomadas com base em observação e experimentos.

·        Transparência: Promovendo a transparência no ampliamento da visão do projeto para todos os stakeholders e pelo Time Scrum com acesso a documentação Backlog Priorizando o produto aberto e visibilidade do progresso dos times através do Scrumboard, Gráfico Burndown, etc. Enfatizando o fortalecimento da comunicação com Reuniões Diárias para troca de informações do que foi feito anteriormente e o que será planejado fazer.

·        Inspeção: No melhor acompanhamento do progresso do Time Scrum em completar as tarefas do Sprint atual e feito o uso do Scrumboard representando as características da inspeção, juntamente com coleta de feedback dos clientes e outros stakeholders constantemente durante os processos de Desenvolver os Épicos, criar o Backlog Priorizado do Produto e Conduzir o Planejamento da Release,  e também pela inspeção e avaliação das entregas, feitas pelo Product Owner e pelo cliente.

·        Adaptação: São melhorias no trabalho que está sendo realizados através de adaptação adotadas a partir das dificuldades comunicadas nas reuniões diárias, da identificação de riscos ou mesmo das reuniões de retrospectiva, então parti daí surgi as melhorias que também podem resultar em Solicitações de Mudança, que são discutidas e aprovadas durante os processos de Desenvolver os Épicos, criar o Backlog Priorizado do Produto e Refinamento do Backlog do Produto.

1.3.2 Auto-organização

No Scrum a empatia, o comprometimento e a introspecção, ao compartilhar poder e autoridade com os membros do time, trans aos colaboradores motivação se tornado proativos buscam aceitar responsabilidades maiores, tendo a auto-organização como principal característica, isso caracteriza o estilo de liderança servidora preferida pelo scrum, de modo algum significa que os membros do time estejam autorizados a agir de qualquer maneira, pois, são bem definidos hierarquicamente. Então compreendendo a Auto-organização com a responsabilidade compartilhada o time maximiza desempenho caracterizando um ambiente criativo e inovador favorecendo o crescimento.

1.3.3 Colaboração

Refere-se ao Time Central do Scrum trabalhando e interagindo em conjunto com os Stakeholders contribuindo uns com os outros para produzir algo maior, de forma que todos os envolvidos e interessados no andamento do projeto ficam alinhados garantindo que a visão do projeto será alcançada. As dimensões principais do trabalho colaborativo são:

Consciência: Um deve saber do trabalho do outro colega do time.

Articulação: deve ser dividido o trabalho de maneira organizada entre os integrantes do time. O produto final é divido em unidades, e então é dividido entre os membros do time as unidades, de maneira que quando o trabalho for concluído, deve-se reintegrar novamente.

Apropriação: refere-se à adaptação da tecnologia para as situações do dia a dia, quando pensamos em colaboração, é essencial para apoiar as operações de trabalho ter aparato tecnológico, então a adaptação de tecnologia para a própria situação é imprescindível.

1.3.4 Priorização baseada em valor

O Scrum, usa a Priorização Baseada em Valor como um dos princípios fundamentais que impulsiona a estrutura e funcionalidade de todo o framework Scrum.

Compreendendo o princípio da Priorização Baseada em Valor, é colocado em prática durante os processos de criação do Backlog do Produto e de Refinamento do Backlog do Produto.

O PO deve entender o que o cliente quer e os valores, para melhor organizar os itens do Backlog Priorizado do Produto, devendo trabalhar simultaneamente com o Time scrum para entender as consequências negativas associadas do projeto, levado em conta uma estimativa subjetiva do valor de negócio projetado ao priorizar as User Stories, também são considerados três fatores na priorização que é valor, risco ou incerteza e Dependências. O PO também trabalha juntamente com o cliente e com o patrocinador para entender quais são os requisitos de negócios que fornecem o maior valor do negócio, então recebendo os requisitos do cliente e transcrevendo para a forma de User Stories viáveis. Averiguando todas as determinações da importância de cada User Stories é feito a identificação dos requisitos de alto valor e movidos para o topo do Backlog Priorizado do Produto. Quando o PO prioriza as User Stories no Backlog priorizado do produto, sabe-se que lá contém uma lista de todos os requisitos necessários para a realização do projeto.

1.3.5 Time-boxing

Para garantir que a equipe não se perca nos prazos e não atrase entregas as restrições de tempo são fixadas previamente, princípio muito característico do Scrum é a limitação do tempo de cada Sprint e de cada Evento dentro dela. Sendo sempre recomendável manter o Sprint Time boxed em 4 semanas a 6 semanas no máximo, as reuniões diárias de acompanhamento, tem um tempo parametrizado não podendo ser ultrapassado os 15 minutos de duração.

No aumento da velocidade de trabalho e inclusive da produtividade, trans vantagens na economia com despesas gerais, mas é preciso ter cautela ao determinar o time-boxing dos eventos para que essa atitude não gere o efeito oposto.

1.3.6 Desenvolvimento iterativo

O modelo iterativo é mais flexível para assegurar que qualquer mudança solicitada pelo cliente possa ser incluída, permitindo a correção de curso, na medida em que todas as pessoas envolvidas adquirem um melhor entendimento sobre o que precisa ser entregues de forma interativa como parte do projeto, com isso o tempo e o esforço necessário para chegar ao ponto final é consideravelmente reduzido oferecer o maior valor de negócio em um curto período de tempo.

1.4 ARTEFATOS DO SCRUM

Na busca pela excelência os artefatos do Scrum foram projetados para maximizar a transparência das informações chave facilitando a inspeção e análise para melhoria através de adaptação. Os artefatos do Scrum fazem parte dos elementos oficiais da metodologia Scrum, o framework é composto por papéis, eventos, artefatos e na administração das relações e interações entre eles surge as regras do Scrum. Veremos os Artefatos Scrum Segundo  Schwaber, K. et. al (2013).

1.4.1 Product Backlog

O Product Backlog é uma lista (documento) que está constantemente evoluindo, o PO em conjunto com o Time determina e geri a sequência deste trabalho definindo tudo o que se tem conhecimento inicialmente, que seja necessário para o produto final, desta forma são colocadas na sequência correta usando fatores como valor, custo, conhecimento e risco, feito esse refinamento de maneira que os itens de alto valor aparecerá no topo e comunicado em uma lista de prioridades conhecida como o Product Backlog.

1.4.3 Sprint Backlog

A Sprint Backlog é um conjunto de itens mais priorizados que é responsabilidade do Time, PO e SM através de conversação Sprint Planning onde tem requisitos quebrados em tarefas realizáveis para seleção do Product Backlog em uma Sprint, com o escopo a ser trabalhado pelo Time na próxima interação, então no Sprint Backlog é usualmente listado a ordenada de tarefas de modo transparente e claro.

1.4.5 Incremento

O incremento do produto criado durante o processo de Demonstrar e Validar ao final de cada Sprint, deve possuir todas as características e funcionalidades definidas nas User Story incluídas no Sprint e devem ter sido testadas com sucesso, o cliente ou os Stakeholders podem tomar decisões sobre o desenvolvimento do produto periodicamente. Ao final da Sprint um novo incremento deve estar “Pronto”, o que significa que deve estar na condição utilizável e atender a definição de “Pronto” do Time Scrum.

1.4.5 Definição de Pronto (Definition of Done -DoD) “DONE”

Para o Time Scrum DONE é usado para assegurar quando o trabalho está completado no incremento do produto, ou seja, quando um incremento é entregue utilizável pelo time para o Product Owner responsável por escolhe liberá-lo, esta "DONE" (pronto) significando que o produto foi testado e homologado.

1.5 ARTEFATOS COMPLEMENTARES AO SCRUM

Apesar de não estarem descritos diretamente como uma prática a ser adotada no Guia SBOK (Conhecimento em Scrum), sua utilização ocorre de maneira a complementar práticas.

Devido uma serie de pesquisa em livros e em sites pode compreender os artefatos não oficiais do Scrum, como artefatos complementares, pesquisados também no Wikipedia e no Devmedia. etc...

1.5.1 Declaração da visão do projeto

A Declaração da Visão do Projeto bem estruturada é o resultado principal do processo de Criar a Visão do Projeto que servirá de inspiração e orientação para todo o projeto, devendo se concentra no problema e não ser muito específica tendo espaço para a flexibilidade na acomodação dessas mudanças . Uma boa Visão do Projeto explica as necessidades do negócio e o que o projeto se destina a atender, ao invés de explicar como ele vai atender estas necessidades.

1.5.2 Impedimentos

A não identificação dos impedimentos pode custa caro para um projeto, qualquer fator que impede algum membro da equipe de realizar as suas atividades eficientemente, podendo ser afetados pelas restrições de tempo, custo, escopo, qualidade, recursos, capacidade de organização, e outros bottlenecks que os tornam difíceis de planejar, implementar, gerenciar, vindo de fonte interna ou externa devem ser citados durante a reunião diária, entretanto se o impedimento não pode ser resolvido durante a reunião diária, marca-se uma reunião com os envolvidos desobstruir esses obstáculos para os impedimentos serem solucionados, ao ser identificados e registrados formalmente pelo SM em um log de impedimentos, podendo ser discutidos durante as Reuniões Diárias e Reuniões de Revisão do Sprint, conforme o caso.

1.5.3 Burndown da Sprint

Burndown são gráficos simples, com dois eixos X são os dias mostrando o tamanho da sprint e Y são os números de tarefas na sprint, baseado nas atividades que não ultrapassem um dia de trabalho, utilizados para acompanhar o andamento do produto Release Burndown ou da Sprint Burndown.

1.5.4 Scrum board

O Scrum Board é um artefato extremamente enxuto, composto por três colunas “To do” (a fazer), “Doing” (fazendo) e “Done” (feito), útil para um fluxo de trabalho muito simples. Para serem considerados software passível de promoção para produção os itens devem passar por essas três colunas, sendo assim parte do incremento da Sprint.

1.5.5 User Stories

Bem conhecida em times ágeis, User Stories não faz parte de uma regra a ser seguida e sim uma especificação escrita utilizando linguagem de negócio, objetivando a necessidade dos usuários de forma simples, exemplificando, determinada funcionalidade de um produto e sua utilidade alcançando as expectativas. Veremos as definições dos User Stories logo a baixo:

Ator: O proprietário da User Story mais precisamente o interessado naquela funcionalidade.

Ação: É o que o ator quer fazer para alcançar seu objetivo dentro do sistema.

           Funcionalidade : o que o ator espera, o resultado ideal.

Então o Product Owner mantem a User story escrita comumente em papel. Alguns aspectos importantes de aceitação podem ser notados no verso do User Stories.

·        Validar se a funcionalidade é realmente necessária antes de incluí-la.

·        Análise das necessidades reais do usuário e priorizar o que deve ser feito.

·        Estimar o esforço que será necessário para implementar a funcionalidade.

Para uma User Story produtiva ser contundente é preciso está escrita no padrão INVEST, um acrônimo para:

·        Independente: Sem dependência podendo ser implementada individualmente.

·        Negociável: permiti um nível de negociação.

·        Valiosa : agregue algum valor ao produto de forma perceptível para o cliente ou usuário.

·        Estimável: Sendo mais fácil estimar o tempo e esforço que será necessário para implementar a funcionalidade.

·        Pequena (Small em inglês): Pequena, mas capas de ser realizada em uma sprint.

·        Testável: Os testes de aceitação garanti essa propriedade das histórias.

1.6 PRÁTICAS DO SCRUM

Eventos prescritos Scrum são usados para criar uma rotina e minimizar a necessidade de reuniões não definidas no Scrum. Todos os eventos são eventos Time-boxed, exemplos esses são as Daily Scrum, Sprint Planning, Sprint Review e Sprint Retrospective, todas essas com tempo fixado de começo e termino, maiores explicações de Time-boxed encontrasse na unidade 1.3.5 Time-boxing dos Princípios Scrum.

1.6.1 Sprint

A meta da Sprint são os itens do Backlog do Produto selecionados que entregam uma função coerente com o objetivo de fornece uma direção dentro dos limites da Sprint dando flexibilidade a respeito da funcionalidade para o Time sobre o porquê de estar construindo o incremento, podendo ser também qualquer outro motivo coerente que faça o time trabalhar em conjunto. desta forma o trabalho realizado em cada sprint deve criar algo de valor tangível para o cliente ou usuário. Sprints são Time-boxed com duração fixa para que tenham sempre um início e fim fixados, ela é uma iteração e segue o ciclo PDCA um acrônimo para:  Plan (Planejar); Do (Fazer); Check (Verificar); Act (Agir);  com as fases tradicionais de desenvolvimento: requisitos, análise, projeto e entrega. Objetivo ou meta da Sprint. Este A meta da Sprint é um objetivo definido para a Sprint que pode ser satisfeito através da implementação do Backlog do Produto

Reunião diária (Daily Scrum): A reunião diária e feita entre os membros da equipe com tempo definido de 15 minutos ou menos e cada membro do Time fala brevemente, respondendo as seguintes perguntas ( O que fez ontem, O que vai fazer hoje, há algum impedimento no seu caminho?) para que possa com as informações claras sincronizar as atividades e criar um plano nas próximas 24 horas com objetivo de saber como o time está em relação à direção da Meta da Sprint e produzir um plano de ação para o próximo dia de trabalho, desta forma as reuniões diárias são bem objetivas criando foco que melhora no autogerenciamento.

Reunião de Planejamento Sprint (Sprint Planning Meeting): Comumente é uma reunião realizada antes do Sprint, com Time-boxed 8 horas para o sprint de um mês, sendo dividida em 2 etapas que é definição de objetivo e estimativa de trabalho.

Reunião de Revisão Sprint (Sprint Review Meeting): A Reunião de Revisão Sprint é realizada no processo de Demonstrar e Validar do Sprint, é Time-boxed em quatro horas para um Sprint de um mês. os resultados do Sprint atual para o PO que revisa e compara o produto ou incremento do produto.

Reunião de Retrospectiva Sprint (Sprint Retrospective Meeting): A Retrospectiva da Sprint acontece após a reunião de revisão, antes de iniciar as atividades do próximo ciclo,  é feito uma análise do Sprint anterior e no seguinte com aspectos relevantes para o projeto, podendo ser atualizadas como parte dos documentos do Scrum Guidance Body. Com Time-boxed em quatro horas para o Sprint de um mês.

1.7 CICLOS DE VIDA SCRUM

O Scrum Ciclo de Vida Segundo Koscianski (2006), o ciclo de vida do Scrum é baseado em três fases e dividido em subfases:

·        Pré-Planejamento (Pre-game phase): Nesta fase é produzido o Product Backlog então requisitos são descritos em um documento e classificados por prioridade, definido o cronograma inicial onde é estimado o esforço para seu desenvolvimento de cada requisito. Nesta fase dentre outros atividades e inclui a definição do Time scrum, identificação de treinamento, ferramentas a serem utilizadas, como também a análise dos riscos e a definição da arquitetura do sistema. As alterações futuras devem ser descritas no Backlog.

·        Desenvolvimento (Game Phase): No Scrum o controle dos riscos são feitos continuamente durante o projeto sendo mapeados e acompanhados para avaliação de impacto, o que aumenta a flexibilidade para acompanhar as mudanças, deste modo as sprint são desenvolvidas tradicionalmente de forma iterativa em ciclos.

·        Pós-Planejamento (post-game phase): Nesta fase acontece a integração do software, testes, documentação do usuário, marketing, preparação de treinamento e o lançamento do produto.

CONSIDERAÇÕES FINAIS

O Scrum segue uma maneira de trabalhar onde e centrada nas pessoas, com o mínimo de documentação e planejamento antecipado baixo é baseado no valor do negócio engajada em alcançar a qualidade para o cliente cuja a participação é frequente durante o projeto inteiro, se torna extremamente receptível a mudanças e preparada para isso com seu estilo iterativo. Baseada em liderança servidora, ou seja, com o ambiente de trabalho extremamente colaborativo, alto organizado e descentralizado, mas é muito bem entendido hierarquicamente. O Scrum é super objetivo então com tudo compreendendo com clareza que sua medição de desempenho é baseada na priorização do valor, para desta forma obtenção de retorno do investimento no início e durante o projeto, então é contundente afirmar que a priorização do valor faz parte dos princípios fundamentais do Scrum que impulsiona a estrutura e funcionalidades.

Um dos grandes benefícios iterativos que o Scrum tem e ficou bem claro nesta pesquisa bibliográfica, foi o ciclo de etapas que se repete a cada Sprint, e assim pode entregar valor continuamente desde o começo, sendo atualizados constantemente bem diferenciado se comparado com os modelos tradicionais cujo a metodologia tradicional tem cinco etapas e só no final do estágio do projeto que entrega valor.

REFERENCIAS

Formação Scrum Master Certification

Disponível em:< https://web.dio.me/track/formacao-scrum-master>: Acessado em: 17 de outubro de 2022.

AMBLER, S. Agile Modeling: (2002) Effective Practices for Extreme Programming and the Unified Process. New York: Wiley Computer Publishing.

SCHWABER, K., BEEDLE, M. (2002) Agile Software Development with Scrum. City: Prentice.

SCHWABER, K. (2008) Agile Project Management with Scrum. Redmond: Microsoft Press.

SC RUMstudy. Conhecimento em Scrum (Guia SBOK). 3.Ed. Arizona: Avondale, 2017.

PMI - PROJECT MANAGEMENT INSTITUTE. Guia PMBOK: Um Guia para o Conjunto de Conhecimentos em Gerenciamento de Projetos, 6 .Ed, Pennsylvania: PMI, 2017.

ARAUJO, A. R. S., Silva, J. M., Mittelbach, A. F., SCRUM: Novas Regras do Jogo, Jynix Playware, Brasil.

KOSCIANSKI, A., Soares, Santos, M. Qualidade de Software, São Paulo, Novatec. Editora, 2006.

SZALVAY, V. (2007) Glossary of Scrum Terms. Disponível em: http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms#1117. Acessado em:18 de outubro de 2022.

SCHWABER, K.; SUTHERLAND, J. (2013) Um guia definitivo para o Scrum: As regras do jogo. Disponível em: <https://scrumguides.org/docs/scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf >Acessado em:18 de outubro de 2022.

ARTEFATOS Scrum. Wikipedia. Disponível em: <https://pt.wikipedia.org/wiki/Scrum_(desenvolvimento_de_software)#cite_note-:0-4>:Acessado em: 18 de outubro de 2022.

PRÁTICAS e artefatos comumente utilizados com Scrum. Devmedia. 2013. Disponível em:< Práticas e artefatos comumente utilizados com Scrum (devmedia.com.br)>: Acessado em: 18 de outubro de 2022.