Experiência de Implantação de Melhoria de Processos de Software em um Laboratório de Pesquisa

Transcrição

1 Artigos técnicos selecionados Experiência de Implantação de Melhoria de Processos de Software em um Laboratório de Pesquisa Fabiana Freitas Mendes 2, Jackeline Neves de Almeida 1, Egio Arruda Junior 1 1 Laboratory for Ubiquitous and Pervasive Applications (LUPA) Instituto de Informática (INF) Universidade Federal de Goiás (UFG) Caixa Postal Goiânia GO Brasil 2 Instituto de Computação (IC) Universidade Federal do Mato Grosso (UFMT) Av, Fernando Corrêa da Costa, Bairro Boa Esperança Cuiabá MT Brasil fabiana@ic.ufmt.br, {jackeline.neves, egio.junior}@lupa.inf.ufg.br Abstract. This paper describes how an initiative to improve software development processes has been led at LUPA, a research laboratory at UFG. Moreover, it presents some lessons learned during this work. Such lessons are serving as a basis for planning the next round of process improvements. Resumo. O presente documento descreve uma iniciativa de melhoria de processos de desenvolvimento de software do LUPA, um laboratório de pesquisa da UFG. Além disso, são apresentadas lições aprendidas durante a execução do projeto. Estas lições estão servindo de base para o planejamento do próximo ciclo de melhoria. 1. Introdução O LUPA (Laboratory for Ubiquitous and Pervasive Applications) é um laboratório de pesquisa aplicada que funciona nas dependências do INF (Instituto de Informática) da UFG (Universidade Federal de Goiás). Ele reúne estudantes e profissionais de computação comprometidos no desenvolvimento de soluções de geotecnologia através de interfaces ricas para a web e computação distribuída e paralela. Atualmente, a equipe conta com cerca de 23 pessoas distribuídas em três projetos de desenvolvimento de software que ocorrem em paralelo a um projeto de Melhoria de Processos de Software (MPS). Além disso, ainda compõe a equipe, pessoas diretamente envolvidas na manutenção da infraestrutura necessária para o funcionamento do laboratório. Cada projeto de desenvolvimento conta com equipes de 5 a 8 integrantes. Já o projeto de MPS possui uma pessoa dedicada, um representante de cada um dos três projetos e o coordenador do grupo, totalizando cinco participantes ativos. Participam também, sob demanda, duas pessoas para manutenção da infraestrutura do projeto. A peculiaridade de um laboratório de pesquisa é a ausência de um cliente, o desafio pela inovação, requisitos nebulosos e ausência de base histórica ou dificuldade de utilizá-la quando esta existe, já que, os desafios tecnológicos de inovação que cada projeto propõe é particular. 114 WAMPS 2011

