Desenvolvimento Ágil de Software com Programação eXtrema (XP)

Ricardo Argenton Ramos

Novos ventos no mundo do Desenvolvimento de Software

� Sociedade demanda� grande quantidade de sistemas/aplicações� software complexo, sistemas distribuídos, heterogêneos

2 / 69

heterogêneos� requisitos mutantes (todo ano, todo mês, todo dia)

� Mas, infelizmente,� não há gente suficiente para desenvolver tanto software com qualidade.

Problemas

� Com metodologias de desenvolvimento� Supõem que é possível prever o futuro� Pouca interação com os clientes� Ênfase em burocracias (documentos,

3 / 69

� Ênfase em burocracias (documentos, formulários, processos, controles rígidos, etc.)

� Avaliação do progresso baseado na evolução da burocracia e não do código

� Com software� Grande quantidade de erros� Falta de flexibilidade

Como resolver esse impasse?

� Melhores Tecnologias� Padrões de Projeto (reutilização de idéias)� Componentes (reutilização de código)Middleware (aumenta a abstração)

4 / 69

� Middleware (aumenta a abstração)

� Melhores Metodologias� Métodos Ágeis (o foco nesta palestra)� outras... (RUP, relacionadas a CMM, etc.)

Metodologias de Desenvolvimento de Software OO

� “Tradicionais”� Comunidade de Engenharia de Software� IEEE/ACM ICSE� p.ex. Carnegie-Mellon SEIRUP, CMM, etc.

5 / 69

� RUP, CMM, etc.

� Ágeis� Comunidade de POO� ACM OOPSLA� p.ex. Johnson @ Illinois, Beck, Cockburn, Jeffries, Cunningham…

� XP, Crystal, Scrum, etc.

Métodos Ágeis deDesenvolvimento de Software

� Movimento iniciado por programadores experientes e consultores em desenvolvimento de software.

� Questionam e se opõe a uma série de

6 / 69

� 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.

� Manifesto Ágil:• Assinado por 17 desenvolvedores em Utah em fevereiro/2001.

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

7 / 69

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.

Princípios do Manifesto Ágil

� Objetivo: satisfazer o cliente entregando, rapidamente e com freqüência, sistemas com algum valor.

8 / 69

� Entregar versões funcionais em prazos curtos.

� Estar preparado para requisitos mutantes.

� Pessoal de negócios e desenvolvedores juntos.

� Troca de informações através de conversas diretas.

Principais Métodos Ágeis

� Nesta palestra nos concentraremos em :� Programação eXtrema (XP)

� Outros métodos ágeis interessantes:

9 / 69

� Outros métodos ágeis interessantes:� Crystal (uma família de métodos)� Scrum� Adaptive Software Development� Feature Driven Development� etc.

A família Crystal de Métodos

� Criada por Alistair Cockburn� http://alistair.cockburn.us/crystal� Editor da série Agile Software Development

10 / 69

� Editor da série Agile Software Developmentda Addison-Wesley.

Principais Característicasda Família Crystal

� Filosofia básica:� ênfase em comunicação� leve nos produtos gerados (evitar “peso morto”)

� Princípios:Precisamos de menos produtos intermediários se possuímos:

11 / 69

� Precisamos de menos produtos intermediários se possuímos:1. canais de comunicação informal ricos e rápidos2. 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)

Adaptação da Metodologia

� Em cada caso, escolha a metodologia mais leve possível que pode fazer o que você precisa.

� Quanto maior o projeto (número de pessoas), maior

12 / 69

� Quanto maior o projeto (número de pessoas), maior burocracia será necessária e pior será a produtividade.

� Reflection Workshops ao final de cada fase.

Oficinas de Reflexão(Reflection Workshops)

� Perguntas:� O que aprendemos na última fase (p.ex. mês)?� O que podemos fazer de uma forma melhor?

13 / 69

O que podemos fazer de uma forma melhor?

� Resultado:� pôster Tentar

testes automatizadosmultas para interrupçõesescrita pareada de testes

Manterreuniões com cliente

programação pareada

Problemasmuitas interrupções

erros no código entregue

Mais perguntas na reflexão

� 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?

14 / 69

� 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.

Scrum

15 / 69

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.

Scrum

� Jeff Suttherland� http://jeffsutherland.com

� Ken Schwaber� http://www.controlchaos.com

16 / 69

� http://www.controlchaos.com� Conferências

� OOPSLA 96, PLoP 98� Inspiração

� Desenvolvimento Iterativo e Incremental em empresas (DuPont, Honda, etc) nos anos 80

Programação eXtremaXP

� Metodologia de desenvolvimento de software aperfeiçoada nos últimos 5 anos.

17 / 69

� Ganhou notoriedade a partir da OOPSLA’2000.

� Nome principal: Kent Beck� Também importante: Ward Cunningham

Reações a XP

� Alguns odeiam, outros amam.

� Quem gosta de programar ama!

18 / 69

