Extreme programming

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

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.

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.

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.

Os dois tipos de processo
•  Processos definidos

•  Processos empíricos

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;

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;

Usar processos definidos em casos
empíricos causa:
•  Surpresas desagradáveis;

•  Perda de controle do processo;

•  Produtos incompletos ou completamente errados;

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;

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;

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

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

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;

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

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

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

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

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;

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;

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;

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;

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?

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?

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;

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

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;

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

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?

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

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

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;

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;

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?

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”

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?”

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

Extreme Programming
O que é isso?

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;

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…);

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;

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;

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?

... 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;

Waterfall
Análise

Design

Desenvolvimento

Teste

Implantação

ÀGIL
Iteração 1

Iteração 2

Iteração 3

Cada iteração
Testes
Análise

Implantação
Design

Desenvolvimento

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

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;

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;

Os princípios do XP

•  Feeback;

•  Sempre assuma a simplicidade;

•  Abraçe a mudança;

As atividades do XP
•  Codificação;

•  Testes;

•  Ouvir;

•  Design;

Codiﬁcaçã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;

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;

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;

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;

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;

Valores do XP
•  Comunicação

•  Simplicidade

•  Feedback

•  Coragem

•  Respeito

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;

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;

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;

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;

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;

Quais os papéis no XP?
•  Gerente;

•  Cliente;

•  Equipe;

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;

Bons gerentes são...
•  Líderes;

•  Facilitadores;

•  Comunicadores;

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;

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);

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;

O que o cliente queria?

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);

Quem pode meter o
bedelho na coisa?

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!

Mãos a obra!
Release
Visão
Preparação
Planning

Iteration
Produto
Iteração
Planning

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;

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

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;

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;

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;

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;

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

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;

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;

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?

Estimativas
•  O tamanho de uma User Story;

•  Influenciado por
o  O quanto difícil é a Story;
o  Qual o tamanho do trabalho.

•  Valor relativo;

Estimativas –
Classiﬁcando 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)

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

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;

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;

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;

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;

PRODUTO
ENTREGÁVEL

Production

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;

Stand up meeting
•  O que você fez ontem?

•  O que você vai fazer hoje?

•  Há alguma coisa atrapalhando o seu trabalho?

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é;

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;

Retrospectiva
•  O que funcionou durante o sprint?

•  O que não funcionou?

•  Podemos melhorar? Onde? Como? A que custo?

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;

Extreme programming

Mais conteúdo relacionado

Mais procurados (20)

Destaque (9)

Semelhante a Extreme programming (20)

Mais de Maurício Linhares (20)

Último (19)

Extreme programming