Universidade de Pernambuco

Escola Politcnica de Pernambuco

Departamento de Sistemas e Computao

l><l
GAP
Gesto gil de Projetos

Disciplina: Gerncia de Projetos

Professora: Cristine Gusmo

Equipe: Anderson Tenrio, Danillo Wanderley, Frederico Menezes,

Nathlia Silva, Renata Melo

RESUMO

O gerenciamento gil de projetos vem se tornando uma importante alternativa ao

modo como os gerentes podem conduzir seus trabalhos em suas organizaes. Esse tipo
de gerenciamento baseia-se intrinsecamente nos conceitos envolvidos com as
metodologias geis de desenvolvimento. Nessas metodologias, o foco principal a
entrega de um valor, em detrimento a uma especificao detalhada de como as tarefas
devem ser realizadas ao logo do ciclo de vida do projeto. Essa caracterstica
principalmente inspirada na natureza dos projetos em geral.
Projetos, na grande maioria dos casos, operam sob presso (em relao a custos,
requisitos, tempo, etc.) e so inerentemente dinmicos, passveis a mudanas tanto em
relao ao ambiente (interno ou externo) quanto s necessidades e interesses de clientes
e usurios. Nesse sentido, o gerenciamento gil de projetos tem o principal objetivo de,
levando em considerao a volatilidade no ciclo de vida, maximizar os valores e a
capacidade de adaptao e aprendizado.
O trabalho a seguir faz um estudo acerca do gerenciamento gil de projetos,
focando principalmente nas tcnicas conhecidas como Scrum e XP. Inicialmente, feita
uma introduo abordando a origem dos conceitos envolvidos, bem como os princpios
e prticas comuns a grande parte das metodologias ditas geis. O gerenciamento gil
ento apresentado, considerando-se os seus gatilhos para alcanar o sucesso dos
projetos.
Em seguida, o Scrum apresentado. Foi realizada uma pesquisa bibliogrfica
acerca de como essa tcnica aplica os conceitos do gerenciamento gil de projetos, bem
como o seu funcionamento detalhado. So descritos todos os elementos envolvidos e a
forma como as atividades so conduzidas rumo ao sucesso do projeto.
Para tambm ilustrar a aplicao do gerenciamento gil de projetos, outras
tcnicas geis so apresentadas, buscando fixar a aplicao dos princpios e prticas
sugeridos. Algumas dessas tcnicas so eXtreme Programming (XP), Crystal, entre
outras.

SUMRIO

Resumo ................................................................................................................. 2
Sumrio................................................................................................................ 3
CAPTULO I ........................................................................................................ 5
INTRODUO .................................................................................................... 5
CAPTULO II ..................................................................................................... 11
Scrum .................................................................................................................. 11
Princpios Bsicos........................................................................................... 11
Papis .......................................................................................................... 12
Funcionamento ............................................................................................... 13
Sprint Planning ........................................................................................... 14
Sprint Retrospective.................................................................................... 17
CAPTULO III.................................................................................................... 18
XP eXtreme Programming: ............................................................................. 18
UMA VISO GERAL ....................................................................................... 18
Ciclo de vida do XP ........................................................................................ 18
Como o XP trabalha?...................................................................................... 19
Planejamento............................................................................................... 19
Anlise ........................................................................................................ 20
Design e Implementao............................................................................. 20
Teste............................................................................................................ 21
Entrega de produtos .................................................................................... 21
CAPTULO IV ................................................................................................... 22
OUTRAS TCNICAS DE GERENCIAMENTO GIL ................................... 22

DSDM Dynamic Systems Development Method Mtodo Dinmico de

Desenvolvimento de Sistemas .................................................................................... 22
FDD Feature Driven Development Desenvolvimento Guiado por
Funcionalidades .......................................................................................................... 23
TOC Theory of Constraints Teoria das Restries................................... 26
CCPM Critical Chain Project Management Gesto de Projetos pela
Corrente Crtica .......................................................................................................... 27
CAPTULO V..................................................................................................... 29
CONCLUSO .................................................................................................... 29
Bibliografia ......................................................................................................... 30

CAPTULO I
INTRODUO

Atualmente, as organizaes lidam quase que diariamente com presses relativas

ao custo e prazos de seus projetos. Orientadas pelas restries e pelo gerenciamento das
incertezas do ambiente, elas precisam, sobretudo, desenvolver e entregar um produto.
nesse sentido que agilidade pode ser definida como a habilidade de entregar um produto
pela organizao, seja ele de qualquer natureza, levando em considerao o dinamismo
intrnseco a um projeto e adaptao s mudanas. So algumas das principais
metodologias geis: Scrum, eXtreme Programming (XP), Crystal, entre outras.
De maneira geral, as metodologias geis tm por objetivos evitar a perda e
aumentar a conformidade do desenvolvimento e criao de um produto com mudanas
diversas. Abaixo, podemos ver algumas das principais caractersticas comuns aos
diversos tipos de metodologias geis:

Entregas curtas: o trabalho total dividido em pequenas tarefas para um

melhor gerenciamento da complexidade e melhoramento na captura dos feedbacks

dos clientes e usurios. As entregas, parciais ou o produto em si, podem ser
apresentadas ao cliente em um ou trs meses, por exemplo.

Desenvolvimento iterativo e incremental: os planos, requisitos, design,

cdigos e testes so desenvolvidos de forma incremental atravs de iteraes. As

iteraes tm tamanho fixo, a depender da metodologia utilizada. Essa caracterstica
fixa o escopo e busca estabilidade.

Colocao: todos os membros da equipe so condicionados a facilitar a

comunicao entre si e possibilitar uma maior interao entre eles prprios. Dessa
forma, so organizados encontros constantes entre a equipe, bem como atividades de
grupos formais ou informais.

Plano de entrega: as caractersticas desejadas do produto so definidas

