O documento discute a gestão tradicional de projetos versus a gestão ágil, introduzindo o conceito de agilidade. Apresenta a natureza dinâmica dos projetos de software e a necessidade de metodologias que possam responder rapidamente às mudanças, questionando se o objetivo sempre permanece fixo nos projetos complexos.

1. Gerenciamento
Ágil de Projetos
..
Daniel de Amaral | Agosto 2009

2. Agenda
• Gerência de Projetos “Tradicional” e os modelos
“Clássicos” de desenvolvimento de Software.
• Natureza dos projetos de Softwares.
• Agilidade: uma breve introdução.
• A mudança de paradigma.
• Gerenciamento Ágil de Projetos.
• O papel do Gerente de Projetos no contexto do
GAP.

3. Agenda
• Apresentação é sobre:
– Introdução ao conceito Ágil.
– Contextualização do GAP.
– Premissas, princípios e valores que guiam o GAP.
• Apresentação não é sobre:
– Detalhamento dos Métodos Ágeis.
– Técnicas ágeis para desenvolvimento e
qualificação de software.
– Exposição sobre Gerenciamento de Projetos.

4. Gerenciamento de Projetos
• Quando o projeto será finalizado?
• Quanto vai custar?
• Todos concordamos sobre o objetivo final do
projeto e seus critérios de qualidade?
• Quais são os riscos que ameaçam a finalização
do nosso projeto? Como podemos mitigar
estes riscos?

5. Gerenciamento de Projetos
“Tradicional”
• Deposita grande esforço em
detalhar todo trabalho a ser feito
em um projeto em seu período
inicial (fase de planejamento).

6. Gerenciamento de Projetos
“Tradicional” – ciclo de vida
Seqüência típica de fases no ciclo de vida de um projeto
FONTE: PMBoK, 2004, p.23

7. Gerenciamento de Projetos
“Tradicional” – ciclo de vida
Nível típico de custos e
pessoal ao longo do
projeto
Influência das partes
interessadas ao longo do
tempo
FONTE: PMBoK, 2004, p.21

8. Gerenciamento de Projetos
“Tradicional” – ciclo de vida
Grupos de processos PMBoK
FONTE: PMBoK, 2004, p.40

9. Modelos “Clássicos” de
desenvolvimento de Software
Modelo Cascata (Waterfall)
Definição dos
requisitos de
Sistema
Definição dos
requisitos de
Software
Análise
Design
Codificação
Testes
Implantação/
Operações
FONTE: ROYCE, 1970

10. Modelos “Clássicos” de
desenvolvimento de Software
Modelo Incremental
Incremento n
Definição dos
Funcionalidades e Características do Software
requisitos
Incremento 2
Definição dos Análise
requisitos
...
Design
Incremento 1 Análise
Definição dos Codificação
requisitos Design
Testes
Análise Codificação
Implantação/
Design Testes Operações
Codificação Implantação/
Operações
Testes
Implantação/
Operações
Tempo decorrido do projeto
FONTE: PRESSMAN, 2006, p.40

11. Modelos “Clássicos” de
desenvolvimento de Software
Modelo Espiral
Custo
Acumulado
Progresso
1. Determinar objetivos, 2. Avaliar alternativas,
Alternativas, restrições Identificar e atacar riscos
Análise
Análise dos riscos
dos riscos
Análise
dos riscos
Protótipo Protótipo Protótipo
Revisão 2 Operacional
1
Planejamento Conceituação
dos requisitos e Design
da operação Design Detalhado
Ciclo de vida
Requisitos
Codificação
Plano de Validação dos
Desenvolvimento Requisitos
Verificação Integração e
E validação Testes
Integração e
Plano de testes Testes de
Aceitação
4. Planejar próximas fases/ Implementação
3. Desenvolvimento e Testes
iterações
FONTE: BOEHM, 1988

12. Determinando o objetivo

13. Determina-se o objetivo
• Normalmente fixa-se o plano, e todo esforço busca
controlar os possíveis desvios...
Esforço para
controlar os desvios
Ponto
de partida
Alvo/Goal = Sucesso
Plano
Desvios

14. Mas o alvo é sempre fixo?

15. Cenário
• A indústria de Software opera sob constante mudança
(ambientes com alto grau de inovação – exemplo: P&D).
• Os processos do chamado Gerenciamento de Projetos
“Tradicional” freqüentemente demonstram-se muito
burocráticos e não atendem a natureza dinâmica do
desenvolvimento de softwares.
• Neste contexto, surge a necessidade de metodologias que
possam facilmente responder as mudanças.

