O documento discute princípios e práticas de gerenciamento ágil de projetos, como SCRUM e XP. Ele apresenta valores, princípios e características de processos ágeis, como entregas incrementais frequentes, envolvimento do cliente, equipes auto-organizáveis e foco na comunicação. Além disso, explica conceitos como Product Backlog, Sprints, Daily Scrum e Retrospectivas para gerenciar de forma iterativa o desenvolvimento de software.

1. Agilidade:
SCRUM e XP

2. Facilitador
Fernando Costa
formado em Redes de Computadores
Sócio da 3LJ Tecnologia – www.3lj.com.br
Agenda SCRUM:
Contexto de
projetos
Valores ágeis
Princípios ágeis
Scrum

3. Paradoxo de Cobb
We know why projects fail, we know
how to prevent their failure – so why
do they still fail?
Martin Cobb
Treasury Board of Canada Secretariat
Nós sabemos porque os
projetos falham, sabemos
como previnir – Porque
eles continuam falhando?

4. Reflexão do Caranguejo
 Todos os caranguejos
ficam amarrados a um barbante que fica
solto.
 Não é preciso amarrar pois todos querem fugir
mas cada um que ir para um lado
diferente.
 Ficam no mesmo lugar

5. Valores do Manifesto Ágil
Indivíduos e interações Processos e ferramentas
Documentação
Software que funciona
ao invés
abrangente
de
Colaboração do cliente Negociação de contrato
Resposta à mudanças Seguir um plano
www.agilemanifesto.org - 2001

6. Princípios do Manifesto Ágil
1 - O principal compromisso é com a satisfação
do cliente, por meio da entrega mais rápida e
contínua de produto com valor
2 - Receba bem as mudanças de requisitos(mesmo
em estágios tardios do projeto). Processos ágeis
devem admitir mudanças que trazem
vantagens competitivas ao cliente
3 - Libere produto frequentemente (de 2 a 4
semanas), dando preferência para uma escala de
tempo curta

7. Princípios do Manifesto Ágil
4 - Mantenha pessoas ligadas ao negócio (cliente) e
desenvolvedores trabalhandos juntos a maior
parte do tempo do projeto
5 - Construa projetos com indivíduos motivados, dê
a eles o ambiente e suporte que precisam e confie
neles para ter o trabalho realizado
6 - O método mais eficiente e efetivo para repassar a
informação entre a equipe é pela comunicação
face a face

8. Princípios do Manifesto Ágil
7 - Produto funcionando é a principal medida
de progresso de um projeto
8 - Processos ágeis promovem o
desenvolvimento sustentado. Patrocinadores,
desenvolvedores e usuários devem ser capazes
de manter conversação pacífica
indefinidamente
9 - Atenção contínua para excelência técnica e
bom projeto (planejamento) aprimoram a
agilidade

9. Princípios do Manifesto Ágil
10 - Simplicidade é essencial e deve 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 então refinarem e ajustarem seu
comportamento

10. SCRUM

11. Em resumo...
Imagem disponível em:
www.mountangoatsoftware.com/scrum

12. Cliente (ou Product Owner)
 Quem é o nosso cliente?
 Funcionalidades do
produto
 Decide as datas e
conteúdo
 Rentabilidade (ROI)
 Ajusta e prioriza
funcionalidades e
prioridades
 Aceita o rejeita resultados

13. Scrum Master
 Remove obstáculos
 Não tem autoridade
 Produtividade da equipe
 Conduz eventos
 Escudo da equipe

14. Equipe
 5 a 9 pessoas
 Multi-funcional
 Auto-organizável
 Sugere funcionalidades
do produto

15. Product Backlog
 Lista de funcionalidades desejadas no projeto
 Os itens que compõe a lista são chamados de
histórias ou itens de backlog
 Todos podem incluir histórias
 Somente o Product Owner pode priorizá-las
 Product Owner pode priorizar novamente no
início de cada Sprint

16. Nosso Product Backlog
ID Nome Importância Estimativa Observação
1 Catálogo de
produtos
2 Cesta de
compras
3 Cadastro do
cliente
4 Boleto bancário
5 Cartão de
crédito

17. Planning Poker
 Vamos estimar os itens de Backlog?

18. Nosso Product Backlog
ID Nome Importância Estimativa Observação
1 Catálogo de 3
produtos
2 Cesta de 5
compras
3 Cadastro do 2
cliente
4 Boleto bancário 4
5 Cartão de 3
crédito