em alto nvel e priorizadas pelo prprio cliente. Essa priorizao feita de forma
colaborativa com os desenvolvedores do projeto. Os desenvolvedores provem
estimativas e nveis de esforo, enquanto os clientes definem a prioridade das regras
de negcio.

Plano de iterao: os requisitos, definidos em alto nvel pelo plano de

entrega, so detalhados levando-se em considerao as tarefas que devem ser

realizadas para sua concluso satisfatria.

Equipe auto-organizvel: os membros da equipe se relacionam entre si

continuamente para a realizao das tarefas definidas no plano de iterao.

Tracking: as tarefas so consideradas completas apenas se estiverem

100% feitas. No h o conceito de realizao parcial.

Diante dessas caractersticas, pode-se perceber que as metodologias geis
pregam simplicidade e capacidade de adaptao. O desenvolvimento enxuto
maximiza o valor do produto final e passvel a mudanas proporcionadas pelo
ambiente e pelos clientes.
Em fevereiro de 2001, esses conceitos, at ento separados e no sistematizados,
foram reunidos no chamado Manifesto for Agile Software Development. O Manifesto
pelo Desenvolvimento gil de Software est reproduzido na tabela abaixo, no original
em ingls:

Tabela 1: Manifesto for Agile Software Development

MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT

We are uncovering better ways of developing software by doing it and helping others do
it. Through this work, we have come to value:
Individuals and interaction over processes and tools;
Working software over comprehensive documentation;
Costumer collaboration over contract negotiation;
Responding to change over following a plan.
That is, while there is value in the items on the right, we value items on the left more.

Segundo Augustine, gerenciamento gil de projetos o trabalho de energizar,

capacitar e habilitar os times dos projetos para rapidamente e de maneira confivel
construir valores de negcio seguindo os requisitos estabelecidos pelos clientes e
continuamente aprendendo e se adaptando a mudanas em suas necessidades e no
ambiente.
Metodologias geis diferem de outras abordagens de gerenciamento de projetos
tanto quantitativamente quanto qualitativamente. Quantitativamente porque as
metodologias geis focam principalmente na execuo e na entrega de um produto
(parcial ou final), diferentemente de centrar-se em planos, processos e controle. Por
6

outro lado, elas so baseadas em um modelo terico que enxerga os projetos como nolineares, a metfora chamada Sistemas Adaptativos Complexos. Esses sistemas encaram
as mudanas como normais diferindo dos modelos tradicionalmente lineares, que
assumem que a estabilidade o caminho comum.
A figura 1 mostra como o gerenciamento gil de projetos se relaciona com o
conceito de Sistemas Adaptativos Complexos.

Figura 1: Diagrama dos relacionamentos existentes na utilizao de um gerenciamento gil.

Como j visto, para serem sustentveis frente a mudanas, metodologias geis

devem manter prticas flexveis adaptveis s necessidades do ambiente e s
circunstncias. Nesse aspecto, a utilizao de gerenciamento gil de projetos juntamente
com o conceito de Sistemas Adaptativos Complexos fundamenta-se basicamente nos
seguintes princpios:

Promover alinhamento e cooperao: as pessoas so consideradas agentes

primrios na conduo de valores, mudanas, aprendizagem e adaptao. Por
outro lado, uma viso compartilhada mantm as pessoas alinhadas e focadas
num objetivo. Quando as pessoas esto alinhadas, a cooperao para concluir
um trabalho torna-se maior do que a competio, e h ganhos mtuos.

Encorajar emergncia e auto-organizao: processos e prticas so mantidos

na menor medida possvel. Os envolvidos devem se auto-organizar para

construir um valor de negcio. Padres complexos, incluindo comportamento

auto-organizado e estrutura tima, emergem a partir de interaes surgidas do
cumprimento de regras simples.

Instituir aprendizado e adaptao: o feedback utilizado para contnua

aprendizagem, adaptao e aumento das capacidades. Geralmente os projetos
operam bem num ponto entre a normalidade e a ordem, onde h o bastante de
controle, estrutura, otimizao e explorao.

Os princpios das metodologias geis de projetos servem como base para as suas
prticas. Tais prticas so primariamente orientadas rumo entrega de um valor de
negcio, frente ao controle das atividades e otimizao dos custos. Abaixo, seis das
prticas das metodologias geis de projetos so listadas.

1. Equipes Orgnicas Habilitar conexes e adaptaes atravs de

relacionamentos estreitos e equipes flexveis.
A auto-organizao e a ordem emergente surgem principalmente a partir de
fluxos ou interaes entre as pessoas. As equipes devem ser construdas por
especialidade e quando necessrio mais esforo, mais organismos devem ser
adicionados. Entretanto, prefervel que membros da equipe adquiram funes extras
em oposio a adicionar peas sobressalentes. Isso oferece equipe uma maior
capacidade de adaptao evoluo das condies externas. Por outro lado, equipes
pequenas tendem a cometer menos erros no que diz respeito s conexes e com isso
podem alcanar a interao desejada. Quando um projeto realmente exige uma equipe
grande, deve-se organizar o projeto em pequenas partes.

2. Viso Orientadora Manter a equipe alinhada e direcionada com um

modelo mental compartilhado.
Os modelos mentais das pessoas so os mecanismos de antecipao e
adaptao. Quando uma viso de projeto traduzida em um mapa de projeto e
comunicada a todos os membros da equipe, ele serve como um modelo mental
compartilhado, influenciando o comportamento de todos. Assim, um gerente gil guia o
time e continuamente influencia o comportamento da equipe pela definio,
disseminao e sustentao de uma viso orientadora que influencia os modelos mentais
dos membros das equipes. Essa viso tambm responsvel por tornar a equipe mais
consistente e capaz de fazer melhores escolhas. O gerenciamento convencional de
projetos prega a criao de um plano detalhado para o alcance dos objetivos. Ao invs
de perder tempo em um plano detalhado, gerentes geis mantm uma viso suficiente,
focando principalmente nos resultados das tarefas.

