1. Conhecendo XP
e Lean
Entenda o que a Toyota, os processos e
as pessoas tem haver com o
desenvolvimento de software

3. De onde vem isso?
• DeMarco, Tom; Lister, Tim. Peopleware: Productive
Projects and Teams. Dorset House Publishing.
• Poppendieck, Tom & Mary. Lean Software Development:
An Agile Toolkit. Addison-Wesley.
• DeMarco, Tom. Slack: Getting Past Burnout, Busywork
and the Myth of Total Efficiency. Broadway.

4. De onde vem isso?
• Poppendieck, Tom & Mary. Implementing Lean Software
Development: From concept to cash. Addison-Wesley.
• Cockburn, Alistair. Agile Software Development: The
Cooperative Game. Addison-Wesley Professional.

5. De onde vem isso?
• Material de aula do Certified Scrum Trainer
Michel Goldenberg;
• Schwaber, Ken; Beedle, Mike. Agile Software
Development with Scrum. Prentice Hall.
• Schwaber, Ken. Agile Project Management
with Scrum. Microsoft Press.

6. Os dois tipos de processo
• Processos definidos
• Processos empíricos

7. Processos definidos
• Dado um conjunto de entradas bem definidas, a mesma
saída é gerada sempre;
• Tudo é repetível;
• Trabalhos são associados um ao outro na forma de uma
corrente;

8. Processos empíricos
• Entradas e saídas não são previsíveis;
• Inspeção e controle de direcionamento contínuos e em
prazos cursos para avaliar os resultados;
• Ajustes imediatos para todo e qualquer problema que
surgisse;

9. Usar processos definidos em casos
empíricos causa:
• Surpresas desagradáveis;
• Perda de controle do processo;
• Produtos incompletos ou completamente errados;

10. Eu não posso ter pessoas
E processos?
• Se você valoriza as pessoas, os processos tornam-se
menos importantes, eles tornam-se mais maleáveis,
eles não pertencem aos chefes, mas as pessoas;

11. Eu não posso ter pessoas
E processos?
• Se você valoriza os processos, eles tornam-se mais
importantes do que as pessoas que os executam
(afinal, o processo já diz como as coisas devem
ser), o trabalho das pessoas é apenas executar;

12. O que nós vemos no dia-­‐‑a-­‐‑
dia?
Processos normalmente são mais
importantes do que as pessoas

13. Mas em alguns lugares, as
pessoas são mais importantes
do que os processos

14. Onde?

15. Como tudo começou?
• Japão, 1940;
• Povo pobre, mercado pequeno;
• Produção em massa era impossível, o mercado
não seria capaz de absorver os produtos;

16. Como produzir carros em
pequenas quantidades
com o custo de carros
produzidos em massa?

17. Elimine o
desperdício!
Essa foi a solução encontrada
por Taiichi Ohno, pai do Toyota
Production System, simples,
não?

18. Simples, até ele dizer pra
você o que é desperdício
Qualquer coisa que não gere
valor para o cliente, é
desperdício

19. Exemplos de desperdício
segundo Ohno
• Estoque;
• Transporte;
• Movimento;
• Espera;
• Produzir algo antes da hora que ele é necessário;
• Serviços extras;
• Defeitos;

20. Como funciona uma
indústria de carros da
velha guarda?
• Vários departamentos diferentes produzem pilhas
de produtos intermediários;
• Estes produtos ficam estocados nas fábricas até
que a linha de produção precise deles;

21. Como funciona uma
indústria de carros da
velha guarda?
• Quando a linha de produção precisa de alguma
coisa, vai ao estoque e pega os produtos que são
necessários;
• Após reunir as partes, eles começam a produção,
se houver alguma falha em alguma das partes e
ela só for descoberta agora, tudo o que está no
estoque vai pro lixo;

