Mtodos geis de Desenvolvimento de Software O caso

Métodos Ágeis de Desenvolvimento de Software O caso de Programação e. Xtrema (XP) Prof. Fabio Kon Departamento de Ciência da Computação IME / USP 3/2001 a 3/2006 Copyleft Fabio Kon 1

Novos ventos no mundo do Desenvolvimento de Software l Sociedade demanda 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 l Mas, infelizmente, l não há gente suficiente para desenvolver tanto software com qualidade. 3/2006 Copyleft Fabio Kon 2

Problemas l Com metodologias de desenvolvimento 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 l Com software Grande quantidade de erros l Falta de flexibilidade l 3/2006 Copyleft Fabio Kon 3

Como resolver esse impasse? l Melhores Tecnologias Padrões de Projeto (reutilização de idéias) l Componentes (reutilização de código) l Middleware (aumenta a abstração) l l Melhores Metodologias Métodos Ágeis (o foco nesta disciplina) l outras. . . (abordadas, p. ex. , na disciplina ES) l 3/2006 Copyleft Fabio Kon 4

Metodologias de Desenvolvimento de Software OO l “Tradicionais” l l l Comunidade de Engenharia de Software IEEE/ACM ICSE p. ex. Carnegie-Mellon SEI RUP, CMM, etc. Ágeis l l Comunidade de POO ACM OOPSLA p. ex. Johnson @ Illinois, Beck, Cockburn, Jeffries, Cunningham… XP, Crystal, Scrum, etc. 3/2006 Copyleft Fabio Kon 5

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

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

Princípios do Manifesto Ágil l Objetivo: satisfazer o cliente entregando, rapidamente e com freqüência, sistemas com algum valor. l Entregar versões funcionais em prazos curtos. l Estar preparado para requisitos mutantes. l Pessoal de negócios e desenvolvedores juntos. l Troca de informações através de conversas diretas. 3/2006 Copyleft Fabio Kon 8

Principais Métodos Ágeis l Neste projeto nos concentraremos em : l l Programação e. Xtrema (XP) Outros métodos ágeis interessantes: Crystal (uma família de métodos) l Scrum l Adaptive Software Development l Feature Driven Development l etc. l 3/2006 Copyleft Fabio Kon 9

A família Crystal de Métodos Criada por Alistair Cockburn l http: //alistair. cockburn. us/crystal l Editor da série Agile Software Development da Addison-Wesley. l 3/2006 Copyleft Fabio Kon 10

Classificação de Projetos de Desenvolvimento de Software. . . Prioridade para responsabilidade legal Criticalidade (defeitos causam perdas de. . . ) Prioridade para Produtividade & Tolerância Life (L) L 6 L 20 L 40 L 100 L 200 L 500 L 1000 Essential money (E) E 6 E 20 E 40 E 100 E 200 E 500 E 1000 Discretionary money D 6 (D) D 20 D 40 D 100 D 200 D 500 D 1000 C 20 C 40 C 100 C 200 C 500 C 1000 Comfort (C) C 6 1 -6 - 20 - 40 - 100 Número de pessoas 3/2006 Copyleft Fabio Kon - 200 - 500 - 1, 000 envolvidas +20% 11

Escopo da Família Crystal L 6 L 40 L 80 E 6 E 20 E 40 E 80 D 6 D 20 D 40 D 80 C 6 C 20 C 40 C 80 Clear 3/2006 L 20 Yellow Orange Copyleft Fabio Kon Red 12

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

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. 3/2006 Copyleft Fabio Kon 14

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

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

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. 3/2006 Copyleft Fabio Kon 17

Scrum l Jeff Suttherland l l Ken Schwaber l l http: //www. controlchaos. com Conferências l l http: //jeffsutherland. com OOPSLA 96, PLo. P 98 Inspiração l Desenvolvimento Iterativo e Incremental em empresas (Du. Pont, Honda, etc) nos anos 80 3/2006 Copyleft Fabio Kon 18

Programação e. Xtrema XP l Metodologia de desenvolvimento de software aperfeiçoada nos últimos 5 anos. l Ganhou notoriedade a partir da OOPSLA’ 2000. l Nome principal: Kent Beck. 3/2006 Copyleft Fabio Kon 19

Reações a XP l Alguns odeiam, outros amam. 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. l 3/2006 Copyleft Fabio Kon 20

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 3/2006 Copyleft Fabio Kon 21

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. 3/2006 Copyleft Fabio Kon 22

