APS relatório SCRUM

Prévia do material em texto

4
Relatório técnico SCRUM
Engenharia de Software
São Paulo
2020
4
3
LISTA DE ILUSTRAÇÕES
Figura 1 - Representação da equipe Scrum ………………………….........................08
Figura 2 - Elementos da ação de um Scrum………………………….........................12
Figura 3 – Fluxograma de atividades no Scrum........................................................13
Figura 4 - Ilustração dos gráficos Burndown e Burnup..............................................16
Figura 5 - Burndown chart do exemplo......................................................................19
Figura 6 – Representação SCRUM...........................................................................22
LISTA DE QUADROS
Quadro 1 - Tempo máximo para a realização de cada reunião.......................................11
Quadro 2 - Atividades e responsáveis no método Scrum do exemplo.....................20
Quadro 3 - Comparação de resultados teóricos e obtidos no estudo..................23/24
1 - Enunciado 
Leia e estude as referências sobre o Scrum e elabore um relatório técnico sobre Scrum escalável, o SCRUM em larga escala aplicável a grandes projetos. Além do relatório técnico deverá ser pesquisado um caso prático (descritivo de sistema), elaborando um backlog de produto, os backlogs de sprints, burndown e histórias de usuário.
Escrever um relatório sobre o Scrum como um framework ágil e mostrar como Scrum é utilizado no desenvolvimento de um produto de software. Escolher um case e desenvolver os artefatos do Scrum para o case escolhido. Elaborar um backlog de produto, sprints, burndown e as histórias de usuário.
2 - Introdução Scrum
O Scrum foi criado oficialmente na década de 90, por Ken Schwaber e Jeff Shuterland, com a ajuda de Mike Beedle, John Scumniotales e Jeff McKenna. A sua criação foi na realidade feita de maneira completamente independente, em duas frentes: de um lado, Ken Schwaber, e do outro Jeff Shuterland. Em 1995- 1996, Ken e Jeff se reuniram e documentaram o processo do Scrum como se conhece hoje em dia [Sutherland, 2004]. Em 2001, Ken Schwaber e Jeff Shuterland fizeram parte do grupo de profissionais que assinou o Agile Manifesto.
É um framework para desenvolvimento, entrega e suporte a produtos complexos para atingir o resultado otimizado, mantendo-se em um ritmo sustentável por um time. É aplicado em projetos com características igualmente variadas. Em projetos críticos de centenas de milhares de dólares e em projetos mais simples. Em projetos para produção de softwares comerciais, de sistes de Internet, de softwares embarcados, de aplicativos para dispositivos móveis, de softwares financeiros, de jogos e etc.
2.1 - Características e benéficos
Existe desde o início dos anos 1990, mas foi só na década seguinte que se tornou popular. Scrum ganhou o mundo, desbanco métodos tradicionais e se tornou a forma mais comum de se trabalhar em projetos de desenvolvimento de software.
Scrum é um processo iterativo incremental para desenvolver qualquer produto ou gerenciar qualquer trabalho. No fim de cada Sprint (iteração), é produzido um incremento de funcionalidades potencialmente entregáveis. As principais características do Scrum são [Schwaber, 2004]:
· um processo ágil (Agile) para gerenciar e controlar trabalho;
· é um “embrulho” para as práticas existentes de engenharia;
· uma aproximação coletiva (equipes) para desenvolver produtos e sistemas iterativamente e incrementalmente, onde requisitos mudam rapidamente.
· processo que controla o caos de interesses e necessidades conflitantes.
· maneira de melhorar a comunicação e maximizar cooperação.
· é uma forma de detectar e remover barreiras que entrem no meio do desenvolvimento e entregas de produtos.
· é uma forma de maximizar produtividade.
· scrum é escalável de um único projeto a toda uma organização, com vários projetos inter-relacionados.
· scrum é uma maneira de fazer com que todos se sintam bem em relação ao seu trabalho, suas contribuições, e que eles fizeram o melhor possível, o melhor que eles poderiam fazer
· scrum requer trabalho duro.
· scrum requer comprometimento
Ao aprender Scrum, você passará por termos como facilitação, trabalho em equipe, auto-organização, metas de negócios, motivação, relacionamento com os clientes, entre muitos outros. Utiliza-se de poucos conceitos mas possui grandes qualidades, como por exemplo: junta práticas de mercado já conhecidas e consagradas de uma forma organizada e que já funciona.
Um pequeno adendo para o fato de que não existe uma solução única para todos os problemas. O Scrum é um framework pequeno e bem simples, mas possui os seguintes benefícios:
· entregas frequentes de retorno ao investimento dos clientes;
· redução dos riscos do projeto;
· maior qualidade do produto gerado;
· mudanças utilizadas como vantagem competitiva;
· visibilidade do progresso do projeto;
· redução do desperdício;
· aumento da produtividade.
2.2 – Três pilares do controle do processo empírico
TRANSPARÊNCIA:
Para tomar decisões, as pessoas precisam de visibilidade do processo e do estado atual do produto. Para garantir que todos entendam o que estão vendo, os participantes de um processo empírico devem compartilhar um idioma. As revisões frequentes do Scrum fornecem aos membros da equipe e partes interessadas uma visão clara do estado do projeto.
INSPEÇÃO:
Para evitar desvios do processo ou produto final desejado, as pessoas precisam inspecionar o que está sendo criado e como, em intervalos regulares. A inspeção deve ocorrer no local do trabalho, mas não deve atrapalhar o trabalho. As equipes Scrum inspecionam seu trabalho concluído e seu processo no final de cada iteração durante as revisões e retrospectivas do Sprint.
ADAPTAÇÃO:
Quando ocorrerem desvios, o processo ou produto deve ser ajustado o mais rápido possível. Scrum permite ajustes no final de cada iteração.
O scrum é iterativo. Onde um processo, para chegar a uma decisão ou a um resultado desejado por meio da repetição de rodadas de análise ou de um ciclo de operações. O objetivo é trazer a decisão ou resultado desejado mais perto da descoberta a cada repetição (iteração).
Ele também é incremental. Uma série de pequenas melhorias em um produto ou linha de produtos existente que geralmente ajuda a manter ou melhorar sua posição competitiva ao longo do tempo. A inovação incremental é regularmente usada no negócio de alta tecnologia por empresas que precisam continuar a melhorar seus produtos para incluir novos recursos cada vez mais desejados pelos consumidores. A maneira como as equipes Scrum entregam peças de funcionalidade em pequenos lotes é incremental.
2.3 – Valores do Scrum
Os cinco valores do Scrum são: foco, coragem, franqueza, compromisso e respeito (Scrum Alliance, 2012).
· foco: os times mais produtivos trabalham apenas em um projeto de cada vez, evitando a multitarefa. O time trabalha focado em metas de negócios claras e alcançáveis com as quais se comprometem. Ao mesmo tempo, essas metas, definidas e negociadas com o Product Owner mantêm o foco do trabalho nas necessidades de negócios mais urgentes de cada momento. Além disso, para auxiliar o time a manter seu foco no seu trabalho, há no Scrum uma facilidade que remove impedimentos e protege o time de distrações e interferências externas, chamado ScrumMaster;
· coragem: As pessoas que trabalhamn no projeto têm coragem para aceitar a mudança como parte natural do processo de desenvolvimento do produto. O Product Owner e a organização têm coragem para confiar no time e deixa-lo livre para realizar o trabalho necessário para atingir metas acordadas. O time tem coragem para falhar e criar visibilidade sobre os problemas e, assim, aprender com essas falhas e problemas o mais cedo possível. Tanto o time quando o PO tem coragem para mostrar e entregar com frequência as partes do produto criado. O ScrumMaster tem coragem para remover impedimentos e realizar as mudanças necessárias na organização, de forma a ajudar a equipe a se tornar mais produtiva;
· franqueza:a franqueza ou transparência é necessária para que se possa realizar a inspeção e adaptação. Assim, o time busca melhorar sua forma de trabalhar a partir do feedback frequente de seus membros, o que cria a visibilidade sobre os problemas e estimula a busca por soluções. O time também busca validar os resultados de seu trabalho a partir do feedback frequente sobre o que produzem, o que cria visibilidade sobre as mudanças necessárias. Ele mantém visível o progresso do seu trabalho, para poder tomar medidas de correção necessárias. 
· Compromisso: o time determina como seu trabalho será realizado, monitora seu progresso e realiza as correções de rumo que achar necessárias. Assim é responsável e responsabilizado pelos seus resultados. Esse controle maior que ele tem sobre seu trabalho o torna mais comprometido com o sucesso do projeto, em cada ciclo de desenvolvimento, o time se compromete a alcançar a meta de negócio acordada com o PO e, assim, dá o seu melhor para fazê-lo. Por sua vez, o PO compromete-se a estabelecer as prioridades de trabalho de forma a satisfazer as necessidades de negócio do projeto, interagindo com quem for necessário para fazê-lo. 
· respeito: os membros do time trabalham juntos, compartilhando responsabilidades, e assim ajudam-se uns aos outros em seu trabalho. Todos que trabalham no projeto respeitam as opiniões uns dos outros, ouvem e buscam entender os diferentes pontos de vista. O PT respeita as decisões técnicas dos membros do time, que respeitam suas decisões de negócios.
· 
3 - A equipe Scrum
O Scrum prevê a criação de cargos bem definidos em uma equipe de desenvolvimento. Pereira, Torreão e Marçal (2007) mostram que uma equipe Scrum tem de cinco a nove integrantes. Sutherland (2016) mostra que existem três papéis em uma equipe Scrum: o dono do produto, o desenvolvedor do projeto e o mestre Scrum. O dono do produto assume o papel de cliente do projeto e deve dar à equipe feedbacks sobre as entregas. Esse feedback deve acontecer na reunião de revisão da sprint, ao término de cada sprint. O autor enfatiza ao citar que "o mestre Scrum e a equipe são responsáveis pela rapidez com que estão produzindo e como podem aumentar a velocidade. O dono do produto é responsável por traduzir a produtividade da equipe em valor." Sutherland (2016) mostra que identificou a necessidade de definir um líder para a equipe Scrum, algo como um treinador ou capitão. Essa pessoa seria responsável por ser um facilitador de todas as reuniões da equipe e também alguém que removeria todos os obstáculos que surgirem ao longo do desenvolvimento do produto. 
Figura 1 - Representação da equipe scrum
 