22. E como a Toyota faz?
• Só é produzido o que é necessário;
• Não existem diversas equipes para se produzir um
carro, apenas uma “célula” cuida de fazer todo o
trabalho;
• Se um defeito é encontrado, toda a linha de
produção pára até que o defeito seja corrigido;

23. Onde entram as pessoas?
• Agora não é mais responsabilidade do processo
garantir que as coisas funcionem, é das pessoas,
pois agora todos controlam a linha de produção e
tem o dever de mandar parar tudo se houver
algum problema;

24. Mas o que é que isso tem
haver com sofware?
• Você já teve que escrever “componentes” para
uso futuro?
• Já escreveu documentos que ninguém leu?
• Já encontrou defeitos que impediam o uso de
aplicações em produção?

25. Mas o que é que isso tem
haver com software?
• Já adicionou uma funcionalidade que ninguém
havia pedido?
• Já deixou o cliente esperando por uma ferramenta
que nunca chega?

26. Toyota Product
Developmemt System –
Lean Development
A prática do Lean Software development (e das
metodologias ágeis no geral) tem como base os
avanços da gestão industrial capitaneada pela
Toyota e outras montadoras do Oriente;

27. Os 7 tipos de desperdício
Indústria
Software
Estoque
Trabalho feito “pela metade”
Processamento extra
Processos extras
Superprodução
Funcionalidades “extras”
Transporte
Troca de tarefas
Movimento
Movimento
Espera
Espera
Defeitos
Defeitos

28. Post-­‐‑it’s de desperdício
• Pegue 3 post-its (ou mais) e escreva exemplos de
desperdício da sua empresa ou que você já tenha
visto acontecer;
• Cole eles no quadro na posição que você achar
mais correta;

29. Indústria
Software
Estoque
Trabalho feito “pela metade”
Processamento extra
Processos extras
Superprodução
Funcionalidades “extras”
Transporte
Troca de tarefas
Movimento
Movimento
Espera
Espera
Defeitos
Defeitos

30. Trabalho feito “pela
metade”
• Sabe aquele seu framework “caseiro”, ele mesmo;
• Qualquer coisa que você faça que não vai ser
utilizado imediatamente;
• No dia que você realmente precisar, será que ele
atende as necessidades?

31. Processos extras
• Sabe aquele diagrama UML que ninguém olhou?
Pois é, ficou obsoleto;
• Já pensou em quem está lendo esses documentos
que você anda fazendo? Traças letradas essas viu.
• Cada folha de papel que você usa, é uma árvore
a menos no mundo J

32. Funcionalidades extras
• “Olha, agora o menu aparece e desaparece!”
• Cada linha de código a mais é uma linha de
código que precisa ser testada, compilada e
documentada;
• Usuário + Opções = Problema

33. Troca de tarefas
• “Olha, você tem 8 horas hoje, então são 16 bugs
para corrigir, um a cada 30 minutos, agora começa
que os primeiros 30 minutos já tão contando”;
• Desenvolvimento de software é uma tarefa que se
faz com o cérebro, quem trabalha com os dedos é
digitador;

34. Uma pequena pausa para
um clássico
• Peopleware, DeMarco e Lister;
• Desenvolvedores só produzem de verdade quando
eles entram no estado de “flow”;
• Você só entra em “flow” após algum tempo de
trabalho concentrado e initerrupto;

35. Espera
• “Seguinte, já tá quase pronto, mas eu só posso
colocar em produção depois que o financeiro
liberar a nota e o gerente terminar a planilha de
horas”;
• Quanto o seu cliente perde de dinheiro a cada
segundo sem utilizar a aplicação?

36. Movimento
• “Ei, você sabe se os testes passaram?”
• “Náo, vai ali e pergunta pra equipe de testes”
• “O analista já tá com o documento de requisitos?”
• “Não, o arquiteto ainda tá validando ele”

37. Movimento
• “Como assim eu vou ter que ir pro Amazonas pra
poder fazer uma visita ao cliente?”
• “Será que essa p&%%# só atende pelo call
center?”

