Implementando maturidade e agilidade em uma fábrica de software através de Scrum e MPS.BR nível G

(1)

Implementando maturidade e agilidade em uma fábrica de

software através de Scrum e MPS.BR nível G

Fernando Szimanski1, Jones Albuquerque2, Felipe Furtado2

1_{CRIATIVA tecnologia - 77.410-020 - Gurupi - TO - Brasil}

2_{C.E.S.A.R - Centro de Estudos e Sistemas Avançados do Recife - 50.030-390 - Recife}

- PE - Brasil

{fszimanski, jones.albuquerque}@gmail.com, felipe.furtado@cesar.org.br

Abstract. Introduce agile concepts into software processes looking a balance

between flexibility and maturity is an alternative capable of improving the quality of products and, therefore, increased competitiveness in the market. This paper presents the extension of the agile method Scrum in the process areas of MPS.BR level G applied in a small software factory. This is useful for organizations that have the intention to adopt agile practices in the software process maintaining compatibility with the MPS.BR.

Key-words: Agile methodologies, Scrum, MPS.BR, Project Management,

Requirements Management.

Resumo. Introduzir conceitos ágeis em processos de software buscando um

equilíbrio entre agilidade e maturidade é uma alternativa capaz de promover a melhoria da qualidade dos produtos e, conseqüentemente, aumento da competitividade no mercado. Este trabalho apresenta a extensão da metodologia ágil Scrum para as áreas de processo do MPS.BR nível G aplicada em uma pequena fábrica de software. A extensão realizada neste trabalho pode contribuir de forma relevante para organizações que têm o propósito de adotar práticas ágeis no seu processo de software mantendo a compatibilidade com o MPS.BR.

Palavras-chave: Metodologias Ágeis, Scrum, MPS.BR, Gerenciamento de projetos,

Gerenciamento de requisitos.

1. Introdução

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 REF8 (2004) REF11 (2006) REF12 (2008), 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 REF3 (2006).

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

(2)

SZIMANSKI, Fernando, ALBUQUERQUE, Jones, FURTADO, Felipe. Implementando maturidade e agilidade em uma fábrica de software através de Scrum e MPS.BR nível G. In: XI Encontro de Estudantes de Informática do Tocantins, 2009, Palmas. Anais do XI

Encontro de Estudantes de Informática do Tocantins. Palmas: Centro Universitário Luterano de Palmas, 2009. p. 161-170.

Disponível em: http://tinyurl.com/yzrxyy4

promover a melhoria da qualidade dos seus produtos e, conseqüentemente, aumento da competitividade no mercado REF5 (2008).

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

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 avaliando os resultados esperados do guia segundo as práticas do Scrum e partir do mesmo a extensão é 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 buscando avaliar os primeiros resultados obtidos com o uso desta abordagem.

Além do capítulo introdutório, este trabalho está organizado da seguinte forma: na Seção 2 é apresentada uma visão geral do MPS.BR; na Seção 3 apresenta-se o Scrum; na Seção 4 é descrito o mapeamento entre o Scrum e o MPS.BR; na Seção 5 é proposta a extensão de práticas complementares para o atendimento do guia MPS.BR; na Seção 6 é realizada a adaptação da extensão proposta em uma fábrica de software; a Seção 7 apresenta-se o estudo de caso com os primeiros resultados obtidos com o uso desta nova abordagem. Finalmente, através da Seção 8, apresenta-se conclusão deste trabalho.

2. 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, de forma a atender as suas necessidades de negócio e também, ser reconhecido nacional e internacionalmente como um modelo aplicável à indústria de software REF7 (2007).

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 REF7 (2007)

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.

3. 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 REF6 (2008).

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

(3)

reintroduz as idéias de flexibilidade, adaptabilidade e produtividade REF2 (2002). Ela se baseia em princípios como: equipes pequenas, requisitos pouco estáveis ou desconhecidos e iterações curtas. Divide as iterações em intervalos de tempos de, no máximo 30 dias, também chamadas de Sprints.

