FACULDADE CENECISTA NOSSA SENHORA DOS ANJOS

Gerência de Projeto com PMBOK e SCRUM

Um Estudo de Caso

por

Aleckssandro Tavares

Monografia apresentada na disciplina

de Trabalho de Conclusão de Curso I, sob
orientação do Prof. Daniel Wildt

Gravataí, 2008
 SUMÁRIO

RESUMO........................................................................................................03
ABSTRACT....................................................................................................04
LISTA DE ABREVIATURAS.........................................................................05
LISTA DE FIGURAS......................................................................................06
INTRODUÇÃO...............................................................................................07
1 REFERENCIAL TEÓRICO.........................................................................13
1.1 Processo de Software..........................................................................13
1.2 Gerenciamento de Projetos.................................................................15
1.3 Metodologias Ágeis..............................................................................22
1.4 Scrum...................................................................................................23
1.5 Ruby on Rails.......................................................................................33

2 ESTADO DA ARTE....................................................................................36
2.1 Estudos da Aplicação de Práticas do PMBOK com Agile...................37
2.2 Projetos com Metodologias Ágeis.......................................................40
2.3 Comparativo com Estudos e Projetos Apresentados..........................41

3 SOLUÇÃO IMPLEMENTADA....................................................................43
3.1 Levantamento de Requisitos, Product Backlog e Escopo...................43
3.2 Planejmento.........................................................................................44
3.3 Visão Geral do Sistema em Casos de Uso.........................................45
3.4 Arquitetura............................................................................................49
3.5 Diagrama de Classe Conceitual..........................................................51
3.6 Layout do Site......................................................................................52

CONSIDERAÇÕES FINAIS...........................................................................53
REFERÊNCIAS BIBLIOGRÁFICAS.............................................................56
ANEXO 1: Declaração Preliminar de Escopo............................................59
ANEXO 2: Plano de Gerenciamento do Escopo.......................................65
 RESUMO

A utilização de práticas de processos Ágeis com práticas tradicionais de

gerenciamento de projetos é um desafio, porém não é impossível. Há muitos
profissionais que são radicais quanto ao uso de uma ou outra abordagem, e
que acham impossível que o processo Ágil e tradicional possam ser aplicados
conjuntamente. Mas o histórico da indústria de software está mostrando que é
sim viável e positivo. O segredo está em saber adaptar o processo, pois não há
solução perfeita. É justamente esse o objetivo deste trabalho, apresentar o
estudo da aplicação de Metodologias Ágeis para gerenciamento de projetos de
software, mais especificamente o SCRUM (CONTROL CHAOS, 2008) e o seu
uso em conjunto com práticas de gerenciamento de projetos do PMBOK Guide
(PMBOK, 2004). Também se propõe estudar e usar a linguagem de
programação Ruby com o framework para desenvolvimento de aplicações web
Ruby on Rails (RAILS-USA, 2008). Todos estes assuntos serão aplicados
através de um estudo de caso, que consiste na construção de um web site
para a Editora Adhonai.

Palavras-Chave: Gerenciamento de Projeto, Metodologia Ágil, Scrum,

Ruby, Rails.
 ABSTRACT

The use of practices of Agile processes with traditional practices of

project management, is a challenge but not impossible. There are many
professionals who are radical about the use of one or another approach, and
who believes to be impossible that Agile and Traditional processes can be
applied together. But the history of the software industry is showing that it is
viable and positive. The secret is knowing adapt the process, because there is
no perfect solution. It is precisely that the objective of this work, make the study
of the implementation of Agile methodologies for project management,
software, specifically the SCRUM (CONTROL CHAOS, 2008) and its use in
conjunction with practice in project management, the PMBOK Guide (PMBOK,
2004). It also proposes to study and use the programming language Ruby with
the framework for development of web applications Ruby on Rails (RAILS-USA,
2008). All these matters will be implemented through a case study, which
consists in building a web site for the Publisher Adhonai.

Keywords: Project Management, Agile Methodology, Scrum, Ruby,

Rails
 LISTA DE ABREVIATURAS

Abreviaturas utilizadas ao longo deste trabalho:

ABNT Associação Brasileira de Normas Técnicas

APM Agile Project Management

CMM Capability Maturity Model

CMMi Capability Maturity Model Integration

CSS Casacading Style Sheet

EAP Estrutura Analítica do Projeto

IEC International Electrotechinical Commission

ISO International Organization for Standardization

HTML Hypertext Markup Language

HTTP HyperText Transfer Protocol

MPS.BR Melhoria dos Processos de Software Brasileiro

MVC Model View Controller

XPM Extreme Project Management

WBS Work Breakdown Structure

 LISTA DE FIGURAS

Figura 1.1: Formato de Processo.............................................................19

Figura 1.2: Grupos de Processos............................................................19

Figura 1.3: Metodologia Scrum................................................................24

Figura 1.4: Ciclo do Sprint........................................................................25

Figura 1.5: Exemplo de gráfico de Burndown para Sprint.......................30

Figura 2.1: EAP para Release e Iteração................................................38

Figura 2.2: Desenvolvimento iterativo e grupos de processos PMBOK..39

Figura 3.1: Diagrama de Caso de Uso - Geral........................................46

Figura 3.2: Diagrama de Caso de Uso - Navegar no Web Site...............47

Figura 3.3: Diagrama de Caso de Uso - Gerenciar Web Site..................48

Figura 3.4: Diagrama de Componente - Arquitetura Alto Nível...............50

Figura 3.5: Diagrama de Classe - Conceitual primeiro release...............51

Figura 3.6: Capa atual do site institucional da editora.............................52

Figura 4.1: Processos executados no trabalho na abordagem de Koch.55

 INTRODUÇÃO

Indústrias de todo o mundo, buscando um diferencial num mercado cada

vez mais competitivo, partiram para a adoção de programas de qualidade total
e melhoria contínua. Estes programas foram adotados inicialmente pela
indústria japonesa, que após a segunda guerra mundial começou a se destacar
no mercado mundial.

Estes programas baseiam-se na afirmação de que a qualidade do

produto é intimamente influenciada pela qualidade do processo empregado na
produção (REINEHR, 2001). Para atestarem a competência de seus
processos, as empresas buscaram a certificação na família de normas
internacional ISO 9000, que atestam que a empresa utiliza um processo bem
definido, gerenciado e medido.

Baseados nestes princípios surgiram modelos e normas específicos para

software, dos quais o mais conhecido internacionalmente é o modelo CMM –
Capability Maturity Model, desenvolvido pelo SEI – Software Engineering
Institute (SEI-USA, 2008).

Seguindo o mesmo caminho de busca da excelência surgiram outros

modelos e propostas para as mais variadas áreas de atuação, como o
gerenciamento de projetos, que hoje está amplamente difundido nas
organizações do mundo todo.

Na área de gerenciamento de projetos o PMI (Project Management

Institute) com o seu PMBOK Guide (PMBOK, 2004) vem sendo adotado em
empresas de todos os tipos, para gerenciamento dos mais variados tipos de
projetos. Na área de tecnologia é ainda mais comum a adoção do
gerenciamento de projetos seguindo as práticas do PMBOK. Os processos de
 8

gerenciamento descritos pelo PMBOK não são específicos para o

desenvolvimento de software, mas é genérico e amplo de forma que pode ser
usado para qualquer tipo de projeto. O segredo está em saber adaptar e usar
as práticas da melhor forma possível para o projeto e/ou empresa em questão.

Dentre os métodos de desenvolvimento adotados pelas empresas, o

mais famoso é o modelo em “Cascata” (Waterfall), geralmente utilizado em
conjunto com práticas do PMBOK, embora o PMBOK não advogue por nenhum
ciclo de desenvolvimento, deixando isto a cargo do gerente do projeto:

“Não existe uma única melhor maneira para definir um ciclo de

vida ideal do projeto...
...permitem que a equipe de gerenciamento de projetos escolha
o ciclo de vida mais adequado para seu próprio projeto.”
(PMBOK, 2004 p. 20).

Este modelo Cascata possui fases bem definidas e seqüenciais no ciclo

de vida do software, bem como pouca interação com o cliente. Neste modelo
as fases são longas e em conseqüência o ciclo de vida torna-se também longo
e pouco dinâmico.

Por outro lado as Metodologias Ágeis (AGILE MANIFESTO, 2001), mais

voltadas para o desenvolvimento de software, também tem ganhado
visibilidade nas organizações de todos os cantos do planeta entre equipes que
desenvolvem software como alternativa ao modelo Tradicional. Dentre estas
metodologias o SCRUM (CONTROL CHAOS, 2008) é uma das mais difundidas
por ter maior foco em gerenciamento.

Para resolver essas questões do modelo Tradicional (Cascata), os

Métodos Ágeis têm como visão “um desenvolvimento de software interativo,
evolutivo e incremental”, sendo mais dinâmicos e flexíveis, possuindo também
mais proximidade e comunicação com o cliente. Eles trazem não só a mudança
no ciclo de vida do desenvolvimento, mas defende princípios a serem seguidos
pela equipe, uma mudança de cultura (AGILE MANIFESTO, 2001). Este
modelo Ágil está sendo considerado uma moderna substituição para o modelo
em cascata tradicional (LARMAN, 2003).
 9

Motivação

É justamente porque a adoção de ambos os modelos ou processos

estão cada vez mais comuns que surgem as dúvidas como: É possível usar o
modelo PMBOK com Métodos Ágeis em um mesmo projeto? Ou é preciso
optar por uma abordagem ou outra? Se é possível, como adaptar o processo
para o uso em conjunto? Como trabalhar as áreas e processos do PMBOK com
uma abordagem Ágil? Como gerenciar o escopo? E o tempo? Áreas que
parecem conflitantes entre PMBOK e Métodos Ágeis.

Alguns mais radicais defendem a adoção puramente de PMBOK e

outros, por sua vez a adoção exclusiva de Metodologias Ágeis. O certo é que
nem tanto para um lado, nem tanto para outro. No que se refere a projetos de
software, o uso das duas abordagens é perfeitamente possível e positiva.

A motivação para este trabalho de conclusão vem da visibilidade

crescente que as Metodologias Ágeis de desenvolvimento de software têm
recebido em todo o mundo, e também aqui no Brasil. E principalmente pelos
inúmeros casos de sucesso (AMBLER, 2007) de projetos sendo entregues com
qualidade e buscando a satisfação constante do cliente, além de relatos de
equipes motivadas após adoção deste tipo de processo (VERSIONONE, 2007).
Essas características são justamente alguns dos princípios do Manifesto Ágil
(AGILE MANIFESTO, 2001), dentre os quais se cita: “A nossa maior prioridade
é a satisfação do cliente através da entrega antecipada e contínua de software
com valor.” As Metodologias Ágeis tem trazido um novo panorama e uma nova
motivação à medida que tem abordado o desenvolvimento de software sobre
um novo paradigma e com resultados expressivos (VERSIONONE, 2007).

Objetivo do Trabalho

Este trabalho busca experimentar esse novo paradigma Ágil de

gerenciamento de projetos e comprovar os benefícios dessa metodologia e ao
 10

mesmo tempo, comprovar que o uso de práticas Ágeis com PMBOK é viável
com devidas adaptações de acordo com o tipo de projeto. Tentar identificar
como adaptar os processos do PMBOK para co-existir com o modelo Ágil. Não
uma forma estática ou única, já que cada projeto pode ter as suas
necessidades de adaptações.

Também se propõe estudar e usar a linguagem de programação Ruby

em conjunto com Ruby on Rails, que é um framework para desenvolvimento
de aplicações web (RAILS-USA, 2008). Todos estes assuntos serão aplicados
através de um estudo de caso, que consiste na construção de um web site para
a Editora Adhonai.

São várias as opções de Metodologias Ágeis para desenvolvimento de

software, sendo o SCRUM uma delas. Pesquisa sobre o estado do
Desenvolvimento Ágil (VERSIONONE, 2007) indica que 40% dos entrevistados
utilizam SCRUM. O SCRUM mostra-se uma metodologia flexível e de fácil
aprendizado recomendada para gerenciamento de qualquer tipo de projetos
(CONTROL CHAOS, 2008). Por essas, e outras características, o SCRUM será
a metodologia utilizada como base para o gerenciamento neste trabalho,
podendo ainda ser adotadas práticas de outras metodologias, como o XP
(TELES, 2004), que tem suas práticas fortemente voltadas à codificação com
qualidade.

Para validar o uso das Metodologias Ágeis, suas práticas serão

