Extreme programming
-
Upload
mauricio-linhares -
Category
Technology
-
view
510 -
download
0
Transcript of 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
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;