38. Defeitos
• “Errrrrr... Cê sabe aquela piada do gato que subiu
no telhado?”
• “Sei.”
• “Sabe o banco de dados?”
• “Fala.”
• “Ele subiu no telhado.”

39. Extreme Programming
O que é isso?

40. O que não é XP?
• A solução pros seus problemas de software
atrasado;
• A solução pro seu problema de equipes com baixa
produtividade;
• A solução proseu problema de produtos que não
atendem as necessidades do cliente;

41. O que é XP?
• Um framework de práticas e métodos que fazem
com que os problemas sejam detectados cedo o
suficiente para que a solução deles seja rápida e
indolor (ou nem tanto indolor assim…);

42. Histórico
• Desenvolvido originalmente por Kent Bech, para
um projeto da folha de pagamento da Chrysler em
1996;
• Desenvolvido da necessidade de se colocar ordem
no caos no qual o projeto se encontrava;
• Foi a primeira “metodologia ágil” do mercado, mas
é influenciada fortemente por outras idéias;

43. Características básicas do
XP
• Ciclos curtos de entrega, normalmente de 2 a 4
semanas;
• Equipes pequenas e multidisciplinares, onde todas
as necessidades estão cobertas;
• O cliente faz parte da equipe e é responsável por
definir e ajudar a priorizar o trabalho que deve ser
feito;

44. XP é bom pra ajudar...
• Projeto a 4 meses andando sem produzir nada de
útil;
• Moral baixa e equipe sem apoio da gerência;
• Produto complexo e de necessidade básica para a
empresa;
• O que é que nós podemos fazer?

45. ... A arte do possível
• Fazer o máximo possível com aquilo que temos
na mão hoje;
• Produzir valor para o cliente o mais rápido
possível;
• Ser transparente, estar sempre disponível para
inspeções e adaptar-se sempre as mudanças do
mercado;

46. Waterfall
Análise
Design
Desenvolvimento
Teste
Implantação

47. ÀGIL
Iteração 1
Iteração 2
Iteração 3

48. Cada iteração
Testes
Análise
Implantação
Design
Desenvolvimento

49. Planos VS Valor
Waterfall Ágil
O que é fixo Funcionalidades Tempo, Custo
O que é estimado Tempo, Custo Funcionalidades

50. Contratos de escopo
aberto
• Contrata-se baseado no tempo e não na
funcionalidade;
• Funciona mais próximo de uma consultoria do que
de desenvolvimento de software;
• Baseia-se na confiança mútua entre cliente e
fornecedor;

51. XP é bom porque:
• Entrega valor mais rápido e baseado exatamente
na necessidade do cliente;
• Ciclos curtos aumentam a flexibilidade e as
respostas a mudanças no ambiente externo e
interno ao projeto;
• Inspeções frequentes garantem que as
funcionalidades implementadas realmente
representam funcionalidades necessárias;

52. Os princípios do XP
• Feeback;
• Sempre assuma a simplicidade;
• Abraçe a mudança;

53. As atividades do XP
• Codificação;
• Testes;
• Ouvir;
• Design;

54. Codificação
• É a atividade mais importante e a que deve ser
mais protegida;
• Sem código não há produto;
• Também envolve a escolha da melhor
implementação pra se resolver um problema;
• Pode ser utilizado pra comunicar e expressar idéias
sobre os problemas encontrados;

55. Testes
• Testes formam um dos pilares do XP junto com o
código, não há código escrito sem que hajam
testes em XP;
• Os testes servem tanto pra demonstrar o que
precisa ser feito como também são os primeiros
clientes do código que está sendo produzido;
• O sistema deve conter testes unitários e testes de
aceitação;

56. Ouvir
• Os desenvolvedores devem ouvir e prestar atenção
nas necessidades dos clientes;
• A participação direta de todos os envolvidos na
hora de discutir uma necessidade faz com que seja
mais fácil de acertar na sua implementação no
final;
• A proximidade entre cliente e equipe faz com que
os resultados gerem mais valor;

