A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Copyleft by Fabio Kon & Alfredo Goldman1 Métodos Ágeis e Programação eXtrema Desenvolvendo Software com Qualidade e Agilidade Prof. Dr. Fabio Kon Prof.

Apresentações semelhantes


Apresentação em tema: "Copyleft by Fabio Kon & Alfredo Goldman1 Métodos Ágeis e Programação eXtrema Desenvolvendo Software com Qualidade e Agilidade Prof. Dr. Fabio Kon Prof."— Transcrição da apresentação:

1 Copyleft by Fabio Kon & Alfredo Goldman1 Métodos Ágeis e Programação eXtrema Desenvolvendo Software com Qualidade e Agilidade Prof. Dr. Fabio Kon Prof. Dr. Alfredo Goldman Departamento de Ciência da Computação IME / USP Simpósio Brasileiro de Engenharia de Software Manaus - outubro 2003

2 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman2 / 83 Novos ventos no mundo do desenvolvimento de software l Sociedade demanda l grande quantidade de sistemas/aplicações l software complexo, sistemas distribuídos, heterogêneos l requisitos mutantes (todo ano, todo mês, todo dia) l Mas, infelizmente, l não há gente suficiente para desenvolver tanto software com qualidade.

3 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman3 / 83 Problemas l Com metodologias de desenvolvimento l Supõem que é possível prever o futuro l Pouca interação com os clientes l Ênfase em burocracias (documentos, formulários, processos, controles rígidos, etc.) l Avaliação do progresso baseado na evolução da burocracia e não do código l Com software l Grande quantidade de erros l Falta de flexibilidade

4 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman4 / 83 Como resolver esse impasse? l Melhores Tecnologias l Componentes (melhoram a reutilização) l Middleware (aumenta a abstração) l Melhores Metodologias l Métodos Ágeis (foco deste mini-curso) l outras... (não abordadas aqui)

5 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman5 / 83 O que é desenvolvimento de software (A. Cookburn)?

6 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman6 / 83 Processo Reprodutível ??? l Pode existir um processo pré-definido? l Alguns pensam que além de possível isto é necessário! l Abordagem CMM l 5 níveis (inicial, sistematizado, definido, gerencial e otimizado) l Os processos-chave são definidos em seguida

7 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman7 / 83 Processo Reprodutível ??? (extraído de artigo da PLoP98) l Suposições para sistematizado/definido l Problema. fase para definição de requisitos l Podem não ser bem definidos, ou mudar l Solução. Especificação completa da arquitetura l Além do problema acima, envolve processo criativo l Desenvolvedores. l São humanos (logo, diferentes) l Ambiente. l Pressão de cronograma, prioridades e clientes mudam

8 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman8 / 83 Métodos Ágeis l Movimento iniciado por programadores experientes e consultores em desenvolvimento de software. l Questionam e se opõe a uma série de mitos/práticas adotadas em abordagens tradicionais de Engenharia de Software e Gerência de Projetos. l Manifesto Ágil: Assinado por 17 desenvolvedores em Utah em fevereiro/2001.

9 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman9 / 83 O Manifesto do Desenvolvimento Ágil de Software 1. Indivíduos e interações são mais importantes que processos e ferramentas. 2. Software funcionando é mais importante do que documentação completa e detalhada. 3. Colaboração com o cliente é mais importante do que negociação de contratos. 4. Adaptação a mudanças é mais importante do que seguir o plano inicial.

10 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman10 / 83 Princípios do Manifesto Ágil l Maior prioridade: satisfazer o cliente entregando, antes e sempre sistemas com valor. l Estar preparado para requisitos mutantes. O quê fornece uma vantagem competitiva. l Entregar versões funcionais em prazos curtos. l Pessoal de negócios e desenvolvedores juntos. l Construir projetos com indivíduos motivados, dando um ambiente de trabalho e confiando neles. l Troca de informações através de conversas diretas.

11 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman11 / 83 Princípios do Manifesto Ágil l Medir progresso através de software funcionando. l Desenvolvimento sustentável. l Cuidados com o nível técnico e bom desenho. l Simplicidade é essencial. l As melhores arquiteturas, requisitos e desenho aparecem de equipes que se auto organizam. l De tempos em tempos, o time pensa em como se tornar mais efetivo, e ajusta o seu comportamento de acordo.

