Você está na página 1de 61

Universidade Federal de Pernambuco

Centro de Informtica

Gerenciamento gil de Projetos

Luciana de Queiroz Leal


(lql@cin.ufpe.br)

Junho/2008

Agenda
Motivao
Mudana de Paradigma
Gerenciamento gil de Projetos de Software

Tcnicas
Problemas
Crticas
Abordagem Tradicional vs. Abordagem gil

Scrum
Consideraes Finais
Referncias

Luciana Leal

2 / 61

Motivao

Gerenciamento de Projetos
Orientado a processos
Processos bem definidos devem ser impostos para garantir a
qualidade do produto

Rgido
Pressupe que possvel especificar de antemo todos os
requisitos do projeto

Preditivo
Cada etapa de desenvolvimento baseada na etapa anterior,
parte do principio de que requisitos so estveis

Burocrtico
Sobrecarrega desenvolvimento, pode comprometer a velocidade
do projeto

Possui forte resistncia a mudanas

Luciana Leal

4 / 61

Gerenciamento de Projetos
de Software
Particularidades
Invisibilidade
Progresso no imediatamente visvel

Complexidade
Flexibilidade
Propenso a um alto grau de mudana

Dificuldade de antever suas funcionalidades


Necessidades surgem durante seu desenvolvimento, e
vo amadurecendo at a sua implantao

A mudana se torna inevitvel

Luciana Leal

5 / 61

O que agilidade?
Agilidade
Rapidez, desembarao
Qualidade de quem veloz

Capacidade de responder rapidamente a mudanas


Mudanas de tecnologias, de equipe, de requisitos...

Entregar valor ao cliente quando se lida com

imprevisibilidade e dinamismo dos projetos

Problema
Aparenta ser indisciplinado

Luciana Leal

6 / 61

Manifesto gil
Estamos descobrindo melhores formas de

desenvolver software atravs da nossa prpria


prtica e auxiliando outros.
Valores

Indivduos e Iteraes
Software funcionando
Colaborao com cliente
Responder a mudanas

Processos e Ferramentas
Documentao detalhada
Negociao de contratos
Seguir um plano

Luciana Leal

7 / 61

Princpios da agilidade
1.

A mais alta prioridade a satisfao do cliente, por


meio da liberao mais rpida e contnua de software de
valor.

2.

Receba bem as mudanas de requisitos, mesmo em


estgios tardios do desenvolvimento. Processos geis
devem admitir mudanas que trazem vantagens
competitivas para o cliente.

3.

Libere software freqentemente (em intervalos de 2


semanas at meses), dando preferncia para uma escala
de tempo mais curta.

4.

Mantenha pessoas ligadas ao negcio (clientes) e


desenvolvedores trabalhando juntos a maior parte do
tempo do projeto.

Luciana Leal

8 / 61

Princpios da agilidade
5.

Construa projetos com indivduos motivados, d a eles


o ambiente e suporte que precisam e confie neles para
ter o trabalho realizado.

6.

O mtodo mais eficiente e efetivo para repassar


informao entre uma equipe de desenvolvimento pela
comunicao face-a-face.

7.

Software funcionando a principal medida de


progresso de um projeto de software

8.

Processos geis promovem desenvolvimento sustentado.


Assim, patrocinadores, desenvolvedores e usurios
devem ser capazes de manter conversao pacfica
indefinidamente.

Luciana Leal

9 / 61

Princpios da agilidade
9.

A ateno contnua para a excelncia tcnica e um


bom projeto (design) aprimoram a agilidade.

10. Simplicidade - a arte de maximizar a quantidade de

trabalho no feito essencial, devendo ser assumida


em todos os aspectos do projeto.

11.

As melhores arquiteturas, requisitos e projetos emergem


de equipes auto-organizadas.

12.

Em intervalos regulares, as equipes devem refletir


sobre como se tornarem mais efetivas, e ento
refinarem e ajustarem seu comportamento de acordo.

Luciana Leal