aplicadas em um estudo de caso com um projeto real. A motivação para este
projeto é comercial, com o objetivo de ver o cliente satisfeito, disponibilizando
um web site dinâmico para sua empresa que permita a divulgação da mesma e
seja um diferencial, posto que o site é o principal canal de relacionamento com
seus clientes.

Os objetivos específicos deste trabalho são:

 Estudar aspectos que envolvam o desenvolvimento de sistemas

utilizando Metodologias Ágeis para gerenciamento de projeto;

 Estudar a metodologia SCRUM;

 11

 Aplicar práticas de algumas das áreas de conhecimento do

PMBOK;

 Estudar o framework de desenvolvimento para web Ruby on Rails

;

 Estudar o banco de dados MySQL (MYSQL, 2008);

 Estudar a ferramenta de gerenciamento de projeto Mingle

(THOUGHTWORKS, 2008);

 Definir as funcionalidades do site;

 Estruturar e criar o layout do site;

 Implementar e validar o web site proposto.

 Implantar o site em produção substituindo o atual site da editora.

Não é objetivo deste trabalho advogar para uma ou outra metodologia, e

não é objetivo propor uma nova metodologia baseada no uso de ambas
práticas tradicional e ágil.

Algumas limitações estarão presentes neste projeto e dificultarão a

abordagem de algumas práticas tanto do PMBOK quanto do SCRUM. Por
exemplo, como a equipe de desenvolvimento do projeto será de apenas uma
pessoa, a área de Gerenciamento de Recursos Humanos não poderá ser muito
bem explorada, assim como, no lado Ágil, a Daily Meeting em função da
mesma questão. Outras questões não visualizadas neste momento poderão
aparecer ao longo do projeto.

Estrutura do Trabalho

Este trabalho está organizado em cinco capítulos conforme descrito

abaixo:

 Na Introdução, é apresentada a motivação, objetivos e estrutura

do trabalho;
 12

 No capítulo 1, chamado de referencial teórico, são descritos os

principais fundamentos teóricos deste trabalho como o Processo
de Software, Gerenciamento de Projetos, Metodologias Ágeis e
SCRUM.

 O capítulo 2, chamado de estado da arte, aborda outros estudos

e projetos relacionados ao tema e objetivos deste trabalho.

 No capítulo 3, solução implementada, é descrito o trabalho

efetuado e artefatos gerados, visando a implementação e
execução do projeto de software, quanto ao planejamento,
definição de escopo e arquitetura inicial do sistema.

 Finalmente nas considerações finais, é apresentado o que foi

realizado durante o trabalho, se os objetivos propostos foram
alcançados, as dificuldades encontradas e como será
desenvolvida a segunda etapa do trabalho.
 1. REFERENCIAL TEÓRICO

1.1 Processo de Software

Uma das questões que surge ao se tratar de desenvolvimento de

software, e da qualidade de software é compreender o que é o “processo de
software”.

Segundo Humphrey, um dos criadores do CMM, em (HUMPHREY,

1995) ele descreve o “processo de software” como “uma seqüência de passos
necessários para o desenvolvimento e manutenção de software”. Ainda outros
autores conceituam em (PAULK, 1993) com a seguinte definição: “Um
processo de software efetivo une pessoas, ferramentas e métodos em um todo
integrado”.

A definição de um processo de software bem projetada e apresentada

guia os desenvolvedores de software sobre como eles trabalham. Embora
muitas vezes o que se vê são processos guiando “o que” deve ser feito sem
detalhar exatamente o “como fazer”.

1.1.1 CMM

Há muitos modelos e normas baseadas nos princípios de que a

qualidade do produto de software é intimamente ligada à qualidade do
processo utilizado para desenvolvê-lo e mantê-lo.

Dentre estes modelos, um dos mais conhecidos e utilizados

internacionalmente é o modelo SW-CMM – Capability Maturity Model for
Software, que foi desenvolvido pelo SEI - Software Engineering Institute.
 14

Também conhecido simplesmente como CMM ou CMMI, versão mais atual do

modelo (SEI-USA, 2008).

1.1.2 ISO / IEC / ABNT

Há ainda outros órgãos internacionais de padronização, como a ISO e a

IEC, que estabeleceram um comitê conjunto específico para tratar as questões
de software. E a partir deste comitê já foram elaboradas e publicadas diversas
normas internacionais para software, dentre elas:

• ISO/IEC 12207 – Define Processos de Ciclo de Vida de Software (a

equivalente nacional é a NBR ISO/IEC 12207 (ABNT 98));

• ISO/IEC 15504 – Define a Avaliação do Processo de Software (também

conhecido como projeto SPICE – Software Process Improvement and
Capability dEtermination).

1.1.3 MPS.BR

O MPS.BR ou Melhoria do Processo de Software Brasileiro é, assim

como o CMMI, um modelo de maturidade que busca a qualidade do processo
de software, porém adaptado para a realidade brasileira. Ele é também
baseado nas normas ISO/IEC 12207 e ISO/IEC 15504 (MPS.BR, 2008).

Coordenado pela SOFTEX (Associação para Promoção da Excelência

do Software Brasileiro), conta ainda com o apoio do Ministério de Ciência e
Tecnologia, da FINEP (Financiadora de Estudos e Projetos), do BID (Banco
Interamericano de Desenvolvimento) e universidades (MPS.BR, 2008).

A grande vantagem em comparação ao CMMI é o custo reduzido de

certificação.

Estes modelos e normas descritos acima, para manterem-se genéricos e

robustos o suficiente para serem aplicados em qualquer contexto, não
especificam detalhes de implementação, ou seja, o “Como”. Logo, o “Como”
 15

deve ser definido por quem utiliza estes modelos, fazendo-se as adaptações
necessárias para a sua realidade. Ainda, como bem salientado por REINEHR,
sobre estes modelos e normas, eles possuem foco na organização e são de
difícil aplicação a pequenas equipes:

“Outro ponto importante é que, devido à sua robustez, têm um

foco organizacional, sendo dificilmente adaptáveis para o nível
individual ou de pequenas equipes de projeto” (REINEHR,
2001, p. 10).

1.2 Gerenciamento de Projetos

O mundo está cada vez mais dinâmico, as empresas e os negócios cada

vez mais competitivos. Quem sai na frente tem mais chances de vencer, quem
tem acesso a mais informação possui vantagens sobre os concorrentes. Desde
a chegada da internet comercial, na década de 90, a velocidade dos
acontecimentos no mundo é quase que de acordo com a velocidade da luz. A
informação cruza o globo quase que instantaneamente ou “online”, usando o
termo comum da internet. Uma notícia sobre uma empresa no Japão pode
afetar a bolsa de valores no mundo inteiro em questões de segundos, conforme
a velocidade da internet.

Diante deste cenário, o gerenciamento de projetos tem se tornado muito

importante para as organizações. Não que ele seja tão novo quanto à internet,
mas tem ganhado mais visibilidade à medida que os desafios vão aumentando
e que as práticas de gerenciamento de projetos têm sido uma forte aliada para
responder a estes desafios.

Projeto tem sido a linguagem cada vez mais comum nas empresas,
ainda que isso não garanta que elas estejam conduzindo os projetos da melhor
maneira ou alcancem os resultados esperados da forma mais eficaz.

Há muitas teorias, técnicas e ferramentas para gerenciar projetos,

muitas com origens militares vindas da época da segunda-guerra mundial ou
no pós-guerra no período conhecido como Guerra Fria. Dentre essas técnicas
o modelo de gerenciamento de projetos apresentado pelo PMI (Project
 16

Management Institute) tem tido ampla aceitação internacionalmente (VIEIRA,

2003).

O PMI é uma associação mundial sem fins lucrativos com foco exclusivo
em Gerenciamento de Projetos. Sua origem se deu em 1969 nos EUA através
de cinco voluntários e atualmente conta com mais de 270.000 associados no
mundo inteiro (PMI-SP, 2008).

O PMI é líder mundial no desenvolvimento de padrões para a prática de

Gerenciamento de Projetos. Sua principal publicação é um guia com práticas
de gerência de projetos chamado de “A Guide to the Project Management Body
of Knowledge” ou mais popularmente PMBOK Guide (PMI-SP, 2008).

Olhando para a história cronológica do PMI pode-se perceber a evolução

do gerenciamento de projetos nas empresas pelo mundo inteiro e o quanto que
a internet contribuiu para este crescimento. Iniciando em 1969 com cinco
associados, no final da década de 70, aproximadamente 10 anos após, o
número havia crescido para pouco mais de 2.000 associados. Em 90 esse
número havia aumentado para 8.500. No início dos anos 2000 já eram mais de
50.000 associados e hoje, em apenas oito anos, esse número já passa de
270.000 (PMI-SP, 2008).

Esses números nos mostram um pouco do quanto o gerenciamento de

projetos tem crescido nas empresas e conseqüentemente o número de
profissionais especializados na prática de gerência de projetos.

Embora as práticas do PMI sejam aplicadas a qualquer tipo de projetos,

elas têm sido amplamente utilizadas pelas organizações para a gestão de
projetos de tecnologia da informação (VIEIRA, 2003).

1.2.1 PMBOK

O Project Management Body Of Knowledge ou simplesmente PMBOK

Guide é o principal documento de referência do PMI, embora não seja o único.
Como o próprio nome em português diz, ele é “Um Guia do Conjunto de
Conhecimentos em Gerenciamento de Projetos”. Está atualmente na terceira
edição, lançada em 2004. Como ele mesmo descreve o seu objetivo é:
 17

“O principal objetivo do Guia PMBOK® é identificar o

subconjunto do Conjunto de conhecimentos em gerenciamento
de projetos que é amplamente reconhecido como boa prática.
“Identificar” significa fornecer uma visão geral, e não uma
descrição completa. “Amplamente reconhecido” significa que o
conhecimento e as práticas descritas são aplicáveis à maioria
dos projetos na maior parte do tempo, e que existe um
consenso geral em relação ao seu valor e sua utilidade. “Boa
prática” significa que existe acordo geral de que a aplicação
correta dessas habilidades, ferramentas e técnicas podem
aumentar as chances de sucesso em uma ampla série de
projetos diferentes. Uma boa prática não significa que o
conhecimento descrito deverá ser sempre aplicado
uniformemente em todos os projetos; a equipe de
gerenciamento de projetos é responsável por determinar o que
é adequado para um projeto específico.” (PMBOK, 2004, p. 3).

No PMBOK Guide encontram-se muitas definições e práticas que guiam

na gerência de projetos em geral. Algumas destas definições são descritas
abaixo.

1.2.2. Projeto

Projeto é descrito pelo PMBOK Guide (PMBOK, 2004) como “um

esforço temporário empreendido para criar um produto, serviço ou resultado
exclusivo”.

Quando diz temporário, significa que o projeto deve ter um inicio e fim
definidos. Basicamente quando os objetivos do mesmo são alcançados chega-
se ao fim, logo para isso é importante ter bem claro quais os objetivos do
projeto. Quando se fala em temporário pensa-se instintivamente em um curto
espaço de tempo, porém projetos podem levar dias, meses ou até anos, no
entanto precisa ter uma data de fim já que um projeto não é eterno. O produto
gerado pelo projeto até pode ter vida “eterna” e/ou indeterminada, mas não o
projeto.

Quando diz produto, serviço ou resultado exclusivo significa que as

entregas são únicas, pois há elementos que os tornam únicos, seja a data, as
pessoas que estão envolvidas, os recursos. O PMBOK Guide exemplifica
através do exemplo da construção de prédios. Cada prédio é diferente um do
 18

outro, pois possuem proprietários diferentes, locais diferentes, construtora

diferentes. Embora haja elementos que se repetem, ainda assim cada prédio
possui sua singularidade.

1.2.3 Gerenciamento de Projeto

O PMBOK define a atividade de gerenciamento de projeto como:

“a aplicação de conhecimento, habilidades, ferramentas e

técnicas às atividades do projeto a fim de atender aos seus
requisitos.” (PMBOK, 2004, p. 8).

O papel do Gerente de Projetos é responsável pelo andamento do

projeto e por gerenciar as atividades necessárias para o atendimento dos
objetivos do mesmo. Para isso ele precisa planejar, controlar e executar as
atividades do mesmo.

O termo Stakeholders descreve todas as partes envolvidas ou

interessadas no projeto, inclusive o próprio Gerente de Projeto. Dentre os
interessados, um dos mais importantes é o Sponsor, ou patrocinador do
projeto. É a pessoa que financia e/ou defende o projeto dentro da organização.
Outros exemplos de partes envolvidas: fornecedores, sociedade, a equipe do
projeto, cliente, usuários finais, dentre outros, conforme o projeto.