57. Parada importante –
Linguagem ubíqua
• Cliente e equipe de desenvolvimento devem criar
um vocabulário próprio pra discutir os objetos do
sistema;
• Não devem haver traduções dos conceitos reais
do problema para os conceitos que estão sendo
aplicados no sistema;
• Os envolvidos devem construir esse vocabulário
junto, para que todos possam discutir pensando a
mesma coisa;

58. Design (ou arquitetura)
• É o processo de diminuir as dependências entre as
partes diferentes do projeto;
• Não é necessário planejar tudo antes de
acontecer, mas um pouco de planejamento deve
ser feito pra evitar que o sistema tenha
dependências demais;
• O apoio dos testes deve ser utilizado ao melhorar o
design da aplicação;

59. Valores do XP
• Comunicação
• Simplicidade
• Feedback
• Coragem
• Respeito

60. Comunicação
• Construir software é transformar as idéias do cliente
em uma solução de computador, transmitir essas
idéias para a equipe é um ponto chave na
produção de software;
• Utilize ténicas especializadas para disseminação do
conhecimento entre a equipe, como testes
automatizados, programação em par e movendo
pessoas para partes dos sistemas que elas não
conhecem;

61. Simplicidade
• YAGNI – You Aint Gonna Need it – Você não vai
precisar disso;
• Procure soluções simples, fáceis de serem
entendidas e documentadas a soluções
complexas para os seus problemas;
• Procure implementar as funcionalidades pensando
no HOJE e não em um futuro que ainda não existe;

62. Feedback – é tudo
• Todo o ciclo de XP é alimentado pelo feedback do
cliente e dos testes, tudo é feedback;
• Do sistema: feedback dos testes unitários e testes de
aceitação;
• Do cliente: feedback sobre o que e como o programa
faz suas coisas e como ele pode melhorar;
• Da equipe: feedback sobre onde melhorar, quais
requisitos não técnicos precisam ser melhorados, onde o
código precisa de re-trabalho;

63. Coragem
• Refactorings devem ser constantes e fazer parte do
dia a dia da equipe toda;
• Não deve haver medo de se implementar uma
solução menos complexa quando ela atinge a
necessidade atual;
• Não deve haver medo de remover o que é inútil,
não foi utilizado ou não o gerou valor que era
esperado;

64. Respeito
• Para si e para os outros membros da equipe;
• As pessoas devem respeitar o trabalho dos outros
ao não escrever código que quebre os testes, que
seja fora dos padrões pré-definidos;
• As pessoas devem procurar oferecer o melhor de si
para que o seu trabalho também possa ser
respeitado e admirado pelos outros membros da
equipe;

65. Quais os papéis no XP?
• Gerente;
• Cliente;
• Equipe;

66. Gerente
• Protege a equipe do caos que existe fora da iteração;
• Avalia o progresso da equipe dia a dia, para que seja
possível perceber cedo quando problemas estão a
caminho;
• Mantém a equipe trabalhando com o máximo de
produtividade;
• Remove os impedimentos que possam surgir no caminho
da equipe;

67. Bons gerentes são...
• Líderes;
• Facilitadores;
• Comunicadores;

68. Cliente
• Define o que o produto deve ter e sua visão geral;
• É responsável por criar as user stories;
• Define a importância de cada estória e se elas
entram no sprint ou não;
• Aceita (ou não) o produto desenvolvido pela
equipe;
• Não é quem paga, é quem USA o sistema;

69. Equipe
• De 5 a 9 pessoas, idealmente 6 ou 7;
• Multifuncional;
• Auto-gerenciável;
• Capaz de tomar decisões sozinhos sobre como
atingir o objetivo final (entregar valor ao final da
iteração);

