PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ PROGRAMA DE PÓS-GRADUAÇÃO ESPECIALIZAÇÃO MBA EM GESTÃO DE PROJETOS DE SOFTWARE

Transcrição

1 PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ PROGRAMA DE PÓS-GRADUAÇÃO ESPECIALIZAÇÃO MBA EM GESTÃO DE PROJETOS DE SOFTWARE DANIEL AIUB NUNES MARCO AURÉLIO DE FIGUEIREDO LOCKS RAFAEL HAYASHI VERIFICAR A ADEQUAÇÃO DO USO DA METODOLOGIA ÁGIL SCRUM PARA ATENDIMENTO DO NÍVEL G DO MPS.BR CURITIBA 2011

2 DANIEL AIUB NUNES MARCO AURÉLIO DE FIGUEIREDO LOCKS RAFAEL HAYASHI VERIFICAR A ADEQUAÇÃO DO USO DA METODOLOGIA ÁGIL SCRUM PARA ATENDIMENTO DO NÍVEL G DO MPS.BR Monografia apresentada ao Curso de MBA em Gestão de Projetos de Software, da Pontifícia Universidade Católica do Paraná, como requisito à obtenção do título de Especialista. Orientadora: Prof. Msc. Cristina Ângela Filipak Machado CURITIBA 2011

3 FICHA CATALOGRÁFICA Aiub Nunes, Daniel Hayashi, Rafael Locks, Marco Aurélio de Figueiredo VERIFICAR A ADEQUAÇÃO DO USO DA METODOLOGIA ÁGIL SCRUM PARA ATENDIMENTO DO NÍVEL G DO MPS.BR Curitiba, Área de concentração: Tecnologia da Informação Monografia (especialização) Pós-Graduação da Pontifícia Universidade Católica do Paraná, Curitiba, PR. Orientadora: Prof. Msc. Cristina Ângela Filipak Machado. 1. Metodologias ágeis; 2. Metodologias clássicas; 3. Scrum; 4. MPS.BR; 5. Qualidade; 6. Certificação

4 DANIEL AIUB NUNES MARCO AURÉLIO DE FIGUEIREDO LOCKS RAFAEL HAYASHI VERIFICAR A ADEQUAÇÃO DO USO DA METODOLOGIA ÁGIL SCRUM PARA ATENDIMENTO DO NÍVEL G DO MPS.BR Monografia apresentada ao Curso de MBA em Gestão e Projetos de Software, da Pontifícia Universidade Católica do Paraná, como requisito à obtenção do título de Especialista. COMISSÃO EXAMINADORA Prof. Msc Pontifícia Universidade Católica do Paraná Prof. Msc Pontifícia Universidade Católica do Paraná Prof. Msc Pontifícia Universidade Católica do Paraná Curitiba, de de 2011.

5 A todos os nossos familiares e amigos pelo apoio e compreensão em nossos momentos de ausência em função deste trabalho... Dedico

6 AGRADECIMENTOS Agradecemos a princípio a Deus, que nos permitiu a inteligência. À nossa orientadora, Prof. Msc. Cristina Ângela Filipak Machado, pela dedicação nas correções e orientações neste período de aprendizado.

7 Para aprender é preciso passar por situações emocionantes. Para isso é preciso tirar as pessoas de suas rotinas físicas e mentais. Não aprendemos nada dentro de nossas zonas de conforto, sentados todos os dias, no mesmo lugar, na mesma mesa, fazendo a mesma coisa, onde tudo é previsível. Na zona de aprendizado há uma dose de desconforto e as emoções são intensificadas. Ernest Shackleton