10 / 61

Signatrios do Manifesto
Kent Beck

Jon KernBrian Marick

Mike Beedle

Robert C. Martin

Arie van Bennekum

Steve Mellor

Alistair Cockburn

Ken Schwaber

Ward Cunningham

Jeff Sutherland

Martin Fowler

Dave Thomas

James Grenning

Andrew Hunt

Jim Highsmith

Scott Ambler

Ron Jeffries

Luciana Leal

11 / 61

Declarao de Interdependncia

Abordagens geis e adaptativas para permitir ligar

pessoas, projetos e valor

Somos uma comunidade de lderes de projeto


que altamente eficaz entregando resultados.

Luciana Leal

12 / 61

O que significa interdependncia?


Que membros de uma equipe de projeto so parte

interdependente do tudo e no um grupo de


indivduos desconectados.
Dependem reciprocamente uns dos outros

Que equipes de projeto, seus clientes, seus

interessados (stakeholders) tambm so


interdependentes.

Equipes de projeto que no reconhecem esta

interdependncia raramente tem sucesso.


Luciana Leal

13 / 61

Declarao de Interdependncia
Para atingir os resultados:
Entregamos resultados confiveis engajando clientes em
iteraes freqentes e propriedade compartilhada.
Esperamos incerteza e a gerenciamos atravs de
iteraes, antecipao e adaptao.
Despertamos a criatividade e a inovao atravs do
reconhecimento que indivduos so a fonte ultima de valor,
e criando um ambiente no qual eles possam fazer
diferena.

Luciana Leal

14 / 61

Declarao de Interdependncia
Para atingir os resultados:
Impulsionamos desempenho atravs de cobrana do grupo
por resultados e responsabilidade compartilhada pela
efetividade da equipe.
Melhoramos efetividade e a confiabilidade atravs de
estratgias, processos e praticas especificas dependendo
da situao.

Luciana Leal

15 / 61

Signatrios da Declarao
David Anderson

Ole Jepsen

Sanjiv Augustine

Lowell Lindstrom

Christopher Avery

Todd Little

Alistair Cockburn

Kent McDonald

Mike Cohn

Pollyanna Pixton

Doug DeCarlo

Preston Smith

Donna Fitzgerald

Robert Wysocki

Jim Highsmith

Luciana Leal

16 / 61

Mudana de paradigma

Gerenciamento de Projetos
Projetos gerenciados atravs de
Especificao detalhada dos requisitos
Auxilia no planejamento
O sistema construdo atende a necessidade do cliente?

Abordagem BRUF
Big Requirements Up Front (Grandes requisitos primeiro)
Algumas funcionalidades raramente utilizadas

Luciana Leal

18 / 61

Gerenciamento de Projetos
Implicaes da abordagem BRUF
Criar um plano de projeto precocemente detalhado no
ciclo de vida
Criar precocemente estimativas precisas para o projeto
Usar o processo de mudanas preventivamente

Luciana Leal

19 / 61

Quebra de paradigma
Clssico

gil

Escopo

Qualidade

Escopo

Prazo

Qualidade

Custo

Prazo

Custo

Luciana Leal

20 / 61

Gerenciamento gil de
Projetos de Software

Gerenciamento gil de Projetos


Um conjunto de valores, princpios e prticas que auxiliam

a equipe de projeto a entregar produtos ou servios de valor


em um ambiente complexo, instvel e desafiador

o exerccio de princpios e prticas geis aliados aos

conhecimentos, habilidades e tcnicas na elaborao das


atividades de projeto, de forma a diminuir o time-to-market, e
se adequar s mudanas durante o projeto.

Objetivo
Garantir que exista um equilbrio entre demandas de qualidade,
escopo, tempo e custos

Luciana Leal

22 / 61

Gerenciamento gil de Projetos


Valores centrais
As respostas s mudanas so mais importantes que o
segmento de um plano
A entrega de produtos est acima da entrega de
documentao
Priorizao da colaborao do cliente sobre a
negociao de contratos
Os indivduos e suas interaes so mais importantes
que os processos e ferramentas