Segundo REF2 (2009) o Scrum define para sua estrutura iterativa incremental três papéis principais para diferentes responsabilidades: Scrum Master, Product Owner e o Team e se o seu ciclo de desenvolvimento é baseado em três fases principais: Pregame, Game e Postgame REF1 (2009).

4. Mapeando o Scrum para as áreas de processo do MPS.BR nível G

Para cada área de processo do MPS.BR nível G foi realizada uma análise detalhada entre os resultados esperados do MPS.BR e as práticas encontradas no Scrum, classificando cada resultado esperado de acordo com os critérios estabelecidos na Tabela 1.

Tabela 3. Critérios para classificação das áreas de processo.

CLASSIFICAÇÃO CRITÉRIO

NS Não Satisfeito Não há evidências da prática na metodologia

PS Parcialmente Satisfeito Há evidências da prática na metodologia, embora a prática _{não esteja plenamente atendida.}

S Satisfeito A prática está totalmente atendida na Metodologia.

O mapeamento detalhado apresentando e pontos que o Scrum satisfaz ou não os resultados esperados do MPS.BR nível G (Gestão de projetos e Gerenciamento de requisitos) por ser encontrado em REF9 (2006).

O processo de gestão de projetos (GPR) é composto por dezessete resultados esperados e o resumo da análise para este processo é apresentado na Tabela 2.

Tabela 4. Resumo do mapeamento entre Scrum e área de GPR.

MPS.BR - Nível G SCRUM

ÁREA DE

PROCESSO ABREV. OBJETIVOS CLASSIFICAÇÃO

RESUMO DAS PRÁTICAS G E S T Ã O D E P R O JE T O S (G P R )

GPR1 Escopo do trabalho SATISFEITO Elaboração da Visão do Produto e Definição dos Itens de Backlog (IBL) GPR2 Dimensionamento de tarefas e produtos de

trabalho

PARCIALMENTE

SATISFEITO Estimativas através de Story Points

GPR3 Modelo e as fases do ciclo _{de vida do projeto} SATISFEITO

Iterativo incremental. Fases: Pregame, Game e Postgame

GPR4

Estimativa de esforço e o custo baseado em dados históricos ou referências técnicas PARCIALMENTE SATISFEITO Retorno sobre o Investimento (ROI), Estimativas através de Story Points e divisão de IBL’s em tarefas GPR5 O orçamento e o _{cronograma do projeto} PARCIALMENTE _SATISFEITO Planejamento de Sprints e Estimativas através de

Story Points

GPR6 Riscos do projeto SATISFEITO Daily Meetings,

(4)

responsabilidades do

Scrum Master

GPR7 Planejamento de recursos _humanos SATISFEITO

Definição dos Recursos humanos (Time,

Product Owner, Scrum Master) baseado no

perfil GPR8 Planjeamento das tarefas, os recursos e o ambiente de

trabalho

SATISFEITO Itens adicionais ao Product Backlog e

Tarefas da Sprint (Task)

GPR9

Planejamento de dados relevantes do projeto (armazenamento, privacidade e segurança)

NÃO SATISFEITO PRÁTICA NÃO MENCIONADA NO SCRUM

GPR10 Planos para a execução do _projeto SATISFEITO

Visão do Produto,

Product Backlog, Sprint Backlog, Sprint

planning 1 e 2 e Daily meeting

GPR11 Avaliação de viabilidade de _{atingir as metas do projeto} SATISFEITO

Sprint Planning (1 e 2) e

Definição do objetivo da iteração na elaboração do Sprint Backlog GPR12 Revisão e compromisso

com o Plano do Projeto SATISFEITO

Sprint Planning (1 e 2) e Daily meeting

GPR13 Monitoramento d progresso

do projeto SATISFEITO

Product Burndown, Sprint Burndown, Daily Review e Retrospective Meeting

GPR14 Gerenciamento do _{envolvimento das partes} interessadas no projeto

SATISFEITO

Daily Scrum Meeting, Sprint Review Meeting e Sprint Retrospective Meeting