8 LISTA DE ILUSTRAÇÕES Figura 1 - Camadas da Engenharia de Software...20 Figura 2 - Áreas de abrangência do gerenciamento de sistemas...21 Figura 3 - Componentes do Modelo MPS...27 Figura 4 - Estrutura de Níveis de Maturidade...28 Figura 5 - Visão geral do Scrum...53 Figura 6 - Papéis, responsabilidades e eventos do Scrum...54 Figura 7 - Burndown Chart em horas...58 Figura 8 - Burndown Chart de tarefas...59 Figura 9 - Exemplo de Product Vision Box...66 Figura 10 - Organização de uma FBS...69 Figura 11 - Plano de release...72 Figura 12 - Planning Poker...75 Figura 13 - Quadro Kanban...77 Figura 14 - Agile System Development Life Cycle...80 Figura 15 - Agile System Development Life Cycle (detailed)...82 Figura 16 - Scrum Board...84 Figura 17 - Resumo do mapeamento entre o processo GPR do MPS.BR e Scrum...99 Figura 18 - Resumo do mapeamento entre o processo GRE do MPS.BR e Scrum Quadro 1 - Níveis de maturidade e processos do MPS.BR...29 Quadro 2 - Exemplo de Product Backlog...57 Quadro 3 - Resultados retrospectiva...64 Quadro 4 - Estrutura de uma Elevator Statement...67 Quadro 5 - Exemplo de Elevator Statement...68 Quadro 6 - Project Data Sheet...71 Quadro 7 - Estrutura de uma User Story...73 Quadro 8 - Exemplo da composição de uma feature...74 Quadro 9 - Modelo simplificado de matriz de rastreabilidade...78

9 LISTA DE ABREVIATURAS E SIGLAS AP Atributos de Processo CMMI Capability Maturity Model Integration DOD Definition of Done EAP Estrutura Analítica do Projeto FBS Feature Breakdown Struture GPR Gerência de Projetos GRE Gerência de Requisitos MA Metodologias Ágeis MA-MPS Método de Avaliação de Melhoria de Processo de Software MN-MPS Modelo de Negócio de Melhoria de Processo de Software MR-MPS Modelo de Referência de Melhoria de Processo de Software MPS.BR Melhoria do Processo de Software Brasileiro PDS Project Data Sheet PMBOK Project Management Body of Knowledge RAP Resultados de Atributos de Processo ROI Return Of Investment RUP Rational Unified Process SEI Software Engineering Institute TI Tecnologia da informação TOC Theory Of Constraints XP Extreme Programming

10 SUMÁRIO 1 INTRODUÇÃO DESENVOLVIMENTO DE SOFTWARE OBJETIVO ESTRUTURA REVISÃO DE LITERATURA MPS.BR Introdução Estrutura Descrição Descrições dos processos Nível G Gerência de projetos Gerência de requisitos Nível F Aquisição Gerência de configuração Garantia da qualidade Gerência de Portfólio de Projetos Medição Nível E Avaliação e Melhoria do Processo Organizacional Definição do processo organizacional Gerência de recursos humanos Gerência de reutilização Gerência de projetos (evolução) Nível D Desenvolvimento de requisitos Integração do produto Projeto e construção do produto...44

11 Validação Verificação Nível C Desenvolvimento para reutilização Gerência de decisões Gerência de riscos Nível B Gerência de projetos (evolução) Nível A METODOLOGIAS ÁGEIS Scrum Papéis e responsabilidades Product Owner O Scrum Master O Time Artefatos Product Backlog Sprint Backlog Burndown Chart Eventos Sprint Planning Meeting Daily Standup Meeting Sprint Review Meeting Sprint Retrospective Meeting Boas práticas utilizadas no Scrum Product Vision Box Elevator Statement Feature Breakdown Structure Project Data Sheet Plano de Release User Stories Planning Poker...75

12 Quadro Kanban Matriz de Rastreabilidade Iniciando o Scrum ANÁLISE E MAPEAMENTO DO SCRUM NO NÍVEL G DO MPS.BR ANÁLISE E MAPEAMENTO DO SCRUM NO PROCESSO DE GERÊNCIA DE PROJETOS DO NÍVEL G DO MPS.BR GPR1 O Escopo do trabalho para o projeto é definido GPR2 As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados GPR3 O Modelo e as fases do ciclo de vida do projeto são definidos GPR4 (Até o nível F) 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 GPR5 O orçamento e o cronograma do projeto, incluindo a definição de marcos e pontos de controle, são estabelecidos e mantidos GPR6 Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados GPR7 Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo GPR8 Os recursos e o ambiente de trabalho necessários para executar o projeto são planejados GPR9 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 GPR10 Um plano geral para a execução do projeto é estabelecido com a integração de planos específicos GPR11 A viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis, é avaliada. Se necessário, ajustes são realizados GPR12 O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido GPR13 O projeto é gerenciado utilizando-se o Plano do Projeto e outros planos que afetam o projeto e os resultados são documentados GPR14 O envolvimento das partes interessadas no projeto é gerenciado GPR15 Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento...97

