Este documento fornece um resumo sobre metodologias ágeis, incluindo: (1) Scrum, XP e Lean são abordados como principais metodologias ágeis; (2) Os princípios ágeis como valorização da interação humana, software funcionando e resposta à mudança são destacados; (3) Práticas como planejamento iterativo, entregas frequentes e foco na qualidade são discutidas.

1. Conhecendo as
Metodologias Ágeis

2. Quem sou eu?
Guilherme Lacerda
guilhermeslacerda@gmail.com
Mestre em Ciência da Computação, área de Engenharia de Software (UFRGS)
Professor de Graduação (FACENSA e UniRitter) e Pós-Graduação (UniRitter)
Consultor de TI, com mais de 15 anos na área de desenvolvimento de Software e 10 anos
de experiência em modelagem e desenvolvimento OO
Instrutor/Consultor de Metodologias Ágeis da TargetTrust Treinamento e Tecnologia
Pioneiro em Metodologias Ágeis no Brasil (Lean, SCRUM e XP)
Fundador do XP-RS (Grupo de Usuários de Metodologias Ágeis do RS) e Vice-Coordenador
do GUMA (Grupo de Usuários de Metodologias Ágeis) vinculado a SUCESU-RS
Membro do IASA (International Association of Software Architects)

3. Quem faz programa?
Por que 80% a 90% dos projetos de SW
fracassam?
Fonte: Standish Group

4. Principais Problemas
Sistemas entregues com atrasos e/ou orçamento estourado
Não atendem os requisitos de negócio
Clientes descontentes (sem confiança nos desenvolvedores)
Clientes não têm compreensão clara do que é desenvolvido
Clientes não dão suporte correto para o desenvolvimento
Clientes não estão interessados em participar de processos complexos

5. Principais Problemas
Desenvolvedores trabalham muitas horas!
Desenvolvedores relaxam na disciplina
Desenvolvedores perdem o foco
Processos prescritivos são atrativos para a gerência mas não para
os desenvolvedores
Baseados no paradigma do comando e controle
Tenta minimizar o papel do cliente
Foco em tecnologia e não no negócio

6. Comunicação

7. Comunicação

8. Comunicação

9. Comunicação

10. Como resolvê-los?

11. Como resolvê-los?

12. O que é ser Ágil?
Ágil é ser rápido, ligeiro (dicionário)
Eficaz: produz o resultado esperado
Eficiente: produz o resultado esperado, mas com qualidade
Características importantes:
Foco nas necessidades do cliente (resultado!)
Liderança
Envolvimento das pessoas
Melhoria Contínua
Tomada de decisões baseada em análise de dados e informações
(controle!)

13. Direitos do Cliente (Ron Jeffries)
Planejamento Geral, definindo o que pode ser realizado, quando e a
que custo
Ver e acompanhar o andamento do projeto e, principalmente, o
progresso do SW, passando por testes definidos em conjunto com a
equipe
Mudar de idéia, substituir funcionalidades, sem pagar custos
exorbitantes
Ser informado de mudanças no cronograma, em tempo de escolher e
reduzir o escopo
Poder cancelar o projeto a qualquer momento e ainda assim ter um
sistema funcionando, refletindo o investimento realizado até o
momento

14. Direitos do Desenvolvedor (Ron Jeffries)
Saber o que é necessário, com declarações claras de
prioridade
Produzir trabalho de qualidade o tempo todo
Pedir e receber ajuda da equipe, superiores e clientes
Fazer e atualizar suas próprias estimativas
Aceitar as suas responsabilidades, ao invés de tê-las impostas

15. Processos de Software
Processos Tradicionais
Analisar, projetar e só depois iniciar codificação
Prever o futuro
Ter certeza do que se sabe hoje será exatamente o que se quer amanhã
Temores
Mudança de requisitos depois de concluída a fase de análise e projeto