2 Experiência de Implantação de Melhoria de Processos de Software em um Laboratório de Pesquisa Este trabalho tem por objetivo relatar a experiência de implantação de MPS neste ambiente. Apesar de existirem diversos trabalhos que relatam a implantação de MPS em organizações, por exemplo, [Mega et al. 2007, Borssatto 2007, Mendes et al. 2010, Ribeiro 2007], foi encontrado, no conjunto de avaliações vigentes do MPS.BR (Melhoria do Processo de Software Brasileiro) [SOFTEX 2011b], apenas uma organização que é também um laboratório de pesquisa (COPPE/UFRJ). Trata-se, portanto, de um tipo de iniciativa pouco explorada no Brasil. O artigo está estruturado como se segue. A Seção 2 descreve a motivação, o ambiente de execução da iniciativa de melhoria e as atividades de implantação planejadas e realizadas desde o início da iniciativa. Na Seção 3 é apresentada uma visão geral do processo criado pelo projeto de melhoria. Já na Seção 4, os resultados até então obtidos e as lições aprendidas durante o período do projeto são descritos. Finalmente, a Seção 5 apresenta as considerações finais do trabalho, incluindo os próximos passos planejados pela iniciativa. 2. Elaboração do Processo de Software Baseados na hipótese de que a qualidade do processo de software influencia a qualidade dos produtos [Tyrrell 2000], o LUPA tem investido na melhoria dos seus processos de desenvolvimento de software desde Março de Além da necessidade de melhoria da qualidade dos produtos do LUPA, teve-se como motivação melhorar a gerência dos recursos e dos projetos, dar maior visibilidade do trabalho desenvolvido pela equipe e preparar-se para a alta rotatividade dos recursos humanos, situação típica de ambientes de pesquisas. Por se tratar de um laboratório de pesquisa, o ambiente de desenvolvimento é diferenciado, pois tem como foco o desenvolvimento de software voltado para P&D&I (Pesquisa, Desenvolvimento e Inovação). Além disso, os projetos executados são caracterizados pela falta de conhecimento do negócio e de um cliente explícito. O escopo dos projetos é instável e, portanto, há grande dificuldade de estimativa. Assim, incerteza e novidade estão presentes no cotidiano dos projetos desenvolvidos Para a implantação de MPS neste ambiente foram contratadas duas implementadoras do MPS.BR e foi escolhido um processo de implantação semelhante ao IDEAL [McFeeley 1996]. A implantação possuiu seis grandes atividades, conforme ilustra a Figura 1. As seções seguintes tratam da descrição de como foi conduzida cada uma das fases do fluxograma presente na Figura Iniciação A primeira fase foi a iniciação. Neste momento, o coordenador do LUPA foi ouvido em uma entrevista não estruturada. Foram coletados os principais pontos fracos do modo de trabalho daquele momento, e portanto, as principais necessidades relacionadas ao processo que seria construído. Apesar de já terem sido coletadas diversas necessidades de melhoria, ainda era necessário conhecer um pouco mais o modo de trabalho. Assim, foi necessário realizar um diagnóstico de processos. WAMPS

3 Artigos técnicos selecionados Figura 1. Fluxograma de Implantação de Melhorias. 2.2 Diagnóstico No diagnóstico foram consultados dois colaboradores, sendo um deles o coordenador do LUPA e o outro um desenvolvedor. O diagnóstico foi realizado por meio de uma entrevista conjunta tendo como base o nível G do MPS.BR [SOFTEX 2011a], pois segundo a entrevista inicial as principais necessidades de melhoria concentrava-se nos processos de Gerência de Projeto e Gerência de Requisitos, os dois processos desse nível. Nesse momento, cada resultado esperado de cada um dos processos do nível de maturidade G foi transformado em um tópico de entrevista. Como resultado da atividade, foi elaborado um relatório de diagnóstico contendo as principais não conformidades com o modelo adotado. Posteriormente, também foram detectados mais pontos fracos no modo de trabalho do grupo e, portanto, a necessidade de se preocupar com outros processos além daqueles já previstos no nível G do MPS.BR: Qualidade (Garantia da Qualidade, Verificação e Validação), Desenvolvimento de Requisitos, Aquisição e Gerência de Configuração. Uma vez montada a lista de processos, foi pedido ao grupo que selecionasse aqueles considerados essenciais e os priorizasse. Entretanto, por não existir conhecimento suficiente para se tomar esta decisão, foi realizado um conjunto de treinamentos que tinha como objetivo fornecer uma visão geral sobre cada um dos processos da lista. Dessa forma, esperava-se que a equipe pudesse entender melhor os problemas do grupo e tomar decisões quanto ao planejamento das melhorias. 2.3 Planejamento Depois do diagnóstico partiu-se para o planejamento da iniciativa de melhoria. Para tanto, os processos escolhidos para treinamento foram priorizados, eliminando aqueles de menor prioridade. As áreas de melhoria escolhidas foram: Gerência de projeto, Desenvolvimento de Requisitos, Gerência de Configuração, Testes e Comunicação. Além disso, durante o planejamento também foi definida a ferramenta que seria utilizada para a definição dos processos. 116 WAMPS 2011