12 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman12 / 83 Uma Boa Metáfora para Desenvolvimento de Software l Um jogo Cooperativo de Invenção e Comunicação. Alistair Cockburn. l Como um grupo de pessoas escalando uma montanha em conjunto. l Jogo cooperativo, finito, onde se busca alcançar um objetivo.

13 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman13 / 83 Dois Objetivos Principais do Desenvolvimento de Software 1. Entregar software que funcione. 2. Preparar o terreno para o próximo projeto.

14 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman14 / 83 Epifanias Ágeis l O gerente de projeto concorda em prosseguir sem que todos os requisitos estejam bem definidos. l Os desenvolvedores concordam em prosseguir sem ter todos os requisitos documentados. l O gerente de projeto vê uma novas funcionalidades a cada nova versão, e percebe que o sua participação foi importante com resultados visíveis. Também percebe que o projeto terá sucesso e será útil.

15 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman15 / 83 Mais Epifanias Ágeis l Os membros da equipe sabem que alguém vai ajudar quando ocorrerem problemas. l O gerente de TI sente o trabalho de equipe nas áreas de trabalho. l Os gerentes percebem que não precisam dizer a equipe o que fazer, ou garantir o que vai ser feito. l A equipe percebe que ninguém vai dizer o quê fazer, isto faz parte do trabalho da equipe. l Não existem mais a impressão de divisão (testers and programmers), todos são desenvolvedores.

16 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman16 / 83 Principais Métodos Ágeis l Daremos uma visão geral l Crystal (uma família de métodos) l Scrum l Abordaremos mais detalhadamente l Programação eXtrema (XP) l Não abordaremos l Adaptive Software Development l Feature Driven Development, etc.

17 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman17 / 83 A família Crystal de Métodos l Criada por Alistair Cockburn l l Editor da série Agile Software Development da Addison-Wesley.

18 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman18 / 83 Pequeno histórico l Foi contratado em 1990 pela IBM l documentar a metodologia de desenvolvimento l optou por entrevistar as diversas equipes l Resultado: l Pedidos de desculpa por não utilizar ferramentas l e entregar software funcionando l Explicações sobre como metodologias foram seguidas a risca l e o projeto falhou

19 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman19 / 83 Conclusões (resumo) l Pode-se trocar documentação escrita por conversas face a face l Quanto mais se entrega software funcionando e testado, menos depende-se da documentação escrita (promissórias)

20 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman20 / 83 Classificação de Projetos de Desenvolvimento de Software Número de pessoas envolvidas Criticalidade (defeitos causam perdas de...) Comfort (C) Essential money (E) Life (L) +20%... Prioridade para responsabilidade legal ,000 C6C20C40C100C200C500C1000 D6D20D40D100D200D500D1000 E6E20E40E100E200E500E1000 L6L20L40L100L200L500L1000 Prioridade para Produtividade & Tolerância Discretionary money (D)

21 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman21 / 83 Escopo da Família Crystal Red C6C20 C40 C80 D6D20D40 D80 E6E20E40 E80 Clear Yellow Orange L6L20L40 L80

22 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman22 / 83 Principais Características da Família Crystal l Filosofia básica: l ênfase em comunicação l leve nos produtos gerados (evitar peso morto) l Princípios: l Precisamos de menos produtos intermediários se possuímos: 1. canais de comunicação informal ricos e rápidos 2. entrega freqüente de código funcionando 3. uso dos pontos fortes das pessoas (conversas, olhar a sua volta, interagir com outros) 4. estar ciente dos pontos fracos das pessoas (baixa disciplina, falta de cuidado)

23 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman23 / 83 Políticas Clear e Orange l Desenvolvimento incremental l com freqüência regular l Acompanhamento com marcos l início, revisão 1, revisão 2, teste, entrega l Envolvimento direto do usuário l Testes de regressão de funcionalidades automáticos l Duas/três visões de usuários por versão l Workshops para ajustes no produto e na metodologia no início e meio de cada incremento

24 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman24 / 83 Adaptação da Metodologia l Em cada caso, escolha a metodologia mais leve possível que pode fazer o que você precisa. l Quanto maior o projeto (número de pessoas), maior burocracia será necessária e pior será a produtividade. l Reflection Workshops ao final de cada fase.

