UNIVERSIDADE DE PERNAMBUCO

FACULDADE DE CIÊNCIA E TECNOLOGIA DE CARUARU

BACHARELADO EM SISTEMAS DE INFORMAÇÃO

MÉTODOS TRADICIONAIS VERSUS ÁGEIS: UM ESTUDO

COMPARATIVO ATRAVÉS DO TRAININGCAD.

Gert Uchôa Müller Neto

Humberto Rocha de Almeida Neto

(Orientador)

CARUARU (PE)
DEZEMBRO DE 2009.
 B.SC. GERT UCHÔA MÜLLER NETO

M.Sc. Humberto Rocha de Almeida Neto

(Orientador)

MÉTODOS TRADICIONAIS VERSUS ÁGEIS: UM ESTUDO

COMPARATIVO ATRAVÉS DO TRAININGCAD.

Monografia apresentada como requisito parcial

para obtenção do diploma de Bacharel em Sistemas
de Informação pela Faculdade de Ciência e
Tecnologia de Caruaru da Universidade de
Pernambuco.

CARUARU (PE)
DEZEMBRO DE 2009.
MÜLLER NETO, Gert Uchôa.
Métodos Tradicionais versus Ágeis: um estudo comparativo através do TrainingCad.
/ Gert Uchôa Müller Neto –
Caruaru: 2009.
57 f.; 30 cm.

Orientação: Humberto Rocha de Almeida Neto.

Trabalho de Graduação em Sistemas de Informação (Bacharelado) - Faculdade
de Ciência e Tecnologia de Caruaru da Universidade de Pernambuco, 2009.
Inclui bibliografia.
1. Metodologia de Gerenciamento e Desenvolvimento de Software. I. Título.
A Deus, aos meus pais, à minha família e a Isabela Salvador.
 AGRADECIMENTOS

G ostaria de agradecer primeiramente a Deus, que me deu forças e capacidade para

conclusão não só do trabalho de graduação, mas de todo o curso; e, em segundo lugar,
aos meus pais, que sempre me apoiaram e me aconselharam em tudo: escolhas, dificuldades e
medos. Tudo que vier a ser, devo a estas duas pessoas maravilhosas e batalhadoras.
Quero aproveitar e agradecer aos meus amigos durante toda minha caminhada de
construção do conhecimento, desde a época de garoto no colégio até os amigos de faculdade.
Mas há alguns agradecimentos em especial. Agradeço a Flávio Ferreira, que foi quem me
ajudou a descobrir meu grande dom dentro da área de informática, e aos gêmeos Diego
Renato e Thiago Rodrigo, por serem sempre meus amigos fiéis, ajudando-me nas horas que
mais precisei durante todo este curso.
Meus sinceros agradecimentos aos professores do curso de Sistemas de
Informação da UPE, por perseverarem e proporcionarem a continuidade da oportunidade que
me foi dada. Em especial ao meu professor Humberto Rocha por ter me orientado e apoiado
de forma brilhante não só durante o desenvolvimento deste trabalho, mas também em alguns
momentos durante o curso, e por aceitar sem hesitar a responsabilidade de ser meu orientador,
sempre acreditando que eu pudesse realizar um bom trabalho. Também gostaria de agradecer
aos funcionários desta universidade.

Obrigado a todos!
 RESUMO

Este trabalho visa apresentar o conceito de Métodos Ágeis, bem como suas características e
aplicações, em contraponto aos Métodos Tradicionais. Suas formas de trabalho, seus valores e
práticas serão apresentados de modo a identificar e justificar suas principais diferenças,
estabelecendo uma relação de comparação entre elas. Também serão detalhados alguns destes
métodos, especificando pontos-chave em sua metodologia e comparando suas características.
Tentou-se alcançar esse objetivo através de uma pesquisa exploratória do Método Tradicional
aplicado ao projeto TrainingCad da UPE Consultoria Jr. Definiu-se o Método Ágil Scrum
alinhado às práticas de da metodologia de desenvolvimento denominada Extreme
Programming, ou apenas XP, para aplicação de uma proposta em um estudo comparativo.
Nesse estudo comparativo foram aplicadas técnicas especificadas pelo Scrum e XP para tentar
aperfeiçoar o gerenciamento e desenvolvimento do projeto de software TrainingCad. Como
resultado preliminar do estudo, apresentou-se uma proposta de desenvolvimento desse projeto
utilizando Scrum alinhado ao XP, visando um desempenho satisfatório, um auxílio na
monitoração das tarefas do projeto e melhorando a organização das atividades.

Palavras-chave: Métodos Ágeis, Scrum, Métodos Tradicionais, Rational Unified Process,

TrainingCad.

i
 ABSTRACT

This paper presents the concept of Agile Methods as well as their characteristics and
applications as opposed to Traditional Methods. Their forms of work, its values and practices
will be presented in order to identify and explain the differences among them, establishing a
relation of comparison between them. Will also detailed some of these methods by specifying
key points in its methodology and comparing their characteristics. We tried to achieve this
goal through an exploratory survey of Traditional Methods applied to the design of UPE
Consultancy Jr‟s TrainingCad. was defined Scrum Agile Method aligned to the practices of
the development methodology called Extreme Programming, or XP only, for application of a
proposal in a comparative study. In this comparative study were applied techniques defined
by Scrum and XP to try to improve the management and development of software project
TrainingCad. As a result of the study, presented a proposal to develop this project using
Scrum aligned to XP in order to perform satisfactorily, an aid in monitoring of project tasks
and improving the organization of activities.

Keywords: Agile Methods, Scrum, Traditional Methods, Rational Unified Process,

TrainingCad.

ii
SUMÁRIO

Resumo i

Abstract ii

Lista de Figuras v

Lista de Tabelas vi

Lista de Símbolos e Siglas vii

1 Introdução 8
1.1 Caracterização do Problema 9
1.2 Motivação 10
1.3 Objetivos 10
1.3.1 Objetivo Geral 10
1.3.2 Objetivos Específicos 11
1.4 Metodologia da Pesquisa 11
1.4.1 Classificação quanto à natureza 11
1.4.2 Classificação quanto à abordagem do problema 11
1.4.3 Classificação quanto aos objetivos 11
1.4.4 Classificação quanto aos procedimentos técnicos 12
1.5 Estrutura do Documento 12

2 Revisão da Literatura 13
2.1 Gerenciamento e Desenvolvimento de Projetos de Software 13
2.2 Métodos Tradicionais 14
2.2.1 O Guia PMBOK® 16
2.2.2 O RUP 17
2.3 Métodos Ágeis 19
2.3.1 APM 21
2.3.2 Scrum 22
2.3.3 Extreme Programming 24

3 Estudo de Caso: TrainingCad 31

3.1 Contextualização 31
3.2 TrainingCad 33
3.3 Gerenciamento e Desenvolvimento do Projeto 34

iii
 3.4 Proposta de Aplicação do Scrum 43
3.4.1 Proposta 43

4 Análise Comparativa 46
4.1 Conclusões 47

5 Considerações Finais 48
5.1 Contribuições 48
5.2 Dificuldades Encontradas 49
5.3 Trabalhos Futuros 49

Referências 51

iv
LISTA DE FIGURAS

Figura 1 Ciclo PDCA (Plan-Do-Check-Act) 16

Figura 2 Mapeamento entre os grupos de processos e o ciclo PDCA 17
Figura 3 Ciclo de Vida do RUP 19
Figura 4 Processo de Desenvolvimento Ágil 21
Figura 5 Ciclo de Desenvolvimento do Scrum 24
Figura 6 Práticas do XP 30
Figura 7 Tela Principal do TrainingCad 34
Figura 8 Gráfico de Gantt do TrainingCad 35
Figura 9 Diagrama de Casos de Uso do TrainingCad 37
Figura 10 Diagrama de Sequência do Requisito Funcional Efetuar Login do TrainingCad 39
Figura 11 Diagrama de Classes do Requisito Funcional Efetuar Login do TrainingCad 40
Figura 12 Tela de Cadastro de Alunos do TrainingCad 41
Figura 13 Tela de Consultas do TrainingCad 42
Figura 14 Fases do Ciclo de Desenvolvimento anterior à Proposta 45
Figura 15 Ciclo de Desenvolvimento após aplicação da Proposta 45
Figura 16 Comparação de Custos de Mudanças entre Métodos Ágeis e Tradicionais 47

v
LISTA DE TABELAS

Tabela 1 Cronograma de Marcos Sumarizado do TrainingCad 32

Tabela 2 Requisitos Funcionais do TrainingCad 36
Tabela 3 Requisitos Não-Funcionais do TrainingCad 36
Tabela 4 Cronograma detalhado do TrainingCad 38
Tabela 5 Gerenciamento de Riscos do TrainingCad 38
Tabela 6 Tabela de Estratégia de Teste de Stress do TrainingCad 42
Tabela 7 Tabela Comparativa entre as Metodologias usadas e propostas no TrainingCad 46

vi
LISTA DE SÍMBOLOS E SIGLAS

APM - Agile Project Management

BPMS - Business Process Management Systems

GRP - Gerência de Riscos de Projeto

PDCA - Plan, Do, Check and Act

PMBOK - Project Management Body of Knowledge

PMI - Project Management Institute

RSC - Rational Software Corporation

RUP - Rational Unified Process

XP - Extreme Programming

vii
 CAPÍTULO 1
Introdução

Cada vez mais os sistemas de computação têm conquistado espaço em no

cotidiano da sociedade moderna. Apesar deste rápido avanço, ainda se faz necessário prazos
mais curtos na produção de software para melhor atender às necessidades dos clientes.
Contudo, a construção de um software robusto, confiável e de boa qualidade dentro dos
prazos e custos estimados ainda é uma árdua tarefa.

O gerenciamento de um projeto de software é uma tarefa complicada e envolve

condições adversas, além de fatores externos que podem ser imprevisíveis. Podem-se citar
algumas entre essas condições como mudanças de tecnologias e as constantes renovações dos
requisitos do produto por parte do cliente (SCHWABER, 2004).

Pesquisas nessa área realizadas por Carlos Bernardo Souza (2008) através da
Pontifícia Universidade Católica do Rio Grande do Sul, por volta de 2005, tomando por base
mais de 8300 projetos, atestam que apenas 16,2% dos projetos foram entregues dentro do
prazo estipulado respeitando os requisitos e os custos. Levando em consideração os projetos
que extrapolaram os limites temporais e financeiros, apenas 61% das funcionalidades
requisitadas pelos clientes foram entregues. Até mesmo os que seguiram à risca os prazos,
custos e funcionalidades são postos a suspeita de que não são de boa qualidade, pois os seus
integrantes foram submetidos a uma grande pressão, o que pode levar a um aumento
significativo dos erros no decorrer do projeto.

Muitas dessas falhas estão relacionadas ao grande uso dos processos de

gerenciamento de software tradicionalistas, podendo-se citar o RUP (Rational Unified
Process1), os quais possuem um nível mais rígido de formalidades, abusando de uma
documentação muito extensa, dificultando que os requisitos dos softwares sejam elásticos e
mutáveis.

