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

3/2006 Copyleft Fabio Kon2 / 54 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/2006 Copyleft Fabio Kon3 / 54 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

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

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

3/2006 Copyleft Fabio Kon6 / 54 Métodos Ágeis de Desenvolvimento de Software l Movimento iniciado por programadores experientes e consultores em desenvolvimento de software. l 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. l Manifesto Ágil: Assinado por 17 desenvolvedores em Utah em fevereiro/2001.

3/2006 Copyleft Fabio Kon7 / 54 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.

3/2006 Copyleft Fabio Kon8 / 54 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 Kon9 / 54 Principais Métodos Ágeis l Neste projeto nos concentraremos em : l Programação eXtrema (XP) l Outros métodos ágeis interessantes: l Crystal (uma família de métodos) l Scrum l Adaptive Software Development l Feature Driven Development l etc.

3/2006 Copyleft Fabio Kon10 / 54 A família Crystal de Métodos l Criada por Alistair Cockburn l l Editor da série Agile Software Development da Addison-Wesley.

3/2006 Copyleft Fabio Kon11 / 54 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)

3/2006 Copyleft Fabio Kon12 / 54 Escopo da Família Crystal Red C6C20 C40 C80 D6D20D40 D80 E6E20E40 E80 Clear Yellow Orange L6L20L40 L80

3/2006 Copyleft Fabio Kon13 / 54 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)

3/2006 Copyleft Fabio Kon14 / 54 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 Kon15 / 54 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

3/2006 Copyleft Fabio Kon16 / 54 Mais perguntas na reflexão l O que fizemos de bom e de ruim? l Quais são as nossas prioridades? l O que mantivemos de mais importante? l O que podemos mudar para a próxima vez? l O que 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.

3/2006 Copyleft Fabio Kon17 / 54 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 Kon18 / 54 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

3/2006 Copyleft Fabio Kon19 / 54 Programação eXtrema 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 Kon20 / 54 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.

3/2006 Copyleft Fabio Kon21 / 54 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 Kon22 / 54 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 Kon23 / 54 O que está por trás deste modelo? Custo de mudanças requisitos desenho testes análise implementação produção

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

3/2006 Copyleft Fabio Kon25 / 54 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).

3/2006 Copyleft Fabio Kon26 / 54 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.

3/2006 Copyleft Fabio Kon27 / 54 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

3/2006 Copyleft Fabio Kon28 / 54 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 like teenage sex. l Hoje não é mais necessariamente assim.

3/2006 Copyleft Fabio Kon29 / 54 As 12 Práticas de XP (versão 2000) 1.Planejamento 2.Fases Pequenas 3.Metáfora 4.Design Simples 5.Testes 6.Refatoração 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

3/2006 Copyleft Fabio Kon30 / 54 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 Kon31 / 54 As 4 Variáveis do Desenvolvimento de Software Tempo Custo Qualidade Escopo (foco principal de XP)

3/2006 Copyleft Fabio Kon32 / 54 Um Projeto XP l Fase de Exploração l 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.

3/2006 Copyleft Fabio Kon33 / 54 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. l Seleciona um “cartão de história” contendo uma tarefa claramente relacionada a uma característica (feature) desejada pelo cliente.

3/2006 Copyleft Fabio Kon34 / 54 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 Kon35 / 54 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.

3/2006 Copyleft Fabio Kon36 / 54 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.

3/2006 Copyleft Fabio Kon37 / 54 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.

3/2006 Copyleft Fabio Kon38 / 54 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!

3/2006 Copyleft Fabio Kon39 / 54 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

3/2006 Copyleft Fabio Kon40 / 54 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!

3/2006 Copyleft Fabio Kon41 / 54 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

3/2006 Copyleft Fabio Kon42 / 54 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)

3/2006 Copyleft Fabio Kon43 / 54 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).

3/2006 Copyleft Fabio Kon44 / 54 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.

3/2006 Copyleft Fabio Kon45 / 54 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.

3/2006 Copyleft Fabio Kon46 / 54 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.

3/2006 Copyleft Fabio Kon47 / 54 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).

3/2006 Copyleft Fabio Kon48 / 54 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.

3/2006 Copyleft Fabio Kon49 / 54 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

3/2006 Copyleft Fabio Kon50 / 54 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)

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

3/2006 Copyleft Fabio Kon52 / 54 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.

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

3/2006 Copyleft Fabio Kon54 / 54 Maiores Informações No IME: agilcoop.incubadora.fapesp.br/portal/agilcast Fora do IME: