Extensão do Scrum segundo o MPS.BR nível G

Ao final dos anos 90, como reação às formas tradicionais de desenvolvimento de software, que baseado em estudos realizados pela indústria e academia [12], foi apontada como a principal responsável por falhas encontradas em projetos de software, acompanhamos o surgimento de várias metodologias ágeis, como: Adaptive Software Development, Crystal, Dynamic Systems Development, eXtreme Programming (XP), Feature Driven Development (FDD) e Scrum [4].

As metodologias ágeis são uma coleção de diferentes técnicas (ou práticas), que utilizam os mesmos valores e princípios básicos, tais como ciclos iterativos, entrega rápida de software funcionando e simplicidade, conforme está definido no Manifesto para Desenvolvimento Ágil [2].

Neste sentido, organizações que procuram melhoria em seus processos de produção através de modelos e frameworks como Capabitity Model Integration (CMMI), Control Objectives for Information and related Technology (COBIT), Information Technology Infrastructure Library (ITIL), entre outros, agora também acreditam que introduzir conceitos ágeis em seus processos de desenvolvimento, buscando um equilíbrio entre agilidade e maturidade, é uma alternativa capaz de promover a melhoria da qualidade dos seus produtos e, consequentemente, aumento da competitividade no mercado [9].

Segundo o [Softex 2007], alcançar competitividade pela qualidade para as empresas de software implica tanto na melhoria da qualidade dos produtos de software e serviços correlatos, como dos processos de produção e distribuição de software. Desta forma, assim como para outros setores, qualidade é fator crítico de sucesso para a indústria de software.

O desenvolvimento ágil e os modelos e padrões de qualidade de software tradicionais são vistos frequentemente como contraditórios, pois se tem o raciocínio que os modelos são muito burocráticos, enquanto que o desenvolvimento ágil é ad-hoc [6].Na verdade existem desafios na integração entre os dois, embora o esforço possa valer a pena, pois ao final pode-se obter qualidade no produto através da união de maturidade e agilidade.

Nessa direção, [Chin 2004] afirma que, se por um lado o excesso de formalidade e estruturação tende a inibir e limitar as equipes, por outro, a liberalidade caótica e informal, desprovida de processos, pode fazer com que os objetivos do projeto nunca sejam atingidos.

Inserido neste contexto, este trabalho tem o objetivo de propor uma estratégia para extensão do Scrum segundo as áreas de processo do guia MPS.BR nível G. Este estudo se inicia com o mapeamento entre o Scrum e o MPS.BR através de uma avaliação dos resultados esperados do guia segundo as práticas do Scrum. A partir deste mapeamento, uma extensão do Scrum é realizada através da adição de práticas complementares para satisfazer o guia. Ao final, é gerado um novo processo de desenvolvimento para uma fábrica de software.

O MPS.BR

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 as suas necessidades de negócio e também ser reconhecido nacional e internacionalmente como um modelo aplicável à indústria de software [11].

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 [11].

O nível G de maturidade do MPS.BR (Parcialmente Gerenciado) é composto pelos processos de Gerência de Projetos e Gerência de Requisitos satisfazendo os atributos de processo AP 1.1 e AP 2.1.

O processo de Gestão de Projetos (GPR) é composto por dezessete resultados esperados e tem o propósito de estabelecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o andamento do projeto que permitam a realização de correções quando houver desvios significativos no desempenho do projeto [11].

O processo de Gerência de Requisitos (GRE) é composto por cinco resultados esperados. 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 [11].

O Scrum

A metodologia ágil Scrum foi criada em 1996 por Ken Schwaber e Jeff Sutherland, e destaca-se das demais metodologias ágeis pela maior ênfase dada ao gerenciamento do projeto [10].

Trata-se de uma abordagem empírica focada nas pessoas para ambientes em que os requisitos surgem e mudam rapidamente, resultando em uma abordagem que reintroduz as ideias de flexibilidade, adaptabilidade e produtividade [3]. Ela se baseia em princípios como: 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 "