1
Tradução: Processo Unificado Rational.
8
 Contudo, o mercado atual é muito dinâmico e exige dos requisitos de um projeto
de software o mesmo dinamismo. Logo, os modelos ou práticas de gestão e desenvolvimento
de projetos orientados a documentação (tradicionalistas), como exemplo pode-se citar o guia
PMBOK (Project Management Body of Knowledge2) (2004), limitam a flexibilidade de
adaptação desses mesmos requisitos. Então, algumas organizações acabam por não usar
processo algum, tentando fugir da lentidão e do alto custo, e prejudicam a qualidade de seu
produto final.

As metodologias ágeis surgem então como contraposto às metodologias

tradicionais. Mas, em sua grande maioria, não aparecem com algo novo, mas mudam os
enfoques e os valores do gerenciamento de projetos. O enfoque agora é direcionado a pessoas,
e não mais em processos. Começa, também, a existir a preocupação em reduzir os custos com
o tempo e documentação extensiva. A implementação passa a ocupar mais tempo,
proporcionalmente, no projeto (COCKBURN, 2001).

Em 2001, foi criado o Agile Manifesto (2009), onde um grupo de especialistas em

desenvolvimento ágil de software se reuniu e estabeleceu princípios comuns a estes métodos.

Inserida neste contexto, uma empresa júnior do Campus Caruaru – Faculdade de

Ciência e Tecnologia de Caruaru – da Universidade de Pernambuco, propôs o
desenvolvimento de um software de gestão de inscrições para seus próprios cursos, o
TrainingCad. Este software foi desenvolvido utilizando o RUP como método de
desenvolvimento e as práticas do PMBOK (2004) como método de gerenciamento, e foram
levantados muitos questionamentos sobre seu tempo de desenvolvimento e sobre seu custo
durante suas reuniões.

1.1 Caracterização do Problema

Como garantir o sucesso do projeto TrainingCad, desprendendo seu método de

gerenciamento e desenvolvimento do tradicionalismo rígido usando as novas metodologias
ágeis, suas práticas e valores?

2
Tradução: Corpo de Conhecimentos de Gerenciamento de Projetos.
9
1.2 Motivação

O sucesso da produção de software depende cada vez mais da qualidade final do

seu produto, além do cumprimento fiel dos prazos e custos estipulados. É necessário, então,
aplicar uma metodologia para gerenciar e desenvolver o projeto, com o intuito de acompanhar
as etapas de seu desenvolvimento e gerenciar qualquer impedimento que venha a ocorrer.

As metodologias de gerenciamento e desenvolvimento de projetos tradicionais

não são apenas baseadas em boas práticas para desenvolvimento de software, mas também,
boas práticas para gerenciar os negócios. Entretanto, a maioria das empresas envolvidas neste
tipo de negócio não possui recursos financeiros para implantação de processos de gerência
tradicionais. Pode-se adicionar isso à informação de que os requisitos tendem a ser cada vez
mais mutáveis, também.

A justificativa para escolha do tema deste trabalho vêm da visibilidade crescente

que as Metodologias Ágeis de desenvolvimento de software têm recebido em todo o mundo, e
também aqui no Brasil. As características presentes neste trabalho também levam à tentativa
de resolução de questionamentos, dos quais se pode citar: Quando devo usar que tipos de
metodologia? Como obter resultados mais rápidos? Inspirado nisso, este trabalho tem por
motivação responder algumas dessas questões que foram levantadas sobre o processo de
criação do TrainingCad, propondo a aplicação de uma ou mais metodologias ágeis.

1.3 Objetivos

Nesta seção serão apresentados os objetivos geral e específicos que este estudo
comparativo tentou alcançar.

1.3.1 Objetivo Geral

Propor uma metodologia de gerenciamento e desenvolvimento de projeto para o

TrainingCad baseado nas premissas das Metodologias Ágeis após análise do processo que
fora realizado utilizando o RUP como metodologia primordial.

10
1.3.2 Objetivos Específicos

- Contextualizar o projeto TrainingCad e sua metodologia;

- Analisar a metodologia utilizada no projeto de software em estudo;

- Adaptar as disciplinas da metodologia usada no projeto;

- Propor um novo método baseado no Scrum e no XP a ser seguido no

gerenciamento e desenvolvimento do TrainingCad;

- Estimar os efeitos da possível adoção do método proposto.

1.4 Metodologia da Pesquisa

O método de construção do trabalho científico que se segue, está organizado da

forma nos itens dispostos a seguir:

1.4.1 Classificação quanto à natureza

Quanto à sua natureza, este trabalho se classifica como uma pesquisa aplicada, já
que pretende gerar conhecimentos dirigidos à solução de uma problemática (CERVO, 2007).

1.4.2 Classificação quanto à abordagem do problema

Do ponto de vista de abordagem do problema, pode ser vista como uma pesquisa
qualitativa, pois não há uma forma de mensuração exata das opiniões descritas na dissertação
(CERVO, 2007).

1.4.3 Classificação quanto aos objetivos

Quanto aos objetivos, este trabalho se encaixa como uma pesquisa exploratória,
pois se trata de um estudo comparativo através do TrainingCad e explora o método de
gerenciamento do projeto de software (CERVO, 2007).

11
1.4.4 Classificação quanto aos procedimentos técnicos

Quanto aos procedimentos, esta pesquisa se encaixa em três aspectos:

bibliográfica, experimental e estudo de caso. Bibliográfica porque se apóia em muitos
aspectos descritos em livros e materiais publicados. Experimental, pois se determina um
objeto de estudo e se identifica as variáveis que possivelmente o influenciariam. E, por fim,
um estudo de caso comparativo, pois usa da analogia entre dois valores de uma característica
do objeto, envolvendo-se profundamente em seu estudo, afim de seu detalhado conhecimento
(CERVO, 2007).

1.5 Estrutura do Documento

Este trabalho está dividido em cinco seções, incluindo o presente prefácio. Os

demais capítulos visam à demonstração, o desenvolvimento do trabalho e o método de
realização do estudo. A pesquisa está dividida da seguinte forma:

Capítulo 1 - Introdução - Nesta seção serão introduzidas a problemática, a

justificativa do trabalho, seus objetivos e metodologia usada na realização da pesquisa, além
dos aspectos do contexto atual sobre os assuntos-chave do trabalho.

Capítulo 2 - Revisão da Literatura - Este capítulo irá tratar sobre o

embasamento teórico do trabalho. É nele que serão vistos conceitos sobre os assuntos-chave
na área de métodos de gerência e desenvolvimento de projetos de software.

Capítulo 3 - Estudo de Caso: TrainingCad - Esta parte se responsabilizará por

apresentar, contextualizar, analisar o aplicativo TrainingCad. Também será nele que será
proposto um novo método de gerência de projetos baseado no Scrum e no XP.

Capitulo 4 - Análise Comparativa - Neste momento serão abordados os

resultados esperados e comparados aos resultados obtidos anteriormente para uma análise
comparativa entre as duas metodologias em questão.

Capítulo 5 - Considerações Finais - Nesta seção serão tratadas as considerações

finais do projeto. Bem como trabalhos relacionados, as dificuldades encontradas e opiniões
para trabalhos futuros.

12
 CAPÍTULO 2
Revisão da Literatura

A pesquisa realizada neste trabalho tem por objetivo intrínseco auxiliar de alguma
forma às atividades do ramo de gerenciamento e desenvolvimento de projetos. A disciplina de
Gerência de Projetos é aquela responsável pelo controle dos riscos de insucesso do projeto
durante o desenvolvimento do mesmo. Consiste na aplicação de conhecimentos e métodos de
elaboração de tarefas que se relacionam para atingir os objetivos definidos (TAVARES,
2008).

Há duas vertentes principais de metodologias de gestão de projetos de software:

tradicionais e ágeis. Elas possuem os mesmos objetivos e metas, porém funcionam de
maneiras distintas, além de enfatizarem valores diferentes. Explanarei o assunto um pouco
aprofundado mais a seguir.

2.1 Gerenciamento e Desenvolvimento de Projetos de Software

O mercado está cada vez mais dinâmico, o mundo por sua vez também está. As
relações empresariais e os negócios estão cada vez mais competitivos. Quem possui maior
acesso à informação possui vantagens sobre os concorrentes. Desde o advento da Internet na
última década, a velocidade dos acontecimentos no mundo têm se tornado muito rápida. A
informação cruza o globo instantaneamente. Uma notícia sobre uma empresa do outro lado do
planeta pode afetar a bolsa de valores no mundo inteiro em questões de segundos, conforme a
dissipação da informação pela Internet (VIEIRA, 2003).

Defronte este cenário, a importância da gestão de projetos nas organizações tem se

tornado cada vez maior. O TrainingCad se insere nesse quadro. O mesmo utiliza uma
metodologia de gerenciamento e desenvolvimento de projeto tradicionalista, e para facilitar a
compreensão de seu processo de desenvolvimento e de sua aplicação, serão introduzidos mais
adiante, conceitos dos métodos tradicionais (Seção 2.2) e suas especificidades. Também serão
colocados conceitos relacionados aos métodos ágeis (Seção 2.3) e, dentro deles, os conceitos
13
do Scrum e do XP. Serão abordadas as principais diferenças entre os métodos citados, bem
como as vantagens da utilização de metodologias ágeis no contexto atual.

Os conceitos da metodologia de gerenciamento tomada no desenvolvimento do

TrainingCad se apoiaram nos conceitos do RUP, e os princípios ágeis da proposta, nas
práticas existentes de gestão de projetos usando Scrum (SCHWABER, 2004), XP e APM
(Agile Project Management).

2.2 Métodos Tradicionais

Estas metodologias surgiram em um cenário de construção de software muito

diferente do atual. A sequência de tarefas para desenvolvimento do software era realizada em
terminais burros e mainframes, onde o custo para correção de erros ou qualquer outra
alteração era muito elevado, pois o acesso aos computadores era muito limitado e não havia
ferramentas de apoio à construção de software (PRESSMAN, 2002).

Então a maneira de minimizar os problemas durante o desenvolvimento de um

software foi planejar e documentar muito bem este antes do início de seu desenvolvimento.
Esse foi um dos fatores primordiais para a existência de um processo de gerenciamento de
software baseado em documentação detalhada, planejamento extenso e etapas bem
delimitadas (PRESSMAN, 2002).

Hoje, a gerência de projetos tradicionalista ainda é o método mais usado no

desenvolvimento de software. Uma das grandes vantagens do método tradicional está na
comparação e repetição com dados obtidos do passado, devido à padronização proporcionada
pelo processo e guiado pela sensibilidade que indica que variações durante a execução do
processo podem ser identificadas e solucionadas através do refinamento e mensuração do
mesmo. A partir da obtenção de dados de fatos já ocorridos e da repetição, obtém-se a
melhoria da capacidade do processo através da padronização, medição e controle do projeto.
Este método também recebe o nome de pesado, pois possui um grande tamanho e traz consigo
uma grande dificuldade de implementação.

Na fase de planejamento é dissipado muito tempo com a documentação, pois esta