16. Manifesto Ágil
“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:
Interação entre pessoas MAIS QUE processos e ferramentas;
Software em funcionamento MAIS QUE documentação abrangente;
Responder a mudanças MAIS QUE seguir um plano.
Colaboração com o cliente MAIS QUE negociação de contratos;
Ou seja, mesmo tendo valor os itens à direita, valorizamos
mais os itens à esquerda.”
Kent Beck, Robert C. Martin, Scott Ambler, Alistair Cockburn, Ward
Cunningham, Ron Jeffries, Steve Mellor, Mike Beedle, Arie van Bennekum,
Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Brian Marick,
Ken Schwaber, Jeff Shuterland, Dave Thomas
Utah – Fevereiro de 2001

17. Waterfall X Ágil

18. Waterfall X Ágil

19. Cone da Incerteza

20. Riscos
Riscos de Planejamento
Será que conseguiremos
terminar até outubro?
Riscos de Custo
Será que conseguiremos comprar o servidor pelo preço definido
anteriormente?
Riscos de Requisitos
Será que temos todas as informações para começar o trabalho?

21. Risco X Valor
Alto Risco Alto Risco
Baixo Valor Alto Valor
Risco
Baixo Risco Baixo Risco
Baixo Valor Alto Valor
Valor
Evitar Fazer Primeiro
Risco
Fazer por último Fazer depois
Valor

22. Waterfall, Iterativo

23. Metodologias Ágeis

24. Preparando o terreno
Cultura (princípios e valores)
Lean Foco no ROI
Eliminação de desperdícios
Foco no planejamento e priorização
Autogestão
Scrum Colaboração e Comprometimento
Comunicação e feedback
Práticas de engenharia
XP Entregas frequentes
Ênfase em qualidade

25. Lean Software Development

26. Principais Nomes
Kiichiro Toyoda
JIT na linha de produção
Taiichi Ohno
Fluxo JIT e Autonomação (Jidoka)
Shingeo Shingo
Produção sem estoques e Zero Inspeções

27. Problemas de Produção
Muda
Desperdícios
Mura
Falta de regularidade
Muri
Sobrecarga

28. STP

29. Conceitos
Just in Time
Jidoka
Heijunka
Kanban
Andon
Poka-Yoke
Jishuken
Genchi Genbutsu
Trabalho Padronizado e 5S
Hansei e Kaizen

30. Kanban

31. Trabalho Padronizado/5S

32. Prevenção X Inspeção
STP
Foco em prevenção e eliminação de
desperdícios
JIT e Autonomação
100
Falhas
Externas Economia
Falhas Falhas Externas
50 Internas
Falhas
Internas
Avaliação Avaliação
Prevenção
0 Prevenção
Antes Depois

33. Lean Software Development
Principais nomes são Mary e Tom Poppendieck

34. SCRUM

35. O que é SCRUM?

36. O que é SCRUM?
Framework ágil para gerência de projetos
Pode ser utilizada para qualquer tipo de projeto
Processo empírico para gerência e desenvolvimento de produtos
complexos
Empirismo é dependente de inspeção frequente e adaptações dos
objetivos
Inspeção é dependente de transparência
Equipes auto-gerenciadas
SCRUM = jogada no Rugby

37. O que é SCRUM?
Principais nomes são Ken Schwaber, Jeff Sutherland e Mike
Beedle

38. SCRUM Alliance
Instituição sem fins lucrativos
Centraliza cursos, artigos, materiais e eventos sobre SCRUM
Responsável pelas certificações
http://www.scrumalliance.org/scrum_certification
Professional Level
Foudation Level
Guide Level
Mid Level

39. Valores
Comunicação
Trabalho em Equipe
Flexibilidade
Foco no produto e em atividades que agregam valor
Respeito e coragem

40. Fluxo de Valor do SCRUM
Aprovação Suporte
Visão Time Desenvolvimento Implantação
do Projeto e Feedback
Durante
Feedback do Cliente
Aprendizado
Agregar Valor
Antes Depois

