INTEGRANDO GERÊNCIA DE PROJETOS ÁGEIS COM SCRUM E OS PROCESSOS MPS.BR NÍVEL G Claudinei Martins da Silva 1 RESUMO: Com o aumento da dependência tecnológica nas organizações para a tomada de decisões, ocorreu uma demanda por sistemas mais complexos e, consequentemente, aumentaram os riscos de falhas nas entregas, dificultando a liberação de produtos com a qualidade desejada. Tais fatores prejudicam a imagem da organização, aumentam os custos e ampliam o insucesso de projetos existentes. A partir de uma pesquisa bibliográfica, este trabalho descreve como integrar o gerenciamento de projetos com o método ágil SCRUM e o modelo de qualidade do processo MPS.BR voltado para a realidade do mercado de pequenas e médias empresas de software no Brasil. Palavras-chave: MPS.BR, Scrum, Desenvolvimento ágil. 1 INTRODUÇÃO As organizações estão aumentando cada vez mais sua dependência tecnológica, representando um número maior de sistemas informatizados para atender suas operações internas como reflexo de uma tendência natural. Para sobreviver em um ambiente competitivo, as empresas estão buscando tecnologias para reduzir custos e ampliar a sua atuação. A demanda por sistemas cada vez mais complexos com a capacidade de tomada de decisão é primordial para ganhar eficiência e controle. Nesse cenário, todos os processos envolvidos no desenvolvimento de sistemas têm um nível crescente de complexidade, aumentando o risco de mau funcionamento e dificultando a produção com a qualidade desejada. 1 Analista de Sistemas Softplan. Bacharel em Sistemas de Informação. Especialização em Gerência de Projetos de Tecnologia da Informação.
Produzir sistemas com falhas prejudica a imagem da organização, aumenta os custos de desenvolvimento e amplia o insucesso de projetos existentes. Para acompanhar essa complexidade, as empresas estão buscando um método de avaliação de maturidade para trazer disciplina e controle no desenvolvimento de sistema, do qual as organizações partem de um modelo evolutivo de qualidade, com início na total falta de controle para gradativamente adquirir maturidade. (BARTIÉ, 2002). A evolução dos processos é definida pelo nível de maturidade do modelo MPS.BR, caracterizado por sete níveis: A (Em otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente definido), E (Parcialmente definido), F (Gerenciado) e G (Parcialmente Gerenciado). Iniciando pelo nível G, seguindo progressivamente até o nível A. (SOFTEX, 2011). A entrega dentro do prazo é outro ponto crítico no desenvolvimento de sistemas. Existem vários métodos, entre eles os chamados ágeis, que possuem esse nome por serem mais adaptativos e flexíveis em relação aos tradicionais, e os resultados devem ser entregues em pequenos intervalos de tempo, realizando entregas ao final de cada ciclo (sprints). (CARVALHO, 2009). Para atender rapidamente à necessidade do mercado, as indústrias de sistemas estão desesperadas em busca do aperfeiçoamento de seus processos internos. Isso evidência que a maioria das empresas que fornecem sistemas a uma organização são amadora, ou seja, desconhecem de um processo de engenharia de software. A principal conseqüência desse cenário é a não existência de nenhuma garantia na entrega da solução tecnológica dentro do prazo e custo negociados. (BARTIÉ, 2002). A união de uma metodologia ágil com os processos de maturidade é um desafio ainda maior a ser vencido para que as organizações alcancem o estado de excelência no desenvolvimento de sistemas, a fim de atender à expectativa de sistemas complexos. O objetivo desse trabalho é apresentar a metodologia Scrum e os processos de maturidade MPS.BR nível G por meio de uma pesquisa bibliográfica e propor a integração entre essas tecnologias. Para tal, apresenta-se no segundo e terceiro capítulo um estudo da metodologia Scrum e o processo MPS.BR. No quarto capítulo será detalhado os processos MPS.BR nível G, os resultados esperados e a sua integração com Scrum.
2 SCRUM Scrum é uma metodologia ágil. Seu nome teve origem no jogo de Rugby, o qual tem uma reunião rápida antes de iniciar um lance. Nesse método, cada membro possui um papel específico e todos colaboram para alcançar um objetivo comum. Ele baseia-se em seis características (CARVALHO, 2009): Flexibilidade de resultados; Flexibilidade de prazos; Times pequenos; Revisões frequentes; Colaboração; Orientação a objetos. Product Backlog é uma lista de funcionalidades a serem desenvolvidas que devem estar ordenadas por prioridade. Essas funcionalidades são determinadas por meio da coleta de requisitos. (CARVALHO, 2009). Para Kniberg (2007), Backlog é onde começa tudo, é o coração do scrum. Uma lista de coisas que o cliente deseja, chamadas de estórias. Daily Meeting é uma reunião diária que ocorre entre os membros do time, geralmente realizada em pé para maior agilidade. Três perguntas devem ser respondidas por cada membro: O que foi feito ontem? O que será feito hoje? Há algum obstáculo à realização de suas atividades? O objetivo das respostas é a formalização do comprometimento com os demais membros da equipe. Assim, são disseminadas as metas individuais de cada integrante, que conhecem seus impedimentos e podem cobrar compromissos assumidos. (CARVALHO, 2009). Product Owner define os requisitos iniciais e gerais, retorno de investimento, objetivos e planos de entregas. Garante que as funcionalidades de maior valor sejam priorizadas a cada sprint. O Team desenvolve as funcionalidades do produto, transforma o product backlog em valor ao produto, gerencia seu próprio trabalho, e também é responsável pelo sucesso da sprint e do projeto como um todo. (MARÇAL, 2009). Sprint Planning é uma reunião em que estão presentes o Product Owner, o Scrum Master e todo o Scrum Team. O Product Owner descreve as atividades de maior prioridade
para a equipe. A equipe faz perguntas durante a reunião com o objetivo de quebrar as atividades em tarefas que irão dar origem ao Sprint Backlog. (VINÍCIUS, 2012). Sprint é o período de tempo em que são implementados um conjunto de itens definidos no Backlog do Produto. Normalmente dura de uma a quatro semanas, dependendo da decisão da equipe. Para o desenvolvimento de software, uma Sprint possui as fases: requisitos, análise, projeto e entrega. Sprint Review é a reunião que acontece após cada Sprint para ser discutido os erros, acertos e lições aprendidas. (CARVALHO, 2009). Sprint Backlog é construída durante a reunião de planejamento da Sprint, constituída por um subconjunto do Backlog do Produto. (CARVALHO, 2009). Segundo KNIBERG (2007), é uma reunião crítica, é o evento mais importante do scrum. Para Carvalho (2009), o Scrum master é a pessoa responsável por fazer o processo do Scrum acontecer. Ele remove os obstáculos apontados na reunião diária (Dayli scrum) para que os membros da equipe realizem o seu trabalho. Segundo Marçal (2009), o Scrum master também deve ensinar o Scrum a todos os envolvidos no projeto e adequar a cultura da organização. Story points é uma medida que qualifica o tamanho da atividade (ECLIPSE, 2012). O gráfico de BurnDown é uma representação do trabalho restante em comparação com o trabalho já realizado, ele é muito útil para mostrar o fim dos trabalhos e para alertar sobre o atraso antes do prazo final. (CARVALHO, 2009). Sprint retrospective é uma reunião com o objetivo de melhorar o processo e o produto para a próxima Sprint.(CARVALHO, 2009). Segundo Victor (2012), Impediments Backlog é qualquer coisa que impede a realização de uma tarefa de um membro da equipe. Cada membro da equipe pode anunciar impedimento durante a reunião diária. 3 MPS.BR O objetivo do processo MPS.BR é a Melhoria de Processo de Software Brasileiro. Suas metas são (SOFTEX, 2011): a) Meta técnica: aprimoramento do modelo MPS.BR por meio de seus guias e instituições. b) Meta de mercado: disseminação e adoção do modelo em todas as regiões do país. O modelo MPS.BR está divido em 4 guias (SOFTEX (Org.)) :
1) Guia Geral: contém a descrição geral do modelo MPS.BR e detalha o modelo de referência MR-MPS. 2) Guia de Aquisição: descreve um processo de aquisição de software e serviços correlatos. destina-se à instituições que queiram adquirir produtos de software e serviços relacionados. 3) Guia de Avaliação: descreve o processo e o método de avaliação MA.MPS. 4) Guia de implementação: contém orientações para a implementação do modelo de referência MR-MPS. É uma série de onze documentos que fornecem orientações para implementar nas organizações os níveis de maturidade. A base desse modelo são os requisitos de processos definidos nos modelos de melhoria de processo, buscando atender à necessidade de implantar os princípios da engenharia de software ao contexto das empresas brasileiras, em consonância com padrões internacionais. (SOFTEX, 2011). O modelo MPS estabelece um modelo e um método de avaliação de processos, e essa estrutura tem por objetivo garantir que ele esteja sendo empregado de forma coerente com as suas definições. O modelo está divido em níveis de maturidade de G até A, que é uma combinação entre processos e sua capacidade. O nível de maturidade em que se encontra a organização permite prever o seu desempenho futuro ao executar um ou mais processos. Quanto ao nível de maturidade, está dividido em sete níveis (SOFTEX, 2011): A Em otimização; B Gerenciado quantitativamente; C Definido; D Largamente definido; E Parcialmente definido; F Gerenciado; G Parcialmente Gerenciado. Os processos são descritos em termos de propósitos e resultados. O propósito descreve o objetivo a ser atingido e o resultado é o que se espera com a afetiva implementação do processo. A capacidade do processo é representada por um conjunto de atributos de processo descritos como resultado esperado. Ela expressa ao grau de refinamento com que o processo é executado na organização. À medida que a organização evolui os níveis de maturidade, um maior nível de capacidade para desempenhar o processo deve ser atingido.
Os diferentes níveis de capacidade são atribuídos por nove atributos de processo (AP). O seu resultado é avaliado por meio de seus respectivos resultados (RAP), conforme definido a seguir para o nível de maturidade G. AP 1.1 O processo é executado Este atributo evidencia o quanto o processo atinge o seu propósito. Resultado esperado: RAP 1. O processo atinge seus resultados definidos. AP 2.1 O processo é gerenciado Este atributo evidencia o quanto a execução do processo é gerenciada. Resultados esperados: RAP 2. Existe uma política organizacional estabelecida e mantida para o processo. RAP 3. A execução do processo é planejada. RAP 4. A execução do processo é monitorada e ajustes são realizadas. RAP 5. As informações e os recursos necessários para a execução do processo são identificadas e disponibilizadas. RAP 6. As responsabilidades e a autoridade para executar o processo são definidas, atribuídas e comunicadas. RAP 7. As pessoas que executam o processo são competentes em termos de formação, treinamento e experiência. RAP 8. A comunicação entre as partes interessadas no processo é planejada e executada de forma a garantir o seu envolvimento. RAP 9. Os resultados dos processos são previstos com a gerência de alto nível para fornecer visibilidade sobre a sua situação na organização. RAP 10. O processo para o projeto é executado. O modelo MPS.BR prevê a exclusão de alguns processos do escopo da avaliação, por não serem pertinentes ao negócio da unidade organizacional, que pode ser total ou parcial. Essa exclusão deve ser justificada no Plano de Avaliação. A aceitação e justificativas são de responsabilidade do avaliador líder. (SOFTEX, 2011).
4 MPS.BR- PARCIALMENTE GERENCIADO E SUA INTEGRAÇÃO COM SCRUM Neste capítulo serão detalhados os processos Gerência de projetos e Gerência de requisitos, no qual será apresentada uma proposta de integração com o Scrum. A implementação do nível de maturidade parcialmente gerenciado deve ser executada com cautela por estabelecer o início dos trabalhos. Ao final da implementação deste nível, a organização deve ser capaz de gerenciar parcialmente seus projetos de software. A mudança de cultura organizacional e a definição do conceito acerca do que é projeto são os dois pontos desafiadores para a implementação no nível G. O nível de maturidade G é composto pelos processos Gerência de Projetos e Gerência de Requisitos. A implementação desses processos devem satisfazer os atributos de processo AP1.1 e AP2.1. (SOFTEX, 2011). Neste capítulo, serão apresentados os processos do nível G e sua integração com o Scrum. 4.1 PROCESSO: GERÊNCIA DE PROJETOS GPR Seu propósito é estabelecer e manter planos que definam as atividades, recursos e responsabilidades do projeto e prover informações sobre o andamento do projeto que permitam correções quando houver desvios significativos. (SOFTEX, 2011). GPR 1: o escopo do trabalho para o projeto é definido - Reúne todo o trabalho necessário e estabelece o que está e o que não está no projeto. Ele contém a definição do objetivo e a motivação, os limites e as restrições e todos os produtos que serão entregues. (SOFTEX, 2011). Scrum - Documento de visão e o Product Backlog. GPR 2: as tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados - O escopo do projeto é decomposto em partes menores que deve fornecer uma referência para a atribuição de tamanho, esforço, cronograma e responsabilidades, e são utilizadas como uma estrutura subjacente para planejar, organizar e controlar o trabalho executado. O resultado esperado é a estimativa de tamanho. (SOFTEX, 2011). Scrum Story points. Atribuir um tamanho para cada estória.
GPR 3: o modelo e as fases do ciclo de vida do projeto são definidas Consiste de fases e atividades que são definidas de acordo com o escopo dos requisitos. Essas fases geram produtos de trabalho necessários para o desenvolvimento das fases posteriores, no qual permite planejar o projeto, incluindo marcos importantes para o controle de revisões. As fases podem ser chamadas de modelo de ciclo de vida. (SOFTEX, 2011). Scrum Sprint planning, Daily Meeting, Sprint review e Sprint retrospective. O Scrum possui quatro fases de ciclo de vida. GPR 4: o esforço e o custo para a execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências técnicas Custo e esforço são baseados em dados históricos aplicados ao tamanho. Para estimar o esforço e o custo, tipicamente são considerados o escopo, produtos de trabalho e as tarefas estimadas para o projeto; os riscos, as mudanças já previstas, o ciclo de vidas escolhido para o projeto, viagens previstas, nível de competência da equipe do projeto, dentre outros. Empresa implementando o nível G, geralmente precisam construir essa base de dados histórica. (SOFTEX, 2011). Scrum - Não possui dados históricos de custo e esforço. GPR 5: o orçamento e o cronograma do projeto, incluindo a definição de marcos e pontos de controle, são estabelecidos e mantidos Dependências entre tarefas e potencias gargalos são identificados utilizando métodos específicos, por exemplo, análise de caminho crítico. É estabelecido o cronograma das atividades com início, duração e término. O orçamento do projeto é definido com base no cronograma e na estimativa de custos. Esse resultado é importante, pois o cronograma e o orçamento são fundamentais para o acompanhamento do projeto. (SOFTEX, 2011). Scrum - Sprint planning e Sprint review para estimativa de horas. O orçamento não é contemplado pelo Scrum. GPR 6: os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinadas e documentadas Identificar, analisar e priorizar os riscos do projeto. É interessante elaborar uma lista de riscos mais comuns para identificar quais são potencias para o projeto. Para definir a prioridades dos riscos, é necessária uma análise de probabilidade de ocorrência e gravidade. Esse resultado
não significa gerenciamento de riscos, mas um acompanhamento para avaliar como afeta o projeto. (SOFTEX, 2011). Scrum - Daily Meeting, Impediments Backlog. Os impedimentos são levantados durante as reuniões diárias e armazenados no Backlog de impedimentos. GPR 7: os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessário para executá-los Determinam funções, responsabilidades e relações hierárquicas do projeto. As funções podem ser direcionadas para membros internos e externos à organização. Incluir informações de quando e como o recurso será envolvido no projeto, critérios para sua elaboração, mapa de competências da equipe e identificação de treinamento, se necessário. (SOFTEX, 2011). Scrum - Product backlog. A equipe deve ter competência e conhecimento para incluir itens no Product Backlog. Se algum treinamento for necessário, deve ser incluído no próprio Product Backlog. GPR 8: os recursos e o ambiente de trabalho necessários para executar o projeto são planejados - Necessário planejar explicitamente todos os recursos, como ferramentas, serviços, componentes ou despesas, mesmo os considerados como existentes e disponíveis, devido a sua alocação para uso. Se não houver nenhum recurso com necessidade de aquisição para o projeto, deve-se registrar que a questão foi examinada. (SOFTEX, 2011). Scrum - Scrum master e Product owner. São responsáveis em garantir os recursos necessários para o projeto. GPR 9: os dados relevantes do projeto são identificados e planejados quanto à forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-los, incluindo, se pertinente, questões de privacidade e segurança - A documentação do projeto pode estar representada por diversas formas, por exemplo: relatórios, dados informais, estudos e análises; lições aprendidas, itens de ação e indicadores. Esses artefatos podem estar em qualquer formato, como: impressos, fotografia, meio eletrônico e multimídia. A identificação, coleta, armazenamento e distribuição devem ser planejados para garantir segurança e integridade. É necessário explicitar a existência ou não de dados confidencias. (SOFTEX, 2011). Scrum - Não possui um gerenciamento de dados.
GPR 10: um plano geral para a execução do projeto é estabelecida com a integração de planos específicos Garantir que todos os planos que afetam o projeto estejam integrados e que a dependência entre eles tenha sido identificada e considerada durante o planejamento, conciliando o trabalho existente aos recursos existentes. A reunião dos documentos de cronograma, planejamento de recursos humanos, custos, riscos, dados e outros é entendida como sendo o Plano de Projeto. (SOFTEX, 2011). Scrum - Documento de visão e Product backlog representam o Plano do Projeto. GPR 11: a viabilidade de atingir as metas do projeto é explicitamente avaliada considerando restrições e recursos disponíveis. Se necessário, ajustes são realizados Considera o escopo do projeto e examina aspectos técnicos (requisitos e recursos), financeiros (capacidade da organização) e humanos (disponibilidade e capacitação). Uma avaliação preliminar pode ser executada a partir da visão geral dos objetivos e resultados esperados. À medida que o projeto evolui, a viabilidade de sucesso pode ser avaliada com mais precisão. (SOFTEX, 2011). Scrum - Durante a definição do Product backlog, o Scrum master e o Product owner são responsáveis por avaliar a viabilidade do projeto. Durante a evolução do projeto, a Daily Meeting pode identificar restrições. GPR 12: o plano de projeto é revisado com todos os interessados e o compromisso com ele é obtido e mantido É importante revisar o planejamento com os interessados e conciliar as diferenças existentes entre os recursos estimados e os disponíveis. Quando houver conflitos como requisitos, custos e prazos, negociações devem ser realizadas. Os comprometidos deverão ter a confiança de que o trabalho pode ser executado dentro das restrições de custos, desempenho e cronograma. Durante o projeto, novos interessados podem ser identificados e compromissos anteriormente podem ser modificados, por isso, é necessário verificar se os compromissos assumidos estão sendo cumpridos. (SOFTEX, 2011). Scrum - Sprint Planning, Daily meeting e Sprint review são os eventos onde a equipe (team), Scrum master e Product owner revisam os planos. GPR 13: o escopo, as tarefas, as estimativas, o orçamento e o cronograma do projeto são monitorados em relação ao planejado - Avaliar constantemente a aderência entre os planos. Os resultados e os critérios de conclusão de cada tarefa são analisados e as entregas são avaliadas em relação às suas características; a aderência ao cronograma e o dispêndio de
esforços são avaliados e o uso dos recursos. Acompanhar o que foi planejado, detectar problemas e corrigi-los é essencial para o gerenciamento. (SOFTEX, 2011). Scrum - Nas reuniões diárias, é possível detectar problemas e desvio de cronograma por meio do gráfico de Burndown. GPR 14: os recursos materiais e humanos, bem como os dados relevantes do projeto, são monitorados em relação ao planejado Monitorar os itens planejados referentes a recursos materiais e recursos humanos. O monitoramento consiste em uma análise do que foi planejado em relação aos valores atuais e, caso seja necessário, planos de ação devem ser executados para evitar a criação de outros problemas futuros. (SOFTEX, 2011). Scrum - O Scrum master poderá identificar a necessidade de recursos materiais e humanos para o projeto. GPR 15: os riscos são monitorados em relação ao planejado Novos riscos podem ser identificados e os parâmetros dos riscos já identificados podem ser alterados. Poderá ser necessário executar ações para diminuir a probabilidade de que um risco ocorra ou, caso já tenha ocorrido, executar uma ação de contingência. A lista de riscos deve ser avaliada periodicamente em conjunto com seus parâmetros e prioridades. (SOFTEX, 2011). Scrum - As reuniões diárias e de Sprint poderão identificar futuros riscos; ou riscos que se concretizaram. Para isso é necessário realizar uma ação para minimizar seus efeitos. GPR 16: o envolvimento das partes interessadas no projeto é planejado, monitorado e mantido Identificar os interessados no projeto, em que fase eles são importantes e como eles serão envolvidos. Depois de identificado e planejado o envolvimento, deverá ser seguido, monitorado e mantido. Deverá haver uma comunicação com os envolvidos, como: questões relativas a prazos, custos, recursos, comprometimentos e também requisitos. (SOFTEX, 2011). Scrum - A essência do Scrum é o envolvimento e comprometimento das partes com o projeto. As reuniões diárias para acompanhamento do que foi planejado é uma forte evidência desse envolvimento. GPR 17: revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento Revisões em marcos do projeto são diferentes do acompanhamento que ocorre dia a dia. Os marcos precisam ser previamente definidos no planejamento do projeto.
Os marcos são fundamentais para avaliar de forma ampla o andamento do projeto. (SOFTEX, 2011). Scrum - A Sprint review é o momento ideal para avaliar em linhas gerais o andamento do projeto. GPR 18: registros de problemas identificados e o resultado da análise de questões pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes interessantes O acontecimento de problemas e desvios em relação ao planejamento devem ser analisados e registrados. A falha na execução dessa tarefa pode afetar a execução de ações para correção nos desvios e, consequentemente, no andamento do projeto. Os problemas precisam ser corrigidos e gerenciados até a sua solução. (SOFTEX, 2011). Scrum - Os problemas identificados são relacionados no backlog de impedimentos e o Scrum master é responsável pela sua solução. GPR 19: ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidas, implementadas e acompanhadas até a sua conclusão - Com o acompanhamento do projeto, problemas são identificados, analisados e registrados. Ações corretivas devem ser definidas e gerenciadas até serem concluídas. O controle dos problemas levantados, as ações tomadas, os responsáveis pelas ações e os resultados devem ser registrados. (SOFTEX, 2011). Scrum - O Scrum master é o responsável por corrigir os desvios em relação ao planejado, mas no Scrum não há registros das ações e seu acompanhamento até a sua conclusão. 4.2 PROCESSO: GERÊNCIA DE REQUISITOS GRE Seu propósito é gerenciar requisitos do produto e dos componentes do produto, e identificar inconsistência entre os requisitos. O objetivo principal é controlar a evolução dos requisitos. Seu processo gerencia todos os requisitos recebidos ou gerados pelo projeto que são requisitos funcionais, não funcionais e os impostos ao projeto pela organização. Para assegurar que os requisitos são gerenciados, a organização deve executar um conjunto de passos apropriados. Ao receber requisitos de um fornecedor, estes devem ser revisados para resolver questões e promover o bom entendimento, antes da entrada do requisito no escopo do projeto. (SOFTEX, 2011).
Dentre outras atribuições da gerencia de requisitos, estão: documentar as mudanças nos requisitos e suas justificativas; manter a rastreabilidade bidiredicional e identificar inconsistências. (SOFTEX, 2011). GRE 1: o entendimento dos requisitos é obtido junto aos fornecedores de requisitos Garantir que os requisitos estejam claramente definidos a partir do entendimento realizado junto aos fornecedores. Os requisitos devem ser documentos para comprovar o entendimento. É importante garantir que a identificação de requisitos atenda às expectativas do cliente. Após avaliação dos requisitos, é necessário registrar o aceite dos fornecedores. (SOFTEX, 2011). Scrum- O Scrum master e o Product Owner são os responsáveis por garantir que os requisitos estejam claramente definidos para posterior entrada no Product backlog. GRE 2: os requisitos são avaliados com base em critérios objetivos e um compromisso da equipe técnica com estes requisitos é obtido Após o requisito ser aprovado pelo cliente, são necessários avaliação e comprometimento com a equipe técnica, esse comprometimento também deve ser registrado na forma de ata, e-mail ou algum outro mecanismo. É recomendável que os requisitos sejam submetidos à aprovação técnica antes de ser enviado para aprovação do cliente, evitando assim retrabalho, ou apresentação de um documento sem qualidade técnica. (SOFTEX, 2011). Scrum - O Product owner deve garantir o entendimento e a aprovação por parte do cliente e da equipe técnica. GRE 3: a rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida Estabelecer um mecanismo que permita rastrear a dependência entre os requisitos e os produtos de trabalho. A rastreabilidade facilita a avaliação de impacto das mudanças de requisitos, como: estimativas de escopo nos produtos de trabalho ou nas tarefas do projeto descritas no cronograma. (SOFTEX, 2011). Scrum - Não possui mecanismo de rastreabilidade. GRE 4: revisões em planos e produtos de trabalho do projeto são realizadas visando a identificação de inconsistência em relação aos requisitos Identificar inconsistência entre os requisitos e os demais elementos do projeto. Essas inconsistências devem ser registradas e ações corretivas executadas e acompanhadas até seu término. (SOFTEX, 2011).
Scrum - Durante a Sprint review, é realizada avaliação e disparadas ações corretivas, se necessárias. GRE 5: mudanças de requisitos são gerenciadas ao longo do projeto Poderá haver mudança dos requisitos durante o projeto, como: requisitos novos, retirados ou modificados no projeto. Essas mudanças devem ser registradas em um histórico de decisões de requisitos. Scrum - Mudanças de requisitos podem ser detectadas durante o planejamento e revisão da Sprint ou nas reuniões diárias. (SOFTEX, 2011). 5 CONCLUSÃO A adoção de metodologias ágeis vem crescendo cada vez mais, por serem de fácil implementação, porém falta documentação, o que é uma característica dos métodos ágeis. O modelo MPS.BR, possui documentação ampla e contempla todas as etapas do desenvolvimento. Como resultado deste trabalho pode perceber que é possível utilizar uma metodologia ágil com qualidade através de um modelo de maturidade. A integração entre Scrum e MPS.BR foi satisfatória e relativamente fácil de ser alcançada para o nível de maturidade G. O Scrum atendeu quase 100% em sua aderência ao modelo MPS.BR, o que não impede de serem implementados trazendo grandes ganhos no planejamento e qualidade do produto final. O Scrum fornece uma metodologia ágil, adequada para que se tenha ganho na produtividade. Seus principais benefícios são: Flexibilidade de resultados, flexibilidade de prazos, times pequenos, revisões frequentes e colaboração. Por ser de fácil entendimento e sua implantação é rápida. As reuniões diárias promovem o comprometimento da equipe com o projeto. O MPS.BR oferece um modelo e uma forma de avaliação de processos para garantir de forma coerente as suas definições, que estão dividas em níveis de maturidade de G até A, permitindo para a organização prever o seu desempenho futuro com base no nível de maturidade em que se encontra. Os seus processos são descritos em termos de propósitos e resultados. A maior dificuldade em realizar esse trabalho foi entender o modelo MPS.BR por ser um conteúdo extenso e estar dividido em vários documentos chamados de guias.
Para trabalhos futuros, sugere-se analisar a integração do Scrum com os demais níveis de maturidade do modelo MPS.BR e integração Scrum com o modelo XP.
INTEGRATING PROJECT MANAGEMENT WITH AGILE SCRUM AND MPS.BR PROCESSES LEVEL G ABSTRACT: With increasing dependence on technology in organizations for making decisions, there was a demand for more complex systems and, consequently, increased the risk of failed deliveries, hindering the release of products with the desired quality. These factors affect the organization's image, increase costs and extend the failure of existing projects. From a literature search, this paper describes how to integrate project management with Scrum agile method and process quality model MPS.BR facing the reality of the market for small and medium-sized software companies in Brazil. Keywords: MPS.BR, Scrum, Agile development.
REFERÊNCIAS BARTIÉ, Alexandre. Garantia da qualidade de software. Rio de Janeiro: Campus, 2002. CARVALHO, Bernardo Vasconcelos de. Aplicação do método ágil Scrum no desenvolvimento de produtos de software em uma pequena empresa de base tecnológica. 2009. Dissertação (Mestrado em Ciências em Engenharia de Produção) Universidade Federal de Itajubá, 2009. ECLIPSE. Concept: Story Points. Disponível em: <http://epf.eclipse.org/wikis/scrumpt/scrum/guidances/concepts/story_points_c511ca10.ht ml>. Acesso em: 23 abr. 2012. KNIBERG, Henrik. Scrum e XP direto das Trincheiras. Estados Unidos: C4Media, 2007. MARÇAL, Ana Sofia Cysneiros. SCRUMMI: Um processo de gestão ágil baseado no SCRUM e aderente ao CMMI. 2009. Dissertação (Mestrado em informática aplicada da Universidade de Fortaleza) Universidade de Fortaleza UNIFOR, 2009. SOFTEX, MPS.BR. Melhoria de Processo de Software Brasileiro, Guia de Aquisição: 2011 (Outubro de 2011). Disponível em: <www.softex.br/mpsbr/_guias/guias/mps.br_guia_de_aquisicao_2011.pdf>. Acesso em 12 mar. 2012. SOFTEX, MPS.BR. Melhoria de Processo de Software Brasileiro, Guia de Avaliação: 2011 (Maio de 2011). Disponível em: <http://www.softex.br/mpsbr/_guias/guias/mpsbr_guia_de_avaliacao_2011.pdf>. Acesso em 12 mar. 2012. SOFTEX, MPS.BR. Melhoria de Processo de Software Brasileiro, Guia Geral: 2011 (Agosto de 2011). Disponível em: <www.softex.br/mpsbr/_guias/guias/mps.br_guia_geral_2011.pdf>. Acesso em 12 mar. 2012. SOFTEX, MPS.BR. Melhoria de Processo de Software Brasileiro, Guia de Implementação Parte 1: Nível G: 2011 (Julho de 2011). Disponível em: <http://www.softex.br/mpsbr/_guias/guias/mpsbr_guia_de_avaliacao_2011.pdf>. Acesso em 12 mar. 2012. SOFTEX. Guias. Disponível em: <http://www.softex.br/mpsbr/_guias/default.asp>. Acesso em: 2 abr. 2012. VICTOR. Glossary of Scrum Terms. Disponível em: <http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms#1126>. Acesso em: 24 mar. 2012. VINÍCIUS. Sprint Planning Meeting. Disponível em: <http://improveit.com.br/scrum/sprint_planning_meeting>. Acesso em: 23 abr. 2012.