é a base do projeto e tem por missão minimizar, o quanto puder, que novos requisitos e/ou
funcionalidades surjam durante o período de construção propriamente dito do software. Nessa
fase encontra-se a delimitação do escopo do projeto, um fator crucial para seu sucesso, pois a
14
qualidade é influenciada diretamente por este mesmo fator (SLIGER, 2006 apud TAVARES,
2008).

É imprescindível ao analista ou engenheiro e ao gerente do projeto ter uma grande

disponibilidade à comunicação. Saber ouvir e respeitar as pessoas que vivem no ambiente de
trabalho, além de saber selecionar e adicionar as necessidades do usuário justificadas
economicamente são qualidades essenciais a esta figura do processo. Quanto mais
impedimentos ocorrerem durante a execução do projeto, maior será o re-trabalho e o tempo de
finalização do mesmo. Isso implica em mudanças estruturais complicadas e que têm impacto
muito grande sobre o custo, o prazo e a qualidade do produto final (SOUZA, 2008).

O planejamento é detalhadamente descrito, extenso por sua vez, e enfatiza a

criação e o cumprimento de cronogramas de atividades e procedimentos que auxiliem na
construção do produto e na coordenação do processo. Este tipo de documento ainda é
utilizado na mensuração do progresso durante a fase de execução do projeto, podendo sofrer
constantes mudanças conforme a evolução do processo (VIEIRA, 2003).

Este tipo de metodologia permite a opção entre vários tipos de ciclos de

desenvolvimento. Pode-se citar os ciclos cascata3, espiral4 ou iterativo5 como exemplos. Sua
arquitetura é focada na reutilização, reduzindo a quantidade de retrabalho, com isso
incentivando o crescimento da produtividade. Também pode ser utilizado em vários projetos,
desde que os requisitos do mesmo não sejam muito voláteis, já que este método demonstra
dificuldades claras em relação às mudanças colocadas pelo ambiente ou proprietário. Este fato
pode ocasionar um desgaste no relacionamento entre o cliente e a equipe de desenvolvimento,
resultando no atraso da entrega do projeto. É por este motivo que muitos estudiosos na área de
Engenharia de Software se dedicam, atualmente, ao desenvolvimento de novos métodos de
gerenciamento e desenvolvimento de projetos de software, entre eles os novos métodos ágeis,
que possuem valores e visões diferentes das metodologias tradicionalistas. Dentre as
metodologias de gerência de projetos tradicionais, pode-se exemplificar o Guia PMBOK
(2004).

3
O modelo de ciclo de vida em cascata consiste basicamente num modelo linear em que cada passo deve ser
completado antes que o próximo passo possa ser iniciado.
4
No modelo espiral para engenharia de requisitos mostra-se que as diferentes atividades são repetidas até uma
decisão ser tomada e o documento de especificação de requisitos ser aceito.
5
Desenvolvimento iterativo é uma estratégia de planejamento de retrabalho em que o tempo de revisão e
melhorias de partes do sistema é pré-definido.
15
2.2.1 O Guia PMBOK®

Um dos principais responsáveis pela difusão do gerenciamento de projetos e da

profissionalização dos gerentes é o PMI (Project Management Institute6). Foi elaborado,
então em 1996, o principal documento do PMI, o Guia PMBOK (2004). Este documento é
referencial em muitas áreas para gerenciamento de projetos e foi desenvolvido para controlar
apenas um projeto por vez.

De acordo com o PMBOK (2004), o ciclo vital de uma metodologia

tradicionalista é composto pelas fases de iniciação, planejamento, execução, controle e
fechamento, e são responsabilidades do gerente do projeto. Estes processos é que irão
conceituar atividades, as quais serão executadas para gerar os produtos que serão entregues ao
cliente no final de cada etapa e as pessoas que irão realizar as atividades. Há uma coerção
bem rígida entre os processos temporais do projeto, e cada um tem suas peculiaridades e
interdependências. Ou seja, a fase a seguir começa apenas após o término da anterior,
caracterizando a definição formal, que diz que esse método é sequencial e linear.

As fases/atividades citadas foram relacionadas pelo Guia PMBOK (2004) de

acordo com um ciclo chamado Plan-Do-Check-Act (PDCA) (Figura 1), onde a fase de
planejamento se refere ao Plan, execução ao Do, controle ao Check e as fases de iniciação e
fechamento, o início e término ou renovação do ciclo, se referem à ação (Act) (Figura 2).

Figura 1 Ciclo PDCA (Plan-Do-Check-Act)

Fonte: PMBOK (2004).

6
Tradução: Instituto de Gerenciamento de Projetos.
16
 Figura 2 Mapeamento entre os grupos de processos e o ciclo PDCA
Fonte: Sacramento (2009).

2.2.2 O RUP

O Rational Unified Process, mais comumente denominado de RUP, é um

processo de Engenharia de Software desenvolvido inicialmente pela RSC (Rational Software
Corporation). Desse modo, é uma metodologia de desenvolvimento e gerenciamento de
software proprietária, onde são definidas regras e papéis, vislumbrando o aumento da
produtividade.

Uma das principais características do RUP é o alto teor de customização. Porém, é

algo complexo, sendo apenas recomendado para grandes equipes e grandes projetos
(KRUCHTEN, 1999).

Do ponto de vista gerencial, o RUP fornece uma solução de como atribuir papéis,
tarefas e responsabilidades de uma forma disciplinada em um ambiente de desenvolvimento
de software, seja ele uma organização, seja ele uma grande equipe de desenvolvimento. Por si
só, o RUP é um produto de apoio à Gerência de Projetos, onde todo método é agregado a
variadas ferramentas de construção, desenvolvimento e gerenciamento.

O RUP possui cinco figuras cruciais: papéis, atividades, artefatos, fluxos de

trabalho (workflows) e disciplinas. Um papel conceitua e controla o comportamento e as
responsabilidades de cada um dos indivíduos ou um conjunto deles na equipe. Uma atividade
é uma parte do trabalho que um membro da equipe executa após estar ciente de qual papel
deve exercer inserido no contexto do projeto. O artefato é o produto do projeto, produzido
durante o desenvolvimento do projeto. É um espaço de informação criado, modificado ou
utilizado em um dado processo. O fluxo de trabalho, por sua vez, é a determinação da

17
sequência do desenvolvimento das atividades, após a atribuição de papéis, para que se possa
ser produzido um artefato. Por fim, a disciplina nada mais é que um conjunto de atividades
inter-relacionadas que fazem parte do mesmo contexto. Ou seja, as disciplinas proporcionam
uma melhor compreensão do projeto sob a visão tradicional, tornando o entendimento de cada
atividade mais fácil (KRUCHTEN, 2001 apud PINHEIRO, 2005).

O RUP faz uso de nove disciplinas, dentre as quais existe a divisão em processo e
suporte. As disciplinas agrupadas em processo são: modelagem de negócios, requisitos,
análise e projeto, implementação, teste e distribuição. Já as disciplinas agrupadas em suporte,
e mais importantes para o estudo de caso em questão, são: configuração e gerenciamento de
mudanças, projeto e ambiente (PINHEIRO, 2005).

O RUP como processo de gerenciamento de projetos de software possui tanto

características técnicas quanto gerenciais. Como o objetivo do trabalho é compará-lo ao
Scrum, visa-se salientar e/ou explicitar seus aspectos gerenciais. Dentre eles, se destaca a
disciplina de Gerência de Projetos e seus papéis, atividades e artefatos.

Gerência de Projetos de Software, no RUP, é o fato de equilibrar objetivos

competitivos, gerenciar riscos e superar as dificuldades para entregar um produto que atenda
às necessidades dos clientes e dos usuários (RATIONAL, 2009).

Logo, a proposta da disciplina de Gerência de Projetos no RUP é desenvolver uma

força estrutural para gerir projetos de software, regras práticas para planejar, alocar recursos
humanos, executar e monitorar projetos e uma estrutura que forneça suporte à gerência de
riscos.

No entanto, esta disciplina não tem objetivo de cobrir todos os aspectos do

gerenciamento real de um projeto. Ela foca principalmente os aspectos do processo de
desenvolvimento iterativo. Gerência de riscos, planejamento de um projeto iterativo através
do ciclo de vida e monitoramento do progresso desse planejamento através das métricas
podem ser alguns exemplos desses aspectos (KRUCHTEN, 2001 apud PINHEIRO, 2005).

18
 Figura 3 Ciclo de Vida do RUP
Fonte: Rational (2009).

O RUP demonstra-se como uma metodologia de desenvolvimento de software que

valoriza a atividade de gerenciamento. Apesar de, em algumas vezes, se tornar muito
burocrático e repetitivo, o processo unificado tem por objetivo garantir o sucesso do projeto
com o cumprimento de várias atividades e artefatos relacionados com a gerência de projetos.
Tais atividades e artefatos são construídos por vários papéis que foram definidos com o
mesmo desejo: dar suporte para realização da gerência de projetos (PINHEIRO, 2005).

2.3 Métodos Ágeis

Os métodos ágeis de gerenciamento de projetos apareceram com contraposto às

chamadas metodologias pesadas – metodologias tradicionalistas – como uma alternativa para
se adaptar ao contexto do mercado atual, que exige resultados cada vez mais rápidos para
atender às necessidades dos clientes, sob condições de constantes mudanças e incertezas.
Pesquisas realizadas na Pontifícia Universidade Católica do Rio Grande do Sul em 2005
demonstram que somente 16,2% dos quase 8380 projetos usados por base da pesquisa, foram
entregues dentro dos prazos, custos e com todas as funcionalidades especificadas (SOUZA,
2008).

Muitos destes empecilhos estão relacionados ao processo de gerenciamento em

cascata – metodologias tradicionais de gerenciamento de projetos de software – que possuem
um nível de burocratização um tanto quanto grande, dificultando mudanças de requisitos no
19
projeto por possuir uma documentação extensa, causando um grande aumento no custo do
projeto. O termo „metodologias ágeis‟ ficou mais popular em 2001, quando especialistas em
vários processos de gerenciamento e desenvolvimento de software se uniram para desenvolver
e estabelecer princípios comuns entre estes métodos, resultando na criação do Agile Manifesto
(2009).

Mesmo possuindo o enfoque voltado para pessoas e não mais para algoritmos, se
preocupando mais com o desenvolvimento do software do que com sua documentação,
usando desenvolvimento iterativo e incremental e aumentando a comunicação as
metodologias ágeis se diferenciam por práticas e ênfases. Esses fatores em comum, de certo
modo, aumentam as possibilidades de atender os requisitos dos clientes, já que estes muitas
vezes passam por mudanças durante o projeto. O cliente possui o domínio do negócio, por
isso agora passa a ser considerado participante e membro da equipe e tem poder de decisão
sobre alterações que aparecerem durante o desenvolvimento do projeto (BOEHM, 2002).

A essência do método ágil de gestão de projetos está em responder de forma mais

rápida e menos dispendiosa às mudanças de requisito ocasionadas pelos clientes ou
ambientes, no aumento da confiança na equipe de desenvolvimento e na entrega cíclica de
versões ao cliente (COCKBURN, 2001).

Os métodos ágeis são adaptativos e não preditivos, como é o caso das