25 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman25 / 83 Oficinas de Reflexão (Reflection Workshops) l Perguntas: l O que aprendemos na última fase (p.ex. mês)? l O que podemos fazer de uma forma melhor? l Resultado: l pôster Tentar testes automatizados multas para interrupções escrita pareada de testes Manter reuniões com cliente programação pareada Problemas muitas interrupções erros no código entregue

26 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman26 / 83 Mais perguntas na reflexão l O quê fizemos de bom e de ruim ? l Quais são as nossas prioridades l O quê mantivemos de mais importante l O quê podemos mudar para a próxima vez ? l O quê podemos adicionar/tirar ? l Após 2 ou 3 versões incrementais, a metodologia deve começar a convergir para uma metodologia tolerável para o projeto.

27 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman27 / 83 Scrum Definição informal: Estratégia em um jogo de rugby onde jogadores colocam uma bola quase perdida novamente em jogo através de trabalho em equipe.

28 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman28 / 83 Origens de Scrum l Jeff Suttherland l l Ken Schwaber l l Conferências l OOPSLA 96, PLoP 98 l Inspiração l Desenvolvimento Iterativo e Incremental em empresas (DuPont, Honda, etc) nos anos 80

29 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman29 / 83 Fundamentos de Scrum 1/2 l Desenvolvimento de software a partir de padrões de projeto (design patterns) l Mas, o que é isto ???

30 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman30 / 83 O quê são padrões ? l No final dos anos 70, o arquiteto Christopher Alexander escreveu dois livros com a idéia. l Cada padrão descreve um problema recorrente no nosso ambiente e, em seguida, o princípio de sua solução. l A solução pode ser aplicada diversas vezes, nunca da mesma maneira. l Um exemplo: escritório com janela.

31 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman31 / 83 Fundamentos de Scrum l Desenvolvimento de software depende muito de criatividade e de trabalho l Logo, não é um bom candidato a processos pré-definidos l modelo de controle de processo empírico l O desenvolvimento nem sempre será repetitivo e bem definido l Mas existem padrões que podem ser usados

32 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman32 / 83 Ênfases l Comunicação l Trabalho em equipe l Flexibilidade l Fornecer Software funcionando l incrementalmente

33 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman33 / 83 Principais Padrões em Scrum l Backlog l Equipes l Sprints l Encontros Scrum l Revisões Scrum/Demos

34 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman34 / 83 Backlog l Lista de todas as funcionalidades desejadas l É gerada incrementalmente l Começa pelo básico, o extra aparece com o tempo l Pode conter l Tarefas diretas, casos de uso e histórias (a la XP) l A lista é priorizada pelo Dono do projeto l Cliente, depto de marketing,...

35 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman35 / 83 O Backlog inicial l Deve conter características que agreguem algum valor de negócio ao produto. l Novos requisitos aparecem quando o cliente vê o produto. l A arquitetura do sistema surge enquanto o projeto surge e é refatorado.

36 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman36 / 83 Equipes l Sem nível hierárquico nem papéis l Mas com várias especialidades l Estão todos no mesmo barco l Geralmente equipes pequenas (até 10) l Existem casos com equipes maiores (800 !) l Usa-se também Scrum hierárquico l Comunicação é essencial l Encontro Scrum diário

37 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman37 / 83 Sprint l Unidades básicas de tempo (até 30 dias) l Começa com um encontro Sprint l Tarefas do Backlog são priorizadas l A equipe seleciona tarefas que podem ser completadas durante o próximo Sprint l As mesmas podem ser quebradas para o Backlog do Sprint l Cada tarefa recebe um responsável na equipe l Não há mudança nas tarefas durante o Sprint

38 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman38 / 83 Encontro Scrum 1/2 l Pequenos encontros diários da equipe l geralmente pela manhã l galinhas e porcos (só os porcos falam) l todos os porcos devem participar l Questões que aparecem devem ser resolvidas durante o dia e não na reunião l Os encontros iniciais são geralmente mais longos

39 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman39 / 83 Encontro Scrum 2/2 l Questões que devem ser respondida por cada porco: l 1) O quê você fez ontem? l 2) O quê você vai fazer hoje? l 3) Quais os problemas encontrados? l Ajuda a manter as promessas l Evita: Como um projeto atrasa um ano? l Um dia por vez... l Qualquer deslize pode ser corrigido de imediato