19. Qual a importância dos itens de
backlog para o Product Owner?

20. Must Should Could Want
(tem que (deveria ter) (poderia ter) (interessante)
ter)
Catálogo de Boleto Controle de Videos dos
produtos bancário estoque produtos
Cadastro de Cartão de Regras de
clientes crédito promoção
Cesta de Fotos dos
compras produtos
Registro do
Pedido e
entrega

21. Nosso Product Backlog
ID Nome Importância Estimativa Observação
1 Catálogo de 1 3
produtos
2 Cesta de 1 5
compras
3 Cadastro do 1 2
cliente
4 Boleto bancário 2 4 BB e CEF
5 Cartão de 3 3 Visa e
crédito Mastercard

22. Sprint
 Deve ter um objetivo
 Período de 2 a 4 semanas
 Nenhuma mudança no sprint
 Processo baseado em uma série de iterações
 Produto é desenvolvido no sprint

23. Product Burnup Chart

24. Planejamento do Sprint
 Cliente, ScrumMaster e Equipe
 Cliente seleciona itens do Product backlog
 O Sprint backlog
− Tarefas identificadas e estimadas (1 a 16
horas)
− De forma colaborativa (por todos)
− Equipe compromete-se a concluir as tarefas

25. Planejamento do Sprint
ID – 1.1
ID - 1 Administrador dos
Produtos
Catálogo de produtos
10 horas
ID – 1.2
Busca fonética de
ID – 1.3 produtos
Front-end da Loja 2 horas
15 horas

26. Scrum diário
 Tempo de 15 minutos
 Todos em pé
 Não é para a solução de problemas
− Todos são convidados
− Apenas a Equipe, ScrumMaster e Product Owner
podem falar
 Sincronização do conhecimento
 Atualização do burnup chart
1. O que fiz desde a última reunião?
2. O que farei até a próxima reunião?
3. Existe algum obstáculo?

27. Gerenciando o Sprint backlog
 Cada membro da equipe escolhe a tarefa
que fará
− Trabalhos nunca são atribuídos
 Atualização diária da estimativa do trabalho
restante
 Equipe pode adicionar, apagar ou mudar
tarefas (não itens de backlog)

28. Scrum board

29. Revisão do Sprint
 Informal
 Todos participam
 Hora do feedback
 Resultados do Sprint
Comunicação eficaz:
(bala / bombom)

30. Retrospectiva do Sprint
 Feita após cada Sprint
 Periodicamente observe pontos
positivos e negativos
 Tipicamente de 15 a 30 minutos
 Todos participam

31. Inicia, Pára, Continua
 A equipe discute o que gostaria de:
Iniciar a fazer
Parar de fazer
Esta é uma das
várias maneiras Continuar fazendo
de se conduzir
uma
retrospectiva do
Sprint

32. Agora vocês explicam!!!

33. Resumo: Gerenciamento ágil
Tópico Características
Objetivo principal Orientado ao produto e centrado nas pessoas
Tipo do projeto Projetos com mudanças constantes e que necessitam de respostas
rápidas
Tamanho Mais efetivo em projeto pequenos(5 a 9 pessoas)
Gerente do projeto Papel de facilitador ou coordenador
Equipe do projeto Atuação colaborativa em todas as atividades do projeto
Cliente Essencial. Deve ser parte integrante da equipe do projeto
Planejamento Curto e com a participação de todos os envolvidos na elaboração
do planejamento
Arquitetura Aplicação de design simples. Evolui junto com o projeto e
baseia-se na refatoração
Modelo de Iterativo e Incremental
desenvolvimento
Comunicação Informal
Tópico Características

35. Dúvidas?
Fernando Costa
fernando@3lj.com.br
www.fernandocosta.com.br
Patrocínio: Agradecimento:
www.3lj.com.br www.innovit.com.br

37. Agenda do XP
Desenvolvimento
tradicional
 Valores
 Princípios
 Práticas

38. Fazer software é dureza

39. Boa
Má notícia
notícia
Cases de sucesso: • Seus colegas não vão
Google
 acreditar
Microsoft
 • O seu chefe não vai
aceitar
Philips

• O chefe do seu chefe
não pode nem pensar
FAB (BR)

Oi Paggo


40. Não é assim que se faz
software
Principais falhas:
a) Não entregam o acordado
b) Orçamento
c) Prazo
d) Todas alternativas