3.1 - Dono do Produto (Project Owner)
O conceito de dono do produto foi apresentado por Pham e Pham (2011), que o definiram como o guardião da visão e dos objetivos do projeto e ainda afirmaram que um gerenciamento ágil de projetos não pode ser bem-sucedido sem um bom dono do produto. Sutherland (2016) reforça isso, ao afirmar que o dono do produto tem como função traduzir a produtividade da equipe em valor. 
De acordo com Schwaber e Sutherland (2014), o dono do produto é o responsável por gerenciar o backlog do produto, o que inclui em suas atividades definir exatamente quais são os itens do backlog, ordená-los na sequência de execução e garantir que a equipe toda entenda e esteja ciente a respeito do backlog. Para Pham e Pham (2011), o backlog é uma lista de requisitos que inclui todos os aspectos referentes ao desenvolvimento de um produto, ou seja, todas as etapas a serem executadas até a equipe chegar ao produto final. 
Ou seja, o dono do produto será um intermediário entre o cliente final e os desenvolvedores do projeto. Ele que irá definir o que será realizado e quando será realizado, conforme a prioridade do cliente final. Para isto, o dono do produto deverá estar bem alinhado aos desejos do cliente final, assim, conseguirá guiar o projeto de forma apropriada. Schwaber e Sutherland (2014) ainda concluem que todo o time deverá respeitar as decisões do dono do produto e que mais ninguém tem autoridade para falar à equipe o que deverá ser feito.
3.2 - Scrum Master
Conforme Sutherland (2014), o mestre Scrum, ou ScrumMaster, e a equipe são responsáveis pela rapidez com que estão produzindo e como podem aumentar a velocidade de produção. Para Schwaber e Sutherland (2014), o mestre Scrum é responsável por garantir que o Scrum seja entendido e aplicado. “O mestre Scrum faz isso para garantir que o time Scrum adere à teoria, práticas e regras do Scrum. O ScrumMaster é um servo-líder para o time Scrum. ” (SCHWABER; SUTHERLAND, 2014, p. 7). Schwaber e Sutherland (2014) ainda listam algumas funções do mestre Scrum, como remover os impedimentos que surgirem durante a execução do projeto, facilitar os eventos previstos pelo Scrum e treinar o time de desenvolvimento para trabalhar com o Scrum. Além disso, Schwaber e Sutherland (2014) citam que o mestre Scrum poderá trabalhar também com o dono do produto, através das seguintes atividades: 
· encontrar técnicas para o gerenciamento efetivo do backlog do Produto;
· comunicar a visão, objetivo e itens do backlog do produto para o time de desenvolvimento;
· ensinar ao time Scrum a criar itens de backlog do produto de forma clara e concisa;
· compreender a longo-prazo o planejamento do produto no ambiente empírico;
· compreender e praticar a agilidade; e,
· facilitar os eventos Scrum conforme exigidos ou necessários.
3.3 - Eventos Scrum
Existem algumas reuniões que são previstas no método Scrum. O Scrum indica a realização de quatro eventos formais ao longo de uma Sprint para inspeção e adaptação do projeto, são eles:
· Reunião de planejamento da Sprint
· Reunião diária
· Reunião de revisão da Sprint
· Retrospectiva da Sprint
O coração do Scrum é a Sprint, que é o tempo determinado para o desenvolvimento de uma entrega. Essa entrega deverá ser um dos itens listados no backlog do projeto. Cada Sprint pode ser vista como um projeto de curto prazo, com o tempo estimado não maior do que um mês.
Quadro 1 - Tempo máximo para a realização de cada reunião
	REUNIÃO
	TEMPO ESTIMADO
	Reunião de planejamento da Sprint
	No máximo 8h de duração para uma Sprint de um mês
	Reunião diária
	No máximo 15 minutos
	Reunião de revisão da Sprint
	No máximo 4h de duração para uma Sprint de 1 mês 
	Retrospectiva da Sprint
	No máximo 3h de duração