1.2.4 Grupos de Processos

A metodologia de gerenciamento do PMI possui 44 processos onde cada

um recebe Entradas que são utilizadas por Ferramentas e/ou Técnicas que
geram Saídas, conforme ilustrado na Figura 1.1.

Segundo o PMBOK processo é:

“um conjunto de ações e atividades inter-relacionadas

realizadas para obter um conjunto pré-especificado de
produtos, resultados ou serviços.” (PMBOK, 2004, p. 38).
 19

Ferramentas
Entradas Saídas
Técnicas

Figura 1.1: Formato de Processo.

Os processos segundo a metodologia PMI ainda são distribuídos em

cinco grupos que se integram entre si, conforme Figura 1.2.

Iniciação Planejamento

Controle Execução

Encerramento

Figura 1.2: Grupos de Processos.

Estes grupos de processos não representam necessariamente uma fase

do projeto, sendo que dependendo do tipo de projeto e sua organização os
processos de um grupo de processo podem ser repetidos por fases do projeto
(PMBOK, 2004, p. 41).

1.2.5 Áreas de Conhecimento

A metodologia de gerenciamento do PMI também organiza os 44

processos em nove áreas de conhecimento, conforme listagem abaixo:

 Gerenciamento de Integração do Projeto;

 20

 Gerenciamento do Escopo do Projeto;

 Gerenciamento de Tempo do Projeto;
 Gerenciamento de Custos do Projeto;
 Gerenciamento da Qualidade do Projeto;
 Gerenciamento de Recursos Humanos do Projeto;
 Gerenciamento das Comunicações do Projeto;
 Gerenciamento de Riscos do Projeto;
 Gerenciamento de Aquisições do Projeto;

1.2.6 Processos nos Grupos e nas Áreas de Conhecimento

O Quadro 1.1 exibe o mapeamento dos 44 processos de gerenciamento

de projetos nos cinco grupos de processos e nas nove áreas de conhecimento
em gerenciamento de projetos.
 21

Áreas de Grupos de Processos

Conhecimento Iniciação Planejamento Execução Controle Encerramento
Desenvolver Termo Desenvolver o Orientar e Monitorar e Encerrar o Projeto
de Abertura Plano de Gerenciar a Controlar o
Gerenciamento Execução do Trabalho do
Integração Desenvolver a Projeto Projeto
Declaração do
Escopo Preliminar Controle Integrado
de Mudanças
Planejamento do Verificação do
Escopo Escopo

Escopo Definição do Controle do

Escopo Escopo

Criar a EAP
Definição de Controle do
Atividades Cronograma

Seqüenciamento
de Atividades

Estimativa de
Recurso das
Tempo
Atividades

Estimativa de
Duração das
Atividades

Desenvolvimento
do Cronograma
Estimativa de Controle de
Custos Custos
Custos
Orçamentação
Planejamento da Garantia da Controle da
Qualidade
Qualidade Qualidade Qualidade
Planejamento de Montagem da Gerenciar a
Recursos Equipe Equipe do Projeto
Recursos
Humanos
Humanos
Desenvolvimento
do Time
Planejamento das Distribuição das Relatório de
Comunicações Informações Desempenho
Comunicação
Gerenciamento
das Partes
Interessadas
Planejamento do Monitoramento e
Gerenciamento Controle de Riscos
dos Riscos

Identificação de
Riscos

Análise Qualitativa
Riscos de Riscos

Análise
Quantitativa dos
Riscos

Planejamento de
Respostas a
Riscos
 22

Planejar Compras Solicitar Administração de Encerramento do

e Aquisições Respostas de Contrato Contrato
Fornecedores
Aquisições
Planejar
Contratações Selecionar
Fornecedores

Quadro 1: Mapeamento dos processos nos grupos de processos e áreas de conhecimento.

Ao olhar para este quadro, é perceptível o forte foco do PMBOK Guide

em planejamento, já que a maioria, 21 dos processos são do grupo de
planejamento. É quase a metade dos 44 processos.

1.3 Metodologias Ágeis

As Metodologias Ágeis de desenvolvimento de software se propõe a

construir softwares com maior produtividade e, sobretudo, com qualidade
garantida. Para isso elas encaram os projetos sobre um novo paradigma e
defendem a adoção de uma série de princípios e práticas.

Entre as quebras de paradigma está a forma de encarar a mudança. Ela

é encarada como algo inevitável no projeto de software. Enquanto que as
metodologias tradicionais abordam o escopo como fixo devendo ser controlado
o máximo possível para não haver mudanças; as Metodologias Ágeis abordam
o escopo como manipulável e oferecem flexibilidade para sua mudança. Um
dos princípios do Manifesto Ágil (AGILE MANIFESTO, 2001) diz que “Mudança
de requisitos são bem vindas, mesmo em estágios tardios do desenvolvimento.
Processos Ágeis devem admitir mudanças que trazem vantagens competitivas
para o cliente”.

Dentre as várias Metodologias Ágeis destacam-se: SCRUM, eXtreme

Programming ou XP (XP-ORG, XP-COM, 2008), Lean Development
(POPPENDIECK, 2008), Feature Driven Development ou FDD (FDD, 2008),
MSF for Agile (MSDN, 2008), Crystal (ALISTAIR, 2008) e DSDM (DSDM-ORG,
2008).

Cada uma das metodologias tem suas peculiaridades e formas de

encarar o desenvolvimento de software. A FDD, por exemplo, tem um foco
 23

muito maior em modelagem e análise e projeto orientado a objeto que outras

metodologias.

O termo Metodologias Ágeis surgiu a partir de um manifesto criado por

dezessete profissionais veteranos na área de software, representantes de
diversas metodologias, que reuniram-se no ano de 2001 no EUA para discutir o
que havia em comum entre estas metodologias. Esse manifesto foi chamado
de Manifesto for Agile Software Development, ou simplesmente Agile Manifesto
(AGILE MANIFESTO, 2001). Os participantes deste manifesto foram: Kent
Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham,
Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon
Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff
Sutherland e Dave Thomas.

Neste manifesto foram descritos princípios que metodologias de

desenvolvimento ágil deveriam seguir:

“Estamos evidenciando maneiras melhores de desenvolver

software fazendo-o nós mesmos e ajudando outros a fazê-lo.
Através desse trabalho, passamos a valorizar:

Pessoas e interação MAIS QUE processos e ferramentas;

Software em funcionamento MAIS QUE documentação
abrangente;
Colaboração com o cliente MAIS QUE negociação de
contratos;
Responder a mudanças MAIS QUE seguir um plano.

Ou seja, mesmo tendo valor os itens à direita, valorizamos

mais os itens à esquerda.” (AGILE MANIFESTO, 2001).

Entre as Metodologias Ágeis, com representação no manifesto está o

SCRUM, uma Metodologia Ágil para gerenciamento de projetos de software,
cuja principal referência são Ken Schwaber, Jeff Sutherland e Mike Beedle.

1.4 SCRUM
 24

SCRUM é um processo iterativo e incremental para desenvolvimento de

qualquer tipo de produto ou gerenciamento de qualquer tipo de trabalho
(CONTROL CHAOS, 2008).

O SCRUM possui um processo bem definido com uma fase de

planejamento (Planning) e de encerramento (Closure) (SCHWABER, 1995),
conforme ilustrado na Figura 1.3. Entre estas fases, há uma fase chamada de
Sprint, com duração de 2 a 4 semanas, que ocorre várias vezes durante o
desenvolvimento do projeto. São as iterações que caracterizam as
Metodologias Ágeis. O Sprint é como uma caixa preta onde ocorre o
desenvolvimento do produto.

Fonte: SCRUM Development Process (SCHWABER, 1995).

Figura 1.3: Metodologia SCRUM.

O SCRUM mantém uma lista de funcionalidades que deverão ser

implementadas, essa lista é chamada de Product BackLog. Para cada iteração
ou Sprint, é feita uma reunião inicial de planejamento, chamada de Sprint
Planning Meeting, onde itens desta lista são priorizados pelo cliente, chamado
no SCRUM de Product Owner. A equipe define quais funcionalidades poderão
ser atendidas dentro da iteração de acordo com a capacidade da mesma. Essa
lista planejada para a iteração é chamada de Sprint Backlog.
 25

Diariamente, durante o Sprint, a equipe faz uma reunião chamada de

Daily Meeting que ajuda a manter a comunicação do time sobre o andamento
do projeto, disseminar conhecimento e identificar possíveis impedimentos.

No final de cada Sprint, na reunião chamada Sprint Review, a equipe

apresenta as funcionalidades que foram concluídas durante o Sprint.

Ao final do Sprint deve sair produto com valor agregado, ou seja, é feito
um incremento no produto. Esse ciclo se repete várias vezes até que o Product
Backlog seja todo atendido (CONTROL CHAOS, 2008). Ver ciclo na Figura 1.4.

Daily Scrum 24 hours

Meeting
Product Backlog
Potentially
Shippable
Product
2-4 Weeks
Sprint Backlog Increment

Fonte: Adaptado de Control Chaos (2005)

Figura 1.4: Ciclo do Sprint.

1.4.1 Fases do Scrum

O Scrum possui 3 grupos de fases. O Pregame, Game e o Postgame,

tendo ainda atividades para cada uma destas fases.

1.4.1.1 Pregame

O Pregame está dividido em dois passos:

 Planning: Ocorre a definição do BackLog inicial, da equipe que irá

trabalhar no projeto, identifica-se os riscos e como controlá-los, verifica-
se a infra-estrutura para o desenvolvimento, as ferramentas necessárias,
 26

levanta-se os custos e ainda outras atividades necessárias antes de se

começar um projeto.

 Architecture/High Level Design: Projeta-se como os itens do Product

Backlog serão implementados. Revisa-se cada item e identificam-se
mudanças necessárias na arquitetura já existente do sistema ou
desenha a arquitetura em caso de um novo produto. Deve ser uma
arquitetura de alto nível, sem muitos detalhes já que o produto será
melhor conhecido a medida que os Sprints forem ocorrendo.

1.4.1.2 Game

Possui apenas uma fase, denominada Development.

 Development: É um ciclo iterativo de desenvolvimento, o Sprint, com um

período pré-definido, normalmente entre 2 a 4 semanas, onde ocorrem
as atividades necessárias para o desenvolvimento do produto. As
iterações ocorrem quantas vezes forem necessárias até que o produto
fique pronto e então ocorra a fase de Closure.

1.4.1.3 Postgame

Possui apenas a fase Closure, e ocorre ao final do Game, quando a

equipe considera que o produto está pronto o suficiente para um release.

 Closure: Inclui a preparação para um release, como um teste integrado

do sistema, a documentação final, treinamento necessário aos usuários
e outras atividades necessárias no fechamento de um projeto.

1.4.2 Papéis e Responsabilidades do SCRUM

O SCRUM define basicamente apenas 3 papéis, o Product Owner,

Scrum Master e Scrum Team.
 27

1.4.2.1 Product Owner

Traduzido literalmente significa Dono do Produto. É o cliente do projeto,

tipicamente um usuário chave que representa os interesses de todos os
envolvidos com o software. É quem define e prioriza as funcionalidades que
compõem o Product Backlog. Deve estar acessível à equipe, tem a
responsabilidade de não trazer novas funcionalidades durante o Sprint e de
fazer a validação do produto ao final de cada Sprint.

1.4.2.2 Scrum Team

É a Equipe responsável pelo desenvolvimento do produto de acordo com

as prioridades definidas pelo Product Owner.

Não há uma definição de papéis formal como programador, testador,

arquiteto ou analista, o que não impede que haja estas funções. Todos
trabalham juntos para completar as funcionalidades que todos conjuntamente
se comprometeram para o Sprint.

A equipe deve ser idealmente pequena, de 5 a 9 pessoas, porém pode

ser maior. Umas das principais abordagens para se trabalhar com equipes
maiores é através do SCRUM of SCRUMs.

1.4.2.3 Scrum Master

É o papel do gerente do projeto, mas pode ser exercido por qualquer

membro da equipe. Responsável por garantir o trabalho da equipe através da
remoção de obstáculos identificados e da proteção da equipe contra
interferências externas.

Deve disseminar e aplicar os valores e práticas do SCRUM na equipe.

 28

1.4.3 Artefatos do SCRUM

Os principais artefatos definidos pelo SCRUM são o Product Backlog,