13 GPR16 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 interessadas GPR17 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 Resumo do mapeamento entre o processo GPR do MPS.BR e Scrum ANÁLISE E MAPEAMENTO DO SCRUM NO PROCESSO DE GERÊNCIA DE REQUISITOS DO NÍVEL G DO MPS.BR GRE1 Os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de requisitos, utilizando critérios objetivos GRE2 O comprometimento da equipe técnica com os requisitos aprovados é obtido GRE3 A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida GRE4 Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos GRE5 Mudanças nos requisitos são gerenciadas ao longo do projeto Resumo do mapeamento entre o processo GRE do MPS.BR e Scrum CONCLUSÕES REFERÊNCIAS...112

14 RESUMO Esta monografia tem como objetivo principal propor uma maneira de cumprir as exigências do Modelo de Maturidade MPS.BR nível G utilizando a Metodologia Ágil Scrum e identificar a necessidade de adaptar o seu modo de trabalho, caso necessário. A proposta do trabalho, busca agregar princípios e valores de novas metodologias e boas práticas, que ganham mais espaço diante do mercado atual de software, às orientações do Modelo de Maturidade MPS.BR, embasado em diversas boas práticas utilizadas no desenvolvimento de software. O estudo também se propõe em mapear o ciclo de vida proposto pelo Scrum dentro do primeiro nível do MPS.BR e evidenciar o potencial das Metodologias Ágeis no gerenciamento de um projeto. Como resultado desse gerenciamento híbrido, Metodologia Ágil regida por modelo de maturidade, empresas que desenvolvem software podem melhorar seus processos e poderão obter uma certificação que as tornará mais competitivas. Embora esse resultado seja o mais previsível, outros benefícios estão agregados ao desenvolvimento que segue bases rígidas de gerenciamento, o produto final terá qualidade a partir de processos maduros que garantem um desenvolvimento que privilegia a qualidade. Vale ressaltar que o MPS.BR possui outros níveis de maturidade, portanto os benefícios que a conjugação do MPS.BR e do Scrum não ficam restritos ao âmbito deste trabalho. Outros trabalhos que abordarem este tema, a análise que o estudo apresentado descreve, pode servir de apoio a investigações de como cumprir as exigências dos níveis seguintes do MPS.BR, uma vez que os níveis são cumulativos. Considerando que as Metodologias Ágeis são flexíveis e é possível propor inúmeras maneiras de utilizá-las, os estudos nessa temática apontam que é possível a combinação entre Scrum e MPS.BR, porém uma organização que deseje adotá-los, deve estar primeiramente disposta a enfrentar uma constante mudança cultural, exigida na adoção de qualquer nova boa prática. Palavras-chave: Metodologias ágeis. Metodologias tradicionais. Scrum. MPS.BR. Qualidade. Certificação.

15 ABSTRACT The main objective of this work is to suggest a way to achieve the goals of the G level of the MPS.BR Maturity Model using the Scrum Agile Methodology and to identify the need to adapt its work structure, if necessary. This work purposes a way to join the principles and values of new methodologies that are becoming commonly used by the current software market to the good practices used by the orientation of the MPS.BR Maturity Model. Another purpose of this work is to map the Scrum lifecycle on the first level of MPS.BR and puts on evidence the potential of Agile Methodologies on the management of a project. As a result of this hybrid way of manage projects (Agile Methodology guided by an maturity model) companies can use it to acquire better process and could achieve an certification that will make them more competitive on the software development market. While this is the most predictable result, there are other benefits that a development process based on solid management practcies brings to the organization. The result is a product with better quality that comes from a better development process focused on quality. It is noteworthy that MPS.BR has other levels of maturity to be achieved, so the benefits are not restricted to the scope of this work. Future works that wil explores the next levels of MPS.BR can use this work as a starting point, since the levels are cumulative. Considering that Agile Methodologies are flexible and its practices able to be used in many ways, studies that approaches this theme points that it is possible to combine Scrum and MPS.BR but an organization that intents to use it must be prepared to face constant cultural change, required by the adoption of any other good practice on software development. Keywords: Scrum, Agile Methodologies, MPS.BR, Maturity Model, Quality, Certification, Traditional Methodologies.