3. Regras Simples Estabelecer um conjunto de regras e processos simples

e genricos para a equipe.
As metodologias de gerenciamento de projetos geralmente utilizam um grande
nmero de processos, templates, entregas e regras. Tais conjuntos so complexos o
suficiente para que freqentemente no sejam seguidos. No gerenciamento gil de
projetos, os membros da equipe seguem regras simples, mas as interaes emergem ao
longo do tempo. Como exemplo, as prticas do XP so um bom conjunto de regras
simples. As normas so declaradas e acordadas entre os membros das equipes no incio,
embora essa mesma equipe esteja disposta a adaptar essas regras ou mesmo criar novas
regras. Durante o projeto, o gerente gil identifica as prticas que no so seguidas, visa
compreender o porqu, e remove obstculos a sua implementao. Esse comportamento
oferece regras para serem seguidas, mas no compromete a criatividade e a autonomia
da equipe.

4. Informao Aberta Prover acesso livre e aberto informao.

Em projetos geis, a informao o catalisador da mudana e da adaptao. As
interaes entre as pessoas envolvem uma contnua troca de informaes. E a riqueza
das interaes depende principalmente da abertura dessas informaes.
Tradicionalmente, os gestores e gerentes tm limitado essa abertura temendo o caos. No
gerenciamento gil de projetos a informao flui livremente e os membros da equipe
beneficiam-se por esse intercmbio.

5. Toque de Luz Aplicar controle inteligente para promover ordem

emergente e valor mximo.
Tradicionalmente, o foco em estabilidade e controle tem freqentemente
resultado em metodologias elaboradas, ferramentas e prticas para gerenciar um mundo
inerentemente incerto e instvel. Mas essas ferramentas falham quando as tarefas no
podem ser facilmente acomodadas e geralmente requerem atualizao para refletir as
mudanas. Esse foco no controle pode no resultar no seu propsito primordial: criar
ordem e devolver valores. E se o foco no alcanado, gerentes convencionais tentam
aplicar ainda mais controle. Entretanto, o ato de aumentar ainda mais esse controle nem
sempre resulta na diminuio da incerteza e no aumento da ordem e dos valores. Com
um toque de luz, gerentes geis percebem que eles no podem prever todos os
acontecimentos do projeto com antemo e renunciam a algum controle para alcanar a
ordem e os valores.

6. Liderana Adaptativa Dirigir o projeto por contnuo monitoramento,

aprendizagem e adaptao.
Liderar um time estabelecendo uma viso orientadora, construindo equipes
orgnicas, criando regras simples, promovendo a abertura das informaes e
gerenciando tudo isso com um toque de luz uma tarefa extremamente desafiadora.
Todas essas interaes ainda possuem o risco de desviar a equipe do curso ideal. O
9

comportamento no-linear pode resultar em aspectos positivos ou negativos, a depender

do contexto do projeto. A uma liderana adaptativa compreende observar e avaliar
continuamente as prticas, analisando e adaptando-as para os resultados desejados e
implement-los com o mximo impacto. Tambm requer uma compreenso das
diferentes partes do projeto e de sua fora natural. O gerente gil compreende os efeitos
da mtua interao entre os diferentes componentes do projeto e o direciona pelo
contnuo monitoramento, constante aprendizagem e adaptao a diferentes abordagens.

10

CAPTULO II
SCRUM

Este captulo fala sobre os princpios bsicos do Scrum e do seu funcionamento.

Princpios Bsicos

O Scrum atende ao Manifesto gil ao priorizar seus valores diferenciados:

Indivduos e interaes > processos e ferramentas;

Software rodando > documentao compreensvel;

Colaborao do cliente > negociao do contrato;

Responder s mudanas > Seguir um plano.

Note que os elementos da esquerda so mais valorizados que os da direita.

Porm, os elementos da direita no so descartados e mantm sua importncia.
A aplicao de Scrum no significa somente uma preocupao com agilidade,
mas uma necessidade de responder melhor s mudanas. Elas esto presentes nos
projetos de diferentes formas:

Os requisitos e suas prioridades podem mudar, pois nem sempre os

usurios tm uma real compreenso do seu problema. Muitas funcionalidades no

previstas so adicionadas, e muitas funcionalidades originais so abandonadas.

As ferramentas podem mudar durante o desenvolvimento do projeto, pois

novas tecnologias e novos releases so lanados e as capacidades reais podem variar

das expectativas iniciais.

11

A composio da equipe do projeto pode mudar e a interao entre os

membros pode ser complexa.

Softwares complexos podem possuir uma rede de dependncias muito

abrangente gerando dificuldades de prever atividades, suas dependncias e impactos

de suas mudanas.
Na verdade, a agilidade e o tratamento de mudanas esto ligados, j que a
principal preocupao manter os prazos e um bom desempenho mesmo com as
constantes mudanas.
Ou seja, projetos conduzidos em ambientes complexos e caracterizados por
muitas incertezas iniciais, com dificuldades para detalhamento do escopo e de
elaborao de um planejamento completo, com elevado grau de mudanas e com
constantes presses pela entrega de resultados em curtos perodos de tempo so timos
candidatos a se beneficiarem com a adoo de Scrum.
O Scrum possui algumas premissas que devem ser consideradas:

Conceito Time Box

o Prazo fixo
o Custo fixo

Lista de funcionalidades que pode variar

Perca funcionalidades, no datas!

Funcionalidades so priorizadas pelo cliente

o Cliente precisa de algo no previsto?

o Sem problemas, inclua. Mas exclua algo!
o Cliente entende que funcionalidades no final da lista podem ficar de fora
O Scrum d maior nfase ao gerenciamento do projeto e independe da escolha
da tecnologia e do modelo de desenvolvimento de software adotado. Ele mais uma
postura, um sentimento, uma filosofia, do que um processo.