� Quem gosta de programar ama!� Deixa o bom programador livre para fazer o que ele faria se não houvesse regras.

� Força o [mau] programador a se comportar de uma forma similar ao bom programador.

Modelo Tradicional de Desenvolvimento de Software

0. Levantamento de Requisitos

1. Análise de Requisitos

2. Desenho da Arquitetura

19 / 69

2. Desenho da Arquitetura

3. Implementação

4. Testes

5. Produção / Manutenção

Premissas Básicas do Modelo Tradicional

� É necessário fazer uma análise de requisitos profunda e detalhada antes de projetar a arquitetura do sistema.

20 / 69

� É necessário fazer um estudo minucioso e elaborar uma descrição detalhada da arquitetura antes de começar a implementá-la.

� É necessário testar o sistema completamente antes de mandar a versão final para o cliente.

O que está por trás deste modelo?

Cus

to d

e m

udan

ças

21 / 69

Cus

to d

e m

udan

ças

requisitos desenho testesanálise implementação produção

E se a realidade hoje em dia fosse outra?

Cus

to d

e m

udan

ças

22 / 69

Cus

to d

e m

udan

ças

tempo

E se essa fosse a realidade?

� A atitude dos desenvolvedores de software seria completamente diferente:� Tomaríamos as grandes decisões o mais tarde possível.

23 / 69

tarde possível.� Implementaríamos agora somente o que precisamos agora.

� Não implementaríamos flexibilidade desnecessária (não anteciparíamos necessidades).

E essa é a nova realidade !(pelo menos em muitos casos)

� Orientação a Objetos: facilita e cria oportunidades para mudanças.

� Técnicas de Refatoração.

24 / 69

� Técnicas de Refatoração.� Testes automatizados: nos dão segurança quando fazemos mudanças.

� Prática / cultura de mudanças: aprendemos técnicas e adquirimos experiência em lidar com código mutante.

A Quem se Destina XP?

� Grupos de 2 a 10 programadores� Projetos de 1 a 36 meses (calendário)� De 1000 a 250 000 linhas de código

25 / 69

� De 1000 a 250 000 linhas de código� Papéis:

� Programadores (foco central)(sem hierarquia)� “Treinador” ou “Técnico” (coach)� “Acompanhador” (tracker)� Cliente

E Se Eu Não Me Encaixo Nesses Casos?

� Você ainda pode aprender muito sobre desenvolvimento de software.

� Terá elementos para repensar as suas práticas.

26 / 69

práticas.� No início se dizia:

� “Ou você é 100% eXtremo ou não é eXtremo. Não dá prá ser 80% XP.”

� XP is like teenage sex.� Hoje não é mais necessariamente assim.

As 12 Práticas de XP(versão 2000)

1. Planejamento2. Fases Pequenas3. Metáfora

8. Propriedade Coletiva9. Integração Contínua10.Semana de 40 horas

27 / 69

4. Design Simples5. Testes6. Refatoração7. Programação Pareada

11.Cliente junto aos desenvolvedores

12.Padronização do código

Princípios Básicos de XP

� Feedback rápido

� Simplicidade é o melhor negócio

� Mudanças incrementais

28 / 69

� Mudanças incrementais

� Carregue a bandeira das mudanças /

não valorize o medo (Embrace change)

� Alta qualidade do código

As 4 Variáveis do Desenvolvimento de Software

• Tempo

• Custo

29 / 69

• Custo

• Qualidade

• Escopo (foco principal de XP)

Um Projeto XP

� Fase de Exploração� duração: 2 a 6 meses. � termina quando a primeira versão do software é enviada ao cliente.

30 / 69

software é enviada ao cliente.� clientes escrevem “historias” (story cards).� programadores interagem com clientes e discutem tecnologias.

� Não só discutem, experimentam diferentes tecnologias e arquiteturas para o sistema.

� Planejamento: 1 a 2 dias.

Um Dia na Vida de um Programador XP

� Escolhe uma história do cliente.� Procura um par livre.� Escolhe um computador para programação pareada.

31 / 69

Escolhe um computador para programação pareada.

� Seleciona um “cartão de história” contendo uma tarefa claramente relacionada a uma característica (feature) desejada pelo cliente.

Um Dia na Vida de um Programador XP

� Discute modificações recentes no sistema

� Discute história do cliente

32 / 69

� Testes

� Implementação

� Projeto (design)

� Integração

Um Dia na Vida de um Programador XP

� Atos constantes no desenvolvimento:� Executa testes antigos.� Busca oportunidades para simplificação.� Modifica desenho e implementação

33 / 69

� Modifica desenho e implementação incrementalmente baseado na funcionalidade exigida no momento.

� Escreve novos testes.� Enquanto todos os testes não rodam a 100%, o trabalho não está terminado.

� Integra novo código ao repositório.

Testes

� Fundamento mais importante de XP.� É o que dá segurança e coragem ao grupo.� Testes de unidades (Unit tests)

34 / 69

� escritos pelos programadores para testar cada elemento do sistema (e.g., cada método em cada caso).

