• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Extreme programming
 

Extreme programming

on

  • 645 views

 

Statistics

Views

Total Views
645
Views on SlideShare
643
Embed Views
2

Actions

Likes
1
Downloads
13
Comments
0

1 Embed 2

http://coderwall.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike LicenseCC Attribution-NonCommercial-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Extreme programming Extreme programming Presentation Transcript

    • 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 encontradapor 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 dasmetodologias ágeis no geral) tem como base osavanços da gestão industrial capitaneada pelaToyota 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
    • ÀGILIteração  1 Iteração  2 Iteração  3
    • Cada  iteração Testes Análise Implantação Design Desenvolvimento
    • Planos  VS  Valor Waterfall ÁgilO que é fixo Funcionalidades Tempo, CustoO 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! 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 eComo usuário eu gostaria de criar uma conta H 4Como usuário eu gostaria de enviar um H 8documentoComo usuário eu gostaria de visualizar um H 5documentoComo usuário eu gostaria de buscar H 10documentos pelo texto delesComo usuário eu gostaria de criar pastas para M 3os documentosComo usuário eu gostaria de poder mover um M 3documento para uma pastaComo usuário eu gostaria de taggear um L 4documento
    • 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;
    • PRODUTOENTREGÁ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;