Papis

O Scrum possui papis que so atribudos aos membros da equipe de

desenvolvimento. Eles so descritos a seguir.

Product Owner

o Tipicamente o cliente, alguma pessoa de marketing ou um usurio chave

12

o Determina as funcionalidades do Product Backlog

o Prioriza o Product Backlog

Scrum Master

o Garante que a equipe de desenvolvimento utilize os valores e as prticas

do Scrum
o o representante da equipe
o Relaciona-se com o cliente e com cada membro da equipe
o Escuta os relatos de cada um
o No deve interferir nas decises da equipe a menos que seja solicitado
o Retira os impedimentos do projeto

Scrum Team

o Tipicamente, 5 a 10 pessoas
o Todos devem trabalhar coletivamente para completar o ciclo de Sprint (o
significado de Sprint ser explicado mais adiante)
o Engenharia, Designer, QA no esto em times separados, todos esto no
mesmo time
o O time auto-gerencivel, no existe mais o papel do gerente dizendo o
que eles tm que fazer
o O sucesso do Scrum depende do comprometimento do Time

Users e Stakeholders

o Aqueles que usaro o sistema

Funcionamento

Sendo o Scrum uma tcnica de gerncia voltada para funcionalidades, o primeiro

passo para a sua aplicao obter uma lista delas. A essa lista damos o nome de
Product Backlog. As entidades responsveis por este documento so o Product Owner,
a representao do cliente no projeto, e a equipe de Scrum. No Product Backlog, temos
a lista de funcionalidades necessrias ao sistema ordenadas por importncia, sendo que
essa lista pode ser atualizada aps os Sprints. Nesse caso, importncia um termo mais
adequado ao problema que prioridade, j que em geral, nveis de prioridade so vistos
como uma numerao decrescente (menor o nmero, maior a prioridade), onde a maior
prioridade costuma ser 0 (zero) ou 1 (um). Acontece que no Scrum, possvel que o
Product Owner decida que existe uma funcionalidade mais importante que aquela com
nvel de prioridade 0. O que ele faria? Usaria uma prioridade -1 que poderia acabar

13

sendo vista como algo no importante, sendo negativo? Usando uma escala de
importncia crescente, possvel que uma funcionalidade tenha, por exemplo,
importncia 100, e uma outra acabe tendo mais importncia que essa usando a
numerao 200. O Product Backlog pode incluir tambm uma estimativa do tempo
necessrio para a realizao da tarefa, alm de instrues de como demonstrar o
funcionamento de cada item.
Durante a elaborao do Product Backlog, o cliente explica para a equipe cada
uma das funcionalidades, enquanto atribui o valor de importncia para elas. Vale
ressaltar que por virem do cliente, todas as explicaes e funcionalidades so feitas em
termos de negcios, nunca tcnicos, o que mantm o foco na funcionalidade. A quebra
em tarefas tcnicas feita em uma prxima etapa do processo. A equipe faz uma
estimativa de quanto tempo / pessoas necessrio para realizar tais tarefas.

Sprint Planning

Uma vez que o Product Backlog esteja pronto, hora de realizar o Sprint
Planning, uma reunio entre a equipe inteira que realizar o Sprint, o Product Owner e o
Scrum Master, para decidir que funcionalidades entre as listadas sero includas no
prximo Sprint. Apenas as funcionalidades de maior importncia iro ser includas
no possvel, por exemplo, preencher uma lacuna de tempo com uma funcionalidade
menor, mas menos importante, a no ser que o Product Owner decida que ela
importante. O segundo critrio usado na priorizao de funcionalidades a
complexidade da mesma. Nessa reunio as principais decises a serem tomadas so:

A meta para o prximo Sprint

A durao do Sprint

Uma lista dos membros do time (e seu nvel de comprometimento, se no

for 100%)

Um Sprint Backlog (uma lista de funcionalidades a serem implementadas

no Sprint)

Uma data para a demonstrao das funcionalidades implementadas

Hora e local para realizar as reunies dirias da equipe

A figura abaixo, ilustra esse processo para um Sprint com durao de 2 a 4

semanas.

14

Figura 2: Atividades de um Sprint com durao de 2 a 4 semanas.

A meta no uma lista de funcionalidades, mas importante para lembrar

equipe, num momento de desmotivao, a razo pela qual aquele Sprint est sendo
realizado. A pergunta chave a fazer para decidir essa meta : Porque iremos fazer esse
Sprint ao invs de todos tirarmos frias?. A meta deve ser indita para aquele projeto,
caso contrrio, a meta j ter sido alcanada.
A lista de funcionalidades deve tambm ser includa na reunio e tambm no
Sprint Backlog, documento que lista as atualizaes que sero implementadas nesse
Sprint. As funcionalidades discutidas nesse documento so quebradas em tarefas
menores, possibilitando um melhor entendimento da funcionalidade como um todo e
facilitando a distribuio das tarefas durante o Sprint.
O Sprint deve ser curto, buscando seguir o princpio de mudanas rpidas do
Scrum, mas deve ser tambm longo o suficiente para evitar excesso de reunies de
demonstrao e planejamento, alm de permitir equipe se recuperar de problemas
internos. Afinal, um Sprint antes de tudo um compromisso, e deve ser cumprido. No
existe um perodo ideal de durao, cada equipe / projeto se adapta melhor com um
perodo diferente.
O Sprint Backlog deve ser decidido de acordo com uma estimativa de velocidade
da equipe, para que sejam includas apenas funcionalidades que possam ser
implementadas no perodo determinado para tal. Quando o Sprint Backlog estiver
pronto e detalhado, um quadro preenchido (em geral, um quadro com bilhetes ou postits usado) com as funcionalidades, para facilitar a visualizao por toda a equipe. Cada
funcionalidade quebrada em tarefas menores e de entendimento mais simples e
tcnico.
O objetivo de um Sprint ter, ao seu final, uma funcionalidade implementada
totalmente para ser demonstrada para o cliente. Logo, devem ser marcadas uma data e
hora para que o cliente assista a essa demonstrao e avalie o resultado desse Sprint. H
sempre uma representao do cliente nas Sprint Plannings, mas se mesmo assim o
15