GPR15

Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento

SATISFEITO Sprint Review Meeting

GPR16 Identificação e registros de _problemas SATISFEITO Daily Scrum Meeting e

Impediment Backlog

GPR17 Ações para corrigir e _{prevenir desvios em relação} ao planejado

SATISFEITO

Daily Scrum Meeting, Impediment Backlog e Retrospective Meeting

O processo de gerenciamento de requisitos (GRE) é composto por cinco resultados esperados e o resumo da análise para este processo é apresentado na Tabela 3.

(5)

Tabela 3. Resumo do mapeamento entre Scrum e área GRE

MPS.BR - Nível G ÁREA DE

PROCESSO ABREV. OBJETI

G E RE N CI A M E N T O D E RE Q U IS IT O S (G RE )

GRE1 Entendimento dos _requisitos

GRE2 Aprovação de requisitos

GRE3 A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho GRE4 Revisões em plano produtos de trabalho do projeto

GRE5 Gerenciamento de _{mudanças nos requisitos}

4.1. Resultado do mapeamento

Este comparativo entre o Scrum

objetivo mapear o alinhamento e a conformidade entre eles. A partir deste mapeamento descobrimos que o Scrum

apresentado na Figura 1.

Figura

O resultado obtido no mapeamento

algumas lacunas e atividades ausentes no Scrum que são apresentadas na extensão realizada neste trabalho (seção 5).

5. Estendendo o Scrum para o MPS.BR nível G

Para as lacunas e atividades ausentes no resultados esperados classificados como “ algumas soluções complementares

na extensão seguinte:

5.1. GAP1 - lacunas na definição de um método apropriado de complexidade ou tamanho para as tarefas e os produtos de trabalho do projeto, impactando diretamente o GPR2.

Satisfeito

Parcialmente Satisfeito Não Satisfeito

Tabela 3. Resumo do mapeamento entre Scrum e área GRE

Nível G SCRUM

OBJETIVOS CLASSIFICAÇÃO RESUMO DAS PRÁTICAS Entendimento dos

requisitos SATISFEITO

Visão do produto, Definição de Itens de Backlog

tarefas da Sprint Aprovação de requisitos SATISFEITO

Aprovação de Business Value de requisitos (ROI) e Planning (1 e 2) A rastreabilidade bidirecional entre os

requisitos e os produtos de NÃO SATISFEITO PRÁTICA NÃO MENCIONADA NO SCRUM Revisões em planos e

produtos de trabalho do SATISFEITO Daily Scrum Meeting e Sprint Review Meeting

Gerenciamento de

mudanças nos requisitos SATISFEITO

Sprint Planning (1 e 2), Daily Scrum Meeting e Sprint Review Meeting

Resultado do mapeamento

Scrum e as áreas de processo do MPS.BR nível G, teve por objetivo mapear o alinhamento e a conformidade entre eles. A partir deste mapeamento

não satisfaz totalmente o nível do G do MPS.BR

Figura 28. Resultado Geral da Avaliação.

O resultado obtido no mapeamento se deve a diversos fatores

algumas lacunas e atividades ausentes no Scrum que são apresentadas na extensão (seção 5).

tendendo o Scrum para o MPS.BR nível G

Para as lacunas e atividades ausentes no Scrum denominadas “GAP resultados esperados classificados como “Parcialmente Satisfeito” e “

complementares foram adicionadas ao processo conforme

acunas na definição de um método apropriado de complexidade ou tamanho para as tarefas e os produtos de trabalho do projeto, impactando

0% 20% 40% 60% 80% 100% GPR GRE Satisfeito 76% 80% Parcialmente Satisfeito 18% 0% Não Satisfeito 6% 20%

RESUMO DAS PRÁTICAS Visão do produto, Definição de

Backlog e elaboração das tarefas da Sprint

Aprovação de requisitos através do Business Value (BV), Priorização de requisitos (ROI) e Sprint

(1 e 2)

PRÁTICA NÃO MENCIONADA

