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

Onde?

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

Implantação

Teste

Desenvolvimento

Design

Análise

ÀGIL Iteração  1

Iteração  2

Iteração  3

Cada  iteração Análise

Design

Desenvolvimento

Implantação

Testes

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;

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;

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;

COMUNICAÇÃO

O  que  o  cliente  queria?

O  que  foi  entregue?

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! Visão Preparação Release  

Planning

Iteration  Planning Iteração Produto

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

ty Estimate

Como usuário eu gostaria de criar uma conta H 4

Como usuário eu gostaria de enviar um documento

H 8

Como usuário eu gostaria de visualizar um documento

H 5

Como usuário eu gostaria de buscar documentos pelo texto deles

H 10

Como usuário eu gostaria de criar pastas para os documentos

M 3

Como usuário eu gostaria de poder mover um documento para uma pasta

M 3

Como usuário eu gostaria de taggear um documento

L 4

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;

Exemplo

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;

Frente  e  verso

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;

Return  of  Investment

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;

Definindo  valores

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

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;

AO FIM DO SPRINT – 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;