16 16 1 INTRODUÇÃO 1.1 DESENVOLVIMENTO DE SOFTWARE A Tecnologia da Informação (TI) dentro das empresas assumiu um papel de ativo fundamental no novo padrão de competitividade que impera atualmente. A TI é vista como necessidade de negócio, se a TI parar, o negócio da empresa também pára. Conforme Pressman (2002, p. 3): O software de computadores tornou-se uma força motora. É o motor que dirige a tomada de decisão nos negócios. Serve de base à moderna investigação científica e às soluções de problemas de engenharia. É um fator chave que diferencia os produtos e serviços modernos. Está embutido em sistemas de todas as naturezas: de transportes, médicos, de telecomunicações, militares, de processos industriais, de produtos de escritório..., a lista é quase sem fim. O software é virtualmente inevitável no mundo moderno (...) irá se tornar um motor para novos avanços em tudo, da educação elementar à engenharia genética. Atualmente a competitividade depende da criação e renovação de vantagens competitivas relacionadas ao aprendizado, a qualidade dos recursos humanos e a capacitação produtiva da empresa. Baseia-se principalmente na construção de um modelo que permita adquirir conhecimento e inovação. A eficiência interna, a capacidade de operação, a habilidade em oferecer produtos e serviços, a agilidade e a flexibilidade, assim como outras vantagens competitivas são fortemente influenciadas pelos sistemas de TI. O desenvolvimento de sistemas de TI, denominados softwares, está cada vez mais presente entre as prioridades das organizações. Os projetos de desenvolvimento de software são similares ao desenvolvimento de um novo produto, são gerenciadas na forma de projetos e os resultados exercem influência direta no sucesso das organizações. É utilizado durante o desenvolvimento do software práticas e princípios da engenharia, o que ficou conhecido como Engenharia de Software, de acordo com Bauer (apud PRESSMAN, 2002, p. 18) engenharia de software é a criação e a utilização de sólidos princípios de engenharia a fim de obter software de maneira econômica, que seja confiável e que trabalhe eficientemente em máquinas reais. Por esse motivo é possível reconhecer que desenvolver um produto, nesse contexto,

17 17 está relacionado em seguir certos passos e muitas vezes basear-se nas melhores maneiras de realizar certas tarefas de acordo com procedimentos adotados por outros. Esse modo de trabalho faz com que a empresa ganhe tempo, não reinventando a roda e sim a aperfeiçoando. O objetivo é estabelecer um modelo, que concentre os passos para desenvolver um bom projeto, para que seja conseguida através da aplicação desse modelo a alta qualidade do software. Por isso, na engenharia de software temos modelos que segundo o Dicionário Aurélio (1995, p. 337), são definidos por: [...] coisa cuja imagem serve para ser reproduzida [...] aquilo que serve de exemplo ou norma; molde [...] aquele que se pretende imitar nas ações, no procedimento, nas maneiras [...] ato que por sua importância ou perfeição é digno de servir de exemplo [ ] conjunto de hipóteses sobre a estrutura ou o comportamento de um sistema físico pelo qual se procuram explicar ou prever, dentro de uma teoria cientifica, as propriedades do sistema. Os modelos na engenharia de software são uma representação genérica, que visa ilustrar em um gráfico o ciclo de vida do software, definidos por determinada metodologia para melhor descrever e explicar o encadeamento de seus processos. Segundo Thomsett (2002 apud DIAS, 2005, p. 9): Os projetos de desenvolvimento de software têm duas vertentes, uma técnica e outra gerencial [...] muita atenção foi dada ao aprimoramento dos modelos de desenvolvimento de software (ênfase técnica), ficando o componente gerencial relegado a segundo plano. A melhoria de âmbito gerencial ocorreu com a publicação dos modelos de maturidade criados pelo SEI Software Engineering Institute, para promover o amadurecimento das organizações no processo de desenvolvimento de software. Modelos estes bastante alinhados ao gerenciamento clássico de software. Fato que animou as empresas em investir na adoção das práticas de gerenciamento de projetos visando a uma melhoria no desempenho de seus projetos. Apesar do crescimento acelerado do desenvolvimento de software muitas empresas especializadas em desenvolvimento encontram dificuldades em seus projetos para alcançar níveis satisfatórios de lucratividade e de vendas, também reportam problemas quanto à qualidade dos produtos, ao cumprimento de prazos e dos custos dos projetos de desenvolvimento de software. Organizações que não tem o desenvolvimento de software como atividade principal também passam pelos mesmos problemas.

