Mapeando o Scrum em Relação ao CMMI Níveis 2 e 3

Transcrição

1 Mapeando o Scrum em Relação ao CMMI Níveis 2 e 3 Yuri Rodrigues Guimarães, Gustavo Rezende Krüger, Alexandre Scheidt, Victor Francisco Araya Santander UNIOESTE - Universidade Estadual do Oeste do Paraná Colegiado de Informática Rua Universitária, Jardim Universitário. Caixa Postal CEP Cascavel, PR - Brasil. {yuri.rg007,gustavorekr,alescheidt}@gmail.com, vfasantander@unioeste.br Resumo. Uma das grandes dificuldades encontradas pelos pesquisadores e profissionais ligados à Engenharia de Software refere-se ao desenvolvimento de software de qualidade. Já é sabido que a melhora no processo de desenvolvimento permite aumentar consideravelmente a qualidade do produto final. Levando este aspecto em consideração, o presente artigo analisa a metodologia de desenvolvimento de software Scrum, observando como esta permite satisfazer, parcial ou completamente, os níveis 2 e 3 do CMMI (Modelo Integrado de Capacitação de Maturidade). 1. Introdução O desenvolvimento de software não é uma tarefa trivial. A fim de aprimorar a qualidade dos softwares desenvolvidos, surgiram diversas metodologias de desenvolvimento de software, bem como modelos de avaliação da maturidade destes processos. Atualmente, existe um grande interesse em relação às metodologias ágeis, pois ao contrário das metodologias tradicionais, que tentam prever todo o processo de desenvolvimento de software, os processos ágeis estão preparados para as mudanças constantes. Ainda assim, o principal motivo que faz com que as metodologias ágeis não sejam utilizadas em larga escala se refere ao fato de que muitos dos clientes exigem maturidade no processo de desenvolvimento. Em outras palavras, acredita-se que as metodologias ágeis, por serem flexíveis, não possuem um processo de desenvolvimento bem definido. Com o objetivo de melhorar a qualidade no processo de desenvolvimento, bem como o organizacional, várias organizações utilizam modelos de avaliação de processos. Dentre os modelos existentes, destaca-se o CMMI, por se tornar uma exigência e critério para a comercialização de software a nível internacional [3]. 128

2 Considerando estes aspectos, neste trabalho optou-se pela avaliação da metodologia Scrum, pois, além de adotar os princípios ágeis de desenvolvimento de software, permite, não somente o desenvolvimento de sistemas, mas também gerenciar outras atividades, tais como a construção de aviões, automóveis, dentre outros [7]. Assim, se engenheiros de software e equipes de desenvolvimento que utilizam o Scrum pretendem melhorar seus processos sob a ótica da avaliação do CMMI, é importante estabelecer um paralelo entre estas duas abordagens. Portanto, neste artigo apresentamos uma análise detalhada das características da metodologia Scrum com foco na satisfação dos níveis 2 e 3 do CMMI. Nas próximas seções apresentam-se a metodologia de desenvolvimento Scrum (Seção 2) e o modelo de maturidade CMMI (Seção 3). Após o entendimento dos elementos básicos para a nossa análise, faz-se, na Seção 4, a avaliação da metodologia Scrum em relação aos níveis 2 e 3 de maturidade, propostos no CMMI. Na Seção 5 apresentam-se os trabalhos relacionados e, por fim, na Seção 6, as considerações finais e trabalhos futuros. 2. Metodologia Scrum De acordo com Sutherland e Schwaber [7], o Scrum é uma metodologia ágil para gestão e planejamento de projetos de software que fornece um processo de desenvolvimento rápido, satisfatório e de qualidade. No Scrum, os projetos são divididos em ciclos (normalmente de duas a quatro semanas) chamados de Sprints. Trata-se de um Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de Sprints, no caso do Scrum. A título de ilustração, a Figura 1 apresenta o ciclo de vida do Scrum. Figura 1: Ciclo de Vida do Scrum Adaptado de Sutherland e Schwaber [7] 129

3 Conforme a Figura 1, as funcionalidades a serem implementadas em um projeto são mantidas em uma lista intitulada Backlog do Produto. Na fase inicial de cada Sprint, é realizado um planejamento. Trata-se de uma reunião na qual o Product Owner 1 prioriza os itens do Backlog do Produto e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Backlog do Produto para o Backlog do Sprint. Em cada dia, dentro de um Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia. Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma reunião chamada Sprint Review Meeting. Finalmente, em uma reunião chamada Sprint Retrospective, a equipe aponta problemas e ações corretivas para serem executadas no próximo Sprint. Em paralelo, a equipe parte para o planejamento do próximo Sprint. Assim, reinicia-se o ciclo. 3. CMMI O CMMI (Capability Maturity Model Integration) é um modelo de maturidade de desenvolvimento de software criado pelo SEI (Software Engineering Institute - Carnegie Mellon University EUA) [4]. Este modelo não descreve processos, mas define, por meio de práticas específicas, orientações para definição e implantação de boas práticas de processos. Com este modelo é possível, também, determinar o grau de maturidade do processo de desenvolvimento de uma empresa por meio de níveis de maturidade. Estes níveis são estruturados com base em uma ou mais áreas de processo que representam aquilo que a organização deve focar para atingir um determinado nível de maturidade. Os níveis podem ser representados de duas formas. De um lado a representação contínua, a qual é caracterizada por níveis de capacidade. Entende-se por capacidade de um processo a habilidade com que este alcança o resultado desejado. Esta representação possibilita à organização utilizar a ordem de melhoria que melhor atende os objetivos de negócio da empresa. Por outro lado tem-se a representação por estágios, que caracteriza-se por possuir níveis de maturidade e disponibiliza uma seqüência, que não deve ser desconsiderada, pré-determinada para melhoria baseada em estágios [1]. Devido à natureza deste trabalho, optou-se pela representação por estágio, uma vez que o interesse, aqui, é a avaliação da maturidade do processo de desenvolvimento do Scrum. A representação por estágio divide-se em 5 níveis, a saber: (1) inicial, (2) gerenciado, (3) definido, (4) gerenciado quantitativamente e (5) em otimização. O 1 Product Owner é a pessoa responsável pelos interesses de todos no projeto, trata do retorno financeiro do produto e define as características do produto decidindo a data e o que deve conter cada Sprint. 130

4 presente trabalho considera apenas os níveis Gerenciado e Definido, visto que o primeiro nível não possui práticas específicas para a melhoria no processo de desenvolvimento. No nível Gerenciado (2) são estabelecidos processos básicos de gerenciamento de projeto para planejar e acompanhar custos, prazos e funcionalidades. Compromissos são firmados e gerenciados. A disciplina de processo permite repetir sucessos de projetos anteriores em aplicações similares. Para alcançar este nível, sete áreas de processo devem ser satisfeitas, as quais são: Gestão de Requisitos, Planejamento de Projeto, Monitoramento e Controle de Projeto, Gestão de Acordo com Fornecedores, Medição e Análise, Garantia da Qualidade de Processo e Produto e Gestão de Configuração. No nível Definido (3), atividades de gerenciamento básico e as de Engenharia de Software são documentadas, padronizadas e integradas em processos-padrão. Todos os projetos de desenvolvimento ou manutenção de softwares utilizam uma versão de um desses processos adaptada às características especificas de cada projeto. Este nível é alcançado com a satisfação do nível 2 e das seguintes áreas de processo: Desenvolvimento de Requisitos, Solução Técnica, Integração de Produto, Verificação, Validação, Foco no Processo Organizacional, Definição do Processo Organizacional + IPPD, Treinamento Organizacional, Gestão Integrada de Projeto + IPPD, Gestão de Risco e Análise de Decisão. No nível 4 ou Gerenciado Quantitativamente, a organização centra-se na gestão dos projetos e processos por meio da utilização de instrumentos estatísticos. Para tanto, faz-se necessário a utilização dos dados que a organização já começou a recolher no nível 3. Este nível divide-se em 2 áreas de processo: Desempenho do Processo Organizacional e Gestão Quantitativa de Projeto. O nível Em Otimização (5) é diferente de todas os níveis anteriores. A própria palavra em otimização enfatiza um sentido de continuidade e melhoria nos processos. Em outras palavras, uma vez que toda a organização trabalha com um processo comum e recolhe dados comum, a única forma de melhorar a organização é melhorar o processo em si. Assim, atualizações incrementais são feitas para o processo. A melhoria em si pode ser feito pelo uso de uma nova técnica, ferramenta ou tecnologia. Este nível divide-se em duas áreas de processo, a saber: Inovação Organizacional e Análise de Causa e Solução de Problemas. Com foco nos conceitos associados aos níveis Gerenciado (2) e Definido (3) já apresentados, a próxima seção faz uma análise do processo de desenvolvimento do Scrum sob a ótica desses dois níveis. 4. Avaliação do Scrum quanto ao o modelo CMMI (versão 1.2) Nas tabelas 1 e 2 apresenta-se o estudo detalhado no qual relacionam-se as áreas de processo dos níveis 2 e 3 do CMMI com os princípios e práticas da metodologia Scrum. 131

5 Com o objetivo de esclarecer alguns conceitos, mencionados na Seção anterior, e de possibilitar melhor compreensão na análise realizada nesta Seção, segue, para cada tabela, uma breve descrição das áreas de processo consideradas. Segue abaixo a descrição das áreas de processo do nível 2: Gestão de Processo: Propõe a gerência de todos os requisitos recebidos ou gerados pelo projeto, incluindo requisitos técnicos, não técnicos e os requisitos impostos pela própria empresa. Planejamento de Projeto: Um planejamento de projeto permite que seja estabelecidos e mantidos planos para gerenciar as atividades relacionadas ao projeto. Monitoramento e Controle do Projeto: O propósito do monitoramento de um projeto é acompanhar seu progresso, de forma que ações corretivas possam ser aplicadas quando necessário. Gestão de Acordo com Fornecedores: O objetivo desta área de processo é gerenciar a aquisição de produtos com fornecedores. Medição e Análise: Permite que os participantes do projeto, a partir de dados medidos e analisados, possam tomar decisões referentes a ações corretivas ou até mesmo modificar o projeto no sentido de reduzir tempo de entrega, caso as medições e análises sejam otimistas. Garantia da Qualidade de Processo e Produto: Garantir a qualidade de processos e produto dá suporte à entrega de produtos e serviços de alta qualidade. Fornece, também, à equipe do projeto e aos gerentes de todos os níveis, uma visão clara e o feedback sobre os processos e produtos de trabalho associados ao projeto. Produto e Gestão de Configuração: O objetivo desta área chave é estabelecer e manter a integridade dos produtos de trabalho, utilizando identificação de configuração, controle de configuração, balanço de configuração e auditorias de configuração. Área de Processo 1: Gestão de Requisitos Nível 2 Gerenciado É satisfeita parcialmente por meio de um planejamento durante o Sprint Planning Meeting, onde define-se o comprometimento dos integrantes do Scrum e os primeiros requisitos (Backlog do Produto). Ao final de cada Sprint é feita uma reunião onde aponta-se os principais problemas encontrados, quais requisitos serão agregados e quais serão removidos do Backlog do Produto. Entretanto, não possui uma documentação formal. 132

6 Área de Processo 2: Planejamento de Projeto Quanto ao estabelecimento de estimativas, no Scrum está previsto, na Sprint Planning Meeting, a definição do escopo do projeto, divisão de tarefas, responsabilidades, participação dos stakeholders, bem como o comprometimento dos participantes. Não existe uma estimativa definida para custos e riscos. Entretanto, por ser um processo iterativo, o Scrum considera que o software está em constante mudança e está sempre preparado. Ao final de cada dia e de cada Sprint é feita uma retrospectiva geral apontando os problemas e custos, bem como as ações corretivas para tratá-los. Esta área de processo não é satisfeita completamente por falta de documentação formal. Área de Processo 3: Monitoramento e Controle Do Projeto Área de Processo 4: Gestão de Acordo com Fornecedores Área de Processo 5: Medição e Análise Através do Daily Scrum, a equipe de desenvolvimento faz uma análise sobre o que foi feito no dia anterior, apontando avanços e problemas. Nesta reunião, ações corretivas são elaboradas a fim de tratar os problemas encontrados pela equipe. Desta forma, até o fim do Sprint, diariamente, o projeto está sendo monitorado. Ao final de cada Sprint, no Sprint Retrospective, reunem-se os envolvidos no projeto a fim de apontar mudanças e elaborar ações corretivas, caso problemas sejam encontrados. Assim, até o final do desenvolvimento do produto, o projeto será monitorado e controlado. Entretanto, este monitoramento e controle não prevê documentação formal. Não é atendida pois o Scrum não prevê esse tipo de gestão. Entretanto, o Scrum também não impede a organização de elaborar uma Gestão de Acordo com Fornecedores. O Scrum não prevê a medição e análise dos processos da organização. Entretanto, idem a área de processo acima, o Scrum não impede a organização de elaborar uma política de medição e análise. Área de Processo 6: Garantia de Processo e Qualidade de Produto Área de Processo 7: Produto e Gestão de Configuração O Scrum prevê a avaliação dos processos apenas por meio da experiência adquirida. Não existe um relatório formal identificando as não-conformidades encontradas, bem como as ações corretivas para tratá-las. Essas não-conformidades são identificadas e tratadas no Daily Scrum e Sprint Retrospective. As lições aprendidas não são formalmente documentadas. Entretanto, o Scrum não impede a organização de elaborar um plano de avaliação de software e processo. O Scrum não prevê controle de versões. Fica a cargo da organização elaborar uma política de controle de versões. Tabela 1: Análise do Scrum quanto ao Nível 2 do CMMI Abaixo segue a descrição das áreas de processo do nível 3: Desenvolvimento de Requisitos: Tem por objetivo o desenvolvimento de requisitos para o projeto a partir de necessidades e objetivos. Solução Técnica: O propósito da Solução Técnica é projetar, desenvolver e implementar soluções para requisitos. Integração de Produto: O propósito desta área é montar um produto a partir de componentes de produto (pedaços) desenvolvidos independentemente. Verificação: A verificação tem por objetivo verificar e corrigir problemas em produtos. Validação: A validação tem como objetivo examinar o produto a fim de demonstrar que o produto atende ao seu uso pretendido. 133

7 Foco no Processo Organizacional: Uma organização precisa manter uma forma de organizar suas atividades. Para tanto, processos organizacionais são planejados a fim de gerenciar tais atividades dentro de uma empresa. Esta área chave tem por objetivo melhorar esses processos. Definição do Processo Organizacional: Definir o processo organizacional de uma empresa é definir os processos, de forma padronizada, que a mesma utilizará na execução de seus projetos e atividades, sejam eles financeiros, administrativos, dentre outros. Treinamento Organizacional: Tem por objetivo capacitar os funcionários a fim de melhorar a qualidade no desenvolvimento de atividades dentro da empresa ou em projetos específicos. Gestão Integrada de Projeto + IPPD: O propósito da Gestão Integrada de Projeto é estabelecer e gerenciar o projeto e o ambiente dos participantes do projeto de acordo com um processo integrado e definido que é adaptado a partir do conjunto de processos padrão da organização. Para IPPD, a Gestão Integrada de Projeto cobre também o estabelecimento de uma visão compartilhada para o projeto e o estabelecimento de equipes integradas que irão cumprir os objetivos do projeto. Gestão de Riscos: A gestão de riscos permite que os responsáveis pelo projeto estejam preparados e se antecipem para possíveis riscos relacionados ao projeto. Ela também fornece técnicas para tratar esses riscos. Análise de Decisão: Decisões são tomadas quando se tem mais de uma solução ou soluções alternativas para alguma questão. Tais soluções são avaliadas e escolhidas a partir de critérios de avaliação. Neste sentido, a gestão de decisão tem como objetivo fornecer métodos para se analisar e escolher soluções. Área de Processo 1: Desenvolvimento de Requisitos Área de Processo 2: Solução Técnica Área de Processo 3: Integração de Produtos Nível 3 Definido O Scrum não possui uma política que engloba todos os aspectos de desenvolvimento de requisitos, propostos no CMMI. Entretanto, existe, ainda que pouco aprofundado, um processo de desenvolvimento de requisitos. No Sprint Planning Meeting, os requisitos sào levantados e analisados de acordo com as preferências do cliente. Como o Scrum possui um processo iterativo e interativo, o cliente tem a flexibilidade de remover e agregar requisitos durante o projeto. O Scrum está preparado para agregar e analisar novos requisitos no início e durante o projeto. Formalmente, o Scrum não prevê soluções para designs e componentes de produto. Entretanto, as soluções para componentes de software e designs podem ser encontrados no Sprint Planning Meeting. A implementação dessa solução acontece durante o Sprint. Não existe nenhuma documentação que aponte as soluções utilizadas. Entretanto, a utilização de documentação não prejudica o processo de desenvolvimento do Scrum. Desta forma, fica a cargo da organização adotar uma política para solução técnica. O Scrum não prevê sequência de integração dos componentes de produtos. Fica a cargo da organização implementar a política de integração de produtos. 134

8 Área de Processo 4: Verificação O Scrum possui um processo de verificação informal. Acontece nos Daily Scrum e Sprint Retrospective, onde o produto desenvolvido passa por uma verificação. Não existe documentação relacionada com esse processo, muito menos uma etapa específica para verificação Área de Processo 5: Validação De forma similar à verificação, o Scrum, ao final de cada Sprint passa por um processo de validação a fim de testar as funcionalidades implementadas. A seguir, no Sprint Retrospective, os problemas encontrados na validação e verificação são abordados e ações corretivas são tomadas. Ainda assim, não existe uma documentação formal para armazenar essas informações. Área de Processo 6: Foco no Processo Organizacional Área de Processo 7: Definição do Processo Organizacional + IPPD O processo organizacional é monitorado constantemente pelo Scrum Master, cuja responsabilidade é a de estabelecer e manter necessidades referentes ao processo organizacional. Por meio do Daily Scrum, Sprint Retroscpective e Sprint Review, o Scrum Master, com o auxílio dos demais envolvidos no projeto, adquire informações suficientes que podem melhorar o processo organizacional. No entanto, nenhum documento, com informações referentes às mudanças e à sua forma de implementação na organização, é elaborado. É atendida parcialmente por meio dos processos e ciclo de vida da metodologia Scrum. Não é satisfeita completamente pois não existem guias padrões do conjunto de processos, repositórios com medidas da organização, biblioteca de ativos e padrões de ambientes de trabalho. Área de Processo 8: Treinamento Organizacional Área de Processo 9: Gestão Integrada de Projetos + IPPD O Scrum não prevê treinamento organizacional. Entretanto, treinamentos organizacionais não prejudicam o processo de desenvolvimento do Scrum. Desta forma, fica a cargo da organização adotar uma política de treinamento. O Scrum fornece processos definidos para o desenvolvimento de software. Além disso, como mencionado anteriormente, o Scrum possui um controle sobre o processo do projeto. Esta área não é satisfeita completamente devido à falta de documentação requerida pelo CMMI, tais como repositórios de medidas da organização, registros de uso, desempenho e manutenção, relatrórios de progresso, dentro outros necessários para uma gestão integrada de projetos. Área de Processo 10: Gestão de Riscos Formalmente, o Srum não satisfaz a gestão de riscos proposta no CMMI. Entretanto, por se tratar de uma metodologia iterativa, o Scrum se adapta à situações de risco facilmente. Como já mencionado, no Daily Scrum e Sprint Retrospective são apontados os problemas e as devidas ações para corrigí-los. Área de Processo 11: Análise de Decisão É satisfeita parcialmente por meio do Daily Scrum e Sprint Retrocpective, onde identifica-se soluções alternativas, avalia-as e seleciona as mais satisfatórias. Não é atendida completamente, visto que não existe um guia sobre quando aplicar um processo de avaliação formal, não existem critérios de avaliação documentados, bem como métodos de avaliação. Tabela 2: Análise do Scrum quanto ao Nível 3 do CMMI Na avaliação feita, o nível 2 apresenta 4 áreas de processo parcialmente satisfeitas e 3 não atendidas, já o nível 3 apresenta 9 áreas de processo parciais e 2 não atendidas. Nas tabelas de avaliação, fica evidente que muitas áreas de processo não são atendidas por falta de documentação, registros e outros aspectos que a metodologia não aborda, ficando a critério da organização que a utiliza. Por este motivo, a metodologia Scrum não satisfaz os níveis 2 e 3 do CMMI. 135

9 No entanto, a metodologia Scrum é flexível a ponto de fornecer espaço suficiente para adaptações neste sentido, visto que algumas áreas de processo a metodologia não questiona nem sugere. Desta forma, aspectos como treinamento, etapa para revisão, verificação, validação, medição e análise, repositório de componentes e documentação podem ser utilizados para a melhoria do processo organizacional, dentre outros aspectos requisitados pelo CMMI, sendo agregados e adaptados ao Scrum, desde que não afetem a essência da metodologia. Estas modificações implicariam, sob a ótica do CMMI, em melhorar a maturidade da organização que utiliza o Scrum como metodologia de desenvolvimento. Quantos aos níveis 4 e 5, cabe destacar que, segundo Ken Shwaber [5], esta metodologia não permite obtê-los devido a limitações da própria metodologia. 5. Trabalhos Relacionados Entre os trabalhos relacionados podemos destacar o de Zanatta [8], o qual analisa as Áreas de Processo do CMMI e afirma que o Scrum não atende totalmente as exigências presentes nas áreas do modelo CMMI, e sobre isso propõe algumas soluções. Neste sentido Siqueira [6] apresenta uma proposta de extensão do Scrum para torná-lo mais aderente à área de processo de Gerenciamento de Projetos do CMMI. Para tanto, Siqueira realiza um estudo de mapeamento das práticas de Scrum nas áreas de processo do CMMI e, para alguns problemas identificados, propõe soluções baseadas em práticas e atividades de outras metodologias ágeis. Já em Zanatta [9], avalia-se o Scrum segundo as perspectivas do modelo CMMI, nas áreas de processo Gerenciamento de Requisitos e Desenvolvimento de Requisitos, encontrando algumas lacunas e propondo uma extensão do Scrum a fim de preencher tais lacunas. Marçal et al [2] possui trabalhos relacionados com o gerenciamento ágil de projetos em ambientes CMMI realizando o mapeamento entre o CMMI e o Scrum. Mostra-se em seu trabalho que organizações que têm seu plano de processos baseados no CMMI podem definir um quadro de gestão baseado em ambas as praticas, CMMI e Scrum. Entretanto, nenhum dos trabalhos realizam um estudo investigativo que abordem, de forma detalhada, os níveis 2 e 3 do CMMI. Para tanto, o presente artigo, como forma de contribuir com os trabalhos realizados, não aponta modificações na metodologia, mas fornece suporte aos desenvolvedores que utilizam o Scrum em suas organizações. 6. Considerações Finais e Trabalhos futuros A principal contribuição do presente trabalho está em apoiar usuários da metodologia Scrum que buscam desenvolver softwares de maior qualidade, considerando o modelo CMMI como mecanismo de avaliação da maturidade dos seus processos. É importante destacar que a utilização de metodologias ágeis está em franca expansão e uma das principais preocupações tanto da comunidade acadêmica quanto industrial está também em garantir a qualidade e maturidade dos processos empregados usando este tipo de metodologia. Contudo, esta não é uma tarefa trivial. O uso da metodologia Scrum, por 136

10 exemplo, atribui grande parte do sucesso a habilidade, experiência e bom senso dos desenvolvedores e demais participantes envolvidos no processo de desenvolvimento. Assim, garantir bons processos passa pela necessidade de que usuários da metodologia Scrum atentem e formalizem práticas bem sucedidas e que possam levar a processos gerenciados e definidos. Também como já comentado, a maturidade da organização que utiliza o Scrum afetará diretamente a possibilidade de satisfazer áreas de processo do CMMI que em princípio não são cobertas pela metodologia. Como trabalhos futuros pretendemos investigar meios que permitam complementar a metodologia Scrum de forma a satisfazer as áreas de processo não cobertas no presente estudo. Pretende-se também realizar estudos de caso reais que permitam avaliar e auxiliar equipes de desenvolvimento que utilizam o Scrum e desejam melhorar seus processos. Referências [1] CMMI. CMMI for Development, Version 1.2. Software Engineering Institute. Agosto, [2] Marçal, A. S. C.; Freitas, B. C. C.; Soares, F. S. F.; Belchior, A. D. Mapping CMMI Project Management Process Areas to Scrum Practices. In: Software Engineering Workshop, SEW st IEEE, 2007, Baltimore. [3] Salaviano, C. F. Jino, M; Mendes, M. J. Towards na ISO/IEC Based Process Capability Profile Methodology for Process Improvement (PRO2PI). In: Proceedings of SPICE 2004: The Fourth International SPICE Conference on Process Assessment and Improvement, Lisboa, Portugal, Abril, 2004, p [4] SEI (Software Engineering Institute), junho 2009, 18. [5] Shwaber, K. Agile Project Management with Scrum, apêndice E. Microsoft Pr, [6] Siqueira, H. B. A. Mapeamento das práticas de Scrum nas áreas de processo do CMMI e uma proposta para sua aderência. monografia Universidade Federal de Pernambuco [7] Sutherland, J.; Schwaber, K. The Scrum Papers: Nuts, Bolts, and Origins of an Agile Process [8] Zanatta, A. L. Uma análise do método ágil Scrum conforme abordagem nas áreas de processo Gerenciamento e Desenvolvimento de Requisitos do CMMI. In: VII Workshop em Engenharia de Requisitos, 2005, Porto. Procedings of WER05. Porto Portugal. [9] Zanatta, A. L. xscrum: uma proposta de extensão de um Método Ágil para Gerência e Desenvolvimento de Requisitos visando adequação ao CMMI. Dissertação. Universidade Federal de Santa Catarina