40 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman40 / 83 Local do encontro l Sempre o mesmo local e hora l Pode ser o local de desenvolvimento l Pessoas sentadas ao redor de uma mesa l A sala já deve estar arrumada antes l Punições (atrasos/faltas) l Todos devem participar l Galinhas ficam na periferia l Pode ser em pé l Sala bem equipada, quadro branco, etc.

41 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman41 / 83 Revisão do Sprint l No final de cada Sprint é feita uma reunião com todos os interessados l Geralmente l Na forma de demonstração l Informal (preparação rápida, sem projetor,..) l Deve ser o resultado natural de um Sprint l O projeto é comparado com os objetivos iniciais do Sprint

42 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman42 / 83 Scrum Master 1/2 l Faz com que a equipe viva os valores e práticas de Scrum l Protege a equipe de: l Riscos e interferências externos l Excesso de otimismo l Resolve os problemas que aparecerem l logísticos l de conhecimento/habilidade

43 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman43 / 83 Scrum Master 2/2 l Mantém o Backlog do Sprint l Tarefas completadas l Identifica eventuais problemas l Mantém um gráfico de quanto falta

44 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman44 / 83 Scrum (de forma gráfica)

45 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman45 / 83 Scrum final l Um último Sprint para fechar o produto l O objetivo é: l Preparar a versão de produção l O foco é a eliminação de erros l Não faz parte do Scrum padrão l Mas é bem usado na prática

46 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman46 / 83 Programação eXtrema XP l Metodologia de desenvolvimento de software aperfeiçoada nos últimos 5 anos. l Ganhou notoriedade a partir da OOPSLA2000. l Nome principal: Kent Beck.

47 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman47 / 83 Reações a XP l Alguns odeiam, outros amam. l Quem gosta de programar ama! l Deixa o bom programador livre para fazer o que ele faria se não houvesse regras. l Força o [mau] programador a se comportar de uma forma similar ao bom programador.

48 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman48 / 83 Modelo Tradicional de Desenvolvimento de Software 0. Levantamento de Requisitos 1. Análise de Requisitos 2. Desenho da Arquitetura 3. Implementação 4. Testes 5. Produção / Manutenção

49 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman49 / 83 Premissas Básicas do Modelo Tradicional l É necessário fazer uma análise de requisitos profunda e detalhada antes de projetar a arquitetura do sistema. l É necessário fazer um estudo minucioso e elaborar uma descrição detalhada da arquitetura antes de começar a implementá-la. l É necessário testar o sistema completamente antes de mandar a versão final para o cliente.

50 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman50 / 83 O que está por trás deste modelo? Custo de mudanças requisitos desenho testes análise implementação produção

51 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman51 / 83 E se a realidade hoje em dia fosse outra? Custo de mudanças tempo

52 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman52 / 83 E se essa fosse a realidade? l A atitude dos desenvolvedores de software seria completamente diferente: l Tomaríamos as grandes decisões o mais tarde possível. l Implementaríamos agora somente o que precisamos agora. l Não implementaríamos flexibilidade desnecessária (não anteciparíamos necessidades).

53 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman53 / 83 E essa é a nova realidade ! (pelo menos em muitos casos) l Orientação a Objetos: facilita e cria oportunidades para mudanças. l Técnicas de Refatoração. l Testes automatizados: nos dão segurança quando fazemos mudanças. l Prática / cultura de mudanças: aprendemos técnicas e adquirimos experiência em lidar com código mutante.

54 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman54 / 83 A Quem se Destina XP? l Grupos de 2 a 10 programadores l Projetos de 1 a 36 meses (calendário) l De 1000 a linhas de código l Papéis: l Programadores (foco central)(sem hierarquia) l Treinador ou Técnico (coach) l Acompanhador (tracker) l Cliente

55 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman55 / 83 E Se Eu Não Me Encaixo Nesses Casos? l Você ainda pode aprender muito sobre desenvolvimento de software. l Terá elementos para repensar as suas práticas. l No início se dizia: l Ou você é 100% eXtremo ou não é eXtremo. Não dá prá ser 80% XP. l XP is now like teenage sex. l Hoje não é mais necessariamente assim.

56 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman56 / 83 As 12 Práticas de XP (versão 2000) 1.Planejamento 2.Fases Pequenas 3.Metáfora 4.Design Simples 5.Testes 6.Refatoramento 7.Programação Pareada 8.Propriedade Coletiva 9.Integração Contínua 10.Semana de 40 horas 11.Cliente junto aos desenvolvedores 12.Padronização do código