que é a lista de funcionalidades definidas pelo Product Owner. O Sprint
Backlog que é uma lista dos itens do Product Backlog que foram priorizados
para serem atendidos no Sprint. E o Burndown Chart que consiste de um
gráfico para acompanhamento diário do Sprint quanto à velocidade do time
pelo consumo diário de horas. Esses artefatos são melhor descritos a seguir.

1.4.3.1 Product Backlog

É uma lista de funcionalidades desejadas para o produto. É definida pelo

Product Owner. Ela não precisa ser completa desde o início do projeto,
podendo ser complementada com novas funcionalidades durante o andamento
do projeto, à medida que o conhecimento do produto vai aumentando.

Normalmente contêm no início do projeto os itens necessários para

começar o primeiro Sprint. É uma lista dinâmica, já que pode sofrer alterações
durante todo o andamento do projeto, como o cancelamento de itens, a
mudança de prioridade, ou da própria descrição da funcionalidade.

O SCRUM não define como esta lista é formada, podendo ser usadas
várias técnicas de captura de requisitos. Uma das técnicas utilizadas é tratar
cada item da lista como uma história, ou User Stories como no XP
(MOUNTAIN, 2008).

O Product Owner deve priorizar os itens desta lista, e a equipe deve

estimar cada item para definirem o trabalho, ou funcionalidades que serão
contempladas no Sprint.

1.4.3.2 Sprint Backlog

 29

É uma lista que contém as tarefas que o Scrum Team irá trabalhar
durante o Sprint. Os itens do Product Backlog priorizados pelo Product Owner,
e que a equipe após estimativa inicial e a percepção do trabalho necessário se
comprometeu a entregar dentro do Sprint, são depois quebrados em tarefas
que formam o Backlog do Sprint.

Essas tarefas devem ser atendidas dentro do Sprint, mas caso não
sejam, devem fazer parte do próximo Sprint Backlog.

Cada membro da equipe tem a liberdade de escolher qual tarefa irá

trabalhar e qualquer membro pode adicionar, alterar ou excluir tarefas.

Cada tarefa deve ser estimada pela equipe quanto ao número de horas
necessário para completá-la. E é responsabilidade da equipe manter atualizada
diariamente a lista de tarefas, com as tarefas já concluídas, e a estimativa de
tempo necessário para a conclusão das tarefas ainda em andamento. Tarefas
já concluídas devem ter o número de horas para a conclusão estimadas como
zero.

1.4.3.2 Burndown Chart

O gráfico de Burndown é o principal artefato para acompanhamento do

andamento da iteração. Ele é gerado a partir da lista de tarefas do Sprint
atualizadas diariamente pela equipe com as tarefas já concluídas e as tarefas
ainda pendentes. É baseado no número de horas restantes para a conclusão
de cada tarefa. A soma de horas das tarefas determina a quantidade de horas
necessárias para finalizar o Sprint, e conforme tarefas vão sendo concluídas ao
longo dos dias do Sprint, o gráfico vai descendo até atingir o número de horas
zero. No eixo Y encontra-se o número de horas total estimado para o Sprint e
no eixo X os dias do Sprint, de acordo com o seu tamanho. Ver Figura 1.5.
 30

Sprint Burndown Chart

140

120
Re m aining Effort in Hours

100

80

60

40

20

0
26/10 27/10 28/10 29/10 30/10 31/10 01/11 02/11 03/11 04/11 05/11 06/11 07/11 08/11 09/11
Date

Figura 1.5: Exemplo de gráfico de BurnDown para Sprint.

Através deste gráfico é possível visualizar a velocidade da equipe no

Sprint e verificar se no ritmo de “consumo de horas” atual a equipe irá
conseguir terminar todas as tarefas dentro do Sprint. O gráfico pode oscilar
tanto para cima quanto para baixo. Oscilações para cima, podem indicar
alguma tarefa que foi mal estimada, cujo número de horas está consumindo
mais que o planejado inicialmente ou tarefas novas que entraram ao longo do
Sprint. Oscilações para baixo com queda muito brusca, geralmente indica uma
ou mais tarefas que foram mal estimadas e que consumiram um número menor
de horas do que foi planejado.

1.4.4 Planejamento, Execução e Controle do Sprint

Durante o Sprint cada funcionalidade do software é trabalhada de forma

a ser completada dentro do mesmo Sprint. Em se tratando de software, a
funcionalidade é planejada, projetada, codificada e testada gerando software
funcionando. O tamanho do Sprint, de 2 a 4 semanas, uma vez estabelecido
 31

não deve ter a data final alterada para que as métricas de velocidade do time
sejam consistentes.

1.4.4.1 Sprint Planning Meeting

No início de cada Sprint ocorre um reunião de planejamento chamada de

Sprint Planning Meeting. É nessa reunião que o Product Owner prioriza os itens
do Product Backlog e o Scrum Team seleciona os itens que poderá atender no
Sprint.

Durante a reunião, o Product Owner e o Scrum Team coletivamente

devem definir uma meta para o Sprint. Essa meta é uma breve descrição do
principal objetivo a ser atendido pela iteração. A partir dos itens do Product
Backlog priorizados a equipe quebra as funcionalidades em tarefas que irão
compor o Sprint Backlog. Essas tarefas devem ser definidas e estimadas
colaborativamente pela equipe. É recomendado estimar tarefas de no máximo
16 horas, para facilitar o controle diário. Tarefas estimadas com mais de 16
horas devem ser analisadas para uma possível quebra em tarefas menores.

1.4.4.2 Daily Scrum Meeting

Reunião que ocorre diariamente preferencialmente no mesmo local, no

mesmo horário e fora do ambiente de trabalho. Com todos em pé, deve ser
rápida e objetiva, e durar não mais que 15 minutos. É objetivo desta reunião
disseminar conhecimentos, identificar impedimentos e priorizar o trabalho do
dia, por isso o ideal é fazê-la pela parte da manhã. É função do Scrum Master
tratar os impedimentos identificados o mais rápido possível.

Todos do time devem participar da reunião, e outras pessoas também

podem participar, porém apenas como ouvintes.
 32

Não é objetivo dessa reunião resolver problemas. Caso algum problema

seja levantado, este deve ser tratado fora da reunião apenas com as pessoas
diretamente envolvidas no problema ou com aqueles que podem auxiliar na
solução.

Durante a reunião três perguntas devem ser respondidas por cada um

dos membros do time:

 O que foi feito desde ontem?

 O que você planeja fazer hoje?

 Há algum impedimento no seu caminho?

Através da respostas destas questões o time consegue ter uma boa

noção do andamento do projeto quanto ao que já foi feito e o que ainda falta
fazer. Porém a Daily Scrum não deve ser tratada como um relatório de status
para o Scrum Master, mas como compromissos assumidos perante a equipe.

1.4.4.3 Sprint Review Meeting

Reunião informal que ocorre ao final de cada Sprint onde a equipe

apresenta os resultados alcançados durante o Sprint.

É normalmente uma apresentação das novas funcionalidades para o

Product Owner, Scrum Master e outras pessoas interessadas ou envolvidas
com o projeto.

Deve-se verificar, principalmente se a meta do Sprint foi atingida, ainda

que nem todas as funcionalidades planejadas para o Sprint tenham sido
concluídas.

1.4.4.4 Sprint Retrospective

 33

Após a finalização do Sprint e antes da próxima reunião de planejamento

de Sprint a equipe se reúne com o Product Owner, Scrum Master e outros
interessados para uma retrospectiva sobre o Sprint finalizado.

O principal objetivo é identificar pontos de melhorias e ajustes

necessários principalmente nas práticas do SCRUM.

Há várias maneiras de se conduzir uma reunião de retrospectiva, mas é

importante que ela seja objetiva e curta, com duração aproximada de 30
minutos.

1.5 Ruby on Rails

Ruby on Rails é o framework de desenvolvimento para web que será

utilizado para implementar o web site deste projeto. Porém, antes de falar em
Ruby on Rails, é importante falar sobre Ruby.

1.5.1 Ruby

Ruby é uma linguagem de programação orientada a objetos com partes

semelhantes das linguagens Perl, Smalltalk, Eiffel, Ada, e Lisp, as favoritas de
seu criador Yukihiro Matsumoto.(RUBY, 2008).

É uma linguagem open source, criada para ser mais do que simples,
para ser natural segundo seu criador. Desde 1995 quando teve sua primeira
versão pública tem crescido o número de programadores adeptos a nova
linguagem. Ela conta com uma comunidade ativa, embora as principais
decisões quando não há consenso sejam tomadas por “Matz”. Não há
nenhuma empresa por trás da linguagem, sendo mantida exclusivamente pela
comunidade.

Umas das características da linguagem é que tudo é visto como objeto.

Quando procurava a sintaxe ideal em outras linguagens, Matz queria “uma
linguagem de script mais poderosa que Pearl e mais orientada a objeto que
Phyton”. Como tudo é objeto, cada informação pode ter propriedades e ações.
 34

Por exemplo, em outras linguagens, mesmo orientadas a objetos, geralmente

há tipos primitivos, como tipos numéricos. No Ruby não há tipos primitivos, e
até mesmo um número é um objeto. Influencia que recebeu do Smalltalk.

Ruby é muito flexível, permitindo ao usuário alterar qualquer parte de

sua definição. Apresenta uma tipagem forte e dinâmica, ou seja, toda variável
precisa ter um tipo, porém pode ser alterada dinamicamente.

Ainda outra vantagem do Ruby é que está disponível para diversas

plataformas como Windows, .NET, Java, Linux, Unix e MacOs.

1.5.2 Ruby on Rails Framework

Ruby on Rails é um framework para desenvolvimento de aplicações para

web escrito na linguagem Ruby. Aliás, este framework é um dos responsáveis
pela recente popularização do Rails (RAILS-BR, 2008).

As aplicações desenvolvidas no Ruby on Rails, também conhecido como

RoR, são baseadas no padrão de projeto MVC (Modelo-Visão Controle)
(MSDN, 2008).

O RoR foi extraído de uma aplicação desenvolvida por David Heinemeier

Hansson. E tornou-se público em 2004. De lá para cá não para de crescer o
número de adeptos e sistemas na web sendo desenvolvidos com este
framework.

Os principais componentes do RoR são o Active Record, responsável

pela camada de mapeamento objeto-relacional com o banco de dados. E o
Active Pack composto pelo Active View e Active Controller, correspondentes
respectivamente às camadas Visão e Controle. Há ainda outros componentes
como o Active Mailer, Active Support e Active WebServices (RAILS-BR, 2008).

Um conceito muito interessante do RoR que aumenta a produtividade é