18 18 Em vista dos resultados abaixo do esperado obtidos com o uso dos métodos tradicionais de desenvolvimento, gerenciados de acordo com os princípios do gerenciamento clássico de projetos, uma nova abordagem foi criada para o desenvolvimento de software. Primeiramente a resposta para um melhor desempenho dos projetos veio no âmbito técnico propondo alternativas aos métodos convencionais de desenvolvimento de software utilizados, os chamados Métodos Ágeis de desenvolvimento, que têm como foco o atendimento das expectativas e das necessidades do cliente, a entrega rápida e uma forte absorção da mudança. Faz parte dos métodos ágeis o Scrum, que é objeto de estudo nesse trabalho. Na vertente gerencial temos o Gerenciamento Ágil de Projetos, que possui valores como priorizar a entrega de produto à entrega da documentação, a colaboração ao invés da negociação de contratos, maior valor ao indivíduo e suas interações aos processos e ferramentas. Contudo o produto deve ser entregue dentro do prazo, custo e qualidade. Segundo Brasil (2005a apud DIAS, 2005, p. 14) no Brasil o segmento de software ainda é visto com especial atenção pelo governo, por seu grande potencial de geração de empregos e por sua capacidade de absorção de mão-de-obra jovem, recém-saída das universidades. Porém, concorrer no mercado de software interno não é tão simples. O desenvolvimento das Fábricas de Software aqui no Brasil precisa adquirir um padrão de competitividade que seja relacionado a uma imagem de desenvolvimento sustentado pela maturidade de processos alcançada através de certificação. Conforme Dias (2005), a Índia conseguiu vincular a imagem de maturidade a seus softwares e por isso foi bem sucedida nacional e internacionalmente mesmo sendo um país emergente. Uma visão de sucesso nesse contexto seria utilizar Métodos Ágeis de desenvolvimento. A agilidade pode ser tomada como um diferencial, porque torna a Fábrica de Software atual para o mercado. A agilidade contribui no gerenciamento de um projeto oferecendo aos desenvolvedores de software uma forma de melhor atender a expectativa dos clientes durante o gerenciamento do projeto. Como os princípios da agilidade estão voltados para a absorção da mudança, a fábrica que utiliza processos ágeis acompanhará da melhor forma o mercado, que possui alta incerteza em relação a sua necessidade por soluções de TI e consequentemente se apresenta em constante mudança.