metodologias tradicionais. Eles se adaptam aos novos fatores que surgem durante o
desenvolvimento do projeto ao invés de verificar antecipadamente todos os impedimentos que
podem acontecer durante a construção do produto. O problema em si não está nas mudanças,
pois estas estão sempre sujeitas a ocorrer em quaisquer dos âmbitos. O problema está na
maneira que cada uma das metodologias trata essas mudanças. Como recebem, avaliam e
respondem às mesmas (COCKBURN, 2001).

O ciclo de vida básico de um método ágil pode ser observado na Figura 4. A partir
dela, verifica-se que o processo utiliza a construção de uma versão cumprindo todas as fases
de desenvolvimento para cada produto e, depois da entrega, passa pela fase de refatoração
objetivando melhorias no produto, sem mudar o comportamento do processo. Este ciclo se
repete para cada incremento de produto gerado, até o fim do processo de obtenção do produto
final.

20
 Figura 4 Processo de Desenvolvimento Ágil
Fonte: Souza (2008).

2.3.1 APM

APM (Agile Project Management7) é um conjunto de valores, princípios e práticas

que auxiliam a equipe do projeto a entregar produtos ou serviços de valor em um ambiente
complexo, instável e desafiador. É desejável, no APM, que sejam construídos produtos de
modo ágil e adaptáveis e que sejam criadas equipes de desenvolvimento com as mesmas
características (HIGHSMITH, 2004).

Segundo Cockburn (2001), o APM tem como principais objetivos:

» Favorecer a exploração e a cultura adaptativa;

» Permitir a exploração e a autodisciplina;
» Promover a confiabilidade e a consistência possíveis, dado o grau de
incertezas e complexidade inerente do projeto;
» Ser flexível e facilmente adaptável;
» Permitir visibilidade ao longo do processo;
» Incorporar o aprendizado;
» Englobar as práticas específicas de cada fase;
» Prover pontos de verificação.

Este processo ágil tem suas iterações compostas por cinco fases, são elas
(COCKBURN, 2001):

» Visão: Nesta fase é gerada uma visão geral do produto e do negócio,

também são definidos o escopo do projeto, os participantes e a definição
de como a equipe trabalhará em conjunto;

7
Tradução: Gerenciamento Ágil de Projetos.
21
 » Especulação: Há identificação dos requisitos iniciais do produto, são
elaboradas estimativas e estratégias de resolução dos riscos, estimativas de
custos e ocorre o desenvolvimento de um plano de projeto visando o lucro
do cliente;
» Exploração: Essa fase engloba a entrega dos produtos planejados sob a
forma de incrementos de funcionalidades divididas entre os ciclos do
projeto;
» Adaptação: Nessa fase os resultados são revisados, é feita uma análise da
situação atual do projeto, ocorre a avaliação da equipe e ações adaptativas
podem ser incluídas na próxima iteração;
» Encerramento: Ocorre a finalização das atividades do projeto e são
registradas as lições aprendidas para que possam ser utilizadas em outros
projetos.

2.3.2 Scrum

Teoricamente, a melhor maneira de acelerar o processo de desenvolvimento é

construir apenas o que o cliente valoriza e nada mais. O uso em exagero de formalização –
planejamento extensivamente detalhado das tarefas e documentação em excesso – pode
impedir o andamento do projeto, mas o contrário, ou seja, sem a utilização de algum modo de
gerenciamento, pode gerar um cenário em que os objetivos do projeto não irão ser alcançados.
O uso do Scrum – Metodologia Ágil para Gestão de Projetos – permite desenvolver projetos
bem mais adaptados à nova realidade das organizações de forma rápida. O foco do Scrum é
descobrir uma forma que os membros da equipe trabalhem para produzir um software flexível
em um ambiente de constantes mudanças (SCHWABER, 2004).

A maioria dos projetos em que se é escolhido inserir o Scrum é complexa e

imprevisível. Ele provavelmente não vai solucionar todos os problemas do projeto, mas
ajudará a percebê-los. Essa metodologia ágil serve como guia de boas práticas para o alcance
do sucesso. Uma das características positivas do Scrum é a adaptabilidade, ou seja, a
aplicação das mesmas de formas variadas. Decisões de como usá-lo e criação de estratégias
para chegar a uma produtividade maior e realizar entrega de artefatos mais rapidamente ficam
por responsabilidade de quem está aplicando o processo (SCHWABER, 2004).

22
 Segundo Ken Schwaber (2004), criador da metodologia, o Scrum, os papéis dos
membros do projeto são bem definidos e estão dispostos como a seguir:

» Product Owner: É o proprietário do produto, como o próprio nome diz. É

quem se responsabiliza pelo financiamento do projeto. Define e prioriza
requisitos e funcionalidades e aceita ou rejeita o resultado de cada iteração;
» Scrum Team: É uma equipe formada por entre cinco e dez pessoas.
Seleciona itens priorizados pelo cliente para serem executados durante a
iteração, com liberdade dentro da mesma para cumprir seus objetivos e ao
fim de cada uma delas gera uma versão do produto.
» Scrum Master: Responsável pela garantia das práticas do Scrum. Verifica
se o time está produtivo, mitiga e remove impedimentos que atrapalham o
progresso do projeto e participa de todas as reuniões.

O ciclo de vida do Scrum se inicia com a fase de planejamento (View), onde

requisitos e possíveis restrições são definidos pelo cliente em um documento chamado
Product Backlog. Os requisitos (itens) são priorizados, os recursos para o desenvolvimento de
cada um deles são estimados e o Product Backlog é dividido em releases. Cada release
contém um conjunto de requisitos priorizados, denominado Sprint Backlog, e estes irão ser
desenvolvidos em iterações denominadas Sprints. É aconselhável que cada Sprint dure de
duas a quatro semanas gerando um produto ao final. Logo, é essencial que durante a
construção do produto, os Sprints possuam o mesmo tempo de duração (Time-Box). Nessa
fase – Sprint Planning Meeting – também são escolhidos os membros da equipe de
desenvolvimento, as ferramentas que serão utilizadas e possíveis impedimentos.

Durante a execução de cada uma das Sprints, o time realiza reuniões diárias de
aproximadamente quinze minutos para acompanhar o andamento do projeto (Daily Scrum
Meeting). As variáveis técnicas do ambiente que foram especificadas anteriormente são
controladas nessa fase de desenvolvimento. Ao contrário das metodologias tradicionalistas, o
Scrum considera essas variáveis durante todo o processo, não apenas na inicialização do
projeto, aumentando com isso a flexibilidade em relação à adequação de mudanças. Ao final
de cada Sprint, é realizada uma reunião de revisão denominada Sprint Review Meeting, onde o
time mostra o resultado ao cliente e ao Scrum Master.

Por fim, o Scrum Master realiza uma reunião com sua equipe (Sprint
Retrospective Meeting) analisando a execução do progresso do projeto e a versão do produto
23
gerada. Essa reunião tem por objetivos melhorar o processo, a equipe e o produto para o
próximo Sprint. A Figura 5 ilustra de forma simples o ciclo de desenvolvimento do Scrum.

Figura 5 Ciclo de Desenvolvimento do Scrum

Fonte: Improve It (2009).

2.3.3 Extreme Programming

Para Kent Beck (2000), criador da Extreme Programming, XP é uma metodologia

ágil para pequenas e médias equipes desenvolvendo software com requisitos vagos e em
constante mudança. Extreme Programming usa times integrados de programadores, clientes, e
gerentes para desenvolver software de alta qualidade em velocidade alta. Reúne também um
conjunto de práticas de desenvolvimento de software já testadas, que quando estimuladas as
sinergias entre elas, gerarão vastas melhorias em produtividade global e satisfação do cliente
(JEFRIES, 2009).

Extreme Programming é uma disciplina de desenvolvimento de software baseada

nos valores simplicidade, comunicação, realimentação e coragem. Trabalha reunindo o time
inteiro na presença de práticas simples e através do feedback permite à equipe observar onde a
mesma se encontra e afinar as práticas para situações únicas.

As raízes do XP estão na comunidade Smalltalk8 com a colaboração íntima de

Kent Beck e Ward Cunningham – este, por sua vez, programador americano criador dos

8
Linguagem de programação orientada a objetos fracamente tipada.
24
conceitos de wiki –, no final da década de 1980. No início dos anos 90 os dois refinaram suas
práticas em numerosos projetos, estendendo o desenvolvimento de software adaptável e
orientado a pessoas. O passo mais importante, da prática informal para uma metodologia
aconteceu na primavera de 1996. Kent foi convidado para revisar o andamento de um projeto
de folha de pagamento para a montadora de veículos. Este estava sendo desenvolvido em
Smalltalk por uma empresa contratada e estava em dificuldades. Devido à baixa qualidade da
base de código, Kent sugeriu que fosse jogado todo fora, iniciando a partir daí o projeto
Chrysler C3 que serviu como uma base de aplicação e treinamento para o XP (FOWLER,
2000).

2.3.3.1 Valores de Extreme Programming

O XP é uma disciplina de desenvolvimento de software baseada nos seguintes

valores: comunicação, simplicidade, feedback e coragem. Ele também prega 12 práticas que
projetos de XP devem seguir. Muitas destas práticas são antigas, experimentadas e testadas.
Ainda que esquecidas por muitos, são incluídas na maioria dos processos planejados. Com
base nestas técnicas, XP tece uma sinergia entre elas onde cada uma é reforçada pela outra.
(FOWLER, 2000). A seguir descrevem-se detalhadamente os valores da metodologia XP:

2.3.3.1.1 Comunicação

Uma equipe de XP prospera ao entender e compartilhar o problema e o software.

O método mais eficiente e efetivo de alcançar compartilhamento é tendo uma comunicação
face a face. Qualquer obstáculo que obstrua a comunicação eficiente precisa ser removida. O
valor de comunicação representa a convicção da metodologia XP de que a chave para um
projeto próspero é a comunicação entre os membros do projeto (e consequentemente precisa
ser apoiado através de práticas). Não é declarado por que comunicação é tão importante, mas
é seguro assumir que a comunicação é vista como um valor fundamental para a coordenação e
colaboração em um projeto (RIEHLE, 2000).

O XP procura manter a fluência da comunicação através da utilização de diversas

práticas que não podem ser feitas sem comunicação. Estas práticas fazem sentido em curto
prazo, como testes de unidades, programação em pares e estimativas de tarefas. Como
consequência destas práticas é que programadores, gerentes e clientes precisam se comunicar.
É importante lembrar, que em se tratando do valor comunicação em XP, sempre significa
comunicação verbal (BECK, 2000).
25
2.3.3.1.2 Simplicidade

A simplicidade visa a facilitação contínua do design do software, não adicionando

partes desnecessárias ao código, mantendo-o claro, com nomes significativos e algoritmos
sempre quebrados em partes menores, para que não possua código nem funcionalidade
duplicados. A flexibilidade adicionada logo no começo do design pode ser desnecessária e
tornar o software complexo, o melhor estado do software no momento da mudança é o
simples (BECK, 2000).

O valor da Simplicidade representa a convicção do XP de que não se deve investir