4 Experiência de Implantação de Melhoria de Processos de Software em um Laboratório de Pesquisa Para a gerência do projeto de MPS, foi criado um cronograma e uma tabela de riscos que serviria como acompanhamento do projeto. As estimativas foram realizadas utilizando-se uma variação do método Delphi [Linstone et al. 2002], contando com as opiniões das duas especialistas em MPS e que também conheciam o ambiente em que a iniciativa ocorreria. No cronograma elaborado, a definição e implantação dos processos selecionados teria início em junho e término em setembro de Definição dos processos Finalmente, teve início a definição dos processos. À princípio foi estabelecido um template para a definição dos processos e posteriormente as duas especialistas em MPS dividiram os esforços desta atividade. Devido às características dos projetos de desenvolvimento e da forma de trabalho em andamento no LUPA, optou-se por utilizar tanto modelos de maturidade de processo (MPS Melhoria do Processo de Software Brasileiro [SOFTEX 2011a] e CMMI Capability Maturity Model Integration [SEI 2006]) quanto algumas metodologias de desenvolvimento ágil (SCRUM [Schwaber, 2004] e XP extreme Programming [Beck, 1999]). Em relação ao processo de Gerência de Projetos, adotou-se inicialmente o SCRUMMI [Marçal et al. 2010] o qual foi adaptado durante sua utilização nos projetos. Entretanto, à medida que os processos iam sendo definidos, novas necessidades foram surgindo o que acarretou na inclusão de outras áreas de melhoria. Assim, foram definidos, além dos processos anteriormente listados, os processos de teste, gerência de configuração e práticas que facilitassem a comunicação através da equipe. Assim, o término da definição de processo que estava prevista para agosto, foi finalizada apenas em dezembro. 2.5 Treinamento Após a definição, teve início a atividade de treinamento dos processos de Gerência de projeto, Desenvolvimento de Requisitos, Gerência de Configuração e Testes. Para tanto, a equipe foi divida em grupos de interesse, formando assim o público para cada um dos treinamentos. A preocupação era que pelo menos um colaborador de cada projeto em execução recebesse informações de pelo menos um processo e trabalhasse como disseminador dele na equipe. Os treinamentos consistiram na exposição de conceitos fundamentais e apresentação do fluxograma, e do detalhamento das atividades de cada um dos processos. Porém, durante estes treinamentos, percebeu-se que os processos ainda não atendiam as necessidades da equipe e os esforços tiveram que ser concentrados nas adaptações delas. Além disso, a ferramenta adotada para apoiar a Gerência dos Projetos também não se mostrou adequada às necessidades da equipe e, por isso, teve que ser trocada imediatamente. Para realizar a troca da ferramenta foram listados os principais itens esperados de uma ferramenta de gerência de projeto e itens desejáveis pelo LUPA. Depois de selecionada a ferramenta, foi estabelecido um cronograma de troca que incluía, além da migração dos dados, um treinamento na ferramenta escolhida. Cada projeto migrou para a nova ferramenta seguindo um calendário, de tal forma que nenhum projeto migrasse ao mesmo tempo. O tempo de migração entre um projeto e outro deveria durar no máximo três semanas. WAMPS