16. Cenário
• Natureza dos projetos de Software:
– Software é intangível.
– Descoberta.
– Investigação.
– Evolução dos requisitos ao longo do
desenvolvimento do produto.
– Mudança!
• Projetos complexos acabam demandando uma
abordagem empírica.

17. O alvo é fixo?
Esforço para
controlar os desvios
Ponto
de partida
Alvo/Goal = Sucesso?
Plano
Desvios
O alvo mudou, afinal,
no mundo tudo muda...

18. Agilidade
• Habilidade de criar e responder a
mudanças de forma a manter a
lucratividade em um turbulento
ambiente de negócios. (HIGHSMITH, 2002)

19. Manifesto Ágil
Estamos descobrindo maneiras melhores de desenvolver software
fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste
trabalho, passamos a valorizar:
Indivíduos e suas interações acima de processos e ferramentas
Software funcionando acima de documentação abrangente
Colaboração do cliente acima de negociação de contratos
Resposta às mudanças acima da execução de um plano
Isto é, ainda que haja valor nos itens à direita, valorizamos mais os
itens à esquerda.
(AGILLE ALLIANCE, http://agilemanifesto.org/)

20. Métodos Ágeis
Extreme
Scrum Programming (XP)
Crystal Methods Adaptive Software
Development (ASD)
Lean Development (LD) Feature Driven
Development (FDD)
Agile Modeling (AM)
Dynamic Systems
Development Method (DSDM)

21. Gerenciamento Ágil de
Projetos (GAP)
• Conjunto de valores, princípios e práticas que
auxiliam equipes de projeto a entregar produtos ou
serviços de valor em um ambiente complexo, instável
e desafiador. Highsmith (2004)
• Nova plataforma de gerenciamento de projetos,
aplicável a ambientes voláteis e desafiadores,
sujeitos a mudanças freqüentes, em que o processo
prescritivo e padronizado acaba não apresentando-
se como a opção mais adequada. Chin (2004)

22. Mudança de Paradigma
Tradicional Ágil
Fixo Escopo Custo Tempo
Orientado pela
Visão/Valor
(Value/Vision-Driven)
Orientado pelo
Planejamento (Plan-
Driven)
Variável Custos Tempo Escopo
FONTE: SLIGER & BRODERICK, 2008, p. 68

23. Declaração de
Interdepêndencia (DOI)
Somos uma comunidade de líderes de projeto que é altamente
eficaz entregando resultados. Para atingir estes resultados:
Aumentamos o retorno sobre o investimento fazendo com que o
fluxo contínuo de valor seja nosso foco.
Entregamos resultados confiáveis engajando clientes em
interações freqüentes e compartilhando responsabilidades.
Esperamos a incerteza e a gerenciamos a mesma através de
iterações, antecipação e adaptação.
(AGILE PROJECT LEADERSHIP NETWORK, http://www.pmdoi.org/)

24. Declaração de
Interdepêndencia (DOI)
Despertamos a criatividade e a inovação através do
reconhecimento que indivíduos são a fonte última de valor, e
criando um ambiente no qual eles possam fazer diferença.
Impulsionamos desempenho através de cobrança do grupo por
resultados e responsabilidade compartilhada pela efetividade da
equipe.
Melhoramos a efetividade e a confiabilidade através de
estratégias, processos e práticas específicas dependendo da
situação.
(AGILE PROJECT LEADERSHIP NETWORK, http://www.pmdoi.org/)

25. Princípios do GAP
FONTE: HIGHSMITH, 2004, p. 28

26. Framework do GAP
FONTE: HIGHSMITH, 2004, p. 81

27. Aplicabilidade do GAP
Múltiplas organizações Múltiplas organizações Um única organização
externas internas interessada
interessadas/envolvidas interessadoas/envolvidas
Projetos Operacionais Clássico Clássico Clássico
Projetos de Clássico/Ágil Clássico/Ágil Ágil
Desenvolvimento de
novos produtos /
processos
Projetos de Clássico/Ágil Ágil Ágil
desenvolvimento de
novas tecnologias /
plataformas
Clássico: Gerenciamento de Projetos “Tradicional” FONTE: CHIN, 2004, p.20
Ágil: Gerenciamento Ágil de Projetos

28. Características - Tradicional x Ágil
Tópico Características Gerenciamento de Características Gerenciamento Ágil
Projetos Tradicional de Projetos
Objetivo Principal Orientado por atividade e centrado em Orientado por produto e centrado em
processo. pessoas.
Tipo de Projeto Estáveis e com baixo nível de Projetos com mudanças constantes e
mudanças. que necessitam de respostas rápidas.
Tamanho Aplicável em projetos de todos os Mais efetivo em projetos pequenos (5-
tamanhos. Mais efetivo em projetos de 10 pessoas) – porém não existe
maior duração. restrições em ser implementado em
projetos de maior porte.
Gerente de Projeto Controle total do projeto. Papel de facilitador ou coordenador.
Equipe de Projeto Atuação com papéis claros e bem Atuação colaborativa em todas as
definidos. atividades do projeto.
Cliente Participa das fases iniciais de requisitos Essencial. Deve ser parte integrante da
e das validações dos produtos. equipe do projeto.
Planejamento Detalhado e os envolvidos têm o papel Curto e com a participação de todos os
de validação, não participam da envolvidos na elaboração do
elaboração do planejamento. planejamento.
FONTE: ADAPTADO DE CHIN, 2004

29. Características - Tradicional x Ágil
Tópico Características Gerenciamento Características Gerenciamento
de Projetos Tradicional Ágil de Projetos
Arquitetura Definida com foco em todo o projeto e Aplicação de design simples. Evolui
na reusabilidade. junto com o projeto e baseia-se na
refatoração.
Modelo de Desenvolvimento Cascata, espiral e iterativo. Iterativo e incremental.
Comunicação Formal. Informal.
Controle de Mudanças Processo formal de identificação e Dinâmico e com rapidez de
aprovação entre os envolvidos. incorporação nas iterações.
Incorporação de novos requisitos pode
ser lento e caro.
FONTE: ADAPTADO DE CHIN, 2004

30. GAP - Papel do Gerente de
Projetos
• Reconhecer que projetos ágeis irão mudar de direção
muitas vezes durante seu curso.
• Mapear as influências externas que possam impactar
o projeto e compartilhar de maneira adequada essa
informação com os times.
• Ser mais um facilitador do que um gerente (no
sentido de comando).
• Atuar como um “canalizador” de informações,
provendo informações de valor para o time de
projeto.

31. GAP - Papel do Gerente de
Projetos
• Manter uma visão geral do projeto para o time.
• Facilitar o processo de interação entre as pessoas.
• Liderar o processo de adaptação através da
manutenção das lições aprendidas, atuando nas
ações corretivas.

32. “Agilidade é um modelo-mental,
uma maneira de pensar, não um
conjunto de práticas ou processos”
Jim Highsmith

33. Alguns livros

34. Obrigado

35. Scrum

36. Scrum
24 horas
Reuniões Scrum diárias
Sprint
(iteração )
Nova funcionalidade é
Sprint apresentada ao final do
Backlog Sprint
Backlog do
produto
selecionado
Backlog do produto
Visão
FONTE: SCHWABER, 2003, p. 9

37. Scrum
• Papéis:
– Product Owner
– Scrum Master
– Scrum team

38. Scrum
• Artefatos:
– Product Backlog
– Sprint Backlog
– Burndown / burnup chart
...

39. Referências
• AGILLE ALLIANCE. Manifesto for agile software development. Disponível em
<http://www.agilemanifesto.org>.
• BOEHM, B. W. A Spiral Model of Software Development and Enhancement. Computer, v.21, n.5,
p.61-72, 1988.
• CHIN, G. Agile Project Management: how to succeed in the face of changing project requirements.
NY: Amacon, 2004.
• HIGHSMITH, J. Agile Software Development Ecosystems. Boston: Addison-Wesley, 2002.
• HIGHSMITH, J. Agile Project Management: creating innovative products. Boston: Addison-Wesley,
2004.
• HIGHSMITH, J. Declaration of Interdependence. 2005. Disponível em <http://www.pmdoi.org/>.
• PRESSMAN, R.S. Engenharia de Software. 6.ed. São Paulo: McGraw-Hill, 2006.
• PROJECT MANAGEMENT INSTITUTE – PMI. Um Guia do Conjunto de Conhecimentos em
Gerenciamento de Projetos – Guia PMBok. 3.ed. Pennsylvania, EUA, 2004.
• ROYCE, W.W. Managing the development of large software systems. Proc. IEEE WESCON, p. 1-9,
aug. 1970.
• SCHWABER, K. Agile Project Management with Scrum. Washington: Microsoft Press, 2004.
• SLIGER, M.; BRODERICK, S. The Software Project Manager's Bridge to Agility. Boston: Addison-
Wesley Professional, 2008.