cliente no ficar satisfeito com o resultado obtido, foi descoberto o problema num
estgio adiantado da implementao, e ainda h tempo para mudanas no curso do
desenvolvimento, seguindo os princpios de agilidade. A forma de demonstrao de
cada funcionalidade deve estar descrita no Sprint Backlog ou ser discutida durante o
Sprint. As demonstraes servem tambm para motivar a equipe, j que software
funcionando bem agrada ao cliente e gera elogios para a equipe.
As reunies dirias de Scrum (Daily Sprint Meeting) com a equipe servem para
manter o quadro de tarefas atualizado, para a equipe reportar ao Scrum Master os
impedimentos existentes para a realizao das tarefas. Os pontos principais da reunio
so:

O que voc fez desde a ltima reunio?

O que voc pretende fazer at a prxima reunio?

Existe alguma coisa lhe impedindo de fazer o seu trabalho?

Todos os membros do time so consultados sobre os trs pontos, visando dar

uma idia para todos sobre o andamento do projeto e uma soluo para os problemas da
equipe. permitida a qualquer pessoa a entrada em uma reunio da equipe, mas apenas
os membros podem se expressar. Em geral, so planejadas de modo a serem curtas (em
torno de 15 a 30 minutos).
Outro objetivo dos Daily Meetings atualizar o Burndown Chart, grfico que
ilustra o andamento do Sprint em horas restantes. Grficos burndown muito
discrepantes da viso mdia podem dar boas indicaes equipe da necessidade de
mudar a quantidade de funcionalidades includas no Sprint. O aspecto de um grfico
burndown ilustrado na figura abaixo.

Figura 3: Aspecto de um grfico burndown. A linha azul indica a progresso ideal, a linha verde indica a
fronteira do atraso. A linha vermelha indica a progresso real e pode ser atualizada a cada hora ou a cada
dia.

16

Sprint Retrospective

Quando o Sprint termina (aps a reunio de demonstrao), cabe ao time fazer

uma retrospectiva daquele perodo, numa reunio chamada Sprint Retrospective. Essas
reunies do s equipes a chance de listar (e posteriormente reparar) os erros cometidos
durante o Sprint. Todos os participantes (o Scrum Master, o Product Owner e os
membros da equipe) tm a chance de opinar sobre o que eles acharam que foi bom, o
que poderia ter sido melhor e o que eles gostariam de fazer diferente no prximo Sprint.
importante lembrar que as funcionalidades acordadas no Sprint Planning
devem ser entregues, exceto em casos em que a equipe percebe durante o andamento
que no ser possvel e faz um novo acordo com o cliente para incluir menos
funcionalidades na prxima demonstrao. Entregar as funcionalidades acordadas ao
final de cada Sprint mais importante que entregar todo o software pedido ao final do
prazo estipulado em contrato, j que as funcionalidades feitas a cada Sprint so sempre
as mais importantes para o cliente / projeto naquele momento.

17

CAPTULO III
XP EXTREME PROGRAMMING:
UMA VISO GERAL

Juntamente com o Scrum, o XP situa-se como uma das tcnicas mais utilizadas
para o gerenciamento gil de projetos de software. Sua filosofia de desenvolvimento
baseia-se na execuo simultnea das principais fases para a criao de um produto:
planejamento, anlise, implementao e teste. Com isso, no h distino temporal
longo prazo destas fases, sendo todas realizadas diariamente. Os marcos temporais que
definem o andamento de um projeto deixam de ser o fim de uma dessas fases, passando
a ser o fim de uma iterao. A iterao pode ser definida como uma unidade de tempo
onde todas as fases foram executadas simultaneamente e um produto foi liberado ao seu
trmino.

Ciclo de vida do XP

Como as fases para a criao de um produto so realizadas diariamente, uma

equipe de desenvolvimento que trabalha sob as regras e especificaes do XP so
capazes de liberar produtos toda semana. Contudo, quando falamos de produtos em XP,
no significa necessariamente o produto completo, mas sim subconjuntos de funes
caractersticas e recursos deste.
O fato de uma equipe liberar produtos em intervalos curtos, devido
implementao do XP, no significa que esta equipe aumentou sua produtividade, mas
sim que esta equipe agora capaz de dar feedbacks de forma mais rpida. Como
conseqncia, esta equipe agora capaz de identificar de forma mais rpida as causas
latentes que determinam o sucesso ou fracasso da entrega dos produtos.
A quantidade de trabalho a ser realizada em cada iterao estrategicamente
pequena em relao ao todo, o que permite equipe corrigir rapidamente erros de
programao em pleno vo sem que haja o comprometimento da entrega semanal.
Com este feedback mais rpido a equipe de desenvolvimento pode refinar
rapidamente seu planejamento para a prxima iterao. Isso facilita a insero ou

18

modificao de requisitos definidos pelo cliente, visto que este agora tambm tem
acesso a prottipos do seu produto semanalmente.

Como o XP trabalha?

Como j mencionado anteriormente, o XP trabalha com a execuo simultnea

das fases de planejamento, anlise, implementao, teste e entrega de produtos
semanalmente. Com isso, a mtrica temporal de acompanhamento do projeto passa a ser
atravs de iteraes.
Em cada iterao, a equipe trabalha com o desenvolvimento de produtos
baseados em histrias que correspondem a recursos ou pedaos de recursos que devem
estar contidos no produto final. Semanalmente, uma equipe trabalhando sob a filosofia
deve liberar entre quatro a dez histrias, sendo que cada histria trabalhada em todas
as suas fases de desenvolvimento (planejamento, anlise, design, implementao, teste e
liberao).
Como cada fase de desenvolvimento trabalhada em XP?
A seguir, faremos uma breve descrio de como cada fase de desenvolvimento
trabalhada pelo XP.