70. Equipe
• Responsável por escolher o trabalho que vai ser
executado durante a iteração (baseado nas
prioridades do cliente);
• Responsável por quebrar as funcionalidades em
trabalhos e estimar a sua complexidade;
• Deve continuar seguindo as políticas da
empresa, quando elas existirem;

71. COMUNICAÇÃO

72. O que o cliente queria?

73. O que foi entregue?

74. Equipes muito grandes?
• Equipes com mais do que 8 pessoas devem ser
quebradas em equipes menores;
• O sistema deve ser modularizado de forma a
diminuir a dependência do trabalho entre as
duas equipes;
• A integração entre os trabalhos de ambos deve
ser constante (Big Bang Integration NÃO
FUNCIONA);

75. Quem pode meter o
bedelho na coisa?

76. Se você é galinha...
• Você não faz parte do time;
• Você não pode mandar no time;
• Você não pode alterar o caminho do time;
• Quer mandar? Seja porco!

77. Mãos a obra!
Release
Visão
Preparação
Planning
Iteration
Produto
Iteração
Planning

78. Começando
• Equipe e cliente se reúnem para:
• Definir a visão do projeto;
• Começar a discutir e preparar as user stories
(não é necessário colocar tudo, apenas trabalho
suficiente para 1 iteração);
• Criar e estimar user stories;

79. Exemplo de user stories
User Story Priori Estimat
ty e
Como usuário eu gostaria de criar uma conta H 4
Como usuário eu gostaria de enviar um H 8
documento
Como usuário eu gostaria de visualizar um H 5
documento
Como usuário eu gostaria de buscar H 10
documentos pelo texto deles
Como usuário eu gostaria de criar pastas para M 3
os documentos
Como usuário eu gostaria de poder mover um M 3
documento para uma pasta
Como usuário eu gostaria de taggear um L 4
documento

80. User stories
• Devem ser escritas seguindo o padrão:
o Como <ator>, eu gostaria de <ação>, para <motivo>;
• Com os seguintes atributos:
o Tamanho relativo (definido em pontos ou dias/horas ideais);
o Prioridade;
o Condições de satisfação;

81. Exemplo

82. Tech Stories
• Quando necessário, a equipe também pode
definir estórias para o produto;
• Essas estórias devem entrar na priorização pelo
cliente, através de negociação com a equipe;
• Deve ficar claro qual o objetivo da estória e se
outras funcionalidades (ou user stories)
dependem da implementação dela;

83. Frente e verso

84. Detalhes que surgem
• Quando uma User Story cresce demais, ela deve
ser quebrada em casos menores;
• Se conforme as conversas novos casos ou
caminhos são descobertos, os dados novos são
adicionados a estória;
• Estórias grandes demais sempre podem esconder
uma falha na hora de se comunicar com o cliente
ou requisitos incertos;

85. Return of Investment

87. Criando user stories
¢ Formem equipes;
¢ Escolham um cliente;
¢ Escolham um produto a ser definido;
¢ Definam de 10 a 12 user stories;
¢ Priorizem com o cliente
¢ 30 minutos;

89. Release planning
• Fase de exploração – cliente define um conjunto
de necessidades que ele gostaria de ver
implementadas
• Fase de compromisso – equipe avalia e estima uma
data de quando esse release pode ser lançado
pra produção
• Fase de correção – momento onde equipe e
cliente podem ajustar as necessidades

90. Release Planning -­‐‑ 2
• Definição geral do que queremos como produto;
• Definição do tempo/dinheiro disponível para
atingir esse objetivo;
• Montagem das primeiras iterações através das
user stories que já foram definidas;
• Definição do tamanho (em tempo) das iterações;

91. Spike solutions
• Funcionalidades que são incertas demais ou que a
equipe ainda não sabe exatamente como
implementá-las podem ser prototipadas uma
solução “pra jogar fora”;
• Uma spike é uma avaliação feita pra ajudar a
estimativa de uma funcionalidade onde ainda não
há segurança do seu resultado final;
• Spikes devem sempre ser utilizados quando o
problema é desconhecido ou é difícil avaliar o
quão difícil é implementar alguma coisa;