5 Artigos técnicos selecionados 2.6 Execução dos processos definidos Depois disso, passou-se para a execução dos processos que foram definidos. Durante a execução foi realizado mentoring no qual era orientado o que se esperava para cada processo e como deveria ser preenchido cada template. Aproveitando a experiência de acompanhamento da implantação de MPS, o grupo de processo investiu na construção de guias de execução do processo junto com exemplos de cada resultado. Esses guias eram mais informais e possuíam informações relacionando as atividades e os templates referentes. Para cada guia foi realizada uma validação com os líderes dos projetos. A validação consistia na explicação do fluxograma do processo, detalhando-se cada passo, relacionando com o cotidiano e verificando a facilidade de entendimento e execução. Dessa forma, foi possível verificar se as necessidades do laboratório estavam sendo satisfeitas e se a utilização do processo estava acarretando atrasos no fluxo natural das atividades do laboratório. Se o guia refletisse a realidade do laboratório e fosse realizável ele era aprovado, caso contrário o guia seria reformulado tendo como insumos as inconsistências que porventura pudessem ser encontradas. Após estes ajustes, iniciou-se, ainda na execução dos processos definidos, a avaliação de conformidade da execução com a definição, como uma Garantia da Qualidade realizada pelo grupo de processos. A equipe viu esta atividade como uma consultoria do grupo. A próxima seção irá descrever o ProLUPA (Processo do LUPA) criado durante a execução do Projeto de Melhoria. 3. Descrição do Processo do LUPA O ProLUPA usa uma abordagem híbrida de metodologias ágeis de desenvolvimento (Scrum e XP) e modelos de maturidade (MPS.BR e CMMI) adaptados às necessidades para gerenciamento de projeto de P&D&I (Pesquisa, Desenvolvimento e Inovação). A Figura 2 mostra um fluxograma resumido das fases processo desenvolvido. Figura 2. Fluxograma das Fases do projeto. 118 WAMPS 2011

6 Experiência de Implantação de Melhoria de Processos de Software em um Laboratório de Pesquisa Como pode ser visto, o primeiro passo previsto no ProLUPA é identificar as necessidades do sistema a serem atendidas pelo projeto. Para cada uma destas necessidades é definida uma prioridade de acordo com valor para o negócio. O valor de negócio varia de 0 a 10, onde 0 significa que a necessidade não é importante para o negócio e 10 representa aquela que possui a maior significância. Esse valor é determinado pela influência da necessidade para o sucesso do projeto. Em seguida é realizado o planejamento da abertura do projeto no qual itens como escopo, premissas, restrições, riscos preliminares, atores envolvidos são definidos. Esta etapa encerra-se com a reunião de abertura do projeto com a equipe definida. A próxima fase consiste no planejamento do projeto com base no objetivo do projeto e a lista de necessidades. Para cada necessidade identificada são definidas listas de macro atividades para atendêla. Paralelamente são executadas as atividades do processo de Gerência de Configuração: identificar itens de configuração e definir a estrutura de armazenamento dos produtos do projeto. Após o planejamento do projeto, inicia-se as atividades executar e monitorar projeto. Na execução é buscado o alinhamento dos objetivos estratégicos do projeto com os objetivos técnicos do desenvolvimento. O objetivo do projeto é fragmentado e estruturado em marcos que duram de um a dois meses. Depois disso, são definidas as iterações em função dos objetivos definidos (sprints) com duração de duas semanas. No início de cada sprint é feito o planejamento das atividades a serem desenvolvidas durante uma reunião com a equipe e, durante o período do sprint, a equipe trabalha no desenvolvimento destas atividades. Ao final do sprint é realizada uma reunião de fechamento com a equipe para a validação das atividades desenvolvidas. A identificação e monitoramento dos riscos são realizados por meio de reuniões com os membros da equipe. Na abertura e no fechamento dos sprints a equipe do projeto analisa o desempenho do projeto em relação aos riscos. Também nestas reuniões é analisado o quanto as atividades propostas/ desenvolvidas contribuirão/contribuíram para atingir o objetivo do sprint, do marco e do projeto. Além disso, diariamente é realizada uma reunião de acompanhamento que dura, em média, 15 minutos. Nestas reuniões discutem-se as atividades dos projetos e as dificuldades encontradas. O monitoramento também é feito por um conjunto de métricas que visam acompanhar a velocidade da equipe, o esforço gasto e a relação das atividades planejadas e não planejadas. Através da análise dos dados obtidos pela aplicação das métricas é possível detectar atrasos no cronograma, a quantidade de tarefas não planejadas e realizadas no projeto, a falta de alinhamento das atividades com o objetivo do projeto, a produtividade da equipe, dentre outros. Com estas informações em mãos, é possível, se necessário, realizar o replanejamento. O projeto é encerrado quando não existem mais necessidades a serem implementadas e os testes foram realizados. Quando um novo membro integra a equipe do projeto são realizados treinamentos nos quais são apresentados os fluxogramas do ProLUPA. Para a evolução contínua do ProLUPA são realizadas reuniões mensais com todos os líderes dos projetos e com o coordenador do laboratório. Nestas reuniões são apresentados os resultados dos WAMPS

7 Artigos técnicos selecionados projetos e as experiências vivenciadas no período. Nessas reuniões também são consideradas as solicitações de melhorias enviadas por , formulário de avaliação do sprint e os indicadores gerados durante o período. Através disso, são coletadas oportunidades de melhoria do processo e discutidas as estratégias para melhorá-lo. 4. Resultados e Lições Aprendidas Apesar do pouco tempo do projeto de MPS, já foram alcançados diversos resultados: 1. Conscientização da equipe sobre a necessidade de processos definidos e otimizados, e de planejamento de atividades; 2. Definição e documentação dos processos-chave para o LUPA; 3. Criação de um padrão para a gerência e execução de projetos; 4. Aumento da visibilidade das atividades e esforços dos projetos desenvolvidos no LUPA; 5. Participação da equipe na elaboração do processo; 6. Melhoria na comunicação do time; 7. Criação de um glossário para uniformização dos termos utilizados pela equipe; 8. Aceitação do processo; e 9. Melhoria e evolução contínua do processo. Esta experiência também gerou diversas lições aprendidas, as quais são apresentadas a seguir, com algumas discussões. 1. Elaborar versão inicial do processo o mais próximo possível do realizado pela equipe e evoluí-lo progressivamente à medida que o processo é aceito pela equipe. Quando o projeto de MPS foi iniciado, o desenvolvimento de software ocorria de forma diferente daquela proposta pelo processo. Assim, houve resistência na adoção das práticas propostas até que elas fossem completamente entendidas e discutidas pela equipe. Ao se definir um processo, este deve soar o mais natural possível, de modo a facilitar o entendimento. 2. Definir o processo de maneira bottom-up. A definição do processo preocupou-se em desenvolver um fluxograma macro, contendo as principais fases e atividades do processo. Depois disso, cada atividade foi melhor detalhada e foram criados templates e guias de acordo com a necessidade. Entretanto, um melhor resultado poderia ter sido atingido se tivesse sido adotada uma abordagem mais bottom-up, ou seja, primeiro definir os processos que seriam trabalhados e um fluxograma para mostrar a interação entre eles. Depois formalizar as práticas da equipe, criando-se guias e templates para elas. E, só então, as atividades seriam criadas. 3. Planejar mais efetivamente o projeto de MPS. Apesar de ter sido realizado o planejamento do projeto, alguns itens não ficaram claros para toda equipe como o cronograma geral do projeto, incluindo o processo de implantação e de melhoria. A equipe de MPS deve manter 120 WAMPS 2011

8 Experiência de Implantação de Melhoria de Processos de Software em um Laboratório de Pesquisa todos os colaboradores do laboratório trabalhando juntos e alinhados com o cronograma para uma melhor aceitação. 4. Definir o processo de maneira a envolver melhor a equipe. O processo foi definido pelos dois membros mais experientes nesta tarefa. Apesar da equipe ter sido consultada antes e durante a definição, percebeu-se que o envolvimento de mais pessoas na tarefa de definição teria ajudado, posteriormente, na implantação dos processos. No final, para a aceitação do processo isso teve de ser realizado. 5. Definir processo tendo apenas um tipo de projeto como foco principal. Atualmente o LUPA possui projetos de diversas naturezas e o processo foi definido de forma a tentar se adaptar a qualquer um dos projetos do laboratório. Entretanto, isso acarretou em um processo que acabava não sendo adequado a nenhum dos projetos. Assim, percebeu-se a necessidade de definir um processo tendo como fornecedor de requisitos apenas um tipo de projeto, resultando em um processo mais focado. Logo, os outros projetos devem adaptar o processo definido de acordo com suas características específicas e detalhar as particularidades no plano de projeto. 6. Estabelecer e manter a prioridade do projeto de MPS. Durante o período do projeto, houve muita oscilação da prioridade do projeto de MPS. Não houve um apoio efetivo do patrocinador ou ele foi dado de maneira muito superficial, pois, na primeira dificuldade, as atividades do ProLUPA eram deixadas em segundo plano. As atitudes que ajudaram na conscientização da importância do projeto foram: utilizar página wiki de forma colaborativa, criar guias de execução do processo, criar exemplos do artefatos, criar momentos para comunicação do time, ajudar no preenchimento de cada artefato como se fosse uma consultoria, participação do grupo de processos nas reuniões de abertura e fechamento de sprint fazendo observações a respeito do planejamento e resultados obtidos. 7. Controlar mudanças na equipe do ProLUPA. Durante a execução do projeto houve a saída de pessoas chave, o que resultou no esfriamento do projeto. Assim, faz-se necessário o envolvimento de diversas pessoas nas atividades de definição do processos para que o conhecimento seja disseminado e que a rotatividade não impacte o projeto. 8. Gerenciar a utilização do processo. Houve abandono do processo e utilização de outras abordagens e templates por parte dos projetos, dificultando a implantação do que foi definido no ProLUPA. Dessa forma, houve inclusão de documentos que misturaram conceitos e geraram despadronização da documentação do processo. Para evitar esse cenário o grupo do processo deve atuar mais próximo da equipe de desenvolvimento e preocupar com a definição e liberação de templates antes do fluxo do processo. 9. Disseminar conhecimento dos processos e dos conceitos relacionados a eles. A falta de conhecimento de processos e de alguns conceitos por alguns integrantes, ocasionou diversos problemas como a mudança prematura do processo e a falta de entendimento da abordagem de implantação utilizada. A comunicação deve ser mais efetiva incluindo realização de reuniões com os membros para alinhar ideias, procedimentos, necessidades e costumes. A utilização de ferramentas mais adequadas, como a wiki, são bastante úteis na comunicação da equipe. WAMPS

9 Artigos técnicos selecionados 10. Implantar os processos um a um. Dos processos que foram definidos foram escolhidos apenas três (Gerência de Projeto, Desenvolvimento de Requisitos e Gerência de Configuração) para serem implantados no período de dois a três meses. Assim, os dois processos restantes, seriam implantados posteriormente. Entretanto, não foi obtido êxito na execução desta estratégia devido à falta de prioridade do projeto de melhorias. Os processos devem ser definidos e implantados um a um, dessa forma há um melhor entendimento, aceitação dos processos e o impacto das mudanças será menor. 11. Estabelecer projetos menores. Os produtos a serem entregues pelo LUPA possuem uma complexidade alta, o que resulta em projetos com duração superior a um ano. Implantar processo em um ambiente de pesquisa com projetos de longa duração mostrou-se inviável devido à instabilidade dos requisitos e aos desafios tecnológicos. A solução foi estabelecer projetos menores, com duração média de 3 meses. Estes projetos contemplavam os requisitos que a equipe possuía maior segurança para trabalhar. Dessa forma, o processo pôde ser aplicado de um modo mais satisfatório. 5. Considerações Finais Este trabalho mostrou como foram e estão sendo conduzidas as melhorias de processos no LUPA. Neste pouco mais de um ano de projeto, foram definidos os processos de Gerência de Projeto, Desenvolvimento de Requisitos, Gerência de Configuração, Testes, Garantia da Qualidade e itens relacionados à comunicação da equipe. Atualmente, o projeto está na fase de implantação de melhoria de processos. O objetivo agora é dar um foco maior aos processos de Gerência de Configuração, por já se ter uma versão estável e implantada de Gerência de Projeto e Desenvolvimento de Requisitos. Como pode ser visto, por se tratar de um laboratório de pesquisa, a implantação de MPS possui diversas particularidades. A falta de um fornecedor de requisitos, o constante desafio pela inovação tecnológica e a grande rotatividade da equipe acarretaram em muitas adaptações no processo. Uma delas foi o alto investimento na melhoria da comunicação interna da equipe para minimizar as mudanças no grupo. Outra foi a definição de projetos pequenos (com cerca de três meses de duração) contendo apenas os requisitos que a equipe se sente segura para estimar. Além disso, para suprir as necessidades advindas das características do ambiente, foi desenvolvido um processo focado nas características de apenas um projeto. Assim, os demais projetos devem adaptá-lo segundo as características específicas dele. Um ponto forte de se trabalhar em um laboratório de pesquisa é a postura questionadora da equipe. Isso foi impactante na implantação do processo, pois a equipe queria entender antes de aplicar o processo. Apesar do atraso no cronograma de implantação do processo, o interesse e envolvimento da equipe foi importante para a evolução e fortalecimento do processo. Embora falte pouco para a adequação do ProLUPA ao nível G do modelo MPS, uma avaliação oficial do MPS.BR não faz parte dos objetivos do laboratório no momento. Entretanto, ela contribuiria para o alcance de um dos objetivos do LUPA que é tornar-se, até 2015, um Instituto de Pesquisa, 122 WAMPS 2011