19 19 Uma ousadia, não tão incomum, é utilizar princípios dos Métodos Ágeis em conformidade com um Modelo de Maturidade que segue o Método Clássico de desenvolvimento. Nesse cenário está o MPS.BR Melhoria do Processo de Software Brasileiro, desenvolvido pelo SOFTEX, e compatível com a realidade do mercado nacional de software. É possível encontrar na internet casos de sucesso de empresas que atingiram maturidade para uma certificação do MPS.BR. Essa monografia limita-se a estudar o nível G em razão de ser o nível de maior aderência das empresas relacionadas pela SOFTEX, hoje existem 121 empresas certificadas no nível G. Como nível inicial do MPS.BR, o estudo do nível G presente neste trabalho demonstra que a sua adoção e implementação é mais fácil do que pensam muitos empreendedores, e os benefícios de processos maduros já no nível G podem desencadear em uma Fábrica de Software o interesse para a implementação dos demais níveis do MPS.BR. Seguindo essa mesma ideologia encontram-se inúmeras publicações em que os autores apresentam conjugadas à utilização das práticas do gerenciamento ágil de projetos no desenvolvimento de software conduzido segundo os Métodos Clássicos. Dessa forma será abordado o método de maturidade MPS.BR no decorrer do trabalho, que foi baseado em Métodos Clássicos visando a melhoria do processo de software brasileiro, como o acrônimo já diz. O MPS.BR reúne atributos que aconselham como conduzir o gerenciamento de um projeto de modo que o produto final apresente qualidade que foi agregada através de melhores práticas que determinarão um padrão para o planejamento da qualidade em uma empresa de desenvolvimento de software. A qualidade do software depende principalmente do correto emprego de metodologias. De acordo com Pressman, metodologia está vinculada com processo, que é o fundamento da engenharia de software. O processo é o que relaciona o método com a qualidade, porque define uma estrutura para áreas principais do projeto. Ao obter as áreas principais visualiza-se o controle gerencial de projetos. A partir desse passo é possível estabelecer o contexto no qual os métodos são aplicados, os produtos de trabalho como os modelos, documentos, dados, relatórios e formulários são produzidos, marcos são estabelecidos, qualidade é assegurada e modificações são geridas. Na figura abaixo temos a figuração das ferramentas, o

20 20 que auxilia nas tarefas dos métodos. Durante o projeto o desenvolvimento ou adoção de ferramentas auxilia na automatização de tarefas, o que diminui a carga de trabalho de pessoas e faz com que a tarefa produza sempre o mesmo resultado contribuindo na qualidade final. Figura 1 - Camadas da Engenharia de Software Fonte: Adaptado de Pressman (2002, p. 19). Pressman (2002, p. 21) define o que pode ser compreendido como a estrutura de um processo: [...] uma estrutura comum de processo é estabelecida definindo um pequeno número de atividades dessa estrutura, que são aplicáveis a todos os projetos de software, independentemente de seu tamanho ou complexidade. Um certo número de conjuntos de tarefas [ ] marcos de projeto, produtos do trabalho e pontos de garantia de qualidade permite que as atividades da estrutura sejam adaptadas às características do projeto de software e as necessidade da equipe de projeto. Segundo a Figura 1, a camada que dá apoio a engenharia de software é um enfoque na Qualidade. Para Pressman é importante definir o que quer dizer qualidade de software, é possível definir esse termo começando pela criação de um conjunto de atividades que ajudarão a garantir que todo o produto de trabalho de engenharia de software exiba alta qualidade, como realizar atividade de garantia da qualidade em todo o projeto de software e usar métricas para desenvolver estratégias para aperfeiçoar os processos de software e, como consequência, obter a qualidade do produto final. Um exemplo de modelo de maturidade que fornece uma abordagem aos conceitos de qualidade para a Engenharia de Software é citado o MPS.BR durante essa monografia. A Figura 2 ilustra a delimitação dos assuntos que estão presentes nessa monografia e permite esclarecer em que parte do gerenciamento de sistemas os assuntos que serão abordados estão presentes. Este trabalho trata de assuntos

21 21 relacionados ao desenvolvimento de software em uma fábrica de software, portanto o Scrum e o MPS.BR estão presentes nas elipses. Figura 2 - Áreas de abrangência do gerenciamento de sistemas Fonte: Adaptado de WG 7 Strategy - Starting Point and Discussion (2010, s. 8). O MPS.BR apresenta 7 níveis de maturidade progressivos, que começa pelo nível G e encerra no nível A. Os níveis de maturidade são alcançados após uma avaliação de alguns projetos desenvolvidos, os quais a empresa julga estarem de acordo com os propósitos e a todos os resultados esperados de um determinado processo e também aos níveis de capacidade do processo. Ao final da implementação de cada nível de maturidade é possível adquirir um certificado para uma empresa do tipo Fábrica de Software, ou seja, uma empresa totalmente voltada ao desenvolvimento de software. Os detalhes a respeito do nível G, como os processos e seus resultados esperados serão descritos no decorrer da monografia. Entretanto, não será discutido detalhes da avaliação para se obter a certificação, como os níveis de capacidade dos processos, que são os Atributos de Processo (AP) e seus respectivos Resultados de Atributos de Processo (RAP), assuntos de extrema importância quando a empresa se sujeita à uma avaliação. Essa limitação da monografia em não aprofundar a avaliação dos resultados esperados por meio dos AP foi proposta porque esse trabalho visa o principal benefício que o MPS.BR traz a empresa, que