92. Definindo valores

93. Colocando cerâmica na
casa
• Considerando que colocar cerâmica no banheiro
demora 4 horas, quanto tempo demora pra se
colocar cerâmica em todos os outros cômodos da
casa?

94. Estimativas
• O tamanho de uma User Story;
• Influenciado por
o O quanto difícil é a Story;
o Qual o tamanho do trabalho.
• Valor relativo;

95. Estimativas –
Classificando risco
• Dados (o quanto sabemos sobre a necessidade)
o Sabemos tudo (0)
o Sabemos alguma coisa (1)
o Não sabemos nada (2)
• Volatilidade (o quanto essa necessidade pode
mudar)
o Nada (0)
o Pouco (1)
o Muito (2)
• Complexidade (o quanto difícil é implementar)
o Fácil (0)
o Médio (1)
o Difícil (2)

96. Reformem a cozinha do
Mike Cohn
• Reformem a cozinha do Mike Cohn
o Instale um piso novo de madeira
o Pinte os armários
o Instale uma bancada de granito
o Pinte a cozinha inteira
o Substituir o fogão elétrico por um fogão a gás
o Instale uma geladeira nova

97. Velocidade
• Para poder executar um Release Planning, é
necessário ter uma velocidade;
• A velocidade média da equipe pode ser
descoberta através de:
o Média das velocidades anteriores;
o Avaliação da velocidade média por 1 ou 2 sprints;
o Chute;

98. Iteration planning
• As user stories do release planning são agora
transformadas em tarefas e distribuidos entre a
equipe;
• Devem ter ser estimados unitariamente, tarefas
longas demais devem ser quebradas em tarefas
menores;
• Membros da equipe selecionam as tarefas que
desejam trabalhar, a quantidade de trabalho deve
acompanhar a média entre toda a equipe;

99. Iteration Planning
• Definição do que vai ser implementado durante a
iteração;
• Definir o objetivo de alto nível da iteração;
• Caminho geral de como o objetivo vai ser
atingido (design técnico);
• Selecionar o trabalho que vai ser feito nessa
iteração través das user stories;

100. Na hora de
implementar…
• Pegue uma tarefa;
• Selecione um parceiro;
• Escreva o teste;
• Escreva o código que faz o teste passar;
• Execute o teste;
• Refatore o código;
• Execute os testes de aceitação;

101. PRODUTO
ENTREGÁVEL
Production

102. E se as coisas não
estiverem caminhando?
• Se a equipe sente que não tem condições de
entregar o produto;
• Se o mercado mudou abruptamente e isso não
havia sido previsto;
• Se algum desastre aconteceu;
• A iteração pode ser cancelado e um novo
iteration planning deve ser chamado;

103. Stand up meeting
• O que você fez ontem?
• O que você vai fazer hoje?
• Há alguma coisa atrapalhando o seu trabalho?

104. Regras
• Não há discussão, apenas apresentação,
discussões são movidas para DEPOIS;
• Apenas os porcos falam, mas galinhas podem
assistir;
• Deve ser curto, direto e feito com todos os
membros em pé;

105. Iteration Review
• Apresentação geral de o que foi produzido pela
equipe;
• Idealmente, todos devem ser convidados pra isso;
• Esquema de workshop/feira de ciências
normalmente é o melhor para apresentações;

106. Retrospectiva
• O que funcionou durante o sprint?
• O que não funcionou?
• Podemos melhorar? Onde? Como? A que custo?

107. Outras práticas comuns
do XP
• Pair Programming;
• Ritmo sustentável;
• Mover as pessoas dentro do projeto;
• O código pertence a todos;
• Existe um padrão definido sobre como o código
deve ser escrito;