41. Framework SCRUM

42. Framework SCRUM

43. Desenvolvimento Sequencial
X SCRUM
Requerimentos Projeto Código Teste
Fonte: “The New New Product Development Game” by
Takeuchi and Nonaka. Harvard Business Review, January
1986.

44. eXtreme Programming

45. XP
Criado por Kent Beck, Ron Jeffries e Ward Cunningham
Disciplina de desenvolvimento de SW, voltada para equipes
pequenas e médias, com requisitos vagos ou que mudam
freqüentemente
Principal tarefa é a codificação

46. XP

47. Valores do XP
Comunicação
Práticas valorizam a comunicação, não limitada a procedimentos formais
Simplicidade
Incentiva ao extremo práticas que reduzam a complexidade
Feedback
Práticas garantem um rápido feedback sobre várias partes do projeto
Coragem
Práticas aumentam a confiança dos desenvolvedores e do próprio cliente

48. Variáveis de um Projeto
Processos Tradicionais
Tempo
Escopo Manipula-se a
Custo Qualidade
eXtreme Programming
Tempo Manipula-se a
Qualidade Escopo
Custo

49. XP – eXtreme Programming
Práticas organizacionais
Práticas de equipe
Práticas de pares

50. Equipe (Whole Team)
Equipe XP = Cliente + Time de Desenvolvimento
As funções do cliente englobam:
Definição dos requisitos do projeto
Definição de prioridades
Controle do rumo do projeto
Definir os testes de aceitação do SW
Os papéis do time de desenvolvimento englobam:
desenvolvedores
testadores (ajudam o cliente com os testes de aceitação)
analistas/projetistas (ajudam o cliente a definir requisitos)
gerente (garante os recursos necessários)
coach (orienta a equipe, controlando a aplicação do XP)
tracker (coleta as métricas do projeto)

51. Equipe (Whole Team)

52. Jogo de Planejamento (Planning Game)
Principais definições
Definição das User Stories (atividade + tarefas)
Estimativas de User Stories
Prioridades (tarefas + importantes)
Próximos passos
Planejamento de release (cliente propõe as funcionalidades e
desenvolvedores avaliam)
Planejamento da iteração (define as funcionalidades da iteração e os
desenvolvedores estimam)
Ótimo feedback para o cliente, que dirige o projeto
Idéia clara do avanço do projeto
Clareza: Redução de Riscos, aumentando a chance de sucesso

53. Produto, Release, Planejamento
Release 1 Release 2 Release 3
Planejamento
Iteração 1 Iteração 2 Iteração 3-5
Tarefa A
Tarefa B
Tarefa C

54. Releases, Iterações, Velocidade
Um release é formado de múltiplas iterações
Cada iteração pode ser planejada com o mesma caixa de tempo
Stories são colocadas dentro de cada caixa, até estar completa
O tamanho da caixa é a velocidade planejada
3 4 2
3 7
4
5 4
5
2 6 4
2 5
6

55. Testes de Aceitação (Acceptance Tests)
São elaborados pelo cliente em conjunto com analistas e testadores
São automatizados
Quando rodarem com sucesso, funcionalidade foi implementada
Devem ser rodados a cada iteração
Roteiro com um conjunto de respostas esperadas
Ótimo feedback para o cliente
Pode se saber, a qualquer momento, o % de implementação do SW e
quanto falta

56. Pequenos Lançamentos (Small Releases)
Disponibiliza a cada iteração SW 100% funcional
Versão disponibilizada imediatamente
Redução de riscos (se o projeto terminar, parte existe e funciona)
Detecção prévia de problemas
Comunicação entre cliente e desenvolvedor
Cada lançamento possui funcionalidades prioritárias para a iteração
Lançamento pode ser destinado a
usuário/cliente (testa, avalia e oferece feedback)
usuário/final (sempre que possível)
Design simples e integração contínua são práticas essenciais