Daily Scrum Meeting e Sprint Review Meeting

Sprint Planning (1 e 2), Daily Scrum Meeting e Sprint Review

e as áreas de processo do MPS.BR nível G, teve por objetivo mapear o alinhamento e a conformidade entre eles. A partir deste mapeamento não satisfaz totalmente o nível do G do MPS.BR conforme

fatores, ou seja, há algumas lacunas e atividades ausentes no Scrum que são apresentadas na extensão

GAP”, ou seja, os ” e “Não satisfeito”, adicionadas ao processo conforme descrição

acunas na definição de um método apropriado de complexidade ou tamanho para as tarefas e os produtos de trabalho do projeto, impactando

(6)

Para realização da estimativa das tarefas e os produtos de trabalho foi definido a combinação de estimativas por Story Points com a técnica por complexidade Planning Poker, que consiste em um jogo de cartas numeradas com a série de Fibonacci.

5.2. GAP2 – ausência de estimativa do esforço e o custo para a execução das tarefas e dos produtos de trabalho com base em dados históricos ou referências técnicas

Para definição dos custos e esforço serão analisados dados históricos organizacionais mantidos através em um documento que contempla informações de projetos anteriores.

5.3. GAP3 – ausência de definição do orçamento

Para definição do orçamento será utilizada a política de negociação da empresa em questão. Este documento fornece orientações sobre os procedimentos a serem observados na negociação dos projetos de software da empresa.

5.4. GAP4 - ausência de privacidade e segurança no acesso às informações

A proposta é armazenar as informações coletadas no projeto utilizando a política de segurança, acesso e armazenamento das informações de projetos. Este documento define a estratégia para implementação nos projetos da empresa no que se refere à infra-estrutura (confiabilidade, segurança e estabilidade) e nível operacional (níveis de usuários, responsabilidades, limites e controle de versões).

5.5. GAP5 - ausência de rastreabilidade entre os requisitos e produtos de trabalho

Para a rastreabilidade vertical cada item de Backlog (IBL) será inicialmente identificado, então, na criação do Sprint Backlog cada tarefa estará associada a um IBL e os artefatos de engenharia estarão associados ao IBL correspondente. Portanto, a rastreabilidade vertical pode ser distribuída em cada artefato gerado, como por exemplo, o código implementado.

6. Adaptando a extensão em processo de uma fábrica de software

Para validação deste trabalho, foi implementada a extensão proposta na CRIATIVA tecnologia, que é uma empresa de tecnologia que cria produtos e serviços utilizando tecnologia da informação (TI). Atualmente a empresa conta com cerca de trinta colaboradores, atendendo diversos clientes e atuando em três áreas de negócio: fábrica de software, treinamentos e prestação de serviços técnicos em equipamentos eletrônicos.

6.1. Histórico de melhoria de processos da CRIATIVA

Os trabalhos em melhoria de processo de software na CRIATIVA iniciaram cerca de três anos após a sua fundação (2003), onde após um crescimento significativo de sua base de clientes, a empresa começou a apresentar diversos problemas relacionados ao processo de produção de software. Baseado neste contexto, foi realizada a modelagem de um processo de desenvolvimento baseado no guia MPS.BR nível G REF9 (2006), onde no período inicial pode-se notar melhorias, no entanto, após alguns meses de utilização, alguns fatores impactaram negativamente na empresa em relação ao processo que foi definido.

(7)

Em seguida foi proposto o desenvolvimento de

REF10 (2009) que proporcionasse maturidade para a organização e que ao mesmo tempo tivesse seu foco nos princípios do manifesto ági

6.2 O novo processo de software da criativa tecnologia

A partir de uma perspectiva de gerenciamento e baseado no ciclo de desenvolvimento iterativo incremental definido por

um processo composto por 3 (três atividades de Monitoramento e Control

Figura 29. Processo de Software Macro da CRIATIVA tecnologia. Com o objetivo de proporcionar o entendimento p

empresa em questão, para todas as fases deste novo processo foram elaborados fluxos de trabalho, apresentando suas etapas, objetivos, conceitos chave e quadros de estruturação de cada atividade

a) Fase PREGAME: Esta fase tem como objetivos delimitar o escopo do projeto,