Luciana Leal

23 / 61

Gerenciamento gil de Projetos


Principais objetivos
Inovao contnua: a idia de inovao associada a um
ambiente cuja cultura estimule o auto-gerenciamento e a
autodisciplina
Adaptabilidade do produto: os produtos adaptveis s
novas necessidades do futuro
Tempos de entrega reduzidos: direcionamento preciso e
capacidade tcnica da equipe
Capacidade de adaptao do processo e das pessoas:
equipe confortvel com mudanas, processo leve
Resultados confiveis: entrega de produtos que
garantam operao, crescimento e lucratividade da
empresa

Luciana Leal

24 / 61

Tcnicas de Gerenciamento gil de


Projetos
Foque nas pessoas
As pessoas e a maneira como interagem so determinantes
mais importantes para o sucesso de um projeto

Organize seu projeto em iteraes


Curtos perodos de tempo onde ao seu final chega-se a um
objetivo especfico

Estabelea marco de entrega final somente se for

realmente necessrio

Luciana Leal

25 / 61

Tcnicas de Gerenciamento gil de


Projetos
Tenha um plano de projeto de alto nvel
Principais dependncias externas, iteraes planejadas e
uma estimativa de trmino (se possvel)

Crie planos de iterao detalhados com base no JIT

(Just In Time)

Voc s pode planejar precisamente com algumas semanas


de antecedncia da realizao

Envolva todos da equipe no planejamento


Planejar as prprias atividades

Luciana Leal

26 / 61

Tcnicas de Gerenciamento gil de


Projetos
As pessoas deveriam escolher seu trabalho ao invs

de serem mandadas para faz-lo


Organizar o prprio trabalho

Faa estimativa de coisas pequenas


mais fcil fazer a estimativa de um trabalho que levar
apenas um dia do que estimar algo que levar um ms.

As pessoas deveriam estimar seu prprio trabalho


As melhores estimativas vm de baixo para cima e no de
cima para baixo

Luciana Leal

27 / 61

Gerenciamento gil de Projetos


Ambientes onde pode apresentar problemas

Cultura da documentao
Dificuldade para aceitar mudanas
Demora para obteno da realimentao
Resistncia cultural

Luciana Leal

28 / 61

Gerenciamento gil de Projetos


Crticas

Dificuldade de manuteno pela falta de documentao


Efetividade da programao em pares: custo x benefcio
Dificuldade de se ter o cliente no local
Dificuldade de estabelecer contrato com escopo varivel
Requer colaborao e confiana entre equipe e cliente

Luciana Leal

29 / 61

Abordagem Clssica vs. Abordagem


gil
Clssica

gil

Desenvolvedor

hbil

gil

Cliente

pouco envolvido

comprometido

Requisitos

conhecidos, estveis

emergentes, mutveis

Retrabalho

caro

barato

Planejamento

direciona resultados

resultados o direcionam

Foco
Objetivo

grandes projetos

projetos de natureza exploratria e


inovadores

controlar, em busca de alcanar


o planejado

simplificar processo de
desenvolvimento

Luciana Leal

30 / 61

Abordagem Clssica vs. Abordagem


gil
Ciclo de vida gil semelhante ao clssico

Define o que o cliente quer e inicia o projeto


Planeja o projeto, calculando o esforo
Executa o plano, construindo a soluo
Monitora resultados e entrega ao cliente

Luciana Leal

31 / 61

Scrum

Scrum
Uma alternativa de utilizar mtodos geis na

gerncia de projetos

Pode ser aplicvel a qualquer tipo de projeto


simples
Processo, artefatos e regras so poucos e fceis de
entender
A simplicidade pode ser decepcionante aos acostumados
com metodologias clssicas

Luciana Leal

33 / 61

Scrum
No um mtodo prescritivo
No define previamente o que deve ser feito em cada
situao
Projetos complexos no permitem prever todos os eventos