A Figura 2 ilustra os elementos de ação do Scrum. Uma abordagem concisa e introdutória envolvendo os papéis, algumas funcionalidades, atribuições, artefatos e eventos do ciclo de processamento. Os personagens Dono do Produto, Mestre Scrum, Equipe de Desenvolvimento se relacionam com os eventos e atributos a partir das cores especificadas: marrom, azul e verde.
Figura 2 – elementos da ação de um Scrum.
Inicia-se com a criação do Backlog do Produto, uma lista inicial de necessidades que precisam ser produzidas para que a visão do projeto seja bem-sucedida. Fica em cargo do Dono do Produto definir esta visão, com base em informações colhidas com usuários, clientes, time, gerentes e stakeholders. Em seguida, o Time Scrum realiza a Reunião de Planejamento da Sprint, que seleciona itens do Backlog que o Time Scrum irá se comprometer nesse Sprint; são definidas como tarefas, e devem ser priorizadas e estimadas. Estas tarefas irão gerar o Backlog do Sprint, lista de funcionalidades que devem ser desenvolvidas nesse Sprint.
Para melhor elucidar o processamento com Scrum fez-se uso de uma matriz de 4 linhas e 4 colunas, como verifica-se na Figura 3. Suas colunas dispostas são: Planejamento do Sprint, Scrum no dia a dia, Revisão do Sprint e Retrospectiva do Sprint. Em quanto as linhas recebem os seguintes títulos: Entradas, Dono do Produto, Equipe de Desenvolvimento e Mestre Scrum. As células pertencentes a matriz se relacionam com as colunas e linhas por meio de um fluxograma: uma representação esquemática, uma sequência operacional do desenvolvimento do processo. Assim, pode-secaracterizar as Etapas de ação no ambiente Scrum.
 