Custo de mudanças O que está por trás deste modelo? requisitos desenho testes análise implementação produção 3/2006 Copyleft Fabio Kon 23

Custo de mudanças E se a realidade hoje em dia fosse outra? tempo 3/2006 Copyleft Fabio Kon 24

E se essa fosse a realidade? l A atitude dos desenvolvedores de software seria completamente diferente: 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). l 3/2006 Copyleft Fabio Kon 25

E essa é a nova realidade ! (pelo menos em muitos casos) 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. l 3/2006 Copyleft Fabio Kon 26

A Quem se Destina XP? Grupos de 2 a 10 programadores l Projetos de 1 a 36 meses (calendário) l De 1000 a 250 000 linhas de código l Papéis: l Programadores (foco central)(sem hierarquia) l “Treinador” ou “Técnico” (coach) l “Acompanhador” (tracker) l Cliente l 3/2006 Copyleft Fabio Kon 27

E Se Eu Não Me Encaixo Nesses Casos? 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 l l “Ou você é 100% e. Xtremo ou não é e. Xtremo. Não dá prá ser 80% XP. ” l XP is like teenage sex. Hoje não é mais necessariamente assim. 3/2006 Copyleft Fabio Kon 28

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

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 do código 3/2006 Copyleft Fabio Kon 30

As 4 Variáveis do Desenvolvimento de Software • Tempo • Custo • Qualidade • Escopo (foco principal de XP) 3/2006 Copyleft Fabio Kon 31

Um Projeto XP l Fase de Exploração duração: 2 a 6 meses. 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. l 3/2006 Copyleft Fabio Kon 32

Um Dia na Vida de um Programador XP Escolhe uma história do cliente. l Procura um par livre. l Escolhe um computador para programação pareada. l Seleciona um “cartão de história” contendo uma tarefa claramente relacionada a uma característica (feature) desejada pelo cliente. l 3/2006 Copyleft Fabio Kon 33

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 Projeto (design) l Integração 3/2006 Copyleft Fabio Kon 34

Um Dia na Vida de um Programador XP l Atos constantes no desenvolvimento: 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. l 3/2006 Copyleft Fabio Kon 35

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

Testes l Testes das unidades do sistema Tem que estar sempre funcionando a 100%. l São executados várias vezes por dia. l Executados à noite automaticamente. l l Testes das funcionalidades Vão crescendo de 0% a 100%. l Quando chegam a 100% acabou o projeto. l 3/2006 Copyleft Fabio Kon 37

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

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

Propriedade Coletiva do Código 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! l 3/2006 Copyleft Fabio Kon 40

Refatoração (Refactoring) Uma [pequena] modificação no sistema que não altera o seu comportamento funcional l mas que melhora alguma qualidade nãofuncional: l simplicidade l flexibilidade l clareza l desempenho l 3/2006 Copyleft Fabio Kon 41

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 • raiz. Quadrada(float x) raiz(float x, int n) 3/2006 Copyleft Fabio Kon 42

Cliente 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). l 3/2006 Copyleft Fabio Kon 43

Coach (treinador) 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. l 3/2006 Copyleft Fabio Kon 44

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

Quando XP Não Deve Ser Experimentada? 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. l 3/2006 Copyleft Fabio Kon 46

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

Conclusão Vencendo os Medos 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. l 3/2006 Copyleft Fabio Kon 48

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

Práticas de XP l l l As práticas foram refatoradas (veja www. extremeprogramming. org/rules. html) Mas a idéia é exatamente a mesma Novas práticas interessantes: • Conserte XP quando a metodologia quebrar. • Mova as pessoas. • Client Proxy (by Klaus) 3/2006 Copyleft Fabio Kon 50

Conclusão l XP não é para todo mundo. l Mas todo mundo pode aprender com ela. 3/2006 Copyleft Fabio Kon 51

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

Nas próximas aulas… 1. 2. 3. Refatoração Testes Planejamento ágil l l 3/2006 teoria prática Copyleft Fabio Kon 53

Maiores Informações No IME: agilcoop. incubadora. fapesp. br/portal/agilcast www. ime. usp. br/~xp Fora do IME: www. agilealliance. org www. xispe. com. br www. extremeprogramming. org 3/2006 Copyleft Fabio Kon 54