22 22 não é o papel dizendo que a empresa é certificada, mas sim a adoção de processos maduros e a execução de atividades ágeis visando sempre a melhoria contínua do modo de trabalho da Fábrica de Software. Apesar de não apresentar os meios para atingir seus Níveis de Maturidade, os documentos do MPS.BR provêem um guia de trabalho para uma instituição que deseje atingir os resultados propostos em cada nível do MPS.BR. Visto que cada empresa, equipe ou profissional pode propor uma ação de gestão peculiar diante da sua realidade em um projeto, o que permite afirmar que existe uma variabilidade infinita de meios para atingir os níveis do MPS.BR. Conforme o guia esclarece [...] as atividades e tarefas demandadas para atender ao propósito e aos resultados esperados devem ficar sobre a incumbência dos usuários do MR-MPS (Modelo de Referência do MPS.BR), por essa razão não estão presentes em nenhum guia (SOFTEX, 2009). Durante este trabalho foi investigado o modo de trabalho de equipes que utilizam o Scrum, e percebido que além do Scrum, são utilizadas diversas boas práticas que complementam principalmente as etapas de visão do produto, definição de escopo, bem como o levantamento e a análise dos requisitos, conforme apresentadas no Capítulo 2. Visto que o Scrum pode ser adaptado à realidade de uma empresa, será investigado a possibilidade de estabelecer dentro dos princípios do Scrum uma abordagem que permita cumprir a exigência do nível G do MPS.BR. Os frameworks por si também não dizem como fazer ou como agir em determinada situação, por isso cada equipe trabalha de diferentes maneiras diante das circunstâncias do projeto. Entretanto, frameworks como o Scrum visam adaptar-se à mudança e a melhoria contínua do processo de trabalho, o que favorece o surgimento de novas idéias à equipe de como as Metodologias Ágeis (MA) poderiam ser mais bem aplicadas a contextos específicos. É um aprendizado constante. Segundo os princípios das MA percebe-se com maior nitidez que agilidade não é ausência de processos e ferramentas, e seu uso deve ser equilibrado e apropriado em cada situação. É notado também que isso ocorre principalmente ao entender como outras equipes aplicam as MA no processo de desenvolvimento de software, ou seja, reconhecer uma boa prática e em qual situação ela foi aplicada para se tornar bem sucedida.

23 23 A harmonia entre o modo de trabalho do Scrum e do modelo MPS.BR trará como benefício a aquisição de processos disciplinados com tendência a amadurecerem e se moldarem às preferências do modo de trabalho de uma organização a longo prazo. A versatilidade do Scrum em ser adaptado às necessidades do projeto traduz-se em agilidade e eficiência para absorver as mudanças que surgirem, bem como imprevistos durante o projeto. Além da certificação do processo de desenvolvimento guiado pelo modelo de maturidade, tornando a empresa de desenvolvimento mais alinhada aos padrões nacionais e internacionais, refletindo em um fator vital para o crescimento da empresa. 1.2 OBJETIVO Os objetivos primários desse trabalho são: a) descrever o modelo de maturidade MPS.BR nível G; b) descrever os princípios do Scrum; c) mapear o momento em que o ciclo de vida do Scrum e as práticas ágeis atendem a determinada exigência do nível G; d) identificar a necessidade do Scrum ser modificado ou complementado para atender a determinada exigência do nível G. Como objetivos secundários da pesquisa, podem ser citados: a) investigar os mitos em relação a MA, e mostrar que é um método que têm muito potencial no mercado atual de software; b) evidenciar as vantagens que a agilidade agrega ao Gerenciamento de Projetos; c) incentivar aos alunos de graduação e demais interessados, ou seja, potenciais empreendedores, a utilizarem o Scrum e familiarizá-los com o MPS.BR, desmistificando os modelos de maturidade como superfluos e inalcançáveis para uma empresa de software.