57. Projeto Simples (Simple Design)
Projeto está presente em todas as etapas XP
Projeto começa simples e se mantém assim através de testes e
refinamento de código (refactoring)
Em XP, é levado ao extremo
Não é permitido implementar qualquer funcionalidade adicional que
não será usada na iteração atual
Implementação ideal é aquela que
Passa por todos os testes
Expressa todas as idéias definidas no planejamento
Não contém código duplicado ou que “cheire”
Prever o futuro é impossível e é “anti-XP”

58. Programação em Pares (Pair Programming)
SW é desenvolvido em pares
“2 cabeças juntas são melhores que duas cabeças separadas”
1 piloto e 1 co-piloto
Papéis são alternados freqüentemente
Benefícios
Melhor qualidade de código (refactoring, testes)
Revisão constante do código
Nivelamento da equipe
Maior comunicação
“Um” pelo preço de “Dois”??
Pesquisas demonstram que duplas produzem código de melhor
qualidade em aproximadamente o mesmo tempo que programadores
que trabalham sozinhos

59. Desenvolvimento Dirigido por Testes (Test-Driven
Development)
XP valoriza o desenvolvimento dirigido por testes
São automatizados, executados o tempo todo
Testes “puxam” o desenvolvimento
Cada unidade de código só tem valor se o teste funcionar 100%
Testes dão coragem para mudar
De que adianta a OO isolar a interface da implementação se o
desenvolvedor tem medo de mudar a implementação?

60. Desenvolvimento Dirigido por Testes (Test-Driven
Development)
TDD
Obter
tarefa Criar Código de Codificar Fazer
Teste para a tarefa Refactoring
Passou nos testes?
Sim: Nova tarefa Não: Revisar código

61. Refatoração (Refactoring)
Design é melhorado continuamente através de refinamento
Mudança proposital no código que está funcionando
Melhorar sua estrutura interna sem alterar a funcionalidade
Visa simplificar o código, remover o código duplicado
Principal referência é o catálogo de refactorings de Martin Fowler
Existência prévia de testes é fundamental para utilização desta
prática (elimina o medo dos desenvolvedores de adotar a mudança)
“Software é como a nossa casa”
Organizados X desorganizados
XP enfatiza código de alta qualidade

62. Integração Contínua (Continuous Integration)
XP mantém o SW integrado o tempo todo
Realizada pelo menos uma vez por dia
Para integrar, deve-se realizar os testes primeiro
“Reduz o tempo passado no inferno da integração” - Martin Fowler
Benefícios
Expõe o estado atual de desenvolvimento
Oferece feedback
Estimula agilidade e versões freqüentes do SW

63. Posse Coletiva (Collective Ownership)
O código tem um único dono: a equipe
Qualquer par de programadores pode melhorar o código
Revisão constante do código
Aumenta a comunicação
Aumenta a qualidade (menos duplicação, maior coesão) e diminui os
riscos de dependência de indivíduos
Todos compartilham a responsabilidade pelas alterações
Ideal que se troque os pares periodicamente
“Todos conhecem tudo”
Testes e integração contínua são essenciais e dão segurança

64. Padrões de Codificação (Coding Standards)
Os padrões de codificação são definidos pela equipe
Organização de código
Nomenclaturas
Código com aspecto de escrito por um único desenvolvedor
Competência
Organização
Práticas e valores favorecidos
Posse coletiva
Comunicação
Programação em Pares
Refactoring
Projeto Simples

65. Metáfora (Metaphor)
Equipes XP mantém uma visão compartilhada do sistema
Analogia com outros sistemas (natural, computacional, abstrato)
Exercício de criatividade e abstração
Ótima fonte de comunicação entre a equipe, facilitando inclusive as
estimativas
Pattern de alto nível