Planejamento

Embora a fase de planejamento, como todas as outras fases tratadas pelo XP,
seja executada continuamente, os esforos dedicados para sua execuo so maiores nas
primeiras semanas de um projeto. Isto ocorre porque na etapa inicial de planejamento,
contida nas primeiras iteraes, quando ocorre uma elevada interao entre clientes e
equipe de desenvolvimento. Isto serve, entre outras finalidades, para refinar e tornar
mais claras as histrias que sero abordadas para a criao dos produtos de cada
iterao. Esta etapa de negociao entre clientes e equipe para definir prioridades do
projeto denomina-se the planning game. No contexto XP, um cliente no
necessariamente o cliente final do software, mas pode ser tambm um especialista na
rea de atuao do software.
No tempo remanescente do projeto, esta interao se mantm contnua, porm
menos intensa, sendo a participao dos clientes direcionada para revises de requisitos
e criao de novas vises para contornar eventos no previstos.
Por fim, semanalmente a equipe deve detalhar o planejamento para as atividades
a serem desenvolvidas na prxima iterao. Alm disso, deve-se preconizar encontros

19

dirios breves assim como um workspace para a avaliao contnua do status atual do
projeto.

Anlise

Como os clientes so os responsveis por caracterizar e informar os requisitos do

software a ser desenvolvido, eles colaboram com a equipe de desenvolvimento em
tempo integral nas fases de anlise. Isto ocorre devido aos conhecimentos especficos
que os clientes possuem sobre os problemas e processos que sero assessorados e/ou
solucionados pelo software. Aliado a esses conhecimentos especficos, os clientes
contam com tcnicas tradicionais de levantamento de requisitos para organizar,
formalizar e descrever os requisitos do produto final na forma de histrias que sero
ento passadas para a equipe de programao.
Alm disso, tendo em vista a complexidade e dificuldade de entendimento de
alguns requisitos por parte da equipe de programao, os clientes devem sempre estar
presentes e preparados para eventuais perguntas a serem efetuadas pela equipe de
programao.

Design e Implementao

Como forma de agilizar os processos de design e implementao do projeto, o

XP faz uso da metodologia TDD (do ingls Test-Driven Development). Isto permite a
construo dos produtos de forma contnua em pequenas etapas que guiam juntamente
teste, implementao e design.
Para que a equipe de implementao suporte este tipo de metodologia, os
programadores trabalham em duplas, o que aumenta consideravelmente a capacidade de
raciocnio da equipe, visto que em cada dupla h sempre um componente com tempo
disponvel para pensar nas questes de design em um nvel de abstrao mais elevado.
Os programadores so tambm os responsveis pela organizao do seu
ambiente de desenvolvimento. Para isto, eles utilizam ferramentas para atualizao das
verses dos cdigos implementados, de forma a manter sua implementao mais
automtica. Isto permite que todas as duplas de programao integrem seus cdigos
implementados em poucas horas, com o intuito de se liberar um produto funcional.
Alm disso, as duplas devem manter um estilo de programao nico, que permita a
integrao rpida dos cdigos e o rastreamento de erros de codificao e a identificao
do autor do erro.
Por fim, em termos de modificao de cdigo, o XP trabalha fortemente com a
idia de refactoring, com o intuito de se manter o cdigo robusto suficiente para sofrer
alteraes sem que o seu comportamento final seja comprometido
20

Teste

O XP possui um elegante conjunto de tcnicas de teste. Com isso, uma equipe

trabalhando sob a filosofia XP produz, teoricamente, apenas um pequeno punhado de
bugs em seus produtos mensalmente. Para tanto, todos os membros da equipe
(programadores, clientes e equipe de teste) devem dar suas contribuies para aumentar
a qualidade dos produtos.
Os programadores do sua contribuio devido a utilizao da metodologia TDD
em seus trabalhos. A TDD preconiza a integrao e automatizao dos testes de
cdigos. Os clientes, por sua vez, contribuem para que os programadores realmente
entendam as suas expectativas, quanto aos requisitos propostos. Os clientes so os
responsveis por revisarem o progresso da implementao dos produtos e tambm
produzem exemplos para que os programadores tenham uma melhor viso sobre o deve
ser realmente implementado.
Por fim, a equipe de teste tem a responsabilidade de verificar se os produtos
esto sendo desenvolvidos com cdigos de alta qualidade. Para isso, eles utilizam
tcnicas exploratrias para procurar eventos inesperados e gaps nos cdigos
implementados. Quando um bug encontrado pela equipe de teste, toda a equipe realiza
uma anlise do tipo root-cause e estuda como reestruturar os processos do projeto para
prevenir o surgimento de bugs similares no futuro. Alm disso, a equipe de teste deve
explorar as caractersticas no funcionais dos produtos, como performance e
estabilidade. Com estas informaes em mos, os clientes ento decidem o melhor
caminho para a criao de histrias adicionais.

Entrega de produtos

A equipe deve sempre estar preparada para a liberao de produtos ao final de

cada iterao. Os produtos so liberados para os clientes e investidores semanalmente,
para avaliao.

21

CAPTULO IV
OUTRAS TCNICAS DE GERENCIAMENTO GIL

Alm de Scrum e XP, outras vrias tcnicas de gesto gil so utilizadas para se
alcanar um gerenciamento satisfatrio de projetos. Pela figura abaixo, pode-se observar
a porcentagem de uso de algumas destas tcnicas.

Figura 4: Porcentagem de uso de algumas tcnicas de gesto gil.