Define um framework e um conjunto de prticas


Aplica o senso comum
Combinao de experincia, treinamento, confiana e
inteligncia de toda a equipe
Senso comum em vez do senso de uma nica pessoa
uma das razes do sucesso do Scrum

Luciana Leal

34 / 61

Fases
Planejamento
Sprints
Reunies Dirias
Reviso
Retrospectivas

Encerramento

Luciana Leal

35 / 61

Planejamento
Relativamente curto
Projeto da arquitetura do sistema
Estimativas de datas e custos
Criao do backlog

Backlog

Participao de clientes e outros departamentos


Levantamento dos requisitos e atribuio de prioridades

Definio de equipes e seus lderes


Definio de pacotes a serem desenvolvidos

Luciana Leal

36 / 61

Sprint
O time recebe uma parte do

backlog para desenvolvimento


O backlog no sofrer modificaes
durante o Sprint

Durao de 1 a 4 semanas
Sempre apresentam um

executvel ao final

Luciana Leal

37 / 61

Sprint - Reunies Dirias


Cerca de 15 minutos de durao
Todos respondem s perguntas:
O que voc realizou desde a ltima reunio?
Quais problemas voc enfrentou?
Em que voc trabalhar at a prxima reunio?

Benefcios:
Maior integrao entre os membros da equipe
Rpida soluo de problemas
Promovem o compartilhamento de conhecimento

Progresso medido continuamente


Minimizao de riscos

Luciana Leal

38 / 61

Sprint - Reviso
Deve obedecer data de entrega
Permitida a diminuio de funcionalidades

Apresentao do produto ao cliente


Sugestes de mudanas so incorporadas ao backlog

Benefcios:
Apresentar resultados concretos ao cliente
Integrar e testar uma boa parte do software
Motivao da equipe

Luciana Leal

Nova
funcionalida
de

39 / 61

Encerramento
Finalizao do projeto
Atividades:

Testes de integrao
Testes de sistema
Documentao do usurio
Preparao de material de treinamento
Preparao de material de marketing

Luciana Leal

40 / 61

Papis no Scrum
Todas as responsabilidades de gerenciamento so divididas

entre trs papis:


Product Owner
Scrum Master
Time

Para o bom funcionamento do Scrum as pessoas responsveis

pelo projeto devem ter autoridade para fazer o que for


necessrio pelo seu sucesso

Pessoas no responsveis no podem interferir no projeto


Gera aumento de produtividade
Evita situaes constrangedoras para os envolvidos

Luciana Leal

41 / 61

Papis Product Owner


Responsvel por apresentar os interesses de

todos os stakeholders

Define fundamentos iniciais do projeto,

objetivos e planos de release

Responsvel pela lista de requisitos

(Product Backlog)

Certifica se as atividades com maior valor

para o negcio so desenvolvidas primeiro


Priorizao freqente das funcionalidades antes
de cada iterao

Luciana Leal

42 / 61

Papis Scrum Master


Responsvel pelo sucesso do Scrum
Ensina o Scrum para os envolvidos com o projeto
Implementa o Scrum na empresa de forma

adaptada a sua cultura, para continuamente


gerar benefcios

Certifica se cada pessoa envolvida est

seguindo seus papis e as regras do Scrum

Certifica que pessoas no responsveis no

interfiram no processo

Luciana Leal

43 / 61

Papis Time
Responsvel por escolher as funcionalidades a serem

desenvolvidas em cada interao e desenvolv-las

O time se auto-gerencia, se auto-organiza


Todos os membros do time so coletivamente

responsveis pelo sucesso de cada iterao

Luciana Leal

44 / 61

Regras no Scrum
O ScrumMaster deve se certificar de que cada

envolvido no projeto siga suas regras

As regras permitem a execuo correta do Scrum


Mudanas das regras devem se originar do time
O ScrumMaster deve ser convencido de que todos
envolvidos entenderam suficientemente as regras do
Scrum para o correto discernimento
Discusses desnecessrias so perda de tempo de
produo da equipe