verificar a viabilidade econômica e eliminar riscos a partir de uma arquitetura estável. mesma foi dividida em duas sub

a.1) Conceitos chave da sub

A criação da Visão do Produto é de responsabilidade do deve-se frisar que o Scrum

importante que toda a equipe tenha entendimento do produto que alcançar. Este documento deve ser curto e acessível

O Product Backlog

mas também é atualizado pelo time requisitos funcionais, não funcion

a.2) Conceitos chave da sub

Esta sub-fase é uma c voltado à definição de algumas

proposto o desenvolvimento de um novo processo de

que proporcionasse maturidade para a organização e que ao mesmo tempo tivesse seu foco nos princípios do manifesto ágil.

novo processo de software da criativa tecnologia

A partir de uma perspectiva de gerenciamento e baseado no ciclo de desenvolvimento iterativo incremental definido por REF6 (2008) para o framework Scrum

um processo composto por 3 (três) fases: Pregame, Game e Postgame, Monitoramento e Controle conforme ilustrado na Figura 2

. Processo de Software Macro da CRIATIVA tecnologia.

Com o objetivo de proporcionar o entendimento para os colaboradores da empresa em questão, para todas as fases deste novo processo foram elaborados fluxos de trabalho, apresentando suas etapas, objetivos, conceitos chave e quadros de estruturação de cada atividade com seus respectivos papéis, entradas, saídas e artefatos.

Esta fase tem como objetivos delimitar o escopo do projeto, verificar a viabilidade econômica e eliminar riscos a partir de uma arquitetura estável.

duas sub-fases: PLANNING E STAGING.

chave da sub-fase Planning

A criação da Visão do Produto é de responsabilidade do Product Owner

Scrum não estimula a documentação desnecessária, mas é importante que toda a equipe tenha entendimento do produto que está

alcançar. Este documento deve ser curto e acessível por todos.

Product Backlog é outro artefato de responsabilidade do Product Owner também é atualizado pelo time, em comum acordo com o PO. Pode conter requisitos funcionais, não funcionais e outras questões.

chave da sub-fase Staging

fase é uma continuação da sub-fase inicial Planning, mas com o foco e algumas atividades, como: organização da infra

um novo processo de software que proporcionasse maturidade para a organização e que ao mesmo

A partir de uma perspectiva de gerenciamento e baseado no ciclo de desenvolvimento Scrum, chegou-se a Postgame, apoiadas por e conforme ilustrado na Figura 2.

. Processo de Software Macro da CRIATIVA tecnologia.

ara os colaboradores da empresa em questão, para todas as fases deste novo processo foram elaborados fluxos de trabalho, apresentando suas etapas, objetivos, conceitos chave e quadros de saídas e artefatos. Esta fase tem como objetivos delimitar o escopo do projeto, verificar a viabilidade econômica e eliminar riscos a partir de uma arquitetura estável. A

Product Owner, porém não estimula a documentação desnecessária, mas é está se tentando

Product Owner (PO) em comum acordo com o PO. Pode conter

, mas com o foco organização da infra-estrutura para

(8)

desenvolvimento do projeto, definição da arquitetura, definição do plano de comunicação, elaboração do Release Plan, realiza da reunião kick-off.

b) Fase GAME: esta fase tem como objetivos criar releases do produto podendo obter

versões funcionais do software. Nesta direção, o time realiza algumas atividades como: dividir os Itens de Backlog (IBL) que foram selecionados para a Sprint em tarefas, realizar estimativas, priorizar e analisar a viabilidade dos IBL’s. Durante as reuniões diárias, as tarefas são selecionadas para cada membro do time, o compromisso é obtido e uma parte do produto é desenvolvida com base na arquitetura definida e com ênfase no gerenciamento de custos, recursos e qualidade.

b.1) Conceitos chave da fase Game