� Testes de funcionalidades (Functional tests)� escritos pelos clientes para testar a funcionalidade do sistema.

Testes

� Testes das unidades do sistema� Tem que estar sempre funcionando a 100%.� São executados várias vezes por dia.

35 / 69

São executados várias vezes por dia.� Executados à noite automaticamente.

� Testes das funcionalidades� Vão crescendo de 0% a 100%.� Quando chegam a 100% acabou o projeto.

O Código

� Padrões de estilo adotados pelo grupo inteiro.

� O mais claro possível.� XP não se baseia em documentações

36 / 69

� XP não se baseia em documentações detalhadas e extensas (perde-se sincronia).

� Comentários sempre que necessários.� Comentários padronizados.� Programação Pareada ajuda muito!

Programação Pareada

� 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-

37 / 69

� 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

Propriedade Coletivado Código

� Modelo tradicional: só autor de uma função pode modificá-la.

� XP: o código pertence a todos.

38 / 69

� XP: o código pertence a todos.� Se alguém identifica uma oportunidade para simplificar, consertar ou melhorar código escrito por outra pessoa, que o faça.

� Mas rode os testes!

Refatoração(Refactoring)

� Uma [pequena] modificação no sistema que não altera o seu comportamento funcional

� mas que melhora alguma qualidade não-

39 / 69

� mas que melhora alguma qualidade não-funcional:� simplicidade� flexibilidade� clareza� desempenho

Exemplos de Refatoração

� Mudança do nome de variáveis

� Mudanças nas interfaces dos objetos

� Pequenas mudanças arquiteturais

40 / 69

� Pequenas mudanças arquiteturais

� Encapsular código repetido em um novo método

� Generalização de métodos• raizQuadrada(float x)⇒⇒⇒⇒ raiz(float x, int n)

Cliente

� Responsável por escrever “histórias”.� Muitas vezes é um programador ou é representado por um programador do grupo.Trabalha no mesmo espaço físico do grupo.

41 / 69

� Trabalha no mesmo espaço físico do grupo.� Novas versões são enviadas para produção todo mês (ou toda semana).

� Feedback do cliente é essencial.� Requisitos mudam (e isso não é mau).

Coach(treinador)

� Em geral, o mais experiente do grupo.� Identifica quem é bom no que.� Lembra a todos as regras do jogo (XP).

42 / 69

� Lembra a todos as regras do jogo (XP).� Eventualmente faz programação pareada.� Não desenha arquitetura, apenas chama a atenção para oportunidades de melhorias.

� Seu papel diminui à medida em que o time fica mais maduro.

Tracker(Acompanhador)

� A “consciência” do time.� Coleta estatísticas sobre o andamento do projeto. Alguns exemplos:• Número de histórias definidas e implementadas.

43 / 69

• 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

� Mantém histórico do progresso.� Faz estimativas para o futuro.

Quando XP Não Deve Ser Experimentada?

� Quando o cliente não aceita as regras do jogo.� Quando o cliente quer uma especificação detalhada do sistema antes de começar.

44 / 69

detalhada do sistema antes de começar.� Quando os programadores não estão dispostos a seguir (todas) as regras.

� Se (quase) todos os programadores do time são medíocres.

Quando XP Não Deve Ser Experimentada?

� Grupos grandes (>10 programadores).� Quando feedback rápido não é possível:

� sistema demora 6h para compilar.� testes demoram 12h para rodar.

45 / 69

� testes demoram 12h 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).

ConclusãoVencendo os Medos

� Escrever código.� Mudar de idéia.� Ir em frente sem saber tudo sobre o futuro.

46 / 69

� Ir em frente sem saber tudo sobre o futuro.� Confiar em outras pessoas.� Mudar a arquitetura de um sistema em funcionamento.

� Escrever testes.

As 12 Práticas de XP(versão 2000)

1. Planejamento2. Fases Pequenas3. Metáfora

8. Propriedade Coletiva9. Integração Contínua10.Semana de 40 horas

47 / 69

4. Design Simples5. Testes6. Refatoramento7. Programação Pareada

11.Cliente junto aos desenvolvedores

12.Padronização do código

Práticas de XP

� As práticas foram refatoradas(veja www.extremeprogramming.org/rules.html)

� Mas a idéia é exatamente a mesma

48 / 69

� Novas práticas interessantes:• Conserte XP quando a metodologia quebrar.• Mova as pessoas.• Client Proxy (by Klaus)

Portanto

� XP não é para todo mundo.

49 / 69

� Mas todo mundo pode aprender com ela.

Características Comuns dos Métodos Ágeis

� Coloca o foco� Na entrega freqüente de sub-versões do software [funcionando] para o cliente.

� Nos seres humanos que desenvolvem o software.

50 / 69

� Nos seres humanos que desenvolvem o software.� Retira o foco de

� Processos rígidos e burocratizados.� Documentações e contratos detalhados.� Ferramentas que são usadas pelos seres humanos.