o chamado CRY (Don't Repeat Yourself), que para o português poderia ser
traduzido como Não Se Repita. Este conceito reflete a técnica de definir
propriedades, métodos e código apenas em um lugar. Por exemplo, ao invés
de ter uma classe Cliente com métodos get e set para cada umas das
 35

propriedades de uma tabela Cliente no banco de dados, têm se apenas a

tabela no banco e a linguagem se encarrega de injetar na classe os métodos e
propriedades conforme definido na tabela.

1.5.3 MVC

Model-View-Controller é um padrão de projeto de software que organiza

a aplicação em três camadas básicas. Na camada de Modelo é mantida toda a
comunicação e regras de acesso ao banco de dados, enquanto na Visão estão
as regras de interface com o usuário. Na camada de Controle ficam as regras
de negócios. Ela fica entre a camada de Visão e Modelo. Com essa separação
em camadas o MVC facilita a manutenção da aplicação, uma vez que uma
alteração de layout,na aplicação pode ser feita sem afetar as regras de negócio
ou o acesso a dados, e da mesma forma alterações me banco de dados podem
ser efetuadas sem afetar a interface com o usuário (MSDN, 2008).

Em sistemas web geralmente a camada View é a página HTML

apresentada para o usuário. E o código que gera a saída HTML normalmente á
camada Controller.

Embora tenha sido desenvolvido primeiramente para o Smalltalk, hoje

este padrão de projeto está difundido entre várias linguagens de programação
e é possível encontrar muitos frameworks baseados neste modelo.
 2. ESTADO DA ARTE

Houve um tempo em que defensores das Metodologias Ágeis

advogavam o uso exclusivo de uma ou de outra metodologia, até mesmo entre
as próprias Metodologias Ágeis. Por exemplo, ou se usa XP ou se usa
SCRUM. Porém esse tipo de pensamento está mudando, e já se encontra
muitos casos de projetos usando práticas de mais de uma metodologia. Nesse
contexto Ágil é comum, por exemplo, a adoção de SCRUM integrado com
práticas do XP. Usar Metodologia Ágil com algum processo tradicional, então,
era algo impensável, tamanha a radicalidade. Do mesmo modo, entre os
praticantes de processos ou metodologias consideradas tradicionais, como PMI
e CMMI, por longo tempo houve discriminação para com as Metodologias
Ágeis. A principal crítica deles aos Métodos Ágeis era a falta de documentação.

Felizmente este cenário está mudando, e está cada vez mais comum
encontrar a adoção de ambos os processos ou metodologias em conjunto nas
empresas, adaptados para conviverem num mesmo ambiente fornecendo o
que cada uma tem de positivo para o processo como um todo.

A área de gerenciamento de projetos está crescendo nas empresas,

principalmente o uso das práticas do PMI publicadas no seu PMBOK Guide. Da
mesma forma o uso de Metodologias Ágeis está ganhando mercado e adeptos
nas empresas de desenvolvimento de software. Por isso é possível encontrar
cada vez mais materiais, estudos, propostas e discussões sobre o uso
integrado de ambos os processos, principalmente na área de desenvolvimento
de software.

Seguem abaixo alguns destes estudos.

 37

2.1. Estudos da Aplicação de Práticas do PMBOK com Agile

Michele Sliger (2006), uma profissional certificada PMP (Project

Management Prefessional) e CSM (Certified Scrum Master) é uma das pessoas
que tem contribuído para adoção de práticas do PMBOK com Metodologias
Ágeis. Em uma séria de quatro artigos entitulado “Relating PMBOK Pratices to
Agile Pratices” (SLIGER, 2006) a autora discute uma abordagem consistente
de como trabalhar com PMBOK e Metodologias Ágeis. Segundo ela, apesar
das diferenças de filosofias entre PMI e Agile, muitas das práticas do PMBOK
são compatíveis com as práticas ágeis.

Nessa série de artigos, Sliger navega com muita propriedade e clareza

por cinco áreas de conhecimento do PMBOK Guide (integração, escopo,
tempo, risco e qualidade), com uma visão não apenas didática, mas ao que
parece de quem tem experiência prática sobre o que está descrevendo. Ela diz
que para cada uma das áreas do PMBOK, suas práticas têm práticas relativas
nas Metodologias Ágeis, porém a forma de executar é diferente.

Michele escreve que muitos autores e profissionais tanto do CMMI

quanto do PMI declaram que seu modelo é um guia de melhores práticas e que
cada organização deve usar os seus próprios critérios no uso destas práticas.
Por muito tempo o PMBOK tem sido associado ao modelo Waterfall, quando
não é verdade uma vez que ele é perfeitamente aplicável com um modelo
iterativo.

No gerenciamento de integração o principal processo é o

desenvolvimento do plano do projeto, definindo como o projeto será executado
e controlado, onde contém os planos para cada uma das áreas. Já nas
Metodologias Ágeis o plano é feito e revisitado continuamente, com um nível de
detalhe o suficiente para a realidade de tempo, conforme os releases e
iterações. Da mesma forma o controle integrado de mudança é natural no dia-
a-dia da equipe, e ocorre através das priorizações feitas pelo cliente no
backlog, e durante as reuniões de planejamento e revisão de iteração e
releases.

O gerenciamento de escopo é a área mais importante do PMBOK e por

isso recebe grande atenção. Nos Métodos Ágeis também é de extrema
 38

importância, porém a filosofia é totalmente diferente. Enquanto o PMBOK

procura blindar o escopo contra mudanças, a abordagem ágil abraça a
mudança. Uma abordagem interessante colocada pela Sliger é a forma de criar
a EAP. Ao invés de conter todo o trabalho para o projeto como normalmente é
feito no PMBOK, no modelo ágil a EAP pode ser feita no início de cada
release. O primeiro nível poderá conter as iterações e para cada iteração os
pacotes de trabalho são as funcionalidades do bakclog priorizados para o
release dispostos em ordem de prioridade. Durante o início da iteração as
funcionalidades são então quebradas em tarefas. Ver Figura 2.1.

Figura 2.1: EAP para Release e Iteração.

Outro aspecto importante é o gerenciamento do risco que no PMBOK

significa identificar possíveis eventos negativos para o projeto e tentar
minimizar sua ocorrência e impacto. Na abordagem ágil o risco é tratado
naturalmente no ciclo de vida do produto. É natural identificar e responder aos
riscos continuamente. Isso é feito nas reuniões diárias, nas reuniões de
planejamentos e de revisão e de retrospectiva de releases e iterações. Quanto
ao gerenciamento da qualidade, normalmente é uma das últimas fases no
modelo tradicional enquanto que na filosofia ágil há uma busca constante da
 39

qualidade ao longo das iterações e com envolvimento do cliente, quem dará o

aceite final.

Outra abordagem interessante é dada por Alan S. Koch (2004) em sua

apresentação “The Agile Manifesto and the PMBOK”. Ele faz um mapeamento
dos grupos de processos do PMBOK com um desenvolvimento iterativo,
ilustrado na Figura 2.2.

Fonte: Baseado na apresentação de Koch (2004).

Figura 2.2: Desenvolvimento iterativo e grupos de processos PMBOK.

Nesta apresentação Koch vai navegando por cada um dos grupos de

processo e fazendo um paralelo entre os processos do PMBOK e discutindo o
impacto com o enfoque iterativo das Metodologias Ágeis. Ele elenca para cada
grupo de processo a compatibilidade e incompatibilidade entre PMI e Ágil e o
que pode ser feito. Koch conclui dizendo que “Nada nas Metodologias Ágeis é
incompatível com os processos do PMBOK” e que “pode ser oportuno reforçar
as Metodologias Ágeis com processos do PMBOK, porém somente onde
realmente necessário e sem comprometer a agilidade”.

Ana Magalhães em sua apresentação “O Gerenciamento de Projetos à

Luz das Metodologias Ágeis” (MAGALHÃES, 2005) faz um estudo bem
apurado sobre o gerenciamento de projetos sobre os enfoques, tradicional e
Ágil. Ela descreve algumas Metodologias Ágeis e faz um comparativo entre o
PMBOK e a abordagem Agile Project Management (APM) passando por cada
 40

uma das áreas de conhecimento do PMBOK. Em sua conclusão defende que

as abordagens tradicional e ágil podem conviver bem já que as boas práticas
são compatíveis, mas é importante buscar o equilíbrio e considerar o ambiente.

Em outra apresentação, Tierno (2008), embora não faça uma

comparação sobre PMBOK e Métodos Ágeis, ainda assim faz uma clara
explanação sobre o gerenciamento de projetos sobre o enfoque Ágil, a APM
(Agile Project Manegment). Em sua apresentação há muitos pontos de
reflexão, e dentre alguns pontos interessantes colocados por ele, a
comparação entre sucesso do projeto e sucesso do cliente é instigante. Em sua
apresentação sucesso do projeto é entregar dentro do prazo e orçamento
enquanto que para o cliente sucesso é ter o seu negócio contemplado
conforme desejado. Atingindo os dois sucessos, ou seja, entregando no prazo,
no orçamento e atendendo as reais necessidades do cliente é sucesso “Total”.
Outro ponto de reflexão interessante é o que diz que os “profissionais não são
pagos para codificar, produzir modelos, documentos ou planos, mas acima de
tudo para entregar software funcionando para o cliente que responda
efetivamente às necessidades do negócio”. Outro ponto é que projetos de
software necessitam de ambas as abordagens, tradicional e Ágil de
gerenciamento. Para grandes marcos, como releases, para atividades que não
são diretamente relacionadas ao software e para dependências entre projetos o
planejamento e acompanhamento tradicional é mais indicado.

Ainda outro trabalho nessa área, porém com um enfoque um pouco

diferente, é o da Leal (2008) que em sua apresentação “Uma Abordagem Ágil
ao Gerenciamento de Projetos de Software baseada no PMBOK Guide”
propõem uma metodologia para gerenciamento de projetos ágil chamada
Agilius baseada em uma abordagem clássica (PMBOK) e em quatro
abordagens ágeis.(APM, XPM, SCRUM e APM Framework).

2.2. Projetos com Metodologias Ágeis

O Centro de Estudos e Sistemas Avançado do Recife ou C.E.S.A.R é

uma das organizações que tem adotado práticas tradicionais em conjunto com
Métodos Ágeis. Na apresentação “Uso do SCRUM em Ambiente CMMI”
 41

(CESAR, 2007) cinco profissionais do C.E.S.A.R mostram como a organização

estando em busca do CMMI nível 3, já com um processo de software
institucionalizado partiu para o uso de SCRUM a partir da motivação de alguns
gerentes para aderirem a Agile Project Management (APM). Nessa
apresentação é mostrada a adaptação necessária no processo já existente
para contemplar os dois modelos, a estratégia de implantação do SCRUM e as
abordagens adotadas. Segundo eles a adoção do SCRUM foi positiva e
concluem dizendo que o uso de SCRUM em ambiente CMMI é possível
(CESAR, 2007).

Em outro artigo escrito por outros profissionais do C.E.S.A.R, e

publicado na revista Mundo PM, eles descrevem como usar o SCRUM para
gerenciar projetos (PEREIRA, TORREÃO e MARÇAL, 2007). Eles apresentam
a metodologia SCRUM e no final do artigo explicam os resultados do uso do
SCRUM e o que mudou após o uso do mesmo. Segundo o artigo, o uso de
SCRUM começou com projetos de pesquisa e inovação, em um projeto cujo
objetivo era construir 7 jogos para celular em um prazo de 5 meses. Com uma
equipe de 35 pessoas, a equipe foi dividida em 7 células menores, uma para
cada jogo. O resultado foi um sucesso já que o projeto foi entregue dentro do
prazo e orçamento previstos. Houve evolução da equipe em vários aspectos e
a satisfação do cliente que participou do processo de desenvolvimento.

2.3. Comparativo com Estudos e Projetos Apresentados

Há estudos de vários tipos e certamente nem todos foram elencados

neste trabalho. Há os que comparam as abordagens tradicionais e ágeis, os
que simplesmente mostram com mais enfoque as vantagens e como trabalhar
com a moderna Agile Project Management, ainda os que vão um pouco mais
além e propõem uma forma de aplicar as práticas das duas em conjunto, e por
fim aqueles que propõem uma nova metodologia a partir da junção de práticas
de várias metodologias clássica e ágil.

A série de artigos da Michele é um dos mais consistentes e práticos dos

materiais estudados e aqui apresentados. Ele está muito relacionado com este
trabalho uma vez que apresenta de forma prática, clara e organizada como
 42

trabalhar com PMBOK e Métodos Ágeis, o que é um dos objetivos deste

trabalho. Colocar em prática com o uso de ambas as abordagens com
aproveitamento do que há de melhor em cada uma delas, com as adaptações
de acordo com o tipo de projeto.

Seguindo esta linha, os projetos executados pelo C.E.S.A.R são

motivadores á medida que comprovam justamente que Metodologias Ágeis é
perfeitamente aplicável em projetos de software de forma a conviver com
outras abordagens tradicionais como CMMI e PMI.
 3. SOLUÇÃO IMPLEMENTADA

Estão descritos nesta seção os itens e atividades referentes no SCRUM

ao Pregame, onde é trabalhado o planejamento inicial (Planning) e o projeto de
alto nível (Architecture / High Level Design) do sistema. No que se refere ao
PMBOK Guide, estão contemplados os processos de Iniciação e Planejamento,
com processos das áreas de conhecimento de Gerenciamento de Integração e
Gerenciamento do Escopo.

3.1. Levantamento de Requisitos, Product Backlog e Escopo

Para levantar os requisitos e definir o escopo macro do produto, foi feita

uma reunião inicial de projeto com o cliente, na qual ele elencou as
funcionalidades desejadas para o web site da empresa. Essas funcionalidades
foram expressas através de cartões, usando o método “Como
...<papel>...Quero <necessidade>...Para <benefício>”. Essa técnica é descrita
por Mike Cohn (2004) em seu livro “User Stories Applied For Agile Software
Development”.

O objetivo desta reunião foi identificar com o cliente o escopo do projeto,

como ele seria gerenciado e implementado.

Como resultados desta reunião, foram gerados o Product Backlog inicial,

e o documento “Declaração Preliminar de Escopo”, conforme apresentado no
Anexo 1. Nele estão descritos os objetivos e metas do projeto, as
funcionalidades levantadas pelo cliente e organizadas como Product Backlog,
as principais entregas, restrições, premissas e a organização do projeto.
 44

Importante salientar que o Escopo está sendo tratado como mais amplo
que o Product Backlog. Enquanto o Product Backlog contempla as
funcionalidades do produto, e logo define o escopo do produto, o Escopo está
sendo tratado como toda a visão do projeto, que vai mais além do que o
produto em si e por isso define o escopo do projeto, conforme distinção de
escopo feita pelo PMBOK Guide (PMBOK, 2004 p. 104).

No alinhamento do uso de práticas do PMBOK com o SCRUM alguns

artefatos ou processos do PMBOK foram simplificados para não ficarem
pesados demais ao projeto. Para este projeto, o documento “Declaração
Preliminar de Escopo” do grupo de processos de Integração do PMBOK foi
simplificado para conter apenas o que é mais importante para dar uma visão do
projeto tanto ao cliente como para a equipe. Ele contém elementos tanto dos
documentos “Carta de Projeto”, também chamado de “Project Charter”, quanto
da “Declaração Preliminar de Escopo” propriamente dita. Este documento
substituiu também a “Declaração de Escopo”, documento da área de
conhecimento de Gerenciamento de Escopo. Numa “Declaração de Escopo”
tradicional, o escopo deveria estar o mais detalhado possível, porém para o
uso com Metodologias Ágeis, a “Declaração Preliminar de Escopo”, no Anexo
1, é suficiente, uma vez que contém uma visão macro do projeto, porém o
suficiente para a implementação com Metodologias Ágeis. Neste documento o
Product Backlog representa o escopo do produto, enquanto que a EAP inicial
representa o escopo macro do projeto quanto aos pontos de atenção ao longo
do projeto.

A “Declaração Preliminar de Escopo”, Anexo 1, ficou um documento

mais leve e objetivo, alinhado e adequado tanto para o PMBOK quanto para o
uso com SCRUM.

3.2. Planejamento

A partir da “Declaração Preliminar de Escopo” foi gerado o documento

“Plano de Gerenciamento do Escopo”, conforme apresentado no Anexo 2. Este
documento é da área de conhecimento de Gerenciamento de Escopo do
PMBOK e descreve como será gerenciado o projeto quanto à metodologia de
 45

desenvolvimento utilizada, como o escopo será gerenciado, como o Product

Backlog será atendido e controlado, como serão organizados os Sprints, como
será gerenciada a mudança de escopo e ainda como será feita a verificação do
escopo e a comunicação para o cliente.

Este documento também foi simplificado de forma a ficar menos formal,

mais objetivo e adequado à praticidade das Metodologias Ágeis.

Uma vez feito este documento, e utilizando frequentemente

Metodologias Ágeis para outros projetos, este documento não precisaria ter
tantos detalhes sobre como gerenciar o escopo já que estas questões estariam
implícitas a metodologia de desenvolvimento de software escolhida. Logo
poderia ser um documento ainda mais sucinto ou nem existir.

3.3. Visão Geral do Sistema em Casos de Uso

A partir do Product Backlog inicial e da “Declaração Preliminar de

Escopo” foram desenhados os casos de uso que fornecem a visão geral do
sistema a ser implementado.

Não é objetivo detalhar todos os usos do sistema quanto a suas

funcionalidades e papéis, uma vez que SCRUM não exige que sejam usados
casos de uso. Os casos de uso, aqui aplicados, são para auxiliar na visão
macro do produto de forma a visualizar os itens do backlog de uma maneira
mais ampla e organizada. Justamente por isso foram feitos apenas os
diagramas de casos de uso nível 0 e nível 1 e estes não foram detalhados
quanto aos cenários.

Importante destacar que os diagramas e casos de uso vistos nesta

seção não são considerados como definitivos, já que conforme as iterações
forem sendo executadas e o conhecimento do sistema for aumentando o
Product Backlog poderá sofrer alterações como, por exemplo, a eliminação de
funcionalidades. Estes casos de uso refletem apenas a idéia inicial do sistema.

Para facilitar o entendimento foram desenhados 3 diagramas de casos

de uso. Um diagrama nível 0, chamado de “Diagrama Geral”, visualizado na
 46

Figura 3.1, o qual possui dois casos de uso. Cada um destes dois casos de uso
foi detalhado em outro diagrama, resultando em mais dois diagramas. São os
diagramas “Navegar no Web Site” da Figura 3.2 e “Gerenciar Web Site” da
Figura 3.3.

Figura 3.1: Diagrama de Caso de Uso - Geral.

Basicamente o Diagrama Geral representa que o sistema, ou web site

institucional, estará dividido em uma área pública, onde os usuários da internet
ou clientes da editora poderão navegar, e uma área restrita ao administrador,
onde este gerenciará o web site.
 47

Figura 3.2: Diagrama de Caso de Uso - Navegar no Web Site.

O diagrama “Navegar no Web Site” ilustrado na Figura 3.2, cujo principal

ator é o Usuário que navega no site, descreve através dos casos de usos as
ações básicas que o cliente poderá efetuar sobre o web site. São elas:

 Visualizar Produtos: Usuário poderá visualizar os produtos da editora e

algumas informações sobre os mesmos, como foto, autor, preço, etc.

 Enviar Email Contato: O usuário poderá enviar e-mail para pessoas

e/ou setores da empresa através de formulário de contato disponível no
site.

 Interagir Blog: Usuário poderá visualizar e comentar posts do blog da

editora.

 Visualizar Promoções: Usuário poderá visualizar as promoções

disponíveis. Promoções poderão ser disponibilizadas através de
banners, seções específicas ou na própria página de produtos.
 48

 Visualizar Pontos de Premiação: Disponível somente para clientes da

editora. Este poderá consultar sua pontuação no programa de
premiação.

 Cadastrar E-mail para Comunicações: Usuário poderá cadastrar seu

e-mail para receber comunicações da editora.

O diagrama “Gerenciar Web Site” da Figura 3.3. tem como ator o

Administrador do sistema. Nele encontram-se os casos de usos de
gerenciamento do web site.

Figura 3.3: Diagrama de Caso de Uso - Gerenciar Web Site.

Casos de uso deste diagrama:

 49

 Gerenciar Seções: Administrador poderá criar, editar e excluir seções

no site.

 Gerenciar Clientes: Administrador poderá visualizar os clientes

cadastrados na Loja Online e cadastrados pelo web site para receber
comunicações.

 Gerenciar Blog: Administrador poderá administrar as funções básicas

do blog.

 Gerenciar Arquivos de Midia: Administrador poderá atualizar imagens

do site, como banners, imagens de produtos, arquivos PDFs, Flash etc.

 Gerenciar Programa de Premiação: Administrador poderá gerenciar

informações do programa de premiação, como prêmios de clientes,
fornecer prêmios, etc.

 Gerenciar Promoções: Administrador poderá cadastrar promoções e

criar seções específicas de promoções.

 Gerenciar Produtos: Administrador poderá cadastrar produtos e

atualizar dados básicos como descrição, fotos, etc.

 Gerenciar E-mail Marketing: Administrador poderá gerenciar e-mails

marketing, principalmente enviando e-mail para clientes selecionados.

 Autenticar no Sistema: Administrador precisará se autenticar no

sistema para poder gerenciá-lo, pois a área de administração requer
autenticação.

3.4. Arquitetura

Quanto à arquitetura de alto nível da aplicação, ela estará organizada

em: Administração, Site Público, Blog, Banco de Dados, Loja Online e Blog
Afim de Proclamar, conforme Figura 3.4.

O “Site institucional” estará dividido em três componentes, uma parte

pública, uma área de administração e um Blog. A “Loja Online” e o “Blog Afim
 50

de Proclamar” são aplicações independentes e externas ao site, porém haverá

alguns tipos de integrações entre o site institucional e a loja, ainda que seja
apenas um link apontando para a loja. Os dados do site institucional estarão
armazenados num banco de dados MySql. Serão dois banco de dados
independentes, um para o site e outro para o Blog do site.

Figura 3.4: Diagrama de Componente - Arquitetura Alto Nível.

A aplicação será implementada em Ruby on Rails seguindo, portanto o

padrão de projeto MVC (Model View Controller). Na camada visão, os layouts
do Site Público, Administração e Blog serão independentes, configurados
através de arquivos CSS (Cascading Style Sheets).
 51

3.5. Diagrama de Classe Conceitual

Para ter uma idéia de alto nível das classes que serão necessárias no
produto, mas ao mesmo tempo sem entrar no detalhe foi feito um diagrama de
classe conceitual baseado na análise inicial das quatro User Stories
(funcionalidades) priorizadas pelo cliente (Product Owner) para serem
entregues na primeira versão (release) implantada do software. O diagrama
pode ser observado na Figura 3.5.

Figura 3.5: Diagrama de Classe - Conceitual primeiro release.

Este diagrama não entrou no detalhe de atributos e métodos, como

também não contempla a análise para toda a lista de funcionalidades, pois,
uma análise mais detalhada será feita para cada funcionalidade na Iteração em
que ela for desenvolvida. Não há necessidade de se fazer uma análise
detalhada neste momento, sendo que a lista de funcionalidades desejada
poderá, e provavelmente irá, sofre alterações ao longo do projeto conforme as
iterações (Sprints) forem ocorrendo e o cliente ir conhecendo mais sobre o
produto.
 52

3.6. Layout do Site

Na Figura 3.6. é possível ver a capa do site institucional atual da editora.

Este layout é o mesmo que será mantido para o novo site, já que o cliente não
solicitou nenhum tipo de mudança, o que não quer dizer que isso não possa
mudar.

Figura 3.6: Capa atual do site institucional da editora.

O site é composto de um menu superior onde se pode navegar pelas

páginas ou seções do site. Há itens do menu que podem levar para sites
externos, como por exemplo o link para a Loja. Logo abaixo do menu há uma
área de banner e abaixo deste o corpo do site, dividido em duas colunas. Na
coluna da esquerda, e maior, há o corpo da capa propriamente dito com texto e
imagens divulgando o site e produtos. Na coluna direita há links para trechos
de alguns livros em formato pdf. Logo abaixo destes links uma área de banners
menores com divulgação de produtos, promoções ou sites externos.
 CONSIDERAÇÕES FINAIS

Este trabalho concentrou-se em estudar os fundamentos teóricos sobre

o tema abordado, principalmente no que se refere ao processo de
desenvolvimento de software, gerenciamento de projetos e Metodologias
Ágeis. Foi estudada e apresentada mais fortemente a metodologia SCRUM,
base para o gerenciamento deste projeto juntamente com o PMBOK. Buscando
compreender a forma de trabalho destas metodologias, e identificar formas de
adaptá-las para o uso em conjunto. Foram pesquisados e estudados outros
trabalhos e projetos relacionados ao tema “aplicar práticas ágeis com práticas
consideradas tradicionais”, principalmente relacionadas ao PMBOK.

Forma encontrados materiais muito bons sobre o assunto, o que

reforçou o pensamento inicial de que é perfeitamente viável a aplicação de
ambos paradigmas em conjunto. O segredo está em saber adaptar o processo
para o projeto em questão. Não há solução perfeita, cada situação requer
atenção especial. E o mercado tem provado que essa abordagem conjunta é
possível, embora ainda se encontre céticos achando o contrário.

Não há nenhuma referência no PMBOK que proíba o uso de suas

práticas com Métodos Ágeis, assim como o PMBOK não defende o ciclo em
cascata para o desenvolvimento de projetos, mas apenas sita como uma das
variantes possíveis. O próprio PMBOK descreve que o ciclo de vida depende
do projeto e da empresa que aplica:

“Não existe uma única melhor maneira para definir um ciclo de

vida ideal do projeto. Algumas organizações estabeleceram
políticas que padronizam todos os projetos com um único ciclo
de vida, enquanto outras permitem que a equipe de
 54

gerenciamento de projetos escolha o ciclo de vida mais

adequado para seu próprio projeto..” (PMBOK, 2004 p. 20).

Foi parte importante deste trabalho a definição do escopo e

funcionalidades do produto desejado, juntamente com o cliente, aplicando
princípios das Metodologias Ágeis e do PMBOK Guide.

A partir da visão do projeto, começou o trabalho de planejar o projeto

adaptando os processos de acordo com o projeto. No caso do PMBOK, por
exemplo, processos e artefatos foram unificados para simplificar e deixar o
processo mais leve para o uso com o SCRUM. A maior dificuldade foi
identificar as fronteiras de cada metodologia, para não ferir nem uma, nem
outra e encontrar o equilíbrio entre ambas. Por exemplo, no PMBOK o escopo
é algo que deve ser muito detalhado enquanto nos Métodos Ágeis, o escopo
deve ser de alto nível sem muitos detalhes. Para endereçar essa questão o
processo de “Definição de Escopo” do PMBOK foi substituído pela “Declaração
Preliminar de Escopo” que apresentou uma visão simples do escopo, cujo
escopo preliminar foi definido principalmente pelo Product Backlog.

Após o planejamento do projeto no que se refere ao escopo, Product

Backlog, releases e sprints, fez-se um trabalho que no SCRUM é chamado de
Architecture e High Level Design e refere-se à fase de PreGame. Nesta fase
foram desenhados diagramas de alto nível para dar uma visão melhor do
projeto, suas partes e arquitetura. Este foi outro ponto que precisou de muita
atenção para não avançar demais nos detalhes e ao mesmo tempo produzir
artefatos úteis ao projeto.

De modo geral os objetivos propostos foram alcançados, restando para

a segunda parte do trabalho a implementação do software proposto e aplicar
outras práticas de ambas as abordagens, SCRUM e PMBOK, para a execução,
controle e fechamento do projeto.

Ao olhar para a abordagem de Koch, sobre o processo iterativo e os

grupos de processos do PMBOK, é possível ver na Figura 4.1, que nesta
primeira parte do trabalho foram contemplados os processos “Iniciar Projeto” e
“Planejar Projeto”, marcados em amarelo na figura.
 55

Figura 4.1: Processos executados no trabalho na abordagem de Koch.

No TCC II os demais grupos de processos, execução, controle e

fechamento serão contemplados e da mesma forma os processos iterativos
destes grupos. Trabalho que deverá ocorrer até dezembro de 2008, com
releases planejadas para ocorrerem mensalmente, com entrega ao cliente de
produto funcionando a partir do final de agosto.

No mês de julho deverá ocorrer a preparação do ambiente de

desenvolvimento e estudo do framework de programação para web Ruby on
Rails que será utilizado para implementação do sistema.
 REFERÊNCIAS BIBLIOGRÁFICAS

ABNT – ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC

12207 – Tecnologia de informação - Processos de ciclo de vida de
software. Rio de Janeiro: ABNT, 1998, 35 p.
AGILE MANIFESTO. Manifesto for Agile Software Development. Agile
Alliance, 2001. Disponível em: <http://www.agilemanifesto.org/>. Consultado
em abril de 2008.
ALISTAIR. Crystal Methodologies Main Foyer. Disponível em:
<http://alistair.cockburn.us/index.php/Crystal_methodologies_main_foyer>.
Consultado em abril de 2008.
AMBLER, Scott. Agile Adoption Rate Survey: 2007. Disponível em:
<http://www.ambysoft.com/surveys/agileMarch2007.html#Results>.
Consultado em abril de 2008.
CESAR. Uso do SCRUM em Ambiente CMMI. SINPROS 2007. Disponível
em: <http://www.simpros.com.br/upload/2007/36752.pdf>. Consultado em
junho de 2008.
COHN, Mike. User Stories Applied: For Agile Software Development (The
Addison-Wesley Signature Series). Addison-Wesley Professional, 2004.
CONTROL CHAOS. About Scrum – Overview. Disponível em:
<http://www.controlchaos.com/about/>. Consultado em abril de 2008.
DSDM-ORG. DSDM Consortium: Enabling Business Agility. Disponível em:
<http://www.dsdm.org/>. Consultado em abril de 2008.
FDD. Feature Driven Development. Disponível em:
<http://www.featuredrivendevelopment.com/>. Consultado em abril de 2008.
GAMMA, Erich et al. Padrões de Projeto: soluções reutilizáveis de software
orientado a objetos. Porto Alegre: Bookman.
HUMPHREY, Watts S. A Discipline for Software Engineering. Reading, MA:
Addison-Wesley, 1995.
KOCH, Alan S. Are Agile Methods Compatible with the PMBOK? Pittsburgh
Project Management Institute. 2004. Disponível em:
<http://www.pittsburghpmi.org/documents/meetings/presentations/AgileManif
esto-PMBOK.pdf>. Consultado em junho de 2008.
 57

LARMAN, Craig e BASILI, Victor R. Iteractive and incremental Development:

A Brief History. IEEE Computer Society. 200.3
LEAL, Luciana de Queiroz. Uma Abordagem Ágil ao Gerenciamento de
Projetos de Software baseada no PMBOK® Guide. Universidade Federal
de Pernambuco. Centro de Informática. 2008
MAGALHÃES, Ana Liddy Cenni de Castro. O Gerenciamento de Projetos
Desenvolvido à Luz das Metodologias Ágeis. PMI-MG. 2005. Disponível
em: <http://www.pmimg.org.br/downloads/Palestra-GerenciamentoAgil.pdf>.
Consultado em junho de 2008.
MSDN. Model-View-Controler. Microsoft patterns & practices Developer
Center. Disponível em: <http://msdn.microsoft.com/en-
us/library/ms978748.aspx>. Consultado em julho de 2008.
MOUNTAIN Goat Software. The Scrum Development Process. Disponível
em: <http://www.mountaingoatsoftware.com/scrum>. Consultado em junho
de 2008.
MPS.BR. Melhoria de Processo do Software Brasileiro. Guia Geral. Versão
1.2. Disponível em:
<http://www.softex.br/mpsBr/_guias/MPS.BR_Guia_Geral_V1.2.pdf>.
Consultado em maio de 2008.
MSDN. Visual Studio Team System 2005 Developer Center. Disponível em:
<http://msdn2.microsoft.com/en-us/teamsystem/aa718795.aspx>.
Consultado em abril de 2008.
MYSQL. The world's most popular open source database. Disponível em:
<http://www.mysql.com >. Consultado em abril de 2008.
PAULK, Mark; CURTIS, Bill; CHRISSIS, Mary Beth; WEBER, Charles.
Capability Maturity Model for Software - Version 1.1 (CMU/SEI-93-
TR-024). Pittsburg, PA:SEI, Carnegie Mellon University, 1993.
PEREIRA, Paulo. TORREÃO, Paula. MARÇAL, Ana Sofia. Entendendo
SCRUM para Gerenciar Projetos de Forma Ágil. Revista Mundo PM,
Número 14. Abril/Maio 2007. Disponível em:
<http://www.cesar.org.br/files/file/SCRUM_MundoPM-Abril-Maio-2007.pdf>.
Consultado em junho de 2008.
PMBOK, Guide. Um Guia do Conjunto de Conhecimentos em
Gerenciamento de Projetos – Terceira Edição. Versão em Português.
Pennsylvania: PMI, 2004.
PMI-SP. O Instituto: História. Disponível em:
<http://www.pmisp.org.br/instituto.asp>. Consultado em abril de 2008.
POPPENDIECK. Lean Software Development. Disponível em:
<http://www.poppendieck.com/>. Consultado em abril de 2008.
RAILS-BR. Ruby On Rails: Desenvolvimento web sem dor. Disponível em:
<http://www.rubyonrails.pro.br>. Consultado em abril de 2008.
RUBY, A Progamer's Best Friend. About Ruby. Site oficial. Disponível em:
<http://www.ruby-lang.org/en/about/>. Consultado em junho de 2008.
 58

REINEHR, Sheila dos Santos. Utilização do PSP no Desenvolvimento de

Software. São Leopoldo, RS: Universidade do Vale do Rio dos Sinos –
Laboratório de Qualidade de Software, 2001.
SCHWABER, Ken. Agile Project Management with Scrum. 2004.
SCHWABER, Ken. SCRUM Development Process. OOPSLA 1995.
Disponível em: <http://www.jeffsutherland.com/oopsla/schwapub.pdf>.
Consultado em junho de 2008.
SEI-USA. Capability Maturity Model for Softwre – CMM. Disponível em:
<http://www.sei.cmu.edu/cmm/>. Consultado em abril de 2008.
SLIGER, Michele. Relating PMBOK Practices to Agile Practices.
StickyMinds.Com. 2006. Disponível em <http://www.stickyminds.com/s.asp?
F=S10365_COL_2>. Consultado em junho de 2008.
TELES, Vinícius Manhães. Extreme Programming: Aprenda como encantar
seus usuários desenvolvendo software com agilidade e alta qualidade.
São Paulo: Novatec, 2004.
THOUGHTWORKS. Mingle Overview. Disponível em:
<http://studios.thoughtworks.com/mingle-project-intelligence>. Consultado
em abril de 2008.
TIERNO, Marcio. Gerenciamento de Projetos Iterativos e Metodologias
Ágeis. Compuware, 2006. Disponível em:
<www.spinsp.org.br/apresentacao/AgilePMOut.pdf>. Consultado em junho
de 2008.
VERSIONONE. Survey: The State of Agile Development. Pesquisa de 2007.
Disponível em:
<http://www.versionone.com/pdf/StateofAgileDevelopmentSurvey.pdf>.
Consultado em abril de 2008.
VIEIRA, Marconi Fábio. Gerenciamento de Projetos de Tecnologia da
Informação. Rio de Janeiro: Editora Campus, 2003.
XP-COM. XProgramming: an Agile Software Development Resource.
Disponível em: <http://www.xprogramming.com/>. Consultado em abril de
2008.
XP-ORG. Extreme Programming: A Gentle Introduction. Disponível em:
<http://www.extremeprogramming.org/>. Consultado em abril de 2008.
 59

Versão Doc.:

ANEXO 1
Declaração Preliminar de 1.0

Escopo Data:
22/05/2008
Cliente: Editora Adhonai Projeto: Site Institucional Adhonai

Informações do Projeto
Representante do Cliente Gerente do Projeto

José Gustavo Miranda Aleckssandro Tavares

1.2.1.1 Data de lançamento do projeto Data final prevista
15/05/2008 30/12/2008

Justificativa do Projeto

O site institucional da editora é o principal canal de comunicação com os clientes. Para isso
precisa manter-se sempre atualizado com notícias, lançamentos e promoções. Porém atualmente
o site é com conteúdo estático requerendo um especialista para a sua atualização.

Este projeto irá proporcionar uma área de administração para o gerenciamento do conteúdo do
site de forma dinâmica, sem a necessidade de um especialista.

Objetivos e Metas

Situação Atual

A editora possui um Site Institucional e uma Loja Virtual. Ambos são independentes, estando
inclusive hospedados em servidores de fornecedores diferentes. O site é hospedado na LocaWeb
e a loja no Shopping dos Correios.

O site institucional é o principal canal de comunicação com os clientes, onde há notícias,

informações sobre a editora, formulário para contato com os clientes e divulgação de livros e
promoções que apontam (link) para a loja.

O conteúdo do site é totalmente estático, ou seja, em HTML, sem banco de dados e sem área de
administração. Quando necessário atualizações de conteúdo, sejam banners, notícias, novos
produtos, etc, precisam de um especialista para editar as imagens, html e posterior upload do
conteúdo atualizado para o servidor de hospedagem.

Nem todos os pedidos ou compras são feitos pela loja, sendo que alguns pedidos são gerenciados
também por telefone e e-mail. Logo nem todos clientes ficam cadastrados na loja online.

Situação Desejada

Maior flexibilidade para editar o conteúdo do site de forma dinâmica através de uma área de
administração. A edição deverá ser possível por uma pessoa, sem a necessidade de
conhecimento prévio de html.
Também é desejo do cliente concentrar a administração dos clientes pela site já que nem todos
clientes são cadastrados na loja online e também para não ficar dependente do fornecedor da
loja online.
 60

Versão Doc.:

ANEXO 1
Declaração Preliminar de 1.0

Escopo Data:
22/05/2008
Cliente: Editora Adhonai Projeto: Site Institucional Adhonai

Prazo e Marcos

O projeto deverá ser finalizado até dezembro de 2008.

Principais marcos:

3. Planejamento inicial / Backlog / Sprints em Junho/2008

4. Preparação do Ambiente e Treinamento em Julho e Agosto/2008
5. Sprints de Agosto até Dezembro/2008 (releases com software instalado a cada final ou
início de mês conforme data de fim do Sprint).
6. Encerramento do projeto Dezembro de 2008

Descrição da tarefa Jun Jul Ago Set Out Nov Dez

Planejamento (Backlog, Architecture, High Level Design)
Preparação Ambiente / Treinamento
Sprints
Fechamento do Projeto
Preparação da Apresentação para a Defesa do TCC

Custos

O projeto será efetuado sem custo de desenvolvimento para a empresa Adhonai. Outros custos
operacionais, como hospedagem ficarão a cargo da editora.

Funcionalidades do Produto Levantadas pelo Cliente (Product Backlog)

Lista inicial de funcionalidades listadas pelo cliente. Esta lista poderá ser alterada ao longo do
projeto. Funcionalidades poderão ser alteradas quanto a sua prioridade, poderão ser quebradas
em outras funcionalidades ou poderão ser canceladas. Novas funcionalidades poderão ser
adicionadas.

Na lista abaixo, o campo “Prioridade” indica a relevância usando numeração seqüencial. Quanto
menor o número, maior a prioridade.

O produto está organizado em módulos para facilitar o entendimento das funcionalidades. São
eles:

 Integração Loja: Funcionalidades que interagem ou integram de alguma forma com a

loja online hospedada em outro provedor.
 Site Público: Funcionalidades que fazem parte ou tem parte no site público aberto a
qualquer pessoa.
 Administração: Funcionalidades que são de administração ou possuem parte na
administração.

Abaixo segue lista de funcionalidades (Product Backlog) que está ordenada pela prioridade
definida pelo cliente. Para a definição das funcionalidades foram considerados 4 papéis:
 61

Versão Doc.:

ANEXO 1
Declaração Preliminar de 1.0

Escopo Data:
22/05/2008
Cliente: Editora Adhonai Projeto: Site Institucional Adhonai

• Cliente: Pessoa que já fez compra na editora pela loja online, telefone, e-mail ou
pessoalmente.
• Usuário: Pessoa que navega no site da editora sem ser cliente da mesma.
• Administrador: Papel de administrador do site, com acesso a área de administração do
mesmo.
• Gerente: Gerente da editora, que pode ou não ser o administrador.

Nº Funcionalidade Módulo Prioridade

1 COMO Administrador
QUERO administrar textos e imagens do site sem necessidade de comandos que exijam
Administração 1
conhecimento técnico
PARA poder gerenciar o conteúdo do site com maior agilidade.
2 COMO Administrador
QUERO alterar a estrutura do site através da criação, edição e exclusão de seções Administração 2
PARA ter maior liberdade sobre a organização do conteúdo do site
3 COMO Cliente
QUERO entrar em contato com a editora através de formulário de contato no site Site Público 3
PARA esclarecimentos de dúvidas ou outra comunicação que julgue necessária.
4 COMO Gerente
Site Público
QUERO divulgar no site produtos e promoções que podem ser linkados com a loja online 4
PARA melhorar a comunicação com o cliente independente se ele está na loja ou no site.
5 COMO Cliente
QUERO visualizar meu extrato de pontos do programa de premiação Site Público
PARA acompanhar minha premiação.
6 COMO Administrador
QUERO pontuar clientes de programa de premiação a partir de compras feitas
Administração
independente do meio (loja, email, telefone)
PARA fidelizar clientes.
7 COMO Administrador
QUERO incluir objetos (PDF, imagens, MP3, Vídeos, etc) que os clientes pudessem fazer
Administração
download.
PARA ter maior autonomia sobre o conteúdo do site.
8 COMO Gerente
QUERO permitir acesso ao Blog do Ministério "A Fim de Proclamar" como sendo uma
Site Público
seção do site
PARA atrair mais usuários para o site.
9 COMO Gerente
Site Público
QUERO um Blog no site
Administração
PARA tornar a comunicação mais interativa com os clientes
10 COMO Usuário
QUERO me cadastrar no site Site Público
PARA receber comunicações sobre a editora e seus produtos.
11 COMO Administrador
QUERO enviar e-mail para clientes (individual e por grupos) importados da loja ou
Administração
cadastrados voluntariamente no site para receber comunicações da editora
PARA divulgar produtos e promoções ou outros tipos de comunicações importantes.
12 COMO Administrador
QUERO gerenciar clientes da loja online através do site Administração
PARA não ficar dependente de fornecedor da loja online
13 COMO Administrador
QUERO importar da loja online periodicamente os dados dos clientes Integração Loja
PARA poder gerenciar clientes independente do provedor da loja online
 62

Versão Doc.:

ANEXO 1
Declaração Preliminar de 1.0

Escopo Data:
22/05/2008
Cliente: Editora Adhonai Projeto: Site Institucional Adhonai

Principais Entregas

A principal entrega é basicamente o site institucional da editora. Este estará dividido em dois
subprodutos:

 Site institucional: Site web aberto na internet para qualquer tipo de usuário;

 Administração do Site: Área de administração do site institucional, com acesso restrito a

usuários que irão administrar o site.

Premissas

 O cliente estará disponível ao longo do projeto sempre que necessário para planejamento
das funcionalidades, Sprints e validação do software.

 Não está no escopo do projeto alterações ou manutenções na loja online da editora

hospedada em outro provedor

 Não faz parte do escopo criar uma nova loja online ou sistema de CRM para gerenciar
clientes.

Restrições

Há limitações do projeto conforme listadas abaixo:

 Recursos humanos: Projeto será executado por apenas uma pessoa.

 Prazo: Deve ser executado até dezembro de 2008.
 Orçamento: Não deverá ter custos além dos já comprometidos com o serviço de
hospedagem.
 Hospedagem: Continuar usando o mesmo provedor de hospedagem que deverá ter
disponível o serviço para hospedagem de sites usando a linguagem Ruby com o
Framework Rails.

Riscos

Lista de riscos identificados:

2. Apenas uma pessoa estar executando o projeto. Pode impactar tempo/finalização do

projeto.
 63

Versão Doc.:

ANEXO 1
Declaração Preliminar de 1.0

Escopo Data:
22/05/2008
Cliente: Editora Adhonai Projeto: Site Institucional Adhonai

3. Aprendizagem de linguagem de programação nova: Ruby. Pode impactar tempo do

projeto.

Organização do Projeto

Metodologia

Este projeto usará Metodologias Ágeis para o planejamento e execução. Terá como base o
SCRUM.

Sprints / Iterações

Para as entregas de software será dividido em Iterações (Sprints) com tempo a ser definido ao
longo do planejamento.

Estrutura Analítica do Projeto

EAP inicial do projeto.

Dicionário da EAP

Pacote de Trabalho Descrição Critérios de Aceitação

Declaração de Escopo Preliminar Documento que descreve o escopo preliminar
do projeto.
EAP e Dicionário EAP inicial do projeto e seu dicionário. Descrito
no documento de Escopo Preliminar.
Cronograma Cronograma macro do projeto. Descrevendo as Deverá contemplar os itens básicos da
principais fases e tempo. Não precisa entrar no EAP.
detalhamento de tarefas. Deverá contemplar o planejamento inicial
 64

Versão Doc.:

ANEXO 1
Declaração Preliminar de 1.0

Escopo Data:
22/05/2008
Cliente: Editora Adhonai Projeto: Site Institucional Adhonai

das releases.
Relatório de Desempenho E-mail enviado ao cliente com status de Deverá conter o status do projeto,
andamento do projeto. quantidade de tarefas concluídas e
faltantes e o gráfico de burndown.
Product Backlog Lista de pendências do projeto. Conterá Cada item da lista será priorizada e
funcionalidades do produto e itens que deverá conter o status do item ao longo
correspondem ao projeto. das iterações.
Planejamento Releases Organização das releases, seu tamanho em Os itens atendidos a cada release só
semanas, iterações e os itens que serão serão planejados no início da release.
atendidos.
Arquitetura Macro Documento descrevendo a arquitetura macro do Deverá conter diagrama de caso de uso
produto, quanto a camadas, banco de dados, de nível zero e diagrama ilustrando as
módulos, integrações, etc. camadas do software e integrações.
Hospedagem Configurar ambiente de hospedagem do site. Ambiente apto a hospedar o produto
(site) para as integrações e validação do
cliente.
Banco de Dados Instalação e configuração do gerenciador de MySql instalado e configurado.
banco de dados.
Linguagem de Programação Instalação e configuração da linguagem de Ruby instalado e configurado com o
programação utilizada no projeto e frameworks framework Rails.
necessários.
Integração com Loja Funcionalidades específicas de integração com Funcionalidades de integração
a loja online da Adhonai. funcionando conforme validação do
cliente.
Site Público Funcionalidades públicas. Site institucional. Site publicado na internet e disponível
para qualquer pessoa de acordo com
validação do cliente.
Administração Funcionalidades de administração do site. Área de administração funcionando
conforme validação do cliente.
Disponível apenas para usuários
restritos.
Layout Definição de layout do site, quanto a cores, HTML funcionando seguindo a definição
html, css, imagens, etc e funcionalidades TableLess.
referentes a layout.
Lições Aprendidas Documento descrevendo as lições aprendidas Listagem de lições aprendidas.
no projeto. Reflexão e análise feita após a
entrega do projeto e aceite do cliente.
 65

Versão Doc.:

ANEXO 2
Plano de Gerenciamento do 1.0

Escopo Data:
29/05/2008
Cliente: Editora Adhonai Projeto: Site Institucional Adhonai

Preparado por: Aleckssandro Tavares Aprovado por:

Descrição dos Processos de Gerenciamento do Escopo

Metodologia

Este projeto usará Metodologias Ágeis para o planejamento e execução, usando princípios do Manifesto Ágil
(www.agilemanifesto.org).

A metodologia utilizada será o SCRUM, podendo adotar também práticas do XP.

Definição de Escopo / Product Backlog

O escopo do projeto foi definido em conjunto com o cliente, através de reunião.

Nesta reunião o cliente escreveu em post-its as funcionalidades desejadas para o site, sendo apenas uma
funcionalidade (ou história) por post-it.

Cada funcionalidade foi descrita seguindo o formato:

As a <Role>
I want <Feature>
So that <Benefit>

Traduzindo para o português fica “Como <papel>...Quero <funcionalidade>...Para <benefício>”.

Sprint / Releases

Para as entregas de software será dividido em Sprints coforme fluxo do SCRUM e releases.

Cada Sprint representará um período de 2 semanas, ao final do qual, software com valor agregado deverá ser
gerado para validação do cliente.

A cada 4 semanas, ou seja, a cada 2 Sprints uma versão do software pronto e validado pelo cliente será
implantado em produção.

Serão até 6 Releases, ou seja, até 6 meses de projeto. Com Releases programadas de Julho a Dezembro.
Caso Backlog seja atendido antes deste prazo, projeto será considerado finalizado com a devida
concordância do cliente.

Priorização das Mudanças de Escopo

As funcionalidades, itens do Product Backlog, serão priorizadas pelo cliente.

As prioridades serão descritas por numeração seqüencial indicando a ordem de prioridade. Quanto menor o
número de prioridade, maior a prioridade.
 66

Versão Doc.:

ANEXO 2
Plano de Gerenciamento do 1.0

Escopo Data:
29/05/2008
Cliente: Editora Adhonai Projeto: Site Institucional Adhonai

Preparado por: Aleckssandro Tavares Aprovado por:

A prioridade de número 1 indica que deverá ser a primeira funcionalidade a ser atendida, a prioridade de
número 2 indica que deve ser o segundo item a ser atendido. E assim por diante.

No início de cada Release o cliente definirá qual as prioridades, entre as funcionalidades, a serem atendidas
no Release

Com base na priorização do cliente, os itens serão atendidos nos Sprints na ordem de prioridade. Porém, no
início de cada Sprint, o cliente poderá mudar o item a ser atendido no Sprint.

Gerenciamento das Mudanças de Escopo

O cliente poderá acrescentar novas funcionalidades ao Product Backlog, assim como também poderá
cancelar itens de backlog ou mudar a prioridade. Porém uma Sprint uma vez iniciada não deverá mais ser
alterada.

As mudanças serão tratadas conforme necessidade do cliente, através do processo normal do SCRUM, nas
reuniões de Sprint Planning e Sprint Review.

Verificações do Escopo

O escopo será verificado a cada início e fim de Sprint.

No início será verificado o que ainda falta ser atendido no Product BackLog e o que será atendido no Sprint.
E ao final de cada Sprint para definição do que foi realmente atendido ou não e como está o Product
BackLog ao final do Sprint.

O escopo, ou Product Backlog, estará sempre sendo revisado também quando houverem mudanças de escopo
solicitadas pelo cliente.

Ao final de cada Sprint após atualização do backlog será enviado relatório por e-mail para o cliente com o
status de andamento do projeto.

No relatório deverá constar:

2 Percentagem de andamento do Projeto: deverá indicar o quanto do projeto já foi concluído;

3 Sprint Atual: Número da iteração atual;
4 Meta do Sprint: Meta Principal da iteração.
5 Funcionalidades Planejadas: Funcionalidades (itens de backlog) planejadas para a iteração.
6 Funcionalidades Concluídas: Funcionalidades (itens de backlog) planejadas que foram entregues.
7 Lista de BackLog: Lista de backlog com o status de cada item, que poderá ser: Cancelado, Concluído ou
Em Andamento.