57 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman57 / 83 Princípios Básicos de XP l Feedback rápido l Simplicidade é o melhor negócio l Mudanças incrementais l Carregue a bandeira das mudanças / não valorize o medo (Embrace change) l Alta qualidade

58 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman58 / 83 As 4 Variáveis do Desenvolvimento de Software Tempo Custo Qualidade Escopo (foco principal de XP)

59 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman59 / 83 Um Projeto XP l Fase de Exploração l duração: até 20% do tempo total. l termina quando a primeira versão do software é enviada ao cliente. l clientes escrevem historias (story cards). l programadores interagem com clientes e discutem tecnologias. l Não só discutem, experimentam diferentes tecnologias e arquiteturas para o sistema. l Planejamento: 1 a 2 dias.

60 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman60 / 83 Histórias X casos de uso l Caso de uso: Autenticação caixa automático l Ator: Cliente l Descrição: Após inserir o cartão o sistema solicita a senha. O sistema verifica se o cartão é válido e se a senha confere. Se não o usuário tem mais três chances... l Várias historinhas l O sistema mostra telas de boas vindas l O sistema verifica se o cartão é válido l Implementar sistema de leitura de senha l Verificação de senha l Releitura de senha se a mesma não confere l...

61 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman61 / 83 Um Dia na Vida de um Programador XP l Escolhe uma história do cliente. l Procura um par livre. l Escolhe um computador para programação pareada (pair programming). l Seleciona uma tarefa claramente relacionada a uma característica (feature) desejada pelo cliente.

62 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman62 / 83 Um Dia na Vida de um Programador XP l Discute modificações recentes no sistema l Discute história do cliente l Testes l Implementação l Desenho l Integração

63 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman63 / 83 Um Dia na Vida de um Programador XP l Atos constantes no desenvolvimento: l Executa testes antigos. l Busca oportunidades para simplificação. l Modifica desenho e implementação incrementalmente baseado na funcionalidade exigida no momento. l Escreve novos testes. l Enquanto todos os testes não rodam a 100%, o trabalho não está terminado. l Integra novo código ao repositório.

64 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman64 / 83 Testes l Fundamento mais importante de XP. l É o que dá segurança e coragem ao grupo. l Testes de unidades (Unit tests) l escritos pelos programadores para testar cada elemento do sistema (e.g., cada método em cada caso). l Testes de funcionalidades (Functional tests) l escritos pelos clientes para testar a funcionalidade do sistema.

65 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman65 / 83 Testes l Testes das unidades do sistema l Tem que estar sempre funcionando a 100%. l São executados várias vezes por dia. l Executados à noite automaticamente. l Testes das funcionalidades l Vão crescendo de 0% a 100%. l Quando chegam a 100% acabou o projeto.

66 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman66 / 83 O Código l Padrões de estilo adotados pelo grupo inteiro. l O mais claro possível. l XP não se baseia em documentações detalhadas e extensas (perde-se sincronia). l Comentários sempre que necessários. l Comentários padronizados. l Programação Pareada ajuda muito!

67 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman67 / 83 Programação Pareada l Erro de um detectado imediatamente pelo outro (grande economia de tempo). l Maior diversidade de idéias, técnicas, algoritmos. l Enquanto um escreve, o outro pensa em contra- exemplos, problemas de eficiência, etc. l Vergonha de escrever código feio (gambiarras) na frente do seu par. l Pareamento de acordo com especialidades. Ex.: Sistema Multimídia Orientado a Objetos

68 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman68 / 83 Propriedade Coletiva do Código l Modelo tradicional: só autor de uma função pode modificá-la. l XP: o código pertence a todos. l Se alguém identifica uma oportunidade para simplificar, consertar ou melhorar código escrito por outra pessoa, que o faça. l Mas rode os testes!

69 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman69 / 83 Refatoração (Refactoring) l Uma [pequena] modificação no sistema que não altera o seu comportamento funcional l mas que melhora alguma qualidade não- funcional: l simplicidade l flexibilidade l clareza l desempenho