41. Utilização de funcionalidades
Pesquisado em 280 mil projetos de software nos EUA pela
empresa Standish Group

42. 64% de desperdício
 Podem gerar algumas horas extras para a equipe
 Cliente paga por lixo

43. Utilização de funcionalidades
Pesquisado em 280 mil projetos de software nos EUA pela
empresa Standish Group

44. 20% muito útil
 Geram pelo menos 80% do valor do
produto
 20%? desconhecido no início do projeto
“XP é a arte de maximizar a
quantidade de software que
você não vai fazer “
Vinícius Manhães Teles

45. Análise
Pai(cliente): 1 dia de projeto
Mãe(desenv.): 9 meses de projeto

46. Análise
Cliente: “Não era nada disso que eu
queria...”

47. Mentalidade

48. Cascata

49. Custo da Mudança
por Barry Bohem

50. Problemas e mudanças
Patente do VELCRO:
em 1941 por Georges
de Mestral

51. Meio digital
 Fluidez
 Maleabilidade
 Invisibilidade
 Complexibilidade (elementos distintos)
 Baixo custo de manufatura
 Rapidez evolução

52. Nova mentalidade
• Chef
• Escritor

53. eXtreme Programming

55. Valores do XP
ão
aç
ic em
un ag
om Cor
C
Respeito
de ck
ida ba
ic ed
pl
im Fe
S

56. Uma pergunta
“Como você programaria se tivesse
tempo suficiente?”
Kent Beck

57. Possíveis respostas
 Mais testes?
 Mais projeto e arquitetura?
 Menos pessoas?
 Mais qualidade?

58. Programando ao Extremo
− Testar toda hora!!
− Seprojetar é bom, vamos fazer
disso parte do trabalho diário de
cada pessoa!
− Integrar
a maior quantidade de
vezes possível!
− Iterações realmente curtas!

59. Práticas Cliente
Presente
Código
Coletivo Test-Driven Coding
Development Standard
Testes de Programação Planning
Aceitação em pares Refactoring Game
Integração
Design Ritmo
Contínua
Simples Sustentável
Metáfora
Releases
Curtas
Adaptado de xprogramming.com

60. Jogo do Planejamento
 Reunião semanal onde todos participam
 Escopo reavaliado
 Cliente prioriza e seleciona as histórias
que serão desenvolvidas
 Ao fim da semana o cliente recebe produto
funcionando

61. Reunião em pé
 10/15 minutos
 Todos em pé
 Não é para a solução de problemas
− Todo mundo é convidado
− Apenas a Equipe pode falar
 Sincronização do conhecimento
1. O que fiz desde a última reunião?
2. O que farei até a próxima reunião?
3. Existe algum obstáculo?

62. Cliente presente e envolvido
• Responsabilidade do
projeto:
– Equipe
– Cliente
• Comprometimento

63. Ritmo sustentável
 Semana de 40 horas (8hr/dia)
Sem hora extra:
 Baixa produtividade
 Código de má qualidade
 Aumento de BUGs

64. Programação em
par
 Forneça suporte e ferramentas
 Experimente, você vai se surpreender
 Alterne os pares para não ficar cansativo e
nivelar o time
 Respeite a individualidade das pessoas

65. Código Padronizado

66. Código Coletivo
 Inibe ilhas de
conhecimento
 Padrão de codificação
 Membro da equipe pode
ter férias
 Direito de ficar doente

67. Integração Contínua
 Divergências aparecem antes de virar
um problema
 “Isso funcionava na minha máquina”

68. Projeto Simples
 Faça o essencial
 Tudo pode mudar

69. Refatoração
 “Time que está ganhando não se mexe” –
FALSO
 Ex.: Empresas estáveis quebram se não
mudarem
 Melhoria contínua

70. Desenvolvimento
Orientado
a Testes (TDD)
 Início é um pouco demorado
 Primeiro o teste, depois a funcionalidade
para passar no teste
 Testes automatizados: Unitários, Interface e
Aceitação
 RETORNO: Salvação no FIM do projeto

71. Releases curtos

72. Papéis
Tracker
Coach Goal Donnor
Manager
Gold Owner Programador
Analista de Testes

73. Equipe nivelada

75. Dúvidas?
Fernando Costa
fernando@3lj.com.br
www.fernandocosta.com.br
3LJ Tecnologia
www.3lj.com.br
Agradecimento:
Vinícius Manhães Teles
Improve It