Esta fase se inicia com as reuniões da Sprint que são divididas em dois níveis, Sprint Planning 1 e Sprint Planning 2. A Sprint Planning 1 e uma reunião que tem por objetivo diversas atividades, tais como: verificação de dados históricos organizacionais, priorização de IBL da Sprints, seleção de IBL que irão compor a Sprint e elaboração da Sprint Backlog. A Sprint Planning 2 e a segunda reunião de planejamento com participação do time e Scrum Master para realização de atividades como: definição de tarefas (Task) necessárias para realização da Sprint e segundo nível de estimativa em horas, divisão das tarefas da Sprint entre a equipe, análise da capacidade produtiva da equipe, atualização do Task Board;

Ao final da Sprint Planning 1 e 2, a obtenção de compromisso e revisões no planejamento foram realizadas por todos os envolvidos.

A partir disto é executada a Sprint, que consiste no desenvolvimento das tarefas definidas para cada IBL, com o objetivo de obter um produto potencialmente entregável.

Durante a execução da Sprint é realizada a atividade Daily Scrum, que é uma reunião diária onde o time monitora o progresso da execução das atividades e procura identificar os impedimentos encontrados.

Posteriormente, o Scrum Master trabalha no sentido de elaborar ações para resolver tais impedimentos e disseminar a solução para o time. Atualizações na Sprint Backlog e Product Backlog são realizadas para controlar o progresso das Sprints.

c) Fase POSTGAME: esta fase tem como objetivos apresentar o produto ao cliente

para validação, realizar uma reunião para melhoria do processo e avaliar a capacidade produtiva do time.

c.1) Conceitos chave da fase POSTGAME

A reunião de revisão da Sprint, chamada de Sprint Review Meeting fornece algumas visões para todos os envolvidos, tais como: visibilidade se a meta da Sprint foi alcançada, apresentação de resultados, Inspeção de funcionalidades para possíveis mudanças e adaptações e a reunião de retrospectiva (Sprint Retrospective Meeting).

Ao final desta fase caso haja nova Sprint, ou seja, caso ainda exista a necessidade de serem desenvolvidas outras funcionalidades, novos ciclos são realizados iniciando-se pela fase GAME.

Ao final, informações coletadas no projeto são armazenadas para utilização em projetos futuros formando a base de dados históricos organizacionais.

(9)

7. Estudo de Caso

Visando avaliar os efeitos da aplicação da extensão proposta neste trabalho, foi realizado o estudo de caso na empresa em questão em projetos de software selecionados com base na semelhança das características de domínio, escopo, arquitetura, tempo, custo e equipe, através das métricas que mais estavam impactando negativamente nos projetos, tais como: entregas no prazo, satisfação do cliente e quantidade de Bugs.

Na avaliação de entregas no prazo foi possível observar que houve um pequeno desvio em relação à capacidade de produção do time devido ao fato de não existir projetos anteriores que utilizaram este novo processo. Mas apesar de não conseguir completar 100% das funcionalidades planejadas, o novo processo conseguiu demonstrar que as entregas dentro do prazo do processo anterior em relação a esta nova abordagem, apresentam uma melhoria de 42,50%.

Para medir a satisfação dos clientes, foi aplicado um questionário em relação a diversos aspectos, tais como: comunicação, qualidade do produto, gerenciamento de mudanças, entregas no prazo, dentre outros. Para avaliar o processo foram utilizados três indicadores, sendo que para cada questão, o questionário disponibilizou orientações de como ela deve ser avaliada. Foi possível observar que no projeto que utilizou o novo processo de desenvolvimento obteve aumento de 57,14% das respostas “atendem totalmente” no questionário, proporcionando uma grande diminuição nos valores para as respostas que atendem parcialmente (57,14%) e manutenção da ausência de respostas que não atendem o cliente.

Para medir a quantidade de Bugs, foram coletados os dados na ferramenta Bug Tracker da empresa e pode-se observar que o Projeto que utilizou o novo processo teve um número menor de Bugs que o processo anterior.