70 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman70 / 83 Exemplos de Refatoração l Mudança do nome de variáveis l Mudanças nas interfaces dos objetos l Pequenas mudanças arquiteturais l Encapsular código repetido em um novo método l Generalização de métodos raizQuadrada(float x) raiz(float x, int n)

71 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman71 / 83 Sobre Refatoração l Catálogo de Refatorações de Martin Fowler: l Refactoring: Improvng the Design of Existing Code. Addison-Wesley, l Ferramentas para refatoração automatizada embutidas no Eclipse, Smalltalk Browser, Emacs, etc., etc. l

72 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman72 / 83 Cliente l Responsável por escrever histórias. l Muitas vezes é um programador ou é representado por um programador do grupo. l Trabalha no mesmo espaço físico do grupo. l Novas versões são enviadas para produção todo mês (ou toda semana). l Feedback do cliente é essencial. l Requisitos mudam (e isso não é mau).

73 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman73 / 83 Coach (treinador) l Em geral, o mais experiente do grupo. l Identifica quem é bom no que. l Lembra a todos as regras do jogo (XP). l Eventualmente faz programação pareada. l Não desenha arquitetura, apenas chama a atenção para oportunidades de melhorias. l Seu papel diminui à medida em que o time fica mais maduro.

74 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman74 / 83 Tracker (Acompanhador) l A consciência do time. l Coleta estatísticas sobre o andamento do projeto. Alguns exemplos: Número de histórias definidas e implementadas. Número de unit tests. Número de testes funcionais definidos e funcionando. Número de classes, métodos, linhas de código l Mantém histórico do progresso. l Faz estimativas para o futuro.

75 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman75 / 83 Quando XP Não Deve Ser Experimentada? l Quando o cliente não aceita as regras do jogo. l Quando o cliente quer uma especificação detalhada do sistema antes de começar. l Quando os programadores não estão dispostos a seguir (todas) as regras. l Se (quase) todos os programadores do time são medíocres.

76 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman76 / 83 Quando XP Não Deve Ser Experimentada? l Grupos grandes (>10 programadores). l Quando feedback rápido não é possível: l sistema demora 6h para compilar. l testes demoram 12h para rodar. l exigência de certificação que demora meses. l Quando o custo de mudanças é essencialmente exponencial. l Quando não é possível realizar testes (muito raro).

77 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman77 / 83 Conclusão Vencendo os Medos l Escrever código. l Mudar de idéia. l Ir em frente sem saber tudo sobre o futuro. l Confiar em outras pessoas. l Mudar a arquitetura de um sistema em funcionamento. l Escrever testes.

78 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman78 / 83 As 12 Práticas de XP (versão 2000) 1.Planejamento 2.Fases Pequenas 3.Metáfora 4.Design Simples 5.Testes 6.Refatoramento 7.Programação Pareada 8.Propriedade Coletiva 9.Integração Contínua 10.Semana de 40 horas 11.Cliente junto aos desenvolvedores 12.Padronização do código

79 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman79 / 83 Práticas de XP l As práticas foram refatoradas (veja l Mas a idéia é exatamente a mesma l Novas práticas interessantes: Conserte XP quando a metodologia quebrar. Mova as pessoas. Client Proxy (by Klaus) Líbero (by Klaus)

80 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman80 / 83 Conclusão de XP l XP não é para todo mundo. l Mas todo mundo pode aprender com ela.

81 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman81 / 83 l Aplicando XP com Scrum l Scrum: método de gerenciamento l XP: conjunto de práticas l Vantagens l Objetivos por Sprint e não por história l Escalabilidade l Fácil implementação

82 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman82 / 83 Características Comuns dos Métodos Ágeis l Coloca o foco l Na entrega freqüente de sub-versões do software funcionando para o cliente. l Nos seres humanos que desenvolvem o software. l Retira o foco de l Processos rígidos e burocratizados. l Documentações e contratos detalhados. l Ferramentas que são usadas pelos seres humanos.

83 Outubro de 2003 Copyleft by Fabio Kon & Alfredo Goldman83 / 83 Maiores Informações Prof. Dr. Fabio Kon Prof. Dr. Alfredo Goldman


Carregar ppt "Copyleft by Fabio Kon & Alfredo Goldman1 Métodos Ágeis e Programação eXtrema Desenvolvendo Software com Qualidade e Agilidade Prof. Dr. Fabio Kon Prof."

Apresentações semelhantes


Anúncios Google