Luciana Leal

45 / 61

Sprint Planning Meeting


A reunio de planejamento do Sprint deve ocorrer

dentro de 8 horas com duas partes de 4 horas

Primeiro seguimento:
Product Owner deve preparar o Product Backlog antes da
reunio
Seleo dos itens do Product Backlog que o time se
compromete em torn-los incrementos potencialmente
implementveis
Deciso final do Product Owner
Stakeholders no devem participar

Luciana Leal

46 / 61

Sprint Planning Meeting


Segundo seguimento:
Ocorre imediatamente aps o primeiro
Product Owner deve estar disponvel para o que o time faa
perguntas sobre o Product Backlog
O time deve decidir sozinho como os itens selecionados
sero implementados
Nenhum outro participante pode fazer perguntas ou
observaes nesta parte
Resultado deste seguimento o Sprint Backlog

Luciana Leal

47 / 61

Scrum Daily Meeting


Reunio de no mximo 15 minutos, a menos que o

time seja grande o suficiente para precisar de mais


tempo

Deve ser feita no mesmo lugar onde o time trabalha


Resulta em melhores resultados se realizada no

inicio do dia de trabalho

Todos os membros do time devem participar desta

reunio

Luciana Leal

48 / 61

Scrum Daily Meeting


ScrumMaster faz as seguintes perguntas para cada

membro do time:

O que voc fez desde a ltima reunio diria do Scrum


relacionada a este projeto?
O que voc ir fazer desde agora at a prxima reunio
diria do Scrum relacionada a este projeto?
O que est impedindo voc de realizar o seu trabalho o
mais efetivamente possvel?

Os membros devem responder apenas a estas

perguntas para no estender a reunio


Luciana Leal

49 / 61

Sprint
No deve ser maior do que 30 dias consecutivos
Sem considerar outros fatores, este o tempo

necessrio para produzir algo de interesse para o


Product Owner e os stakeholders

O time se compromete com o Product Backlog


No so permitidas modificaes nele durante o Sprint

Luciana Leal

50 / 61

Sprint
Responsabilidades do time durante o Sprint:
Participar das reunies dirias do Scrum
Manter o Sprint Backlog atualizado
Disponibilizar o Sprint Backlog publicamente

O time tem o compromisso de implementar todos

os itens selecionados

Luciana Leal

51 / 61

Reunio de Reviso do Sprint

Reunio de no mximo 4 horas sob responsabilidade do ScrumMaster

O time no deve gastar mais de 1 hora na preparao desta reunio

Objetivo:
Mostrar ao Product Owner e stakeholders as funcionalidades que foram
feitas

Artefatos no devem ser apresentados, pois no so funcionalidades

No final da reunio
Cada stakeholder fala suas impresses e sugere mudanas com suas
respectivas prioridades
Possveis modificaes no Product Backlog so discutidas entre o
Product Owner e o time
ScrumMaster anuncia a data e o local da prxima reunio de reviso
do Sprint ao Product Owner e a todos stakeholders

Luciana Leal

52 / 61

Reunio de Retrospectiva do
Sprint
No deve ser maior do que 3 horas
Participam desta reunio
Time, ScrumMaster e, opcionalmente, Product Owner

Os membros do time devem responder a duas questes:


O que aconteceu de bom durante o ltimo Sprint?
O que pode ser melhorado para o prximo Sprint?
ScrumMaster escreve as respostas e prioriza na ordem que

deseja discutir as potenciais melhorias

ScrumMaster nesta reunio tem o papel de fazer com que o

time encontre melhores formas de aplicar o Scrum

Luciana Leal

53 / 61

Consideraes

Reflexo
Qual a melhor abordagem de gerenciamento para o

desenvolvimento de software conduzido por metodologias


geis?

Grandes projetos podem ser gerenciados de forma gil?


Como possvel?
confivel?