O estudo de caso realizado apresentou os resultados obtidos através da implementação da proposta de melhoria do processo de software deste projeto. Através das métricas apresentadas anteriormente, pode-se observar os efeitos de agilidade e maturidade em relação à abordagem anterior.

Alguns aspectos nos projetos que utilizaram o novo processo podem ser ressaltados, tais como:

• O quadro de tarefas (Taskboard) proporcionou uma grande visibilidade do andamento das tarefas;

• A participação da equipe nas decisões do projeto proporcionou comprometimento e motivação na realização das tarefas diárias;

• Através das reuniões diárias pode-se monitorar a produção do time, promover feedback e remover impedimentos que viessem a atrasar o bom andamento do desenvolvimento da Sprint.

8. Conclusão

No mapeamento entre o Scrum e o guia MPS.BR nível G, descobriu-se que ele não cobre totalmente os resultados esperados do guia, mas pode ser um ponto de partida, pois proporciona uma base fundamental para empresas que estão iniciando melhoria de processos, principalmente as que dispõem de poucos recursos como as micro e pequenas empresas.

(10)

O gerenciamento de requisitos através de abordagens ágeis proporcionou uma forma alternativa e eficaz de gerenciar requisitos e solicitações de mudanças durante o desenvolvimento do projeto evitando o retrabalho.

A abordagem de gerenciamento ágil de projetos foi uma alternativa capaz de proporcionar a inovação, diminuição do tempo de entrega dos projetos, desenvolvimento de produtos de trabalho que agregam valor real para o cliente e resultados para a empresa.

O novo processo proposto demonstrou um avanço inicial no sucesso de um projeto de software desenvolvido pela empresa, mas como se encontra ainda em fase de implantação, o monitoramento se faz necessário para obtenção da melhoria contínua e obtenção de melhores resultados.

9. Referências Bibliográficas

(REF1, 2003) Adm, Advanced Development Methods. Scrum Methodology – Incremental, Iterative Software. Development from Agile Processes.

(REF2, 2002) Beedle, M., and Schawaber, K.. Agile Software Development With Scrum. New Jersey, Books.

(REF3, 2006) Boehm, B.. “A View of 20th and 21st Century Software Engineering.” ICSE06. Shanghai, China, ACM.

(REF4, 2004) Davis, C, et al.. An Agile Approach to Achieving CMMI. http://www.agiletek.com/images/AgileTek/pdf/an_agile_approach_to_achieving_cm mi.pdf (acesso em 27 de Dezembro de 2008).

(REF5, 2008) Playfair, K. “When 'General Agile' Isn't Enough - Why Scrum Wins in the Enterprise.” Agile Journal. http://www.agilejournal.com/content/view/808/111/ (acesso em 29 de Dezembro de 2008).

(REF6, 2008) Schwaber, K.. Agile Project Management With Scrum. Redmond, Microsoft Press.

(REF7, 2007) Softex. MPS.BR, Melhoria de Processo de Software Brasileiro - Guia Geral V1.2. Rio de Janeiro, Softex.

(REF8, 2004) Standish, The Standish Group International. (2004).. “The Chaos Report.” Standish Group. secure.standishgroup.com/reports/reports.php?rid=500. (REF9, 2006) Szimanski, F.. Implementando MPS.BR nível G na melhoria do processo

de software em uma pequena empresa. Simpósio Mineiro de Sistemas de Informação. Lavras, UFLA.

(REF10, 2009) Szimanski, F. Extensão do Scrum segundo as áreas de processo do MPS.BR nível G. Dissertação de mestrado. Recife, CESAR.

(REF11, 2006) GLASS, Robert L. “The Standish Report: Does It Really Describe a Software Crisis?” COMMUNICATIONS OF THE ACM, Agosto de 2006.

(REF12, 2008) MCCONNELL, Steven C. “Classic Mistakes Enumerated.” Web Site Steve Mcconnell. 1996. http://www.stevemcconnell.com/rdenum.htm (acesso em 20 de Abril de 2008).