DSDM Dynamic Systems Development Method

Mtodo Dinmico de Desenvolvimento de Sistemas

O DSDM uma abordagem de desenvolvimento de software que enfatiza o

envolvimento contnuo do usurio, sendo seu objetivo entregar sistemas no tempo e
oramento previstos, enquanto se ajusta a mudanas de requisitos ao longo do processo
de desenvolvimento. O Consrcio DSDM foi fundado em janeiro de 1994, no Reino
Unido, e atualmente a nica metodologia gil formal reconhecida para uso pelo
governo daquele pas. Foi desenvolvido por uma associao entre empresrios e
especialistas na rea de desenvolvimento de sistemas de informao, onde foram
utilizadas as experincias em ambas as reas.

22

A tcnica consiste em trs fases: pr-projeto, ciclo de vida do projeto e psprojeto. A fase de ciclo de vida subdividida em 5 estgios, que so o estudo da
possibilidade de concretizao, estudo de negcio, interao funcional de modelo,
iterao de design e construo e implementao. E em algumas circunstncias
possvel integrar prticas de outras metodologias.
A metodologia guiada por nove princpios:
1. Envolvimento ativo do usurio imperativo
2. O time precisa ter poder para tomar decises
3. O foco est na entrega freqente de produtos
4. Adaptao para fins de negcios o critrio essencial de aceitao de
deliverables
5. Desenvolvimento iterativo e incremental necessrio para convergir em
uma soluo de negcio precisa
6. Todas as mudanas durante o desenvolvimento so reversveis
7. Requisitos so baseados em alto nvel
8. Testes so integrados com o ciclo de vida
9. Colaborao e cooperao entre steakholders essencial

FDD

Feature

Driven

Development

Desenvolvimento Guiado por Funcionalidades

O FDD um mtodo gil e altamente adaptativo que combina as melhores

prticas do gerenciamento gil de projetos com uma abordagem completa para
Engenharia de Software orientada a objetos.
Teve sua origem entre 1997 e 1998, em Singapura, durante o desenvolvimento
de um grande sistema de emprstimos para o banco internacional Unites Overseas
Bank. Tal sistema foi considerado muito complexo e impossvel de ser desenvolvido.
Havia 3.500 pginas de casos de uso e um modelo de objetos com centenas de classes.
Foi, ento, tomada a deciso de implantar as metodologias de anlise e modelagem
orientadas a objetos - OOAD - de Peter Coad e o gerenciamento de projetos de Jeff De
Luca. Como resultado, 15 meses aps a contratao destes profissionais 2.000 features
foram entregues por uma equipe de 50 pessoas.

23

O termo feature pode ser entendido como funcionalidade ou caracterstica. Tem

um conceito muito prximo ao de requisito funcional. Mapeia passos em uma atividade
de negcios, podendo ser um passo de um caso de uso ou o prprio caso de uso. Deve
ser pequena o suficiente para ser implementada em no mximo duas semanas e oferece
valor ao cliente. A figura abaixo detalha a estrutura de uma feature.

Figura 5: Quebra da estrutura de uma feature.

As features seguem o seguinte modelo: <ao><resultado><objeto>.

Exemplos:

Calcular o total de uma venda

Autorizar uma transao com carto de um cliente

Enviar uma nota fiscal para um cliente

Por ser muito objetiva, a metodologia possui somente 2 fases:

1. Concepo e Planejamento, com durao entre uma e duas semanas;
2. E Construo, que ocorre de forma iterativa.
Entre as caractersticas da FDD esto:

Fornecer estrutura suficiente para equipes maiores;

Enfatizar a produo de software de qualidade;

Entregar resultados freqentes, tangveis e funcionais a cada duas

semanas ou menos;

24

Realizar trabalho significativo desde o incio, antes de tornar-se

altamente iterativa;

E fornecer informaes de estado e progresso de forma simples e

compreensvel.
Oferece, ento, vantagens sobre os mtodos prescritivos, pois implementa
conceitos importantes de planejamento, mas sem excessos de documentao e controle.

As melhores prticas pregadas por esta tcnica so:

Modelagem de objetos do domnio;

Desenvolvimento por feature;

Posse individual de classes (cdigo);

Equipes de features;

Inspees;

Builds regulares;

Relatrio / visibilidade de resultados.

Em cada ciclo iterativo o progresso medido com base em 6 marcos ou

milestones bem definidos e a cada etapa cumprida o percentual respectivo agregado ao
total de progresso da feature. Com base nisso, o progresso reportado de acordo com
uma estrutura composta pelo nome da atividade e seu status, barra de progresso e prazo
de entrega, como pode ser observado na figura a seguir, objetivando, como mencionado
anteriormente, ser simples e compreensvel.

25

Figura 6: Reportando o progresso.

TOC Theory of Constraints Teoria das Restries

A primeira meno desta tcnica ocorreu no livro A Meta, de Eliyahu Moshe

Goldratt. Sua criao se baseou no ambiente de manufatura que, assim como os demais
ramos de atuao, est sendo forado a otimizar processos, minimizar custos e aumentar
produtividade. A TOC busca solucionar essa questo vendo a empresa no em partes
isoladas, mas como um sistema integrado, um conjunto de elementos entre os quais h
alguma ligao. Desta forma, o desempenho global do sistema depende dos esforos
conjuntos de todos os seus elementos. Logo, a empresa to forte quanto seu elo mais
fraco, assim como a velocidade de um comboio a de seu veculo mais lento. Para
melhorar o desempenho de um sistema, necessrio conhecer sua principal restrio e
atuar nela, promovendo um processo de melhoria contnua.
Tal restrio de um sistema nada mais do que qualquer coisa que o impea de
atingir um desempenho maior em relao a sua meta. Para realizar esta medio
preciso conhecer a meta do sistema em estudo e definir as medidas que vo possibilitar
o julgamento do impacto de qualquer ao local nessa meta. De acordo com esta teoria e
com o raciocnio de que a principal meta de qualquer empresa seu resultado
financeiro, se a empresa no possusse nenhuma restrio, seu lucro seria infinito. Tem
como base a aplicao de princpios cientficos e raciocnio lgico para guiar
organizaes humanas. Desta forma foram estabelecidos dois tipos de restries: as
fsicas ou polticas e as no-fsicas ou emocionais.
Para realizar mudanas, a TOC responde a trs perguntas atravs do Processo
de Pensamento (Thinking Process), que so:

26

1. O que mudar?
2. Como mudar?
3. Mudar para o qu?
Seguindo o algoritmo abaixo, que composto pelos 5 passos da TOC:

Tabela 2: Algoritmo da TOC.

1: Identificar a restrio;
2: Decidir como explorar a restrio;
3: Subordinar e sincronizar todo o resto deciso acima;
4: Elevar a performance da restrio;
5: Se em qualquer um dos passos anteriores a restrio principal
for alterada voltar ao passo 1.

Os desafios aumentam em cenrios onde vrios projetos so executados ao

mesmo tempo, devendo haver extrema ateno disponibilidade de recursos e forma
de sua utilizao.

CCPM Critical Chain Project Management

Gesto de Projetos pela Corrente Crtica

Este mtodo originou-se na TOC, sendo sua utilizao em ambientes de projetos.

Foi inicialmente publicado em 1997 por Goldratt no livro Critical Chain. Pode ser
aplicado em ambientes mono e multi-projetos, sendo chamado de corrente crtica para
ser feita diferenciao com caminho crtico, que um mtodo tradicional do PMBOK
e outras metodologias.
Esta tcnica leva em considerao a dependncia de recursos, assim como a
aplicao de segurana contra atrasos por meio de buffers, ou pulmes, que so
dispostos nos locais onde sero mais teis, sendo compartilhados pelas tarefas mais
crticas. Defende que o melhor ponto para aplicar a segurana no nas atividades
individuais, pois esta prtica acarreta grande aumento no cronograma final, alm de
acabar por provocar atrasos. Isto pelo raciocnio de que os responsveis pelas atividades

27

s vo desempenh-las quando o prazo estiver prximo do fim, ento o melhor

encurt-los numa poltica agressiva.
Outro ponto interessante a possibilidade de deciso pelo incio posterior das
tarefas, evitando o efeito Big Bang e contrariando a mxima de que quanto mais cedo
se comea, mais cedo se acaba. Eliminam-se datas de incio e fim de atividades sempre
que possvel e o progresso reportado baseado em durao restante e no em
porcentagem. Multitarefas so eliminadas, melhorando significativamente foco e
qualidade e reduzindo drasticamente a durao das mesmas.
A terceira edio do Guia PMBOK o referencia como uma tcnica de anlise de
rede do cronograma, que modifica o cronograma do projeto para que leve em conta
recursos limitados. O mtodo da cadeia crtica mistura abordagens determinsticas e
probabilsticas da anlise de rede do cronograma.

28

CAPTULO V
CONCLUSO

A realidade dos projetos de software no fcil. Os exemplos de mudanas

citados no texto so comuns de acontecer. Ento, por que no adotar uma abordagem
que lide com isso ao invs de aderir a uma que defina um plano a ser seguido sem
considerar a dinmica do processo? Ns entendemos que os exemplos de tcnicas,
prticas ou metodologias de gesto gil de projetos tm muito a oferecer quando usadas
adequadamente.
Um ponto em comum que identificamos a filosofia dividir para conquistar.
Todas as abordagens apresentadas preocuparam-se em quebrar tarefas complexas em
sub-tarefas mais fceis e executveis numa iterao.
Tambm nos chamou a ateno o foco nas pessoas, a comunicao, a interao
e, principalmente, o comprometimento que todos os envolvidos devem ter ao adotar
estas tcnicas. importante notar que, independente da tcnica escolhida, necessrio
um tempo de adaptao a ela.

29

BIBLIOGRAFIA

Shore, J. e Warden, S. The Art of Agile Development. OReilly. 2008.

Augustine, S. Managing Agile Projects. Prentice Hall. 2005.

Apresentao
sobre
gesto
gil
com
FDD.
URL:
http://www.visaoagil.com/downloads/ biblioteca/GestaoAgilcomFDD.pdf. Acessado em
23/10/2008.

Aplicando a Gesto gil de Projetos para o Desenvolvimento de Novos

Produtos na Indstria de Software. URL: www.abepro.org.br/biblioteca/
ENEGEP2006_ TR490328 _7853.pdf. Acessado em 23/10/2008.

Desmistificando a Gesto, Desenvolvimento e Melhoria gil de Projetos

com
Scrum.
URL:
http://www.planoeditorial.com.br/jornada/palestras/campinas/27_11_2007/
JuanBernabo.pdf. Acessado em 23/10/2008.

FDD Feature Driven Development Desenvolvimento Guiado por

Funcionalidades. URL: http://www.featuredrivendevelopment.com/. Acessado em
23/10/2008

FDD Feature Driven Development. URL: http://www.heptagon.com.br/fdd.

Acessado em 23/10/2008.

Quelhas, O., Barcaui, A. B. A teoria das restries aplicada a gerncia de

projetos:
Uma
introduo

corrente
crtica.
URL:
http://www.pmtech.com.br/newsletter/. Acessado em 23/10/2008.

30

Marco_2005/TOC_e_CCPM_em_GP.pdf.
URL:
http://www.pmtech.com.br/newsletter/Marco_2005/TOC_e_CCPM_em_GP.pdf.
Acessado em 23/10/2008.

DSDM Dynamic Systems Development Method Mtodo Dinmico de

Desenvolvimento de Sistemas. URL: http://www.dsdm.org/. Acessado em 23/10/2008.

31