Figura 3 – Fluxograma de atividades no Scrum (Fonte: adaptado de LAULIN, Madhu, 2011)
4 - Artefatos do Scrum
O Product Backlog é basicamente uma lista com todas as funcionalidades definidas para o produto. Essas funcionalidades são priorizadas no início de cada Sprint e nada impede que sejam alteradas, removidas ou novas sejam adicionadas durante o período de desenvolvimento do projeto.
Sprint Backlog
No início de cada Sprint há uma reunião aonde se define quais funcionalidades do Product Backlog serão implementadas naquele ciclo, esses itens compõem o Sprint Backlog que será atualizado durante todo o Sprint servindo como base para todo o time. É a equipe de desenvolvimento, em conjunto com o Scrum Master, quem define quais itens podem ser desenvolvidos e entregues durante o próximo ciclo.
Daily Scrum
A Daily Scrum é uma reunião rápida (15 minutos) que ocorre no início de cada dia, em que cada membro da equipe informa o time sobre o que foi feito no dia anterior e qual o plano para o dia atual. Nessa reunião também são apontadas eventuais situações que estejam bloqueando o andamento do processo de desenvolvimento.
Sprint Review Meeting
Essa é uma reunião final do Sprint. Nela a equipe apresenta as funcionalidades que foram implementadas nesse ciclo. Realiza-se também a “Sprint Retrospective” com as lições aprendidas nesse ciclo, os pontos positivos e o que precisa ser aprimorado nos próximos Sprints. É então iniciado o planejamento do próximo Sprint.
5 - Gráficos Sprint Burndown e Burnup
O gráfico de burndown (que significa em tradução livre queimando para baixo) é formado por dois eixos: o eixo Y (vertical), que representa a demanda de trabalho a ser queimada; e o eixo X (horizontal), que representa o tempo – a quantidade de dias ou horas de trabalho para queimar a demanda.
Esse gráfico é representado em duas linhas. A primeira é a linha ideal, reta, de cima para baixo, que representa a demanda completa de trabalho no começo do projeto (no topo, na esquerda) e que vai até o ponto mais baixo à direita, onde fica a previsão de conclusão do projeto no cronograma. Já a segunda é a linha real, que revela como a equipe se comportou com relação à projeção de uso do tempo para a demanda.
 O burndown revela dados importantes sobre o time, tais como, o seu andamento evolutivo e o que pode ser melhorado. Através dele pode-se saber qual a relação do projeto com o cronograma (adiantando ou atrasado) para que assim providências possam ser antecipadas e adaptadas.