66. Ritmo Saudável (Sustainable Pace)
XP está na arena para ganhar
Projetos vampiros não são projetos XP
Semanas de 80 horas
Código ruim, relaxamento da disciplina, stress da equipe
Tempo ganho será perdido depois
São aceitáveis eventuais horas extras quando a produtividade é
maximizada

67. Reuniões em Pé (StandUp Mettings)
A maioria dos desenvolvedores odeiam reuniões
Assuntos demorados e desgastantes
Impedem os desenvolvedores de codificar
As reuniões são valiosas quando
Não perdem o foco
São breves
São abordadas tarefas realizadas e a realizar

68. Spikes de Planejamento (Spike Solution)
São investigações de tecnologias que podem ser utilizadas no
projeto
Auxiliam nas estimativas e na especificação do projeto
Podem durar horas ou dias, porém devem ser curtos
Englobam
Avaliações de arquiteturas
Algoritmos
componentes e frameworks
BDs
Servidores de aplicação, Web
Utilização de artefatos e ferramentas

69. Ambiente de Trabalho
O ambiente deve apoiar a aplicação das práticas
Tem importância vital para um projeto de software
Trabalhar próximo dos colegas
Facilitar a comunicação
Equipamentos
Mesas e cadeiras
Equipamentos tecnológicos
Telefones
Mural
Quadro Branco
Calendário
Comida ☺
Isolamento (equipes e projetos)

70. Documentação Ágil
Complexidade do Software
Tempo de desenvolvimento
Equipes
Futuras manutenções
Até que ponto documentar?
Uso incorreto da documentação
Quando documentar?
Documentos que compõem a documentação
User stories, testes de aceitação, testes de unidade, documentação de
código fonte, Modelo de Classes, Modelo de Dados, Processos de
Negócio, Manual de usuário, Acompanhamento diário,
Acompanhamento do Projeto

71. Ferramentas de Apoio
Mais em http://xprogramming.com/software.htm

72. Teste de Unidade

73. Teste de Unidade

74. Teste de Unidade

75. Patterns, Boas Práticas, Refactoring

76. Patterns, Boas Práticas, Refactoring

77. Code Coverage

78. Code Coverage

79. Code Coverage

80. Integração Contínua

81. Integração Contínua

82. Padrões de Codificação

83. Padrões de Codificação

84. Mercado
HP
Ford Objective Solutions
Symantec ImproveIt
Motorola Brasil Telecom
Chrysler Embrapa
BMW Qualiti
Borland Trevisan Tecnologia
IBM Argonavis
First National Bank CETIP
Thought Works Secretaria da Fazenda SP
CC Pace Systems Smart Tech Consulting
Industrial Logic iQualy
Moore IME-USP
Workshare EverSystems
Xerox PowerLogic Consultoria
Siemens UFRJ
Object Mentor PUC-Rio
Microsoft Surya Tecnologia
Google
Nokia
Yahoo

85. Principais Eventos

86. Adotando e Escalando Metodologias Ágeis
Adote as práticas em doses homeopáticas
Não seja afobado, saboreie a mudança
Enfatize o problema mais importante
Dificuldades culturais
Deixar alguém mexer no seu código
Aceitar/Pedir ajuda
Ânsia de tentar prever o futuro
Escrever testes antes de codificar
Refatorar com freqüência (superar o medo)
Situações difíceis de aplicar práticas ágeis
Equipes grandes e distribuídas geograficamente
Perda do controle sobre código
Feedback demorado

87. Adotando e Escalando Metodologias Ágeis
Metodologias ágeis valorizam as pessoas
Bons desenvolvedores criam bons SWs
Processos ágeis são suplementos aos outros métodos
São atitudes
São efetivos
Não é um ataque à documentação e sim a criação de
documentos que tem valor
Não são para todos
O segredo está na sinergia de suas práticas
Menos formalidade, mais diversão

88. Combinando Lean + SCRUM + XP

89. Combinando Lean + SCRUM + XP

90. Exercício de Superação do medo
Dois voluntários, por favor...

91. Apoio