10 Experiência de Implantação de Melhoria de Processos de Software em um Laboratório de Pesquisa Desenvolvimento e Inovação de referência na área de Geoprocessamento e RFID (Radio-Frequency IDentification). Um dos fatores que contribuem para a decisão de não se certificar neste momento é a falta de recursos para custear uma avaliação. Ainda assim, é uma preocupação do coordenador do projeto a excelência dos seus profissionais e produtos e, por isso, tem-se investido recursos para que esta meta seja cumprida. Referências Borssatto, I. (2007). A Implementação do MPS.BR Nível F na Synos, In: PROQUALITY Qualidade na Produção de Software, v. 3, n. 2, pp , Novembro. Beck, K. (1999) Extreme Programming Explained: Embrace Change. Addison-Wesley. Linstone, H. A. e Turoff, M. (2002). The Delphi Method: Techniques and Applications. Disponível em: < Acesso em Fevereiro de Marçal, A. S. C. e Furtado, M. E. S. (2010). Scrummi: Um processo de gestão ágil baseado no Scrum e aderente ao CMMI. IX Simpósio Brasileiro de Qualidade de Software, p McFeeley, B. IDEAL: A User s Guide for Software Process Improvement. CMU/SEI-96-HB-001 Pittsburgh, p. Mega, B., Fonseca, K., Boessio, R., et al. (2007). Melhoria de Processos de Software na Drive, In: PROQUALITY Qualidade na Produção de Software, v. 3, n. 2, pp , Novembro. Mendes, F. F., Nascimento, H. A. N. D., Fernandes, P. G., Nunes, R. S., Mota, C. C. (2010). Implantação de Melhoria de Processos em um Setor de Produção de Software de uma Universidade Federal. IX Simpósio Brasileiro de Qualidade de Software, p Ribeiro, A.F. (2007). Melhoria de Processos de Software com Base no Nível G do MPS.BR na Prodemge. In: PROQUALITY Qualidade na Produção de Software, v. 3, n. 2, pp , Novembro. Schwaber, K. (2004) Agile Project Management with Scrum. Microsoft Press, SEI Software Engineering Institute (2006) CMMI for Development (CMMI-DEV). Version 1.2, Technical report CMU/SEI-2006-TR-008. Pittsburgh, PA. SOFTEX, Associação Para Promoção da Excelência do Software Brasileiro (2011). Melhoria de Processo de Software Brasileiro (MPS.BR): Guia Geral: Disponível em: < mpsbr/_guias/default.asp>. Acesso em: Setembro de SOFTEX, Associação Para Promoção da Excelência do Software Brasileiro (2011). Avaliações MA-MPS. Disponível em: < default.asp>. Acesso em Setembro de Tyrrell, S. (2000). The many dimensions of the software process. Crossroads. ACM, New York, p jun WAMPS