no futuro, mas só nas necessidades imediatas do projeto. Estando subentendida neste valor, há
a suposição que o futuro não pode ser predito confiantemente e preocupar-se com isso hoje
não é economicamente inteligente (RIEHLE, 2000).

Complementando, o valor “Simplicidade” prega que se mantenha o sistema tão

simples quanto possível. Isso significa não gastar tempo e esforço para implementar
características que podem não ser necessárias depois. Projetos de XP constroem o mais
simples possível, confiantes de que pode ser mudado depois a pequeno custo adicionado.
Simplicidade e comunicação possuem uma relação de apoio mútuo. Quanto mais contínua é a
comunicação, mas evidente fica o que deve e o que não deve ser feito. A simplicidade deve
ser aplicada em todas as atividades do processo, procurando sempre o mais simples que
possivelmente funcione (HAYES, 2001).

2.3.3.1.3 Feedback

O valor feedback significa que é importante ter um sistema rodando a qualquer

hora. Isso dá para o desenvolvedor a informação fidedigna sobre seu funcionamento (aqui o
feedback não está direcionado aos seres humanos mas, sim a respeito do estado de
desenvolvimento). Efetivamente, o sistema e seu código servem como o oráculo incorruptível
para informar sobre o progresso e estado do desenvolvimento. O feedback também é um meio
para orientação e tomada de decisão, para onde ir (RIEHLE, 2000).

O posicionamento concreto do estado corrente do projeto é absolutamente

essencial, fazendo que todo o problema seja evidenciado o mais cedo possível para que possa
ser corrigido o quanto antes, da mesma forma fazendo com que as oportunidades sejam
descobertas o mais precocemente possível para que possam ser mais bem aproveitadas. O
feedback funciona em conjunto com comunicação e simplicidade. Quanto mais feedback
26
existir, mais fácil será a comunicação. Se os indivíduos envolvidos no projeto estiverem se
comunicando claramente, aprenderão sobre o sistema e saberão o que testar.

2.3.3.1.4 Coragem

Equipes prósperas de desenvolvimento de software precisam constantemente

trabalhar na extremidade do caos, eles precisam agir rapidamente sem perder o controle. Isto
às vezes significa cometer algumas falhas, mas sem perder a coragem para se tomar as
decisões certas mesmo quando se pressionado para fazer outra tarefa (HAYES, 2001).

Na verdade é preciso que a equipe não tenha medo de: parar quando se está
cansada; deixar as decisões do negócio para o cliente; apontar um problema no projeto; pedir
ajuda ao parceiro e aos clientes quando necessário; simplificar o código que já está
funcionando; dizer ao cliente que não será possível implementar um requisito no prazo
estimado; fazer alterações no processo de desenvolvimento, ou muitas vezes jogar o código
fora e recomeçar. Para tudo isto é preciso muita coragem (LONGMAN, 1998).

Os valores de comunicação, simplicidade, feedback e coragem servem como

suporte para as doze práticas do XP, que serão apresentadas no tópico seguinte.

2.3.3.2 Práticas de Extreme Programming

As doze práticas promovidas pelo XP se forem examinadas individualmente

apresentarão falhas, mas uma das forças do XP é que as práticas se combinam de um modo
mútuo apoiando-se. Juntas as práticas conduzem a um complexo comportamento emergente.
Cada prática tem sua função para manter o custo de mudança baixo (HAYES, 2001).

De acordo com BECK (2000) as doze práticas do XP são mapeadas em três

categorias, a primeira englobando as práticas de programação, a segunda as práticas
orientadas para a equipe e a terceira contempla os processos através dos quais a equipe de
programação relaciona-se com o cliente. As práticas estão dividas nas categorias da seguinte
forma:

a) Programming – Simple design (projeto simples), testing (testes), refactoring

(reconstrução), coding standards (código padrão);

b) Team - Collective ownership (código coletivo), continuous integration

(integração continua), metaphor (metáfora), coding standards (código padrão), 40-hour week

27
(40 horas por semana), pair programming (programação em par), small releases (versões
pequenas);

c) Process - On-site customer (cliente no local), testing (testes), small releases

(versões pequenas), planning game (planejamento do jogo).

2.3.3.2.1 Simple Design

Manter o custo de manutenção baixo significa manter o design tão simples quanto
possível. Também significa não implementar funcionalidades (features) que podem ou não
serem utilizadas mais tarde. Em um projeto XP se constrói as funcionalidades tão simples
quanto possível, acreditando que elas poderão ser alteradas mais tarde com um pequeno custo
adicional (HAYES, 2001).

2.3.3.2.2 Testing

Todo o requerimento é refletido em um teste de aceitação. Os testes de aceitação

são produzidos pelos próprios clientes. Os programadores escrevem os casos de teste antes de
escreverem o código, usam o teste para focar o que tem que ser alcançado e também para
especificar a interface. Todos os testes são automatizados e executados regularmente
(HAYES, 2001).

2.3.3.2.3 Refactoring

É o processo de melhorar o design do código sem afetar seu comportamento

externo. O refactoring é feito de forma que o código seja mantido tão simples quanto
possível, pronto para qualquer mudança futura (HAYES, 2001).

2.3.3.2.4 Coding Standards

Codificar é uma atividade de equipe. Com o passar do tempo pessoas diferentes

trabalharão em diferentes pedaços do código, e disparidades de estilo de codificação e
convenções fazem o código mais difícil de trabalhar. Para a equipe ser efetiva precisa-se de
um código padrão, do qual ao ser visto parece ser escrito pela mesma pessoa (HAYES, 2001).

2.3.3.2.5 Collective Ownership

Qualquer pessoa da equipe pode alterar qualquer código, contanto que apoiado
por um parceiro, obedecendo aos padrões e assegurado por todo o trabalho de testes quando

28
eles terminarem. O benefício disto é que remove os gargalos e os problemas de distorção de
arquitetura que podem surgir (HAYES, 2001).

2.3.3.2.6 Continuous Integration

A equipe XP trabalha em etapas curtas e integra o código periodicamente. Isto

significa que os problemas de integração são descobertos logo ao serem criados, desta forma é
razoavelmente fácil retificá-los. Integração contínua evita desenvolvimentos incompatíveis e
ajuda assegurar que toda a equipe esteja trabalhando na mais recente versão do sistema todo o
tempo (HAYES, 2001).

2.3.3.2.7 Metaphor

A metáfora de sistema dá para a equipe um vocabulário consistente para discutir

os problemas e suas soluções. Significa falar sobre o sistema em termos de objetos de negócio
(HAYES, 2001).

2.3.3.2.8 40-Hour Week

Desenvolvimento de software é um exercício criativo, e ninguém pode ser criativo

se está exausto. Restringindo o número de horas por uma semana de trabalho mantém as
pessoas descansadas, reduz a sobrecarga e melhora a qualidade do produto acabado (HAYES,
2001).

2.3.3.2.9 Pair Programming

Toda a produção de desenvolvimento é feita por duas pessoas que compartilham

uma máquina. Isto é muito mais eficiente que ter duas pessoas programando separadamente.
Os pares frequentemente giram. Desta forma, o conhecimento e a experiência circulam pela
equipe e também o código é revisado continuamente (HAYES, 2001).

2.3.3.2.10 Small Releases

Os releases devem ser tão pequenos quanto possível, agregando bastante valor ao
negócio. Equipes de XP podem executar lançamentos em ciclos de algumas semanas, porque
estão trabalhando em passos pequenos, têm testes para efetuar uma regressão, e estão
integrando continuamente. Alguns projetos de XP executam lançamentos diariamente
(NERUR, 2005).

29
2.3.3.2.11 On-Site Customer

Nenhuma exigência escrita está completa e sem ambiguidade. Os programadores

sempre precisam ter acesso a um cliente para esclarecer os requisitos, não importando a
quantidade de esforço dedicada na especificação original. Uma equipe de XP mantém isto
simples saltando muito o esforço destinado para a especificação, e tendo um cliente todo o
tempo disponível para os programadores. Programadores de XP não adivinham os detalhes de
uma feature. Pelo contrário, eles perguntam para o cliente (HAYES, 2001).

2.3.3.2.12 Planning Game

Classifica as negociações regulares em cima das funcionalidades que acontecem

em um projeto de software e as transforma em um jogo. O Jogo de Planejamento é realizado
em repetição para determinar que funcionalidade irá ao próximo lançamento. Programadores
tomam decisões técnicas (estimativas) e os clientes tomam decisões empresariais,
selecionando as funcionalidades com a maioria de benefícios (HAYES, 2001).

Figura 6 Práticas do XP
Fonte: Beck (2000).

30
 CAPÍTULO 3
Estudo de Caso: TrainingCad

No capítulo anterior foram explanados vários conceitos sobre as metodologias de

gerência de projetos tradicionais e ágeis, assim como, conceitos do Scrum, XP e a importância
de sua utilização para o sucesso do produto final. O conteúdo descrito no Capítulo 2 visa
facilitar o entendimento do funcionamento do processo de gerência e desenvolvimento do
projeto TrainingCad, a razão da utilização desse método e todas as etapas que compuseram o
processo.

Nesse capítulo também será apresentado o contexto do estudo comparativo, os

detalhes do projeto e de seu desenvolvimento, além de uma proposta de mudança de
metodologia de gerência do projeto de RUP para Scrum alinhado às praticas do XP.

3.1 Contextualização

A UPE Consultoria Jr. é uma empresa júnior criada pelos cursos de Sistemas de
Informação e Administração com Ênfase em Marketing de Moda do campus Governador
Miguel Arraes de Alencar da Universidade de Pernambuco. Este campus se situa no agreste
pernambucano, mais especificamente na cidade de Caruaru.

O cenário acadêmico onde se encontra essa empresa júnior destaca as atividades

de ensino e aprendizado de tecnologias e conceitos inerentes ao processo de desenvolvimento
e gestão de software. Por esse motivo, a presidência da empresa, juntamente ao seu restante,
tomou a decisão de criar o Núcleo de Treinamento.

O Núcleo de Treinamento da UPE Consultoria Jr. é a fatia da empresa responsável

pela qualificação tanto dos seus próprios funcionários quanto dos alunos/clientes inscritos em
aulas, palestras, mini-cursos ou workshops. A responsabilidade da criação, organização e
desenvolvimento – inclui-se coordenação – também foi atribuída ao Núcleo de Treinamento.

31
 Inicialmente, o Núcleo de Treinamento contava com oito pessoas. Durante a
organização de um evento, a coordenadora do núcleo, Cláudia César, percebeu a necessidade
de introdução de métodos de gerenciamento de inscrições dos clientes nos cursos promovidos
pelo próprio núcleo. Então, propôs a criação de software que não apenas gerenciasse, mas
também tornasse os processos do desenvolvimento dos cursos mais rápidos.

Após a apresentação da proposta à Universidade e à presidência da empresa,

houve a aprovação. Foram, então, atribuídos os papéis e as tarefas do projeto a alguns dos
integrantes do Núcleo de Treinamento:

» Gerente de Projeto;
» Engenheiro de Software;
» Desenvolvedores (dois integrantes).

O processo de desenvolvimento escolhido foi o RUP, por ser a metodologia que já