Gerenciamento gil para qualquer tipo de projeto


Construo de edifcios, avies, robs
Como possvel?

Luciana Leal

55 / 61

Consideraes Finais
Manifesto gil
Pares de alternativas se reforam
Processos e ferramentas podem melhor capacitar os
indivduos e interaes
Documentao ajuda as pessoas a entenderem um software
complexo
Negociao de contrato pode ser parte integrante da
colaborao do cliente
Seguir um plano pode ser o melhor modo para responder a
mudana, quando esta for previsvel

Luciana Leal

56 / 61

Consideraes Finais
Abordagens possuem pontos positivos e negativos
Partem de pressupostos diferentes
Podem coexistir e conviver bem em um mesmo ambiente
Considerar criteriosamente o ambiente correto

Necessrio buscar o ponto de equilbrio, avaliando riscos


Planejamento aperfeioa a agilidade
Agilidade d eficincia ao planejamento

Luciana Leal

57 / 61

Consideraes Finais
Projetos complexos e com restries de tempo necessitam de

uma nova abordagem

Scrum uma boa soluo


eficiente quando as regras e os papis so bem seguidos
Apesar da sua simplicidade, as pessoas costumam no aceitar
facilmente a nova abordagem
H diversos casos de sucesso

Deve-se considerar as condies da equipe e as caractersticas

dos projetos antes de uma migrao

Luciana Leal

58 / 61

Referncias

AMBLER, S. Gerenciamento gil de projetos: Colocando o desenvolvimento


de software em ordem. Mundo PM. out/nov 2006

ANDERSON, D. J. Agile management for software engineering: Applying


the theory of constraints for business results. New Jersey: Prentice Hall, 2003.
336p.

AUGUSTINE, S. Managing agile projects. Prentice Hall, 2005. 264p.

AUGUSTINE, S.; PAYNE, B.; SENCINDIVER, F.; WOODCOCK, S. Agile project


management: Steering from the edges. Communications of the ACM, v. 48,
dez. 2005. p. 85-89.

BECK, K. 2001. AGILE ALLIANCE. Manifesto for agile software


development. Disponvel em <http://www.agilemanifesto.org/>. Acesso em
29 nov. 2006.

CHIN, G. Agile project management: how to succeed in the face of


changing project requirements. New York: Amacon, 2004. 229 p.

DECARLO, D. Extreme project management: Using leadership, principles,


and tools to deliver value in the face of volatility. California: Jossey-Bass,
2004. 560p.

Luciana Leal

59 / 61

Referncias

DECLARATION OF INTERDEPENDENCE. 2001. Declaration of


interdependence. Disponvel em <http://pmdoi.org/>. Acesso em 29 nov.
2006.

GRIFFITHS, M. Using agile alongside the PMBOK. PMI Global Congress


Proceedings, 2004.

HIGHSMITH, J. Agile project management: creating innovative products.


Boston: Addison-Wesley, 2004. 312 p .

KERZNER, H. Project Management: A Systems Approach to Planning,


Scheduling, and Controlling. New Jersey: John Wiley & Sons, 2003. 912p.

PROJECT MANAGEMENT INSTITUTE PMI. PMBOK Guide: Um guia do


conjunto de conhecimentos do gerenciamento de projetos. Pennsylvania:
Project Management Institute, 3. ed., 2004.

SCHWABER, K. Agile Project Management with Scrum. Microsoft Press,


2004.

MAGALHES, A. O gerenciamento de projetos desenvolvidos luz das


metodologias geis. PMI-MG jun/2006. Disponvel em
<http://www.pmimg.org.br/downloads/Palestra-GerenciamentoAgil.pdf>.
Acesso em 29 nov. 2006

Luciana Leal

60 / 61

Universidade Federal de Pernambuco


Centro de Informtica

Gerenciamento gil de Projetos

Obrigada!

Luciana de Queiroz Leal


(lql@cin.ufpe.br)

Junho/2008

Você também pode gostar