O gráfico de burnup apresenta, assim como o gráfico de burndown, o ponto do cronograma com o prazo de entrega planejada (representado no eixo X, horizontal). A diferença é que o eixo Y, vertical (que representa as entregas), exibe em que ponto a equipe está ao longo da Sprint, revelando o quanto de progresso já houve enquanto a linha sobe (queimando para cima) em direção ao ponto final.
No gráfico de burnup a linha ideal é também uma reta, que vai do início do projeto ao fim. É importante lembrar que alterações no escopo do projeto podem alterar a linha, fazendo com que ela tenha acréscimo ou diminuição de demandas.
O gráfico de burnup, diferente do gráfico de burndown, vê o ponto final no alto e busca alcançá-lo, cumprindo as etapas da Sprint. Essa perspectiva permite que o gestor visualize o que falta e em que etapa sua equipe se encontra.
Figura 4 – Ilustração dos gráficos Burndown e Burnup
6 - História de usuários
História de Usuário é um método para levantamento de requisitos que descreve de forma funcional os requisitos para o cliente ou comprador do projeto (Cohn, 2004). Três aspectos devem ser observados durante o processo de levantamento de requisitos:
· Cartão: meio de registro do requisito, normalmente em texto curto e como forma de lembrete quando na fase de desenvolvimento do software; 
· Conversas: comunicação existente entre os envolvidos para melhor detalhar a história; 
· Critérios de aceitação: pormenores a serem validados por meio de testes que servirão para validar e dar por concluída uma história 
7 - Exemplo prático (SCRUM empresa de Softwares em Florianópolis)
A empresa do estudo é uma empresa de desenvolvimento de softwares localizada em Florianópolis. Ela foi criada no ano de 2015 e desde então nunca conseguiu realizar a entrega de um produto dentro dos prazos solicitados pelo cliente. O único grupo pelo qual a empresa é formada conta com quatro programadores e um gerente técnico, responsável por auxiliar os programadores no desenvolvimento de suas atividades. O grupo relatou que eles já trabalhavam com algumas ferramentas do Scrum, como as reuniões diárias e a divisão do tempo do projeto em sprints, porém não havia ninguém que exercesse o cargo de mestre Scrum ou dono do produto, então a metodologia não funcionava da forma desejada.
7.1 - APLICAÇÃO DAS FERRAMENTAS SCRUM
A primeira tarefa foi, portanto, a de criar na equipe os cargos de mestre Scrum e de dono do produto. O mestre Scrum trabalhou como um facilitador das atividades dos desenvolvedores e a sua primeira atividade neste grupo foi a de marcar as reuniões com a equipe.
A primeira reunião que o mestre Scrum marcou foi a reunião de planejamento da sprint, em que, junto aos desenvolvedores e o dono do produto, foram definidas as atividades do backlog do produto e selecionadas as atividades a serem executadas na próxima sprint. Depois dessa primeira reunião, o mestre Scrum marcou as reuniões diárias, onde, conforme apresentado, os desenvolvedores deveriam responder a três perguntas: 
I. O que eu fiz ontem? 
II. O que eu vou fazer hoje? 
III. Quais foram as dificuldades na atividade? 
O mestre Scrum ainda auxiliou os desenvolvedores em todas as dificuldades apresentadas nesta reunião. Também foi sua função neste trabalho atualizar o gráfico de burndown e apresentá-lo à equipe. Um exemplo de burndown chart utilizado nos projetos deste estudo está apresentado na figura 5. Então, percebe-se que o mestre Scrum tinha a clara função de auxiliar a atividade dos desenvolvedores, ou, conforme citado anteriormente, de facilitar o desenvolvimento do projeto.
Ao final da Sprint, o mestre Scrum ainda marcava, junto ao dono do produto e os desenvolvedores da equipe, a reunião de revisão da Sprint, onde os desenvolvedores apresentaram ao dono do produto as tarefas finalizadas daquela Sprint. O dono do produto tem a função de aprovar ou rejeitar o que foi apresentado, sempre representando a vontade do cliente final. Para isto acontecer é fundamental que o dono do produto esteja bem alinhado à expectativa do cliente sobre o projeto. Por fim, ocorreu a reunião de retrospectiva da Sprint, onde a equipe levantou todos os pontos de melhoria para a próxima Sprint.
Figura 5 – Burndown chart do exemplo
Com o término de uma Sprint todo o ciclo se inicia novamente: o mestre Scrum marca uma reunião de planejamento da Sprint, a equipe realiza as reuniões diárias ao longo da Sprint e encerra-se o ciclo anterior com a reunião de retrospectiva da Sprint.
Durante a implementação do método na empresa o time executou três projetos, um de curtíssimo prazo (três sprints de dez dias) e dois considerados prazo normal pela empresa, com a duração de seis sprints de quinze dias cada. Em nenhum dos três projetos houve a necessidade de terminar uma Sprint fora do tempo previsto
As entregas dentro do prazo foram um fato novo que a empresa conseguiu realizar, algo que foi muito comemorado pela equipe. Além disso, a equipe que trabalhou com o método apresentado respondeu a um questionário onde pôde avaliar a experiência com o Scrum. Nesse questionário foram feitas as perguntas apresentadas no apêndice A e as respostas obtidas estão apresentadas no apêndice B deste trabalho. A representação do ciclo do Scrum, apresentada no quadro 2, levou em consideração o modelo de representação do Scrum de Cruz (2013), ilustrado na Figura 6, a seguir e descrito acima.
Quadro 2 – Atividades e responsáveis no método Scrumdo exemplo
	CARGO
	Função
	Momento de realização da função
	Dono do produto e desenvolvedores
	Definir o backlog do projeto
	No início da Sprint
	Mestre Scrum
	Marcar a reunião de planejamento da Sprint
	No início da Sprint
	Desenvolvedores, mestre Scrum e dono do produto
	Realizar a reunião de planejamento da Sprint
	No início da Sprint
	Desenvolvedores
	Executar as atividades planejadas
	Durante a Sprint
	Mestre Scrum
	Marcar as reuniões diárias junto aos desenvolvedores
	Durante a Sprint
	Mestre Scrum e desenvolvedores
	Realizar as reuniões diárias
	Durante a Sprint
	Mestre Scrum
	Remover as dificuldades encontradas pelos desenvolvedores
	Durante a Sprint
	Mestre Scrum
	Marcar a reunião de revisão da Sprint
	Ao final da Sprint
	Desenvolvedores, mestre Scrum e dono do produto
	Realizar a reunião de revisão da Sprint
	Ao final da Sprint
	Mestre Scrum
	Marcar a reunião de retrospectiva da Sprint
	Ao final da Sprint
	Desenvolvedores, mestre Scrum e dono do produto
	Realizar a reunião de retrospectiva da Sprint
	Ao final da Sprint
Figura 6 - Representação SCRUM
8 – CONCLUSÃO
Uma comparação de três resultados esperados, segundo a literatura, com os resultados encontrados na prática deste trabalho é apresentada no quadro 3. O quadro comprova que os resultados esperados na teoria foram atingidos também na prática. A entrega do produto dentro do prazo, a motivação da equipe e com um menor risco devido à entrega contínua de valor foram pontos presentes em todos os estudos e também percebidos neste trabalho. A motivação e o engajamento da equipe estudada foram medidos conforme as respostas obtidas no questionário, respostas que estão apresentadas no apêndice B. Ainda conforme mencionado no apêndice B, algumas respostas isoladas não demonstraram a motivação e entendimento por completo a respeito do método, porém, foram consideradas um caso isolado neste estudo.
Quadro 3 - Comparação de resultados teóricos e obtidos no estudo
	Resultados esperados - segundo Pereira, Torreão e Marçal (2007)
	Resultados esperados - segundo Pham e Pham (2011)
	Resultados esperados - segundo Karabulut e Ergun (2018)
	Resultados alcançados (prática)
	Equipe mais segura e motivada
	Motivação e orgulho da equipe
	Acelerar a entrega do produto
	Entrega dentro do prazo
	Projeto adaptável a mudanças
	Ciclo de vida de desenvolvimento de software mais enxuto
	Aumentar a produtividade
	Maior engajamento da equipe
	Entrega dentro do prazo
	Projeto com redução de riscos
	Realçar a qualidade dos softwares
	Maior motivação da equipe
	Redução de riscos no projeto
	Processo de gestão de projeto adaptativo
	Diminuir os riscos dos projetos
	Produto mais alinhado à expectativa do cliente final, devido a entrega constante de valor
8.1 - Atingimento dos objetivos da pesquisa
Conforme apresentado, o objetivo deste trabalho foi propor uma sistemática baseada no framework Scrum para empresas realizarem entregas dentro do prazo, o que foi realizado. Para isso ser possível, cada objetivo específico foi atingido individualmente. Os elementos cruciais para o cumprimento dos prazos foram: 1. Entrega de valor ao término de cada Sprint 2. Reuniões diárias 3. Acompanhamento do burndown chart. Os resultados alcançados foram satisfatórios e a experiência da equipe com o método proposto também foi positiva, conforme mostra o resultado do questionário realizado. A sistemática proposta pode ser replicada em empresas que busquem entregar os seus produtos dentro do prazo.
IMAGEM DO TRELLO 
3
	333