estava em uso na empresa. O conhecimento sobre a metodologia foi o ponto crucial para sua
escolha, já que na disciplina de Engenharia de Software do curso de Sistemas de Informação –
todos os envolvidos eram alunos desse curso – a explanação sobre o processo é intensa.

A coordenadora do Núcleo de Treinamento, baseada num dos próximos cursos a

ser desenvolvido e baseada também nos prazos dos contratos de estágio dos alunos, definiu
uma data base para entrega do produto final do projeto: 12 de junho de 2009. Após isso, foi
definido um cronograma pelo gerente do projeto, incluindo as tarefas a ser realizadas e os
documentos a ser confeccionados, sumarizando os marcos intermediários. Esse cronograma
pode ser visualizado na Tabela 1.

Tabela 1 Cronograma de Marcos Sumarizado do TrainingCad

Cronograma de Marcos Sumarizado
Apresentação do projeto à universidade 22 de março de 2009
Planejamento do projeto 14 de abril de 2009
Modelagem do negócio e levantamento de requisitos 20 de abril de 2009
Análise e projeto 24 de abril de 2009
Implementação 18 de maio de 2009
Testes 05 de junho de 2009
Fonte: Trainingcad, 2009.

32
3.2 TrainingCad

O TrainingCad é um sistema desktop proprietário do Núcleo de Treinamentos da

UPE Consultoria Jr. e tem por objetivo automatizar e padronizar os processos de inscrição de
alunos/clientes em cursos da empresa. Ele foi desenvolvido de modo que pudesse atender às
necessidades dessa empresa quanto aos processos utilizados, usando a experiência dos
responsáveis pelo projeto na solução dos impedimentos.

Segundo o termo de abertura do projeto, o projeto TrainingCad:

visa desenvolver um sistema desktop de gerenciamento de inscrições

(cadastro e consulta) de alunos em eventos realizados pela UPE
Consultoria Jr. O sistema deve realizar operações tais como cadastro de
qualquer evento realizado, a princípio, pelo Núcleo de Treinamento. O
sistema deve realizar o cadastro de dados pessoais bem como a matrícula
de cursos de interesse do cliente. O que permite a criação de um banco de
dados e extração de informações relevantes, tais como o perfil do cliente.
(TRAININGCAD - Termo de Abertura do Projeto, 2009, p.01).

O projeto durou pouco menos de três meses – de 23 de março a 12 de junho de

2009 – e teve seu desenvolvimento guiado pelo método tradicional de desenvolvimento de
software chamado RUP. Possuiu três papéis bem definidos:

» Gerente de Projeto: Coordenou o projeto envolvido no processo,

principalmente no que diz respeito à fatia inerentemente gerencial.
» Engenheiro de Software: Arquitetou e coordenou o projeto sob o enfoque
técnico e estrutural.
» Equipe de desenvolvimento: produziram os artefatos de software
propriamente ditos através do seguimento das premissas propostas pela
gerente do projeto e obedecendo aos parâmetros de arquitetura de software
anteriormente definidos.

O método de desenvolvimento escolhido foi o RUP, pelo fato da empresa já

possuir projetos que usavam o mesmo processo. Ou seja, a principal motivação para uso do
RUP foi a prévia experiência da equipe adquirida no desenvolvimento de outros projetos
passados.

A Figura 7 exibe a tela de início do TrainingCad. Esta tela foi construída baseada
em requisitos definidos pelos futuros usuários do aplicativo: os membros do Núcleo de
Treinamento.
33
 Figura 7 Tela Principal do TrainingCad
Fonte: Trainingcad (2009).

A principal restrição durante o andamento do projeto foi o prazo. O software

deveria ser entregue impreterivelmente até o dia 12 de junho de 2009. Este projeto apresentou
também uma intensa caracterização e hierarquia de papéis. Além disso, seu processo de
gerenciamento teve foco inicial em estimar o tempo, gerenciar recursos – de software, de
hardware e humanos – minimizar os riscos e monitorar os requisitos e cronograma.

Um dos maiores problemas identificados no Núcleo de Treinamento da UPE

Consultoria Jr. foi a falta de controle sobre o perfil dos seus clientes. Não eram arquivados, ou
analisados, ou ainda estudados, os tipos de alunos/clientes que frequentavam os cursos. Por
esse motivo, a criação deste sistema foi solicitada, o que só reforça sua importância dentro
deste contexto aqui apresentado.

3.3 Gerenciamento e Desenvolvimento do Projeto

A metodologia de gerenciamento e desenvolvimento escolhida para desenvolver o

projeto TrainingCad foi o RUP. Essa metodologia foi escolhida por ser o método utilizado
com constância na empresa. Desse modo, as disciplinas de gerenciamento dessa metodologia
ditam que alguns documentos e tarefas teriam de ser realizados em relação à extensa
formalização, se comparadas aos métodos ágeis.

34
 Logo, foram definidos marcos durante a execução do projeto para a elaboração
dos documentos necessários. O marcos definidos foram os seguintes:

» Apresentação da Proposta à UPE Consultoria Jr.;

» Elaboração do Plano de Projeto;
» Elaboração do Documento de Requisitos;
» Elaboração dos Documentos de Análise e Planejamento;
» Entrega do 1º release;
» Entrega do 2º release;
» Elaboração do Documento de Testes;
» Entrega do release final.

Pode-se visualizar a disposição cronológica do gerenciamento desses marcos

através do gráfico de Gantt9 do projeto TrainingCad gerado pelo aplicativo dotProject (Figura
8).

Figura 8 Gráfico de Gantt do TrainingCad

Fonte: Trainingcad (2009).

Após a apresentação à universidade, iniciou-se a fase de planejamento do

TrainingCad. No planejamento houve a predefinição do modo de gerenciamento de variáveis
do projeto. Comportamento em relação à mudança na lista de requisitos, decisões a serem
tomadas de acordo com a tabela de estimativa de riscos, entre outros. Nessa fase, também foi
modelado o negócio e elicitados os requisitos. Na Tabela 2 e 3 pode-se observar todos os

9
Um gráfico usado na gerência de projetos para planejar e acompanhar o progresso do projeto. O tempo é
indicado por colunas atravessadas no gráfico, com tarefas individuais representadas por flechas terminando em
pontos. O tamanho e posições das flechas mostram a data de início e a duração das tarefas. Você também pode
usar linhas sólidas ao invés de flechas terminando em pontos.
35
requisitos funcionais e não-funcionais definidos a partir da confecção do documento de
requisitos do projeto TrainingCad.

Tabela 2 Requisitos Funcionais do TrainingCad

Identificação Descrição Prioridade
RF-01 Efetuar Login Essencial
RF-02 Efetuar Logout Essencial
RF-03 Incluir Aluno Essencial
RF-04 Atualizar Aluno Essencial
RF-05 Excluir Aluno Essencial
RF-06 Consultar Aluno Essencial
RF-07 Incluir Curso Essencial
RF-08 Atualizar Curso Essencial
RF-09 Excluir Curso Essencial
RF-10 Consultar Curso Essencial
RF-11 Realizar Inscrição Essencial
RF-12 Alterar Inscrição Essencial
RF-13 Cancelar Inscrição Essencial
RF-14 Consultar Inscrição Essencial
RF-15 Criar Conta de Usuário Essencial
RF-16 Alterar Senha de Usuário Essencial
RF-17 Excluir Conta de Usuário Essencial
RF-18 Gerar Relatórios Desejável
Fonte: Trainingcad (2009).

Tabela 3 Requisitos Não-Funcionais do TrainingCad

Identificação Descrição
O sistema deve ser implementado na linguagem Java, com foco para
RNF/PROC-01
computadores desktops.
RNF/PROC-02 Toda atualização nas informações tratadas devem ser realizadas no servidor.
Deverá ser feita uma documentação que contenha o diagrama de classes, já
RNF/PROC-03 que a linguagem utilizada será orientada a objetos, e informações sobre o
código-fonte do projeto.
Não deverá existir custo adicional para a implantação e desenvolvimento do
RNF/EXT-01
sistema.
Implementação de mecanismos de segurança e integridade dos dados
RNF/CONF-01
manipulados durante a execução do sistema.
O espaço disponível em disco para informações deve ser capaz de armazenar
RNF/CONF-02
todos os dados/atualizações que forem adicionados no sistema.
RNF/SEG-01 Restrição de acesso e funcionalidades com definição de senhas.
RNF/USA-01 Robustez para atender ao acesso simultâneo de usuários às bases de dados.
Alto tratamento de exceções para conseguir recuperação de eventuais erros
RNF/USA-02
do sistema.
Uso de interface amigável para permitir a utilização do sistema em toda a
RNF/USA-03
sua potencialidade.
Fonte: Trainingcad (2009).

Na apresentação da proposta, foram definidos os objetivos, a demanda e o escopo

do projeto. No plano de projeto foram traçados os métodos e formas de gerenciamento de
36
cada uma das disciplinas do RUP envolvidas no desenvolvimento do TrainingCad. A partir
daí, iniciaram-se os trabalhos da fase de modelagem de negócio e levantamento de requisitos.
Nessa fase foram elicitadas as funcionalidades que o sistema TrainingCad deveria possuir,
além da construção do diagrama de Casos de Uso10 (Figura 9).

Figura 9 Diagrama de Casos de Uso do TrainingCad

Fonte: Trainingcad (2009).

Após isso, foram planejados os aspectos funcionais do projeto. Foi definida a

relação entre as tarefas e as estimativas de tempo do projeto, foram definidos os recursos
disponíveis e necessários a sua evolução. Nesse momento também foram definidos o
gerenciamento de requisitos e cronograma (Tabela 4), como também o gerenciamento de
riscos (Tabela 5).
10
Um tipo de diagrama que descreve a sequência de eventos de um ator que usa um sistema para completar um
processo e o detalhamento de cada um deles.
37
Tabela 4 Cronograma detalhado do TrainingCad
Tarefa Dependência Resp. Atividade Início Fim
Apresentação da
T1 - Gerente Proposta à UPE 14/04/2009 14/04/2009
Consultoria Jr.
Elaboração do Plano de
T2 - Gerente 17/04/2009 17/04/2009
Projeto
Gerente e Elicitação de Requisitos
T3 - 20/04/2009 23/04/2009
Engenheiro e modelagem
Elaboração do
T4 T3 Engenheiro Documento de 23/04/2009 23/04/2009
Requisitos
Gerente e
T5 - Análise e Planejamento 24/04/2009 07/05/2009
Engenheiro
Desenvolvedores e
T6 - 1º release 08/05/2009 21/05/2009
Engenheiro
T7 T6 Engenheiro Entrega do 1º release 21/05/2009 21/05/2009
Desenvolvedores e
T8 T7 2º release 22/05/2009 04/06/2009
Engenheiro
T9 T8 Engenheiro Entrega do 2º release 04/06/2009 04/06/2009
Elaboração do Plano de
T10 - Engenheiro 05/06/2009 08/06/2009
Testes
Execução do Plano de
T11 T10 Desenvolvedores 09/06/2009 11/06/2009
Testes
Desenvolvedores e Elaboração do
T12 T11 11/06/2009 11/06/2009
Engenheiro Documento de Testes
Fonte: Trainingcad (2009).

Tabela 5 Gerenciamento de Riscos do TrainingCad

Risco Probab. Dano Estimado Aceitab. Mitigação
Falta de horário para as Mitigar: Acompanhar e
reuniões semanais, em cobrar, através de e-mail, que
vista que os componentes Moderado Moderado Moderado Tolerável todos compareçam às
possuem horários reuniões quando essas forem
divergentes. marcadas.
Troca de funções dos Mitigar: Ajustar novo
componentes durante o Muito Muito cronograma e acompanhar de
Baixo Aceitável
projeto, acarretando atraso Baixo Baixo/Baixo forma maior o cronograma
no cronograma. do novo programador.
Cronograma do projeto Evitar: Controlar de forma
Moderado Alto Moderado/Alto Não aceitável
estourar. rigorosa o cronograma.
Mudanças nos requisitos
Mitigar: Realizar, sempre
durante a implementação,
quando houver mudança nos
em função da pouca clareza Baixo Alto Moderado Tolerável
requisitos. a validação dos
das especificações dos
mesmos junto ao cliente.
requisitos.
O sistema depois de
entregue ao cliente gerar Muito Mitigar: Reunir equipe e
Moderado Baixo Aceitável
valores incompletos ou Baixo reparar bugs.
incorretos.
O sistema, depois de Evitar: Controlar,
entregue, não ter o Muito rigorosamente, durante todo
Baixo Moderado/Alto Não aceitável
desempenho ideal para a Alto o projeto os requisitos não
realidade da empresa. funcionais de desempenho.
Fonte: Trainingcad (2009).
Depois de cumprida mais esta tarefa, foi realizada a análise de cada um dos casos
de uso, aplicando as regras de engenharia de software. Foram feitos a descrição sumária,
definidos os atores envolvidos, especificadas as classes de análise e criados os diagramas de

38
Sequência11 (Figura 10) e de Classes12 (Figura 11) para cada um dos requisitos funcionais do
projeto.

Figura 10 Diagrama de Sequência do Requisito Funcional Efetuar Login do TrainingCad

Fonte: Trainingcad (2009).

11
é um diagrama que representa a sequência de processos (mais especificamente, de mensagens passadas entre
objetos) num programa de computador.
12
é uma metodologia usada para descrever os tipos de objetos no sistema e os vários tipos de relacionamento
estático existente entre eles, bem como atributos e operações de uma classe e as restrições.
39
Figura 11 Diagrama de Classes do Requisito Funcional Efetuar Login do TrainingCad
Fonte: Trainingcad (2009).

Após a fase de planejamento do projeto, se deu a fase de desenvolvimento

propriamente dito. Essa fase se deu em três iterações: primeiro release, segundo release e
release final. Durante esta fase, a equipe de desenvolvimento juntamente ao engenheiro de
software, construiu o produto resultante do projeto TrainingCad. Todos os arquivos e códigos
do sistema eram depositados no repositório do próprio projeto, que se encontrava no
aplicativo dotProject, adotado pela empresa. Todas as diretrizes de engenharia e arquitetura
do software definidas nos documentos de requisitos e análise foram seguidas pela equipe de
desenvolvimento.

O primeiro release gerou uma versão beta do projeto. Essa versão continha
apenas o esqueleto da aplicação e algumas das telas da versão definitiva. A Figura 12
apresenta a tela referente à funcionalidade de cadastro de alunos.

40
 Figura 12 Tela de Cadastro de Alunos do TrainingCad
Fonte: Trainingcad (2009).

No segundo release foram entregues todas as funcionalidades finalizadas,

aguardando apenas os testes, seguidos das possíveis correções e melhorias. Após a aplicação
exaustiva dos planos de teste através do uso de ferramentas adequadas para o trabalho, pôde
ser então entregue o release final.

Apenas como maneira ilustrativa, na Figura 13 é apresentada a tela de consultas

do TrainingCad em sua versão final, oferecendo as funcionalidades de consulta, listagem e
geração de relatórios de alunos, cursos e inscrições.

Inserido no contexto dessa fase, se deu início ao planejamento de testes. Foi

elaborado pelo engenheiro de software um plano de testes, o qual foi executado após a entrega
dos primeiro e segundo releases – marcos anteriormente determinados – para se obter um
retorno sobre o estado do software e quais modificações ou reparos deveriam ser realizados.
Finalizados os procedimentos de testes e corrigidos os erros encontrados, o próximo passo foi
a elaboração do documento de testes, onde se encontravam os planos de testes, os
procedimentos realizados e os resultados obtidos. A seguir pode-se ver brevemente uma das
tabelas de estratégia de testes (Tabela 6).

41
Figura 13 Tela de Consultas do TrainingCad
Fonte: Trainingcad (2009).

Tabela 6 Tabela de Estratégia de Teste de Stress do TrainingCad

Teste de Stress
Objetivo do teste Analisar o comportamento do sistema sob
condições adversas.
Técnica Rodar o sistema em uma máquina com
configuração inferior a 256 MB de RAM e
velocidade de CPU igual ou inferior a 900
MHz.
Critério de Finalização Os dados de saída são expelidos conforme o
esperado para as entradas válidas e no tempo
estimado nos requisitos não-funcionais. Se o
tempo de resposta for 100 vezes superior ao
tempo máximo estimado para um único
cadastro, então o teste falhou e o sistema está
ineficiente.
Considerações Especiais Não há.
Fonte: Trainingcad (2009).

42
3.4 Proposta de Aplicação do Scrum

O grande objetivo deste trabalho é comparar as características assumidas pelo

projeto com as características esperadas do desenvolvimento do mesmo projeto tomando por
metodologia de gerenciamento o Scrum aliado às práticas de desenvolvimento do XP. Para
isto, é necessário então que se apresente uma proposta para desenvolvimento baseada no
método escolhido, permitindo assim uma melhor estimativa dos resultados. Na próxima seção
esta proposta é apresentada com base em todo referencial teórico pesquisado em termos de
métodos tradicionais e ágeis aliados à experiência no TrainingCad.

Na Revisão da Literatura (Capítulo 2) foram vistas as características das

metodologias em questão. Levando-se em conta o perfil dos integrantes, do projeto e de seu
proprietário, será demonstrada a forma com que o Scrum, junto ao XP, será aplicado ao
gerenciamento e desenvolvimento do projeto TrainingCad.

3.4.1 Proposta

Esta proposta se baseia nas premissas básicas de métodos ágeis mais fortemente
atreladas ao Scrum. Neste caso, a partir desta proposta torna-se possível prever algumas
mudanças, por meio da análise comparativa realizada, para uma possível reimplementação do
mesmo projeto ou de outros que possuam características similares.

Como promotor das novas tarefas de gerenciamento do projeto TrainingCad, o

Scrum, auxiliado pelo XP, irá guiar o gerente de projeto – no caso Scrum Master – na
coordenação destas mesmas tarefas. A fase de visão (View) deverá iniciar-se e o Product
Backlog deverá ser criado juntamente ao proprietário do produto, bem como suas divisões e a
quantidade de releases. A equipe do projeto, então, deverá definir o Time-Box de cada um dos
Sprints para respeitar o calendário de marcos sumarizado definido pela gerente do Núcleo de
Treinamento.

Seriam implementados o Planning Game, as User-Stories e o Burndown Chart13

especificando a definição dos requisitos extremamente essenciais ao sistema (simple design).
Após isso, se iniciará a codificação do projeto em si, em duplas (pair programming) para que
pequenos releases sejam entregues de acordo com os Sprints definidos anteriormente. Essa

13
Representação gráfica do trabalho a fazer em função do tempo. O trabalho pendente (ou atraso) é representado
freqüentemente no eixo vertical, enquanto o tempo é representado longo da horizontal.
43
codificação seria padronizada para que no revezamento o código escrito seja compreendido
por todos os membros da equipe do projeto.

Enquanto isso, as User-Stories seriam usadas como insumo para desenvolvimento

dos casos de testes e seus scripts para serem realizados ao final de cada release (Testing).
Também seriam realizadas reuniões diárias para verificação e remoção dos impedimentos que
surgiram ao longo do dia anterior pelo gerente do projeto (Daily Scrum Meeting).

E, por fim, ao final de cada um dos Sprints, seria realizada uma reunião para
demonstrar ao cliente o release respectivo (Sprint Review Meeting) e analisar a execução do
progresso do projeto (Sprint Retrospective Meeting) até o fim do número de iterações definido
no início do projeto, respeitando os prazos.

Dessa forma, a quantidade de integrantes dedicados à documentação diminuiria.

Essa força de trabalho estaria agora direcionada a outras atividades como o Refactoring e o
contato constante com o cliente (client on-site). O tempo de desenvolvimento do projeto
também poderia diminuir, já que a fase de planejamento diminuiria consideravelmente. O
ciclo de desenvolvimento não se daria mais em duas iterações – releases – mas em quatro,
pois o Scrum adota duas semanas como tempo mínimo para uma iteração, e de acordo com o
perfil do projeto em questão, embasado no Capítulo 2, dois meses seriam suficientemente
aceitáveis. A documentação do software teria uma redução extrema, caindo de oito artefatos
para apenas quatro: Product Backlog, Planning Game, User-Stories e Burndown Chart. Com
isso a hierarquia de papéis mudaria também. Agora o engenheiro de software passaria a
integrar o time de desenvolvimento junto a um dos desenvolvedores. O antigo gerente do
projeto passaria à condição de Scrum Master.

Por fim, o custo de desenvolvimento do projeto diminuiria bastante, além de ser

concluído em menor tempo, justamente por ser a metodologia exatamente aplicável ao
tamanho, tempo e custo do projeto. De forma ilustrativa, encontram-se nas Figuras 14 e 15 o
ciclo de desenvolvimento anterior à proposta e o ciclo resultante da proposta de aplicação do
Scrum alinhado ao XP.

44
 Figura 14 Fases do Ciclo de Desenvolvimento anterior à Proposta
Fonte: Autor, adaptado de Pressman (2002).

Figura 15 Ciclo de Desenvolvimento após aplicação da Proposta

Fonte: Autor, adaptado de Improve It (2009).

45
 CAPÍTULO 4

Análise Comparativa

Nesta seção serão descritos os resultados do projeto já realizado e os resultados

esperados na aplicação da proposta feita na seção anterior. Será construída uma tabela onde
aparecerão os itens mais importantes da disciplina de gerenciamento e desenvolvimento de
projetos pertinentes ao TrainingCad. Conhecendo o perfil do projeto TrainingCad e seu
proprietário, serão avaliados os seguintes aspectos na comparação da metodologia proposta
em relação à metodologia utilizada.

Tabela 7 Tabela Comparativa entre as Metodologias usadas e propostas no TrainingCad

Aspectos Comparados RUP Scrum (alinhado ao XP)
Gerenciamento Reativo NÃO NÃO
Gerenciamento Pró-ativo SIM NÃO
Planej. Gestão de Riscos SIM NÃO
Identificação dos Riscos SIM NÃO
Análise Quantitativa SIM NÃO
Análise Qualitativa SIM NÃO
Planejamento e resposta SIM NÃO
Monitoramento e controle SIM NÃO
Iterativo e incremental SIM SIM
Arquitetura (foco) SIM NÃO
Validação (foco) NÃO SIM
Interação com o cliente NÃO SIM
Equipes grandes SIM NÃO
Equipes pequenas NÃO SIM
Projetos complexos SIM NÃO
Casos de Uso SIM SIM
Fonte: Autor, adaptado de Castro (2007).

46
4.1 Conclusões

A partir da Tabela 7 apresentada anteriormente e do conhecimento previamente

fornecido sobre o perfil da empresa, do projeto e seus integrantes, pode-se inferir que o custo,
o tempo e a quantidade de integrantes, usando o Scrum, sendo este auxiliado pelos valores e
práticas do XP, a partir de um planejamento embasado com os autores anteriores do projeto,
são menores que usando RUP. A documentação torna-se menos extensa, dificultando a
posterior manutenção do software por outrem, mas a comunicação e a visibilidade entre os
membros do projeto – inclui-se o cliente – aumentam consideravelmente. Por outro lado,
desburocratiza um processo que na maioria das vezes não é utilizado.

A adoção do Scrum no caso do projeto TrainingCad flexibilizaria seu

desenvolvimento à introdução de novos requisitos e/ou funcionalidades, uma premissa muito
questionada em relação à seu desenvolvimento em RUP. Isso teria como apoio, o maior
acompanhamento que o cliente teria sobre o produto devido à maior quantidade de produtos
apresentados ao mesmo.

Tomando por base estas afirmações, o Scrum seria a melhor alternativa para
gerenciar o projeto TrainingCad, usando as práticas de desenvolvimento do XP, devido ao
menor custo, tempo e burocratização e à maior comunicação entre o cliente e os membros do
projeto.

Figura 16 Comparação de Custos de Mudanças entre Métodos Ágeis e Tradicionais

Fonte: adaptado de Nerur (2005).

47
 CAPÍTULO 5
Considerações Finais

Este trabalho avaliou o possível desempenho do processo Scrum aplicado ao

projeto TrainingCad através da definição de um estudo comparativo do mesmo e com isso
acredita-se ter demonstrado a agilidade e eficiência do processo. Graças ao estudo da possível
aplicação do processo, foi exequível encontrar e corrigir alguns pontos fracos do processo,
melhorando a qualidade e os prazos finais o próprio TrainingCad.

Nesse capítulo apresentar-se-á as considerações sobre o trabalho desenvolvido

através das contribuições alcançadas (Seção 5.1), dificuldades encontradas (Seção 5.2) e por
fim, trabalhos futuros que podem dar continuidade a partir dos resultados alcançados (Seção
5.3).

5.1 Contribuições

O objetivo maior do Scrum é gerenciar o projeto de forma ágil, sem prejuízos à

qualidade do produto final. O grande desafio da pesquisa apresentada neste trabalho foi
demonstrar que era possível controlar e buscar soluções para os impedimentos do projeto
TrainingCad, através de um estudo comparativo, sem tornar a aplicação do processo
trabalhosa e carregada de documentação.

O processo se mostrou eficiente também para ambientes com projetos inter-

relacionados. Essa eficiência se tornou evidente graças à colaboração do time de
desenvolvimento dos projetos envolvidos, os quais colaboraram veementemente com todos os
processos de avaliação da metodologia. Além disso, os membros do Núcleo de Treinamento
forneceram idéias para o aprimoramento da aplicação do Scrum ao próprio TrainingCad.
Durante a experiência com o Scrum foram feitas as adaptações necessárias e, como destaque,
teve-se a efetividade no acompanhamento dos principais objetivos do projeto, já que os
principais impedimentos identificados estavam relacionados à entrega do produto final.

48
 A importância de se ter aplicado a metodologia ágil Scrum foi, além de oferecer
um processo mais rápido de se utilizar para as pequenas empresas, também alterar a forma de
gerir projetos para uma gestão voltada para a resolução imediata de empecilhos que possam
estar afetando os objetivos do projeto.

É esperado que o Scrum venha a se tornar uma metodologia ágil utilizada em

grandes empresas e em ambientes corporativos que utilizem vários projetos inter-
relacionados.

5.2 Dificuldades Encontradas

A principal dificuldade encontrada foi com relação à aplicação de uma

metodologia ágil em um ambiente organizacional de projetos múltiplos, em sua maioria
usando RUP, pois a resistência organizacional criada dificulta a adoção da cultura ágil. Como
as metodologias ágeis surgiram há pouco tempo, relativamente, existe certa desconfiança por
parte dos gerentes de projetos da empresa, dificultando assim a implantação da metodologia
nessa organização. Dessa maneira não se conseguiu medir a eficiência do processo fora do
ambiente acadêmico.

Outra dificuldade encontrada foi conciliar os horários de todos envolvidos no

estudo comparativo, para poder realizar as reuniões de acompanhamento e levantar os dados
necessários para as análises que fazem parte deste trabalho de conclusão de curso.

5.3 Trabalhos Futuros

O presente trabalho buscou avaliar de maneira eficaz a eficiência da metodologia

ágil de gerenciamento de projetos Scrum aplicada ao TrainingCad, porém ainda existem
alguns pontos que devem ser estudados e trabalhados futuramente. São eles:

» Aplicar a proposta de desenvolvimento em Scrum ao projeto TrainingCad

e verificar o impacto real;
» Concluir pesquisa com profissionais com experiência em Metodologias
Ágeis para identificar como os mesmos tratam a GRP (Gerência de Riscos
de Projeto) em seus ambientes, avaliando os requisitos ora propostos no
Scrum;

49
 » Utilizar ferramenta BPMS (Business Process Management Systems) para
simulação de processos.

Este trabalho avaliou o desempenho da metodologia ágil Scrum ao TrainingCad

através da definição de um estudo comparativo utilizado a metodologia tradicional RUP do
mesmo e com isso acredita-se ter demonstrado a agilidade e eficiência da metodologia ágil
Scrum. Graças ao estudo da proposta aplicação do processo, foi possível encontrar e corrigir
alguns pontos fracos do processo de desenvolvimento do projeto, melhorando a qualidade e os
prazos do produto final TrainingCad.

50
REFERÊNCIAS

AGILE MANIFESTO. Manifesto for Agile Software Development. Disponível em

<http://agilemanifesto.org/>. Acessado em outubro de 2009.

BECK, K. Extreme Programming Explained: Embrace Change. New York (2000).

BOEHM, B. e TURNER, R. Balancing Agility and Discipline. Boston. Addison-Wesley

(2002).

CASTRO, I. e MOREIRA, A. Metodologias de Desenvolvimento: um comparativo entre

Extreme Programming e Rational Unified Process. Artigo, Faculdade Ruy Barbosa (2007).

CERVO, A. L.; BERVIAN, P. A. e SILVA R. Metodologia Científica. São Paulo. Pearson

Prentice Hall (2007).

COCKBURN, A. e HIGHSMITH, J. Agile Software Development: The Business of

Innovation. IEEE Computer (2001).

FOWLER, M. The New Methodology. Addison-Wesley (2000).

HAYES, S. An Introduction to Extreme Programming. Kathovartech (2001). Disponível

em <http://www.khatovartech.com>. Acessado em junho de 2009.

HIGHSMITH, J. Agile Project Management: Creating Innovative Products. Addison-

Wesley (2004).

IMPROVE IT. Scrum: metodologia ágil para gestão e planejamento de projetos. Improve
It (2009). Disponível em <http://improveit.com.br/scrum>. Acessado em outubro de 2009.

JEFRIES, R. What is Extreme Programming. Disponível em

<http://www.extremeprogramming.com>. Acessado em fevereiro de 2009.

KRUCHTEN, P. The Rational Unified Process: an introduction. Boston. Addison-Wesley

(1999).

LONGMAN, A. XP Immersion. Addison-Wesley (1998).

NERUR, S; MAHAPATRA, R. e MAGALARA, G. Challenges of Migrating to Agile

Methodologies. Communications of the ACM (2005).
51
PINHEIRO, M. R. e SILVA-DE-SOUZA, T. Rational Unified Process: uma
abordagem gerencial. Dissertação de Mestrado, Instituto Militar de Engenharia, Rio de
Janeiro, Brasil (2005).

PMBOK Guide. Project Management Body of Knowledge. Pennsylvania. PMI (2004).

PRESSMAN, R. S. Engenharia de Software. Rio de Janeiro. McGraw-Hill (2002).

RATIONAL SOFTWARE. Rational Unified Process. IBM (2009). Disponível em:

<http://www-01.ibm.com/software/awdtools/rup/support>. Acessado em outubro de 2009.

RIEHLE, D. A Comparison of the Value Systems of Adaptative Software Development

and Extreme Programming: How Methodologies May Learn from Each Other.
McGraw-Hill (2000).

SACRAMENTO, E. C. e ARAÚJO, A. C. As novas estratégias de negócios em gestão de TI e

a aplicação das melhores práticas do PMI. Techoje, Belo Horizonte (2009). Disponível em
<http://www.ietec.com.br/site/techoje/categoria/detalhe_artigo/648>. Acessado em outubro de
2009.

SCHWABER, K. Agile Project Management with Scrum. Microsoft Press (2004).

SOUZA, C. B. Autoria de Artefatos de Software. Dissertação de Mestrado, Pontifícia

Universidade Católica do Rio Grande do Sul, Porto Alegre, Brasil (2008).

TAVARES, A. Gerência de Projetos com PMBOK e Scrum: um estudo de caso. Trabalho

de Conclusão de Curso, Faculdade Cenecista Nossa Senhora dos Anjos, Gravataí, Brasil
(2008).

TRAININGCAD. TrainingCad - Núcleo de Treinamento. Projeto de Software. Caruaru.

UPE Consultoria Jr. (2009).

VIEIRA, M. F. Gerenciamento de Projetos de Tecnologia da Informação. Rio de Janeiros.

Campus (2003).

52
Monografia de Trabalho de Graduação apresentada pelo B.Sc. Gert Uchôa Müller Neto do
Curso de Bacharelado em Sistemas de Informação da Faculdade de Ciência e Tecnologia de
Caruaru da Universidade de Pernambuco, sob o título “Métodos Tradicionais Versus Ágeis:
Um Estudo Comparativo Através do TrainingCad.”, orientada pelo Prof. M.Sc. Humberto
Rocha de Almeida Neto e aprovada pela Banca Examinadora formada pelos professores:

_______________________________________________
Prof. Edmundo Rodrigues da Silva Porto Neto
Departamento de Sistemas de Informação - FAVIP

_______________________________________________
Prof. Marjony Barros Camelo
Faculdade de Ciência e Tecnologia de Caruaru - UPE

_______________________________________________
Prof. Humberto Rocha de Almeida Neto
Faculdade de Ciência e Tecnologia de Caruaru - UPE

Visto e permitida a impressão.

Caruaru, 16 de dezembro de 2009.

______________________________________________________
Prof. Cícero Garrozi
Vice-Coordenador do Curso de Bacharelado em Sistemas de Informação
Faculdade de Ciência e Tecnologia de Caruaru – Universidade de Pernambuco.

53