PÓS-GRADUAÇÃO LATO SENSU EM ANÁLISE, PROJETO E GERÊNCIA DE SISTEMAS DE INFORMAÇÃO CRISTIANE MONTEIRO TAVARES

Transcrição

1 Secretaria de Educação Profissional e Tecnológica Ministério da Educação PÓS-GRADUAÇÃO LATO SENSU EM ANÁLISE, PROJETO E GERÊNCIA DE SISTEMAS DE INFORMAÇÃO CRISTIANE MONTEIRO TAVARES MODELO HÍBRIDO DE DESENVOLVIMENTO DE SOFTWARE: UMA ABORDAGEM NO PROCESSO DE GERÊNCIA DE REQUISITOS SCRUM X MPS.BR Campos dos Goytacazes/RJ Dezembro/2012

2 T 231m Tavares, Cristiane Monteiro. Modelo híbrido de desenvolvimento de software : uma abordagem no processo de gerenciamento de requisitos Scrum X MPS.Br / Cristiane Monteiro Tavares Campos dos Goytacazes (RJ) : [s.n.], f. : il. Orientadora: Simone Vasconcelos Silva. Monografia (especialização). Instituto Federal de Educação, Ciência e Tecnologia Fluminense. Campus Campos-Centro. Pós-graduação Lato Sensu em Análise, Projeto e Gerência de Sistemas de Informação. Campos dos Goytacazes, RJ, Bibliografia: f Software Desenvolvimento. 2. Scrum (Programa de computador). I. Silva, Simone Vasconcelos, orient. II. Título. CDD

3 CRISTIANE MONTEIRO TAVARES MODELO HÍBRIDO DE DESENVOLVIMENTO DE SOFTWARE: UMA ABORDAGEM NO PROCESSO DE GERÊNCIA DE REQUISITOS SCRUM X MPS.BR Monografia apresentada ao Instituto Federal de Educação, Ciência e Tecnologia Fluminense como requisito parcial para conclusão do Curso de Pósgraduação Lato Sensu em Análise, Projeto e Gerência de Sistemas de Informação. Orientadora: Profª. Simone Vasconcelos Silva

4 CRISTIANE MONTEIRO TAVARES MODELO HÍBRIDO DE DESENVOLVIMENTO DE SOFTWARE: UMA ABORDAGEM NO PROCESSO DE GERÊNCIA DE REQUISITOS SCRUM X MPS.BR Monografia apresentada ao Instituto Federal de Educação, Ciência e Tecnologia Fluminense como requisito parcial para conclusão do Curso de Pósgraduação Lato Sensu em Análise, Projeto e Gerência de Sistemas de Informação. Aprovada em 13 de Dezembro de 2012 Banca Avaliadora:... Profª Simone Vasconcelos Silva (Presidente/IFF) Doutora em Computação / UFF Instituto Federal de Educação, Ciência e Tecnologia Fluminense... Profª Aline Pires Vieira de Vasconcelos (IFF) Doutora em Engenharia de Sistemas e Computação / UFRJ Instituto Federal de Educação, Ciência e Tecnologia Fluminense... Profª Fábio Duncan de Souza (IFF) Mestre em Pesquisa Operacional e Inteligência Computacional / UCAM Instituto Federal de Educação, Ciência e Tecnologia Fluminense

5 À minha família, agradeço o apoio, o afeto, o reconhecimento e a compreensão por tantos momentos de ausência.

6 RESUMO Atualmente as organizações de software têm direcionado seus esforços na melhoria dos seus processos com base em modelos de qualidade tais como o MPS.BR. Adicionalmente, estas organizações têm demonstrado um interesse crescente pela adoção de métodos ágeis com foco em aumentar sua produtividade. Acreditando-se na hipótese de que é possível combinar agilidade com modelos de maturidade, este trabalho tem o desafio de analisar a aderência do Scrum em relação ao MPS. Br, especificamente no que diz respeito ao processo de Gerência de Requisitos (GRE). O desenvolvimento ágil e os modelos/padrões de qualidade de software tradicionais são vistos frequentemente como contraditórios, devido a uma tendência de que modelos e padrões são muito burocráticos e o desenvolvimento ágil é ad-hoc. Este trabalho propõe um modelo híbrido de desenvolvimento de software para o processo de Gerência de Requisitos baseando-se na integração do método ágil SCRUM com o MPS.Br (norma brasileira de Melhoria do Processo de Software) Nível G. Para validação do modelo proposto, apresenta-se um estudo de caso. Palavras-Chave: Scrum, MPS.Br, Gerência de Requisitos

7 ABSTRACT Currently software organizations have focused their efforts on improving their processes based on quality models such as MPS.BR. Additionally, these organizations have shown a growing interest in adopting agile methods with a focus on increasing your productivity. Believing on the assumption that it is possible to combine agility with maturity models, this work has the challenge of analyzing the adherence of the scrum against the MPS. Br, specifically with regard to the process of Requirements Management (GRE). And Agile development models / standards of traditional software are often seen as contradictory, due to a tendency of designs and patterns are very bureaucratic and agile development is ad-hoc. This paper proposes a hybrid model of software development for the Requirements Management process based on the integration of SCRUM agile method with MPS.Br (Brazilian Standard Process Improvement Software) Level G. To validate the proposed model, we present a case study. Keywords: Scrum, MPS.Br, Requirements Management

8 LISTA DE FIGURAS Figura 1- MPS.Br - Componentes do MPS.Br...16 Figura 2 - Níveis de Maturidade e processos do Modelo de Referencia do MPS.BR.. 17 Figura 3- Número de empresas avaliadas no MPS.Br Figura 4 - Product Owner responsável pelo Product Backlog...26 Figura 5 - Scrum Team e suas responsabilidades...27 Figura 6 - Exemplo de Task Board (quadro de tarefas) Figura 7 - Burndown Chart Figura 8 - Excesso de backlog itens Figura 9 - Necessidade de backlog items...32 Figura 10 - O Processo Scrum...34 Figura 11 - Tela inicial da Biblioteca Digital...41 Figura 12 - Tela do Gthub...42 Figura 13 - Tela do Kanban...43

9 SUMÁRIO 1 INTRODUÇÃO MOTIVAÇÕES JUSTIFICATIVAS OBJETIVOS QUALIDADE QUALIDADE DE SOFTWARE QUALIDADE DO PROCESSO DE SOFTWARE PRINCIPAIS NORMAS E MODELOS DE QUALIDADE DO PROCESSO DE SOFTWARE MELHORIA DO PROCESSO DE SOFTWARE BRASILEIRO - MPS. BR GERÊNCIA DE REQUISITOS (GRE) DO NÍVEL G MÉTODOLOGIAS ÁGEIS PRINCÍPIOS DOS MÉTODOS ÁGEIS SCRUM PAPÉIS E RESPONSABILIDADES NO SCRUM FASES NO SCRUM ARTEFATOS DO SCRUM FLUXO DO PROCESSO MAPEAMENTO DO SCRUM AO GRE NÍVEL G DO MPS.BR CRIANDO UM MODELO HÍBRIDO DE DESENVOLVIMENTO (MHDS) APLICAÇÃO PRÁTICA DO MAPEAMENTO NSI NÚCLEO DE SISTEMAS DE INFORMAÇÃO BD BIBLIOTECA DIGITAL FERRAMENTAS UTILIZADAS PELA EQUIPE DA BD MAPEAMENTO APLICADO A BD CONCLUSÃO REFERÊNCIAS... 47

10 8 1 INTRODUÇÃO No início de sua produção, o software não tinha nenhuma estrutura formal para o seu desenvolvimento. As organizações se deparavam com produções de softwares maiores e mais complexas (CHRISSIS, KONRAD e SHRUN, 2003), o software passava do estágio de serviço para ser tornar um negócio. Esta maneira ad hoc de produzir software levou a crise do software (SOMMERVILE, 2007) uma vez que na maioria dos projetos de software existiam problemas como atrasos e cancelamentos. A solução encontrada pela indústria de software em melhorar seus serviços foi encontrada na Engenharia, desta forma surge então a Engenharia de Software que viria a tratar de processos, métodos e ferramentas para a produção de software com qualidade. Processos descrevem o que deve ser feito para a entrega efetiva de software, métodos descrevem informações técnicas de como deve ser feito para conceber o software e por fim as ferramentas servem para automatizar processos e métodos (PRESSMAN, 2006). Um processo de desenvolvimento de software tem como objetivo guiar as atividades da equipe, especificar quais e quando os artefatos devem ser gerados, dirigir as atividades individuais a desenvolvedores e à equipe como um todo e oferecer critérios para monitorar e medir as atividades e produtos de projeto. (BOOCH, 1995) 1.1 MOTIVAÇÕES As recentes mudanças ocorridas nos ambientes de negócios têm motivado as empresas a modificar suas estruturas organizacionais e processos produtivos, deixando a visão tradicional, baseada em áreas funcionais e buscando as redes de processos direcionados no cliente. Sendo assim a competitividade passa a depender do estabelecimento de conexões nestas redes, gerando elos essenciais nas cadeias produtivas. Hoje alcançar competitividade

11 9 pela qualidade, para as empresas de software, implica tanto na melhoria da qualidade dos produtos de software e serviços, como dos processos de produção e distribuição de software. Assim como para outros setores, qualidade se torna o fator crítico de sucesso para a indústria de software. Para que se tenha um setor de software competitivo, nacional e internacionalmente, é essencial que os empreendedores do setor coloquem a eficiência e a eficácia dos seus processos em foco nas empresas, visando à oferta de produtos de software e serviços conforme padrões internacionais de qualidade (SOFTEX, 2011). 1.3 JUSTIFICATIVAS O MPS.BR (norma brasileira de Melhoria do Processo de Software) atende a necessidade de implantação dos princípios de Engenharia de Software de forma adequada ao contexto das empresas brasileiras, estando em concordância com as principais abordagens internacionais para definição, avaliação e melhoria de processos de software. Em fevereiro de 2001 um grupo de dezessete pessoas se uniu em Utah, nos Estados Unidos e assinou o Manifesto para o desenvolvimento ágil de Software. Este manifesto tem como primeiro valor definido a seguinte premissa: Indivíduos e Iterações mais do que processos e ferramentas (MANIFESTO, 2001). Atualmente as metodologias ágeis são interesse de uma grande parte da comunidade de produção de software, principalmente para as pequenas empresas, uma vez que suas práticas são bem difundidas principalmente em pequenas configurações ( Santana, Célio A.; Timóteo, Aline L.; Alexandre, M. L. Vasconcelos, 2006). Para as metodologias ágeis o sucesso de um projeto depende única e exclusivamente das pessoas envolvidas e do esforço por elas realizado, enquanto para a engenharia de software um processo bem definido pode auxiliar no sucesso da produção de software e repetir este sucesso através de um processo maduro. ( Santana, Célio A.; Timóteo, Aline L.; Alexandre, M. L. Vasconcelos, 2006).

12 OBJETIVOS Neste contexto, esse artigo propõem mapear as práticas do SCRUM aos resultados esperados do nível G do MPS.BR em relação a Gerência de Requisitos (GRE), para que as organizações tenham a possibilidade de definirem processos que produzam software com alto padrão de qualidade e sejam certificados e reconhecidos nacionalmente, tendo ainda, uma produção de software ágil e eficiente. Este mapeamento gera um modelo híbrido de desenvolvimento de software em relação a Gerência de Requisitos através da integração entre o Scrum e o MPS.Br. O modelo híbrido é validado através de um estudo de caso que contempla o projeto Biblioteca Digital do Núcleo de Sistema de Informação (NSI) do Instituto Federal Fluminense (IFF), o qual utiliza como um dos métodos ágeis de seu processo de desenvolvimento. Neste trabalho no capítulo 1 definimos qualidade de software na visão de diversos autores, no capítulo 2 apresentamos o modelo MPS-BR e no capítulo 3 apresentar uma visão geral do método SCRUM; para no capítulo 4 descrever o mapeamento entre o SCRUM e o MPS.BR em relação ao GRE, gerando o modelo híbrido, validando esse modelo com um estudo de caso visto no capítulo 5. Finalmente o capítulo 6 conclui este trabalho através das conclusões e propostas de trabalhos futuros.

13 11 2 QUALIDADE Ghobadian (1994) e Cardoso (2004), definem que a qualidade está centrada na percepção do cliente. A qualidade percebida pelo cliente deve corresponder ou superar suas expectativas. Desta forma cada cliente percebe a qualidade dos serviços de maneira própria. Nota-se o aspecto qualitativo e pessoal de avaliar o serviço. O resultado dos serviços pode variar conforme a ocasião. Este fato chama-se variabilidade. Já Belluzzzo e Macedo (1993) e Bachmann (2002) enfatizam que a criação e manutenção da qualidade em uma organização de serviços depende de uma aproximação sistemática com a gestão da qualidade pretendida. Garantindo que as necessidades implícitas ou determinadas pelos clientes sejam entendidas e atendidas com eficácia e eficiência. A necessidade gera uma certa expectativa nos clientes. Sob este contexto, FEIGENBAUM (1994) e BACHMANN (2002), define que a qualidade é uma combinação de características de produtos e serviços referentes a marketing, engenharia, produção e manutenção, correspondendo às expectativas do cliente. Segundo Paladini (2000) conceito da qualidade envolve diversos elementos, com diferentes níveis de importância. O consumidor deve ser atendido considerando-se os múltiplos itens que ele considera relevantes. A empresa pode vir a se fragilizar estrategicamente se der atenção demasiada a apenas um deles ou não considerar algum outro elemento. Por outro lado, o conceito de qualidade passa por um processo evolutivo, ou seja, sofre alterações ao longo do tempo para acompanhar as mudanças nas necessidades e preferências dos clientes. Desta forma o conceito de qualidade é aquele que envolve a multiplicidade de itens e o processo evolutivo, sempre com o foco no cliente. O conceito de qualidade evoluiu ao longo do século, mudando de uma atividade de inspeção e seleção de itens não-conformes, com caráter fortemente corretivo, para o uso de técnicas estatísticas que garantiriam a qualidade do produto de forma preventiva. Posteriormente a ênfase mudou do produto para o processo, pois um processo com os padrões de qualidade desejados apresenta como consequência um produto com a qualidade esperada. Paralelamente, passou-se a trabalhar com os sistemas de qualidade das empresas. Atualmente o conceito evoluiu, além das fronteiras da empresa, abrangendo toda a cadeia onde essa está inserida. (CONTE e DURSKI, 2002)

14 12 O conceito de qualidade apresentado na Norma ISO 8402 é descrito como um conjunto de propriedades e características de um produto, processo ou serviço, que lhe fornecem a capacidade de satisfazer as necessidades explícitas ou implícitas. Diversos outros autores conceituaram qualidade. Segundo DEMING, a qualidade significa um grau previsível de uniformidade e confiabilidade a baixo custo, estando adequada ao mercado. Outra definição de qualidade é apresentada por JURAN, que a entende como adequação ao uso. Há autores que separam qualidade em dois aspectos: qualidade técnica e qualidade humana. Afirma que a qualidade técnica está em satisfazer exigências e expectativas concretas, tais como tempo, finanças, taxa de defeitos, funcionalidade, durabilidade, segurança e garantia. A qualidade humana diz respeito à satisfação de expectativas e desejos emocionais, tais como atitude, comprometimento, atenção, credibilidade, consistência e lealdade. Além disso, trabalha-se com cinco tipos de qualidade: a pessoal, a departamental, a de produtos, a de serviços e a da empresa. Em todas elas deve-se verificar a qualidade técnica e humana. (CONTE e DURSKI, 2002) 1.1 QUALIDADE DE SOFTWARE A qualidade de software é a conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todo software profissionalmente desenvolvido. Esta definição enfatiza, três pontos chave: os requisitos de software, padrões especificados e um conjunto de requisitos implícitos. (PRESSMAN, 2006) Rocha et al (2001) definem de forma similar: "Qualidade de software pode ser vista como um conjunto de características que devem ser atingidas em um determinado grau para que o produto atenda às necessidades de seus usuários". Já Bartié (2002) define Qualidade de software como um processo sistemático com foco nas etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos.

15 QUALIDADE DO PROCESSO DE SOFTWARE No desenvolvimento de software, a qualidade do produto está diretamente relacionada à qualidade do processo de desenvolvimento, assim é comum que a busca por um software de maior qualidade passe necessariamente por uma melhoria no processo de desenvolvimento. Processos de software constituem a base para o controle gerencial de projetos de software e estabelece o conteúdo no qual os métodos técnicos são aplicados, os produtos de trabalho são produzidos, os marcos são estabelecidos, a qualidade é assegurada e as modificações são adequadamente geridas. (PRESSMAN, 2006) Um dos principais objetivos da Engenharia de Software é desenvolver sistemas com qualidade, dentro dos prazos estabelecidos e sem a necessidade de alocação de mais recursos. Para que tal objetivo seja alcançado, o foco não deve estar apenas nos produtos gerados, mas também no seu processo de desenvolvimento. A qualidade de um produto de software depende fortemente da qualidade do processo de software utilizado em seu desenvolvimento. (FUGGETTA, 2000) A qualidade do processo de software é determinada pelo grau de flexibilidade para incorporar características implícitas de qualidade de produto e novos métodos, técnicas e ferramentas ao processo de software. SANTOS E CHAIM (2003) 1.3 PRINCIPAIS NORMAS E MODELOS DE QUALIDADE DO PROCESSO DE SOFTWARE O uso de normas e processos de qualidade são extremamente necessários para a avaliação do processo de desenvolvimento de software, garantindo desta forma a correta definição e avaliação dos requisitos de qualidade do produto de software. Dentre as diversas normas, pode-se destacar:

16 14 NBR ISO 9001, modelo para garantia de qualidade em projeto,desenvolvimento, instalação e assistência técnica; NBR ISO 10011, Auditoria de sistemas de qualidade; NBR ISO , gestão de qualidade e garantia de qualidade. Apresenta diretrizes para a aplicação da ISO 9001, a mais utilizada por organizações que desenvolvem software; ISO/IEC 12207, define um processo para o ciclo de vida de desenvolvimento de software; ISO/IEC 15504, padrão para melhoria de processos e determinação de capacidade considerando métodos, normas e processos já existentes; CMMI (Capability Maturity Model Integration.), modelo da SEI para avaliação da qualidade do processo de desenvolvimento de software, uma evolução do CMM (Capability Maturity Model); MPS.Br, modelo para melhoria do processo de software brasileiro.

17 15 2 MELHORIA DO PROCESSO DE SOFTWARE BRASILEIRO - MPS. BR O modelo Melhoria de Processo de Software Brasileiro (MPS.Br) é um programa que começou em 2003 coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), que conta com o apoio Ministério da Ciência e Tecnologia (MCT), Financiadora de Estudos e Projetos (FINEP), Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE) e o Banco Interamericano de Desenvolvimento (BID).e envolve universidades, centros de pesquisa e um grande número de instituições e profissionais da área de qualidade de software. (SOFTEX, 2011) O MPS.BR tem como objetivo definir um modelo de melhoria e avaliação de processo de software, preferencialmente para as micro, pequenas e médias empresas, para satisfazer suas necessidades de negócio e também ser reconhecido nacional e internacionalmente como um modelo aplicável à indústria de software. (SOFTEX, 2011) Espera-se que o modelo MPS. Br seja adequado ao perfil de empresas com diferentes tamanhos e características, públicas e privadas, embora com especial atenção às micro, pequenas e médias empresas, já que possui mais níveis que o CMMI para que a evolução seja mais gradual. Também espera-se que o modelo MPS. Br seja compatível com os padrões de qualidade aceitos internacionalmente e que tenha como pressuposto o aproveitamento de toda a competência existente nos padrões e modelos de melhoria de processo já disponíveis. Dessa forma, ele tem como base os requisitos de processos definidos nos modelos de melhoria de processo e atende a necessidade de implantar os princípios de engenharia de software de forma adequada ao contexto das empresas.

18 16 De acordo com SOFTEX (2011), o MPS.Br possui vários componentes, conforme mostra a Figura1. Figura 1- MPS.Br - Componentes do MPS.Br Fonte:SOFTEX (2011). Conforme pode-se observar na Figura 1, e segundo o guia geral SOFTEX (2011), cada componente do modelo MPS está descrito por meio de documentos em formato de guias: Guia Geral: contém a descrição geral do modelo MPS e detalha o Modelo de Referência (MR-MPS), seus componentes e as definições comuns necessárias para seu entendimento e aplicação; Guia de Aquisição: descreve um processo de aquisição de software e serviços correlatos. É descrito como forma de apoiar as instituições que queiram adquirir produtos de software e serviços correlatos apoiando-se no MR-MPS;

19 17 Guia de Avaliação: descreve o processo e o método de avaliação MA-MPS, os requisitos para avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras; Guia de Implementação: série de onze documentos que fornecem orientações para implementar nas organizações os níveis de maturidade descritos no Modelo de Referência MR-MPS. Ainda de acordo com a SOFTEX (2011), pode-se observar através da Figura 2 que o MPS.Br apresenta sete níveis de maturidade, onde cada nível é composto por um conjunto de processos. Figura 2 - Níveis de Maturidade e processos do Modelo de Referencia do MPS.BR Fonte:SOFTEX, 2011.

20 18 Conforme mostra a figura 2, o Modelo de Referência MR-MPS define sete níveis de maturidade, que são uma combinação entre processos e capacidade de processos, tais como: A (Em Otimização) B (Gerenciado Quantitativamente) C (Definido) D (Largamente Definido) E (Parcialmente Definido) F (Gerenciado) G (Parcialmente Gerenciado) Para cada um destes sete níveis de maturidade foi atribuído um perfil de processos e de capacidade de processos que indicam onde a organização tem que concentrar o esforço para melhoria de forma a atender os objetivos de negócio. O nível G de maturidade do MPS.BR (Parcialmente Gerenciado) é composto pelos processos de Gerência de Projetos (GPR) e Gerência de Requisitos (GRE). Como o foco principal deste trabalho é abordar o GRE em relação ao MPS.BR, este item será detalhado a seguir. Segundo Oliveira, Guimarães e Fonseca (2008), durante a implantação do MPS.Br, são encontradas as seguintes melhorias: Ter um planejamento foi reconhecido como grande benefício. Identificar e categorizar os riscos antecipando possíveis problemas. Proporciona uma visão mais ampla sob todos os aspectos do projeto; O planejamento é definido com todos os envolvidos. Esta prática faz com o que o planejamento se aproxime da realidade, uma vez que o profissional que executa é o mesmo que estima;

21 19 Definir indicadores das equipes e individuais estimula o alcance de melhores resultados. (Indicadores de produtividade, percentual de retrabalho e percentual de desvio previsto x real); Reuniões de reestimativa e de elucidação de requisitos ajudam na execução dos requisitos pela equipe; Segundo dados da SOFTEX (2011) pode-se observar na Figura 3 o quantitativo de empresas avaliadas nos últimos anos e os níveis em que as mesmas se enquadram. Percebemos uma queda no número de avaliações, ao mesmo tempo em que o agilismo vem crescendo no Brasil. Figura 3- Número de empresas avaliadas no MPS.Br Fonte: SOFTEX (2011)

22 GERÊNCIA DE REQUISITOS (GRE) DO NÍVEL G O processo de Engenharia de Requisitos é considerado por alguns autores como a parte mais crítica no desenvolvimento software, pois a qualidade do produto final depende da qualidade dos requisitos. (FERGUSON e LAMI, 2006) Para Pressman (2007), uma compreensão completa dos requisitos de software é fundamental para um bem-sucedido desenvolvimento de software. As atividades da Engenharia de Requisitos conduzem à obtenção de diversos benefícios como a redução do retrabalho e a satisfação dos clientes em relação às soluções desenvolvidas. (ALMEIDA ET AL., 2011) Segundo Sommerville (2007), a Engenharia de Requisitos é o processo que envolve todas as atividades para criação e manutenção de requisitos do sistema. Podemos citar como atividades da Engenharia de Requisitos o levantamento de requisitos e a análise de requisitos. Guedes (2008) define o levantamento de requisitos como uma atividade onde o engenheiro de software tenta compreender as necessidades do usuário e o que ele espera que o sistema realize. Desta forma a análise de requisitos é entendida como uma atividade que objetiva determinar se as necessidades dos usuários foram entendidas da maneira correta. A Análise de Requisitos resulta na especificação das características operacionais do software; indica interface do software com outros elementos do sistema e estabelece restrições a que o software deve satisfazer. (PRESSMAN, 2006) De acordo com a SOFTEX (2011) o processo Gerência de Requisitos (GRE) pertence ao nível de maturidade G do modelo MPS.BR, que é o primeiro nível do organização. O seu propósito é gerenciar os requisitos do produto e dos componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. O GRE é composto por cinco resultados esperados conforme mostra a Tabela 1.

23 21 Tabela 1 Resultados Esperados do GRE GRE 1 Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores responsáveis de requisitos, utilizando critérios objetivos. É preciso garantir que os requisitos estejam claramente definidos, devidamente comprovados através de um documento de requisitos, que pode ter o formato que melhor atender as necessidades da organização. Após esta identificação, eles precisam ser avaliados, tanto pela equipe técnica da organização quanto pelo cliente, com base em critérios que garantam que os requisitos propostos atendem às necessidades e expectativas do cliente e dos usuários. Um registro de aprovação dos requisitos, obtido pelos fornecedores de requisitos será um marco do projeto, a partir do qual todas as mudanças nos requisitos deverão ser tratadas no interesse de minimizar o impacto dessas mudanças no projeto em termos de escopo, estimativas e cronograma. A cada mudança nos requisitos aprovada, deve-se prover uma avaliação e registro de aceite da mudança aprovada. GRE 2 O Comprometimento da equipe técnica com os requisitos aprovados é obtido Os requisitos aprovados pelos critérios estabelecidos no GRE1 deverão obter o comprometimento da equipe técnica. Para formalizar que toda a equipe técnica tenha o conhecimento e aprovam os requisitos, deve ser registrado através de um documento, por exemplo, uma ata de reunião, ou algum outro mecanismo. A cada mudança registrada nos requisitos, um novo comprometimento da equipe deve ser obtido; GRE 3 A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida. Obter esse resultado significa que é possível rastrear a dependência entre os requisitos e o produto de trabalho, ou seja, quais artefatos são de quais produtos. Desta forma, facilitando a avaliação do impacto das mudanças nos requisitos, por exemplo, nas estimativas, nos produtos ou tarefas do projeto; GRE 4 Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos. Estabelecimento de algum mecanismo para identificação de inconsistências entre os requisitos e os demais elementos do projeto. Todas as inconsistências identificadas devem ser registradas e ações corretivas deverão ser tomadas a fim de resolvê-las, sendo que estas ações deverão ser acompanhadas até que as inconsistências sejam resolvidas;

24 22 GRE 5 Mudanças nos requisitos são gerenciadas ao longo do projeto. Como é raro não haver mudanças nos requisitos ao longo do projeto, espera-se que a organização realize o gerenciamento das mudanças que venham a ocorrer. As mudanças devem ser registradas, juntamente com um histórico das decisões tomadas, que deverão ser tomadas com base na análise do impacto da mudança no projeto. 3 MÉTODOLOGIAS ÁGEIS Em fevereiro de 2001, aconteceu em Utah, nos EUA um encontro, onde foi utilizado pela primeira vez o termo ágil na indústria de software, tendo como resultado a criação da organização Agile Alliance, com o intuito de promover os conceitos de agilidade para o desenvolvimento de software, posteriormente sendo publicado o manifesto para Desenvolvimento Ágil de Software. (BECK ET AL. 2001). A origem dos métodos ágeis está relacionada à crise do software; surgiu como resposta a mesma, utilizando-se de padrões opostos aos padrões tradicionais de desenvolvimento (FOWLER, 2005). O manifesto Ágil de software (2001) promove os seguintes conceitos de agilidade para o desenvolvimento de software: Os indivíduos e suas iterações acima de processos e ferramentas; Software funcionando acima de documentação exaustiva; Colaboração do cliente acima de negociação contratual;

25 23 Respostas às mudanças acima de execução de um plano... O manifesto tem como essência a agilidade, a flexibilidade, a habilidade de comunicação e a capacidade de oferecer novos produtos e serviços de valor ao mercado, em curtos períodos de tempo. (HIGHSMITH, 2004) Diante do atual cenário do ambiente de negócios, vivemos a tendência para o desenvolvimento ágil de aplicações devido ao ritmo acelerado de mudanças na tecnologia da informação, pressões por constantes inovações, concorrência acirrada e grande dinamismo no ambiente de negócios. Métodos, práticas e técnicas para o desenvolvimento ágil de projetos prometem aumentar a satisfação do cliente.(boehm, 2006) Hoje para se manterem frente a competitividade do mercado, as organizações necessitam entregar seus produtos em menores prazos e cada vez melhores, para isso se voltam à utilização dos métodos e gerenciamento ágeis.(chrissis; KONRAD; SHRUM, 2007) 3.1 PRINCÍPIOS DOS MÉTODOS ÁGEIS Os métodos ágeis de desenvolvimento de software são baseados em doze princípios: (Manifesto Ágil, 2001) Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente. Entregar frequentemente software funcionando,de poucas semanas a poucos meses,

26 24 com preferência à menor escala de tempo. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face. Software funcionando é a medida primária de progresso.os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente. Contínua atenção à excelência técnica e bom design aumenta a agilidade. Simplicidade - a arte de maximizar a quantidade de essencial. trabalho não realizado - é Melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

27 SCRUM O termo Scrum vem do jogo rugby e significa a necessidade de reinicio do jogo após uma falta. A equipe é composta de 8 pessoas que trabalham para levar a bola para o campo do adversário e conquistar o grande objetivo: O Goal (MACHADO e MEDINA,2011). O termo Scrum foi associada ao desenvolvimento de produtos em 1986 no livro The New Product Development onde os autores defendiam que um grupo de desenvolvimento deveria trabalhar em equipe para que o objetivo pudesse ser atingido como no jogo de Rugby. (RODRIGUES e ROST, 2011) O Scrum foi criado em 1996 por Ken Schwaber e Jeff Sutherland, como um método ágil que aceita que o desenvolvimento de software é imprevisível e formaliza a abstração, sendo aplicável a ambientes voláteis.(adm, 1996) Não é um processo e nem uma técnica, é um framework com objetivo de transparecer a eficácia, onde se pode empregar diversos processos e técnicas. O Scrum é baseado em processos empíricos, possui uma abordagem iterativa e incremental, o que permite uma maior previsibilidade e controle dos riscos. Seus princípios básicos são: equipes pequenas, requisitos pouco estáveis ou desconhecidos e iterações curtas. As iterações são divididas em intervalos de tempos de, no máximo 30 dias, também chamadas de Sprints. (SCHWABER, 2009) 3.3 PAPÉIS E RESPONSABILIDADES NO SCRUM De acordo com Machado e Medina (2011) a metodologia apresenta um grupo de papéis e responsabilidades (Product Owner, Scrum Master, Scrum Team, Stakeholders) definidos conforme a seguir: Product owner é um especialista no negócio do produto a ser desenvolvido e responsável pelo retorno financeiro do mesmo. Devido ao seu alto conhecimento do negócio,

28 26 o Product Owner pode representar o cliente. É responsável pela criação do Realease Plan e o Product Backlog conforme mostra a Figura 4. É atribuído ao Product Owner a atualização do Product Backlog para que haja a garantia de que as funcionalidades mais importantes sejam construídas logo no início. Este Adiciona estórias e define as prioridades em cada Sprint como também aprova ou desaprova o resultado dessa Sprint. Outras pessoas além do Product Owner também podem adicionar estórias mas somente o Product Owner pode priorizar. Esse papel geralmente é exercido por um representante do cliente ou alguém capaz de tirar as dúvidas sobre requisitos que venham a surgir durante o desenvolvimento do produto. É ele quem determina o início e o fim de cada Sprint. Figura 4 - Product Owner responsável pelo Product Backlog Fonte: SCRUM (2011) Scrum master é o líder da equipe apesar da equipe ser auto gerenciada. Geralmente é exercido por um gerente de projetos ou um líder técnico, mas pode ser qualquer um dos componentes da equipe. Acompanha o desenvolvimento diariamente. É ele quem provê toda base para que a equipe trabalhe sem obstáculos, seja produtiva e funcional. Deve fazer a equipe funcionar utilizando adequadamente as práticas do Scrum com toda a disciplina necessária e cuida para que as metas e o retorno do investimento (ROI) desejados sejam alcançados a cada Sprint; Scrum Team é o pessoal responsável por detalhar em itens do Sprint Backlog os itens do Product Backlog e transformar isso em software a ser entregue ao final da Sprint. Atua de forma participativa e não possui uma divisão funcional. É auto gerenciável. Todos os integrantes do Scrum Team atuam em qualquer papel. Geralmente composto por 5 a 9 membros podendo possuir uma quantidade maior de membros dependendo do contexto do projeto. Trabalha com foco nas tarefas atribuídas e a qualquer obstáculo se reportam ao Scrum Master.

29 27 Segundo OLIVEIRA (2008), a equipe desenvolve de forma iterativa, realizando projeto, codificação, testes de unidade, aceitação e até documentação (JIT Just in Time), para cada Select Backlog ( requisito ) antes de passar para o próximo Sprint. Realizam diariamente reuniões (Daily Scrum) para verificar o andamento dos Select Backlog e atualizam o Burndown Chart para sincronização das tarefas e comunicação da equipe. A Figua 5 ilustra o Scrum Team e suas responsabilidades; Figura 5 - Scrum Team e suas responsabilidades Fonte: SCRUM (2011) Stakeholder é qualquer pessoa ou organização envolvida que será afetada e/ou afetará o projeto. Entre eles, o cliente, usuários finais, equipe de vendas. O Stakeholder do projeto é representado pelo Product Owner. O Stakeholder é aquele que fornece feedback em todo o Sprint produzindo assim um produto mais aderente às suas necessidades. (MACHADO e MEDINA, 2011) 3.4 FASES NO SCRUM O SCRUM possui um ciclo de vida composto por 4 fases como definido em :(LARMAN,2004) Planejamento: que tem por objetivo estabelecer a visão do projeto e as expectativas entre os stakeholders, além de garantir financiamento/orçamento para a realização do projeto; Preparação: que tem por objetivo identificar os requisitos e priorizá-los (pelo menos para a próxima sprint). Divide o Product Backlog em sprints, de acordo com a priorização realizada, levando em consideração a produtividade do time;

30 28 Desenvolvimento: corresponde à implementação do sistema em uma série de sprints de 30 dias consecutivos (sprints), com apresentação de um incremento de funcionalidade ao final da sprint; Entrega: corresponde implantação operacional do sistema. 3.5 ARTEFATOS DO SCRUM O Scrum possui o mínimo necessário de artefatos para o desenvolvimento de software: Para Schwaber (2004), o mesmo introduz os seguintes artefatos principais usados ao longo do seu fluxo de desenvolvimento: Product Backlog, Sprint Backlog e incremento de funcionalidade do produto. O Product Backlog contém uma lista de itens priorizados que incluem os requisitos funcionais e não funcionais do sistema/produto que está sendo desenvolvido no projeto. O Product Owner é o responsável pelos conteúdos e priorização do Product Backlog que é usado no plano de projeto apenas como uma estimativa inicial dos requisitos. O Product Backlog nunca está completo e evolui de acordo com a evolução do produto e do ambiente ao qual está inserido. O gerenciamento constante das mudanças serve para identificar o que o sistema/produto precisa para ficar apropriado, competitivo e usável. O Sprint Backlog corresponde à lista de tarefas que o time do projeto define para implementar na sprint os requisitos selecionados do Product Backlog. Apenas o time pode mudar o Sprint Backlog que representa o planejamento real do time para a sprint. No time deverá entregar incrementos de funcionalidade a cada sprint. Os incrementos de funcionalidade consistem de códigos testados, bem estruturados e bem escritos, que são executáveis acompanhados da documentação necessária para a sua operação.

31 29 Já Pereira, Torreão, Marçal (2007) identifica os seguintes artefatos: Product Backlog é uma lista de requisitos funcionais e não-funcionais identificados pelo Product Owner. Esses itens devem estar bem identificados, priorizados e estimados, em tempo ou tamanho antes de cada Sprint. Cada item possui um business value associado onde podemos medir o retorno do projeto e priorizar os itens. Para estimar cada item do Product Backlog podemos utilizar uma técnica chamada de Planning Poker que realiza a estimativa em horas/tamanho. Esse Planning Poker pode ser feito como um jogo onde todo o Scrum Team, o Scrum Master e inclusive o Product Owner participam democraticamente para chegar a um consenso de estimativa de tempo a respeito de cada item do Product Backlog; Impediment Backlog é semelhante ao Product Backlog, porém relacionado a riscos e possui uma lista de itens que atrapalham o progresso da Sprint. Esses itens estão relacionados a algum item do Product Backlog ou tarefa de item, porém não possuem priorização alguma. O Scrum Master deve controlar esses itens de impedimento para que o Scrum Team possa atingir o objetivo da Sprint sem problema algum. O Guia Scrum (2011) ainda identifica o Task Board ou quadro de tarefas (figura 6). Figura 6 - Exemplo de Task Board (quadro de tarefas) Fonte: SCRUM (2011)

32 30 Exibe todas as tarefas necessárias para a conclusão da estória durante um Sprint. Task Board deve estar sempre atualizado no decorrer da Sprint. Pode ser modificado por qualquer integrante do Scrum Team sempre que for identificada a necessidade de uma nova tarefa. O quadro de tarefas pode ser atualizado antes ou durante um Daily Scrum, tendo suas estimativas alteradas e tendo os cartões movidos no quadro. Durante o planejamento da Sprint a equipe define quais itens do Product Backlog serão construídos na Sprint. Esses itens podem ser visualizados em cada linha do quadro de tarefas como estórias. Para cada estória são definidas as tarefas necessárias para sua conclusão. Essas tarefas são representados por cartões colocados inicialmente na coluna To Do. No decorrer da Sprint as tarefas são movimentadas entre as colunas até serem concluídos. Ainda pode ser identificado a Release Plan, que é a lista de estórias priorizadas que serão entregues em cada release do sistema com suas datas de entrega (WELLS, 2011). No início do projeto o release plan será criada em alto nível devido ao pouco conhecimento que se tem do produto a ser desenvolvido. Mesmo sendo de alto nível o release plan deverá abordar a quantidade e a duração de sprints; quantidade de pessoas em uma equipe e até mesmo a quantidade de equipes se for o caso; o número de releases com seus respectivos valores e datas de liberações. As principais informações no release plan são a priorização do Product Backlog, a estimativa de velocidade e atendimento de datas importantes (time-tomarket) impostas pelo mercado pelo Product Owner. (SCRUM, 2011) Conforme podemos observar na fugura 7 o Burndown Chart é um gráfico para acompanhamento da evolução das estórias ao longo de uma iteração ou permite visualizar a quantidade de trabalho cumulativo restante para entrega da iteração ou do projeto. Podemos visualizar também a velocidade da equipe e o tamanho da iteração. Deve ser atualizado sempre ao final de uma reunião para contabilizar o tamanho total entregue a ser representado. A altura indica a quantidade de tarefas do Sprint Backlog não completadas e o comprimento são os dias. Possui duas retas: uma que exibe o planejado e outra que exibe o realizado. (KNIBERG, 2008)

33 31 Figura 7 - Burndown Chart Fonte: Kniberg (2007) O Scrum Master deve acompanhar os membros da equipe para ver o que foi terminado e o dia a dia ajustar o Burndown Chart. Assim, sempre que a equipe necessitar saber como o processo está avançando, o Burndown Chart estará atualizado. O Scrum Master também é responsável por garantir que a equipe atue quando o Burndown Chart indique alguma irregularidade. (KNIBERG, 2008) Figura 8 - Excesso de backlog itens Fonte: Kniberg (2007) itens. A figura 8 indica o excesso de backlog items sendo necessária a remoção de alguns

34 32 Figura 9 - Necessidade de backlog items Fonte: Kniberg (2007) alguns itens. Já a figura 9 indica a necessidade de backlog items sendo necessário o acréscimo de 3.6 FLUXO DO PROCESSO Um projeto no Scrum se inicia com uma visão do produto que será desenvolvido (SCHWABER, 2004). A visão contém a lista das características do produto estabelecidas pelo cliente, além de algumas premissas e restrições. Em seguida, o Product Backlog é criado contendo a lista de todos os requisitos conhecidos. O Product Backlog é então priorizado e dividido em releases. Todo o trabalho é realizado em iterações chamadas de sprints. SCHWABER (2004) explica que cada sprint se inicia com uma reunião de planejamento (Sprint Planning Meeting), na qual o Product Owner e o time decidem em conjunto o que deverá ser implementado (Selected Product Backlog). A reunião é dividida em duas partes. Na primeira parte (Sprint Planning 1), o Product Owner apresenta os requisitos de maior valor e prioriza aqueles que devem ser implementados. O time então define colaborativamente o que poderá entrar no desenvolvimento da próxima sprint, considerando sua capacidade de produção. Na segunda parte (Sprint Planning 2), o time planeja seu trabalho, definindo o Sprint Backlog, que são as tarefas necessárias para implementar as funcionalidades selecionadas a partir do Product Backlog. Nas primeiras sprints, é realizada a maioria dos trabalhos de arquitetura e

35 33 de infra-estrutura. A lista de tarefas pode ser modificada ao longo da sprint pelo time e as tarefas podem variar entre 4 a 16 horas para a sua conclusão. Durante a execução das sprints, diariamente o time faz uma reunião de 15 minutos para acompanhar o progresso do trabalho e agendar outras reuniões necessárias. Na reunião diária (Daily Meeting), cada membro do time responde a três perguntas básicas: O que eu fiz no projeto desde a última reunião? O que irei fazer até a próxima reunião? Quais são os impedimentos? No final da sprint, é realizada a reunião de revisão (Sprint Review Meeting) para que o time apresente o resultado alcançado na sprint ao Product Owner. Neste momento as funcionalidades são inspecionadas e adaptações do projeto podem ser realizadas. Em seguida o Master conduz a reunião de retrospectiva (Sprint Retrospective Meeting), com o objetivo de melhorar o processo/time e/ou produto para a próxima sprint. Na figura 10 podemos acompanhar o fluxo do processo do Scrum.

36 34 Figura 10 - O Processo Scrum Fonte: SCRUM (2011) Ao assumir que o objetivo do projeto é o produto e não a documentação, o Scrum busca gerar apenas a documentação suficiente e necessária para atingir o objetivo de entregar um produto que dê ao cliente um retorno rápido do seu capital investido. Ao defender que abraçar as mudanças é mais importante do que seguir um plano, o Scrum vem de encontro às metodologias tradicionais de desenvolvimento de software, exigindo muita disciplina e organização para que se tenha a habilidade de ser flexível com estabilidade. (MACHADO, 2009) Varaschim (2009) e Fabichak (2009) em seus trabalham identificam alguns problemas encontrados por empresas que iniciaram a utilização da metodologia Scrum: Falta de treinamento em toda a equipe; Falta de definição das responsabilidades de Product Owner e Scrum Master. Mesmo com o treinamento é importante deixar claro antes de começar as atividades; Scrum Master inexperiente na área do negócio;

37 35 Daily Scrum ineficiente. As equipes retornam aos velhos métodos e paralelizam as histórias, se prendiam em estimações em longo prazo e a comunicação era ineficiente e o reflexo disso era no Daily Scrum, que não era informativo a um nível de se ajudarem para o próximo dia, prevendo problemas e impedimentos com uma equipe; Falta de Product Backlog priorizado e estimado; Perda de tempo nas Sprint Planning e Sprints Review. As reuniões de Sprint Planning normalmente demoravam demais e nas Sprints Review muitas vezes era apresentado ao Product Owner funcionalidade que já havia visto e até mesmo validado; Inacessibilidade ao Product Owner, que gerava a decisões serem tomadas sem o seu consentimento, o que constantemente levava a equipe a refazer parte significante das tarefas já concluídas. Ainda com base no trabalho de Varaschim (2009) pode-se citar alguns resultados encontrados após a implantação do Scrum: Normalmente as equipes ficam mais motivadas e comprometidas; O processo de estimativas e o autogerenciamento cria uma relação mais próxima com a área de produto que passa a entender melhor o processo de desenvolvimento; A participação efetiva do cliente trouxe a redução dos riscos e custos, além disso o grau de satisfação por participar do processo como um todo melhorou; As equipes aprendem a se policiar e tentar manter o Daily Scrum o mais breve e

38 36 informativo possível; Os projetos foram melhor priorizados e seus escopos discutido, possibilitando a eliminação de funcionalidades que aparentemente não possuem valor de negócio relevante. 4 MAPEAMENTO DO SCRUM AO GRE NÍVEL G DO MPS.BR Para que a organização atinja maturidade e agilidade através do MPS.B, é necessário que ambos os modelos possam ser realizados em conjunto e que suas práticas e objetivos sejam satisfeitos. Para análise das práticas encontradas no Scrum em relação a satisfazer cada um dos resultados esperados do processo de Gerência de Requisitos (GRE), foram definidos os seguintes critérios: Atendido (A) - A prática está totalmente atendida na Metodologia; Parcialmente Atendido (PA) - Há evidências da prática na metodologia, embora a prática não esteja plenamente atendida; Não Atendido (NA) - Não há evidências da prática na metodologia.

39 37 A Tabela 2 mostra o resumo do mapeamento entre o SCRUM e o GRE. Tabela 2 - Resumo do mapeamento entre SCRUM e área GRE (Gerência de Requisitos) MPS.BR Nivel G SCRUM Gerencia de Requisitos GRE Mapeamento Resultados Classificação Resumo das práticas MAP 1 GRE 1 Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de requisitos, utilizando critérios objetivos. Atendido Elaboração do Backlog do produto, Backlog da Sprint, priorizados por Business Value e Retorno do Investimento. MAP 2 GRE 2 O comprometimento da equipe técnica com os requisitos aprovados e obtidos. Atendido Planejamento da Versão para entrega e geração do Backlog do Produto para a Versão. MAP 3 GRE3 A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho e estabelecida e mantida. Não Atendido Pratica não mencionada no SCRUM. MAP 4 GRE 4 Revisões em planos e produtos de trabalho do projeto são realizadas visando a identificar e corrigir inconsistências em relação aos requisitos. Atendido Daily Scrum, sprint review MAP 5 GRE 5 - Mudanças nos requisitos são gerenciadas ao longo do projeto. Atendido Planejamento da Versão para Entrega, Daily Scrum, sprint review

40 38 Abaixo a descrição detalhada dos mapeamentos gerados entre os processos de Gerência de Requisitos do MPS.BR com a prática da metodologia ágil SCRUM: MAP 1- O Product Owner (PO) identifica tanto os requisitos como os fornecedores de requisitos. O PO deve avaliar os requisitos, obtendo como resultado o Backlog do Produto (BP). O PO deve usar como critério a priorização por Business Value (BV) e Retorno do Investimento (ROI). O mesmo BP é refinado e os requisitos são novamente analisados quando o Time (TS) define o Backlog do Produto para a Versão (BPV) e o Backlog da Sprint (BS). Para registrar toda a comunicação realizada, artefatos como estórias de usuário, Atas, BP, Plano de Execução do Projeto, podem ser gerados. Como o MPS.BR não indica o formato dos artefatos que devem ser gerados, ficando a critério da organização; MAP 2 - Através da Reunião de Planejamento da Versão para Entrega (RPVE), PO e Master (SM) trabalham para que todo o Time (TS) entre em acordo sobre o entendimento dos requisitos, gerando planos e metas que formarão o Backlog do Produto para a Versão (BPV). Desta forma, a equipe técnica está se comprometendo com requisitos aprovados a partir de critérios estabelecidos conforme GRE 1; MAP 3 não atende a GRE 3, pois a rastreabilidade bidirecional entre os requisitos e os produtos de trabalho não é mencionada na prática ; MAP 4 O objetivo deste resultado esperado é uma das maiores evidências na prática. As Reuniões Diárias, a Reunião de Revisão da Sprint e a Reunião de Retrospectiva da Sprint, além do fluxo de desenvolvimento do Scrum, o capacitam a abraçar mudanças ao longo do projeto, permitindo que o projeto esteja apto, a partir de constantes revisões, a identificar e corrigir as mudanças de requisitos correrão ao longo do desenvolvimento do projeto; MAP 5 Características elementares do Scrum encaminham para que as mudanças nos requisitos sejam gerenciadas ao longo do projeto. Uma vez que com a Reunião de Planejamento da Versão para Entrega (RPVE), as Reuniões Diárias, e as Reuniões de Revisão e Retrospectiva da Sprint garantem um gerenciamento das mudanças dos requisitos, ficando a critério do Time (TS) a forma de documentar as mudanças, podendo ser através de estórias de usuário, ou alguma outra ferramenta que também seja adequada para este fim.