XP Interlegis

Desenvolvimento gil de Software com Programao eXtrema (XP): Conceitos Bsicos e a experincia da ALESP
Prof. Fabio Kon
Prof. Alfredo Goldman
Departamento de Cincia da Computao IME / USP na Assemblia Legislativa do Estado de So Paulo 14/10/2005
Copyleft Fabio Kon e Alfredo Goldman
Novos ventos no mundo do Desenvolvimento de Software
Sociedade demanda
grande quantidade de sistemas/aplicaes software complexo, sistemas distribudos, heterogneos requisitos mutantes (todo ano, todo ms, todo dia)
Mas, infelizmente,
no h gente suficiente para desenvolver tanto software com qualidade.

2 / 69
14/10/2005
Copyleft Fabio Kon & Alfredo Goldman
Problemas
Com metodologias de desenvolvimento

Supem que possvel prever o futuro Pouca interao com os clientes nfase em burocracias (documentos, formulrios, processos, controles rgidos, etc.) Avaliao do progresso baseado na evoluo da burocracia e no do cdigo
Com software
Grande quantidade de erros Falta de flexibilidade
14/10/2005
3 / 69
Como resolver esse impasse?
Melhores Tecnologias
Padres de Projeto (reutilizao de idias) Componentes (reutilizao de cdigo) Middleware (aumenta a abstrao)
Melhores Metodologias
Mtodos geis (o foco nesta palestra) outras... (RUP, relacionadas a CMM, etc.)
14/10/2005
4 / 69
Metodologias de Desenvolvimento de Software OO
Tradicionais
Comunidade de Engenharia de Software IEEE/ACM ICSE p.ex. Carnegie-Mellon SEI RUP, CMM, etc.
Comunidade de POO ACM OOPSLA p.ex. Johnson @ Illinois, Beck, Cockburn, Jeffries, Cunningham XP, Crystal, Scrum, etc.
geis

14/10/2005
5 / 69
Mtodos geis de Desenvolvimento de Software
Movimento iniciado por programadores experientes e consultores em desenvolvimento de software. Questionam e se ope a uma srie de mitos/prticas adotadas em abordagens tradicionais de Engenharia de Software e Gerncia de Projetos. Manifesto gil:
Assinado por 17 desenvolvedores em Utah em fevereiro/2001.
14/10/2005
6 / 69
Desenvolvimento gil de Software

1. 2. 3.
4.
O Manifesto do
Indivduos e interaes so mais importantes que processos e ferramentas. Software funcionando mais importante do que documentao completa e detalhada. Colaborao com o cliente mais importante do que negociao de contratos.
Adaptao a mudanas mais importante do que seguir o plano inicial.
14/10/2005
7 / 69
Princpios do Manifesto gil
Objetivo: satisfazer o cliente entregando, rapidamente e com freqncia, sistemas com algum valor.

Entregar verses funcionais em prazos curtos. Estar preparado para requisitos mutantes. Pessoal de negcios e desenvolvedores juntos. Troca de informaes atravs de conversas diretas.
14/10/2005
8 / 69
Principais Mtodos geis

Nesta palestra nos concentraremos em :
Programao eXtrema (XP)
Outros mtodos geis interessantes:

Crystal (uma famlia de mtodos) Scrum Adaptive Software Development Feature Driven Development etc.
14/10/2005
9 / 69
A famlia Crystal de Mtodos

Criada por Alistair Cockburn http://alistair.cockburn.us/crystal Editor da srie Agile Software Development da Addison-Wesley.
14/10/2005
10 / 69
Classificao de Projetos de Desenvolvimento de Software

. . . Prioridade para responsabilidade legal
Prioridade para Produtividade & Tolerncia
(defeitos causam perdas de...)
Life (L)
L6 L20 L40 L100 L200 L500 L1000
Criticalidade
Essential money (E) E6 Discretionary money D6 (D) Comfort (C)
E20
E40
E100
E200
E500
E1000
D20
D40
D100
D200
D500
D1000
C6
C20
C40
C100
C200
C500
C1000
1-6
14/10/2005
- 500 - 1,000 Nmero de pessoas envolvidas +20%

- 20
- 40
- 100
- 200
11 / 69
Escopo da Famlia Crystal

L6 L20 L40 L80
E6
E20
E40
E80
D6
D20
D40
D80
C6
C20
C40
C80
Red
Clear
14/10/2005
Yellow
Orange
12 / 69
Principais Caractersticas da Famlia Crystal
Filosofia bsica:

nfase em comunicao leve nos produtos gerados (evitar peso morto) Precisamos de menos produtos intermedirios se possumos:
1. 2. 3.
Princpios:
4.
canais de comunicao informal ricos e rpidos entrega freqente de cdigo 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)
14/10/2005
13 / 69
Adaptao da Metodologia
Em cada caso, escolha a metodologia mais leve possvel que pode fazer o que voc precisa. Quanto maior o projeto (nmero de pessoas), maior burocracia ser necessria e pior ser a produtividade.
Reflection Workshops ao final de cada fase.
14/10/2005
14 / 69
(Reflection Workshops)
Oficinas de Reflexo
Perguntas:
O que aprendemos na ltima fase (p.ex. ms)? O que podemos fazer de uma forma melhor?
Resultado:
pster
Manter
reunies com cliente programao pareada
Tentar
testes automatizados multas para interrupes escrita pareada de testes
Problemas
muitas interrupes erros no cdigo entregue
14/10/2005
15 / 69
Mais perguntas na reflexo

O que fizemos de bom e de ruim? Quais so as nossas prioridades? O que mantivemos de mais importante? O que podemos mudar para a prxima vez? O que podemos adicionar/tirar?
Aps 2 ou 3 verses incrementais, a metodologia deve comear a convergir para uma metodologia tolervel para o projeto.
14/10/2005
16 / 69
Scrum
Definio informal: Estratgia em um jogo de rugby onde jogadores colocam uma bola quase perdida novamente em jogo atravs de trabalho em equipe.
14/10/2005
17 / 69
Scrum
Jeff Suttherland
http://jeffsutherland.com http://www.controlchaos.com
Ken Schwaber
Conferncias
OOPSLA 96, PLoP 98

Desenvolvimento Iterativo e Incremental em empresas (DuPont, Honda, etc) nos anos 80
Inspirao
14/10/2005
18 / 69
Programao eXtrema
XP
Metodologia de desenvolvimento de software aperfeioada nos ltimos 5 anos. Ganhou notoriedade a partir da OOPSLA2000.
Nome principal: Kent Beck Tambm importante: Ward Cunningham
14/10/2005
19 / 69
Reaes a XP
Alguns odeiam, outros amam.
Quem gosta de programar ama! Deixa o bom programador livre para fazer o que ele faria se no houvesse regras. Fora o [mau] programador a se comportar de uma forma similar ao bom programador.
14/10/2005
20 / 69
Modelo Tradicional de Desenvolvimento de Software

0. Levantamento de Requisitos
1. Anlise de Requisitos
2. Desenho da Arquitetura 3. Implementao 4. Testes 5. Produo / Manuteno
14/10/2005
21 / 69
Premissas Bsicas do Modelo Tradicional
necessrio fazer uma anlise de requisitos profunda e detalhada antes de projetar a arquitetura do sistema.
necessrio fazer um estudo minucioso e elaborar uma descrio detalhada da arquitetura antes de comear a implement-la. necessrio testar o sistema completamente antes de mandar a verso final para o cliente.
14/10/2005
22 / 69
O que est por trs deste modelo?

Custo de mudanas
requisitos desenho testes anlise implementao produo

14/10/2005
23 / 69
E se a realidade hoje em dia fosse outra?

Custo de mudanas
tempo
14/10/2005
24 / 69
E se essa fosse a realidade?
A atitude dos desenvolvedores de software seria completamente diferente:

Tomaramos as grandes decises o mais tarde possvel. Implementaramos agora somente o que precisamos agora. No implementaramos flexibilidade desnecessria (no anteciparamos necessidades).
14/10/2005
25 / 69
E essa a nova realidade !

(pelo menos em muitos casos) Orientao a Objetos: facilita e cria oportunidades para mudanas. Tcnicas de Refatorao. Testes automatizados: nos do segurana quando fazemos mudanas. Prtica / cultura de mudanas: aprendemos tcnicas e adquirimos experincia em lidar com cdigo mutante.
14/10/2005
26 / 69
A Quem se Destina XP?

Grupos de 2 a 10 programadores Projetos de 1 a 36 meses (calendrio) De 1000 a 250 000 linhas de cdigo Papis:
Programadores (foco central)(sem hierarquia) Treinador ou Tcnico (coach) Acompanhador (tracker) Cliente
14/10/2005
27 / 69
E Se Eu No Me Encaixo Nesses Casos?

Voc ainda pode aprender muito sobre desenvolvimento de software. Ter elementos para repensar as suas prticas. No incio se dizia:
Ou voc 100% eXtremo ou no eXtremo. No d pr ser 80% XP.
XP is like teenage sex.
Hoje no mais necessariamente assim.

14/10/2005
28 / 69
As 12 Prticas de XP
(verso 2000)
1. 2. 3. 4. 5. 6. 7. Planejamento Fases Pequenas Metfora Design Simples Testes Refatorao Programao Pareada
14/10/2005
8. Propriedade Coletiva 9. Integrao Contnua 10. Semana de 40 horas 11. Cliente junto aos desenvolvedores 12. Padronizao do cdigo
29 / 69
Princpios Bsicos de XP

Feedback rpido
Simplicidade o melhor negcio Mudanas incrementais Carregue a bandeira das mudanas / no valorize o medo (Embrace change) Alta qualidade do cdigo
14/10/2005
30 / 69
As 4 Variveis do Desenvolvimento de Software

Tempo
Custo
Qualidade Escopo (foco principal de XP)
14/10/2005
31 / 69
Um Projeto XP
Fase de Explorao
durao: 2 a 6 meses. termina quando a primeira verso do software enviada ao cliente. clientes escrevem historias (story cards). programadores interagem com clientes e discutem tecnologias. No s discutem, experimentam diferentes tecnologias e arquiteturas para o sistema. Planejamento: 1 a 2 dias.
14/10/2005
32 / 69
Um Dia na Vida de um Programador XP

Escolhe uma histria do cliente. Procura um par livre. Escolhe um computador para programao pareada. Seleciona um carto de histria contendo uma tarefa claramente relacionada a uma caracterstica (feature) desejada pelo cliente.
14/10/2005
33 / 69

Discute modificaes recentes no sistema
Discute histria do cliente

Testes
Implementao
Projeto (design)
Integrao
14/10/2005
34 / 69
Atos constantes no desenvolvimento:

Executa testes antigos. Busca oportunidades para simplificao. Modifica desenho e implementao incrementalmente baseado na funcionalidade exigida no momento. Escreve novos testes. Enquanto todos os testes no rodam a 100%, o trabalho no est terminado. Integra novo cdigo ao repositrio.
14/10/2005
35 / 69
Testes
Fundamento mais importante de XP. o que d segurana e coragem ao grupo. Testes de unidades (Unit tests)
escritos pelos programadores para testar cada elemento do sistema (e.g., cada mtodo em cada caso).
escritos pelos clientes para testar a funcionalidade do sistema.
Testes de funcionalidades (Functional tests)
14/10/2005
36 / 69
Testes
Testes das unidades do sistema

Tem que estar sempre funcionando a 100%. So executados vrias vezes por dia. Executados noite automaticamente.
Testes das funcionalidades

Vo crescendo de 0% a 100%. Quando chegam a 100% acabou o projeto.
14/10/2005
37 / 69
O Cdigo
Padres de estilo adotados pelo grupo inteiro. O mais claro possvel.
XP no se baseia em documentaes detalhadas e extensas (perde-se sincronia).
Comentrios sempre que necessrios. Comentrios padronizados. Programao Pareada ajuda muito!
14/10/2005
38 / 69
Programao Pareada

Erro de um detectado imediatamente pelo outro (grande economia de tempo). Maior diversidade de idias, tcnicas, algoritmos. Enquanto um escreve, o outro pensa em contraexemplos, problemas de eficincia, etc. Vergonha de escrever cdigo feio (gambiarras) na frente do seu par. Pareamento de acordo com especialidades.
Ex.: Sistema Multimdia Orientado a Objetos
14/10/2005
39 / 69
Propriedade Coletiva do Cdigo

Modelo tradicional: s autor de uma funo pode modific-la. XP: o cdigo pertence a todos. Se algum identifica uma oportunidade para simplificar, consertar ou melhorar cdigo escrito por outra pessoa, que o faa. Mas rode os testes!
14/10/2005 40 / 69
(Refactoring)
Uma [pequena] modificao no sistema que no altera o seu comportamento funcional mas que melhora alguma qualidade nofuncional:
Refatorao
simplicidade flexibilidade clareza desempenho
14/10/2005
41 / 69
Exemplos de Refatorao

Mudana do nome de variveis

Mudanas nas interfaces dos objetos Pequenas mudanas arquiteturais Encapsular cdigo repetido em um novo mtodo Generalizao de mtodos
raizQuadrada(float x) raiz(float x, int n)
14/10/2005
42 / 69
Cliente
Responsvel por escrever histrias. Muitas vezes um programador ou representado por um programador do grupo. Trabalha no mesmo espao fsico do grupo. Novas verses so enviadas para produo todo ms (ou toda semana). Feedback do cliente essencial. Requisitos mudam (e isso no mau).
14/10/2005
43 / 69
(treinador)
Em geral, o mais experiente do grupo. Identifica quem bom no que. Lembra a todos as regras do jogo (XP). Eventualmente faz programao pareada. No desenha arquitetura, apenas chama a ateno para oportunidades de melhorias. Seu papel diminui medida em que o time fica mais maduro.
14/10/2005
Coach
44 / 69
(Acompanhador)

Tracker
A conscincia do time. Coleta estatsticas sobre o andamento do projeto. Alguns exemplos:

Nmero Nmero Nmero Nmero de de de de histrias definidas e implementadas.
unit tests.
testes funcionais definidos e funcionando. classes, mtodos, linhas de cdigo
Mantm histrico do progresso. Faz estimativas para o futuro.

14/10/2005
45 / 69
Quando XP No Deve Ser Experimentada?

Quando o cliente no aceita as regras do jogo. Quando o cliente quer uma especificao detalhada do sistema antes de comear. Quando os programadores no esto dispostos a seguir (todas) as regras. Se (quase) todos os programadores do time so medocres.
14/10/2005 46 / 69
Quando XP No Deve Ser Experimentada?

Grupos grandes (>10 programadores). Quando feedback rpido no possvel:
sistema demora 6h para compilar. testes demoram 12h para rodar. exigncia de certificao que demora meses.
Quando o custo de mudanas essencialmente exponencial. Quando no possvel realizar testes (muito raro).
14/10/2005
47 / 69
Concluso Vencendo os Medos

Escrever cdigo. Mudar de idia. Ir em frente sem saber tudo sobre o futuro. Confiar em outras pessoas. Mudar a arquitetura de um sistema em funcionamento. Escrever testes.
14/10/2005
48 / 69
As 12 Prticas de XP
(verso 2000)
1. 2. 3. 4. 5. 6. 7. Planejamento Fases Pequenas Metfora Design Simples Testes Refatoramento Programao Pareada
14/10/2005
8. Propriedade Coletiva 9. Integrao Contnua 10. Semana de 40 horas 11. Cliente junto aos desenvolvedores 12. Padronizao do cdigo
49 / 69
Prticas de XP
As prticas foram refatoradas
(veja www.extremeprogramming.org/rules.html) Mas a idia exatamente a mesma Novas prticas interessantes: Conserte XP quando a metodologia quebrar. Mova as pessoas. Client Proxy (by Klaus)
14/10/2005
50 / 69
Portanto
XP no para todo mundo.
Mas todo mundo pode aprender com ela.
14/10/2005
51 / 69
Caractersticas Comuns dos Mtodos geis
Coloca o foco
Na entrega freqente de sub-verses do software [funcionando] para o cliente. Nos seres humanos que desenvolvem o software.
Retira o foco de
Processos rgidos e burocratizados. Documentaes e contratos detalhados. Ferramentas que so usadas pelos seres humanos.
14/10/2005
52 / 69
Programao eXtrema na ALESP

1. Problema Complexo
Sistema completo para o depto. de recursos humanos
2. Muito bem estudado

A equipe passou 18 meses estudando os processos envolvidos
3. Mas, no havia nenhuma linha de cdigo.

Nova tecnologia para a equipe (Java)
14/10/2005
53 / 69
Contratao do IME/USP

Atravs da Fundao de Apoio USP (FUSP) Opes possveis:

1.
Desenvolvimento do sistema na USP

+ a equipe do IME/USP tem alto nvel tcnico - mas no conhece a fundo as regras do negcio
2.
Capacitao da equipe
+ permite um maior envolvimento do pessoal da ALESP + a equipe fica apta a desenvolver e manter os sistemas - perde-se tempo com a formao
14/10/2005
54 / 69
Capacitao Mdulo 1
Curso Intensivo de Orientao a Objetos com Java
Pr-requisito: conhecimentos de programao
Conceitos de modelagem OO Introduo a um bom ambiente de desenvolvimento: Eclipse Durao: 6 semanas
14/10/2005
55 / 69
Capacitao Mdulo 2

Introduo aos mtodos geis
Com nfase em XP
Testes automatizados
JUnit e JWebUnit
Refatorao Estilos de Cdigo Interfaces WEB (JSP/Servlets) Mini-projeto real (sistema de crachs)
14/10/2005
56 / 69
Capacitao Mdulo 3
Ferramentas mais avanadas Software livre, cdigo aberto:
Struts Velocity Java + Banco de dados Hibernate
Incio do projeto do sistema RH

Escrita de cartes Explorao
14/10/2005
57 / 69
Capacitao Mdulos Seguintes

Desenvolvimento do Sistema Pessoas do corpo tcnico (IME/USP) participando ativamente do desenvolvimento
Transferncia de conhecimento
Novas ferramentas livres:

CVS Log4J Ferramenta de gerao de arquivos PDF
14/10/2005
58 / 69
ALESP: Resultados Hoje

Aps 8 meses de trabalho: Equipe auto-suficiente Estatsticas do projeto:
Release 1 Data 13/7 # Classes 44 # Mtodos de teste 74
2
3
14/10/2005
29/7
17/8 6/10
62
100 210
110
197 582
59 / 69
Estatsticas do Projeto
700 600 500
Qtdes.
400 300 200 100 0 13/7 1 29/7 2 17/8 6/10 3 Data, Release
# Classes # Mtodos de teste
14/10/2005
60 / 69
Interface Grfica do Sistema de Freqncia
Implementado em Java JSP Servlets Struts Hibernate Oracle

14/10/2005
61 / 69
Jorge de Almeida
14/10/2005
62 / 69
Jorge de Almeida
14/10/2005
63 / 69
14/10/2005
64 / 69
Na prtica
Funcionaram muito bem

Programao pareada Testes (nem sempre a priori) Refatorao Cliente programador
Funcionaram bem
Design simples Propriedade coletiva Integrao contnua
14/10/2005
65 / 69
O que esperamos no futuro prximo
Dentro de poucos meses:
colocar partes do sistema em produo substituir o sistema atual de RH
Dentro de cerca de um ano:
A partir de um ano:
exportar a tecnologia como software livre para outros rgos governamentais Projeto Chinchilla
http://chichilla.sf.net
14/10/2005
66 / 69
Maiores Informaes
www.agilealliance.org www.ime.usp.br/~xp www.xispe.com.br www.extremeprogramming.org www.ime.usp.br/~kon/MAC5715

14/10/2005
67 / 69
Desenvolvedores
Alexandre Felix Alexandre Vernille Cintia Shnaider Edmur Mesquita lcio A. Arajo
14/10/2005
Felipe S. Gomes Ilton Yoshio Narita Joo Henrique Marcia Abraham Marisa N. da Silva
68 / 69
Agradecimentos
Carlos E. Ferreira Celso T. Matsuda Edna M. S. Cymbaum Lcia S. Frana Pinto Luis Shoiti Yvata
Mauricio R. F. Pereira Roberto Sturm Solange Basso Werner Bichler
14/10/2005
69 / 69

XP Interlegis

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

XP Interlegis

Enviado por

Direitos autorais:

Formatos disponíveis

Desenvolvimento gil de Software com Programao eXtrema (XP): Conceitos Bsicos e a experincia da ALESP

Prof. Fabio Kon

Prof. Alfredo Goldman

Novos ventos no mundo do Desenvolvimento de Software

no h gente suficiente para desenvolver tanto software com qualidade.

Copyleft Fabio Kon & Alfredo Goldman

Com metodologias de desenvolvimento

Como resolver esse impasse?

Copyleft Fabio Kon & Alfredo Goldman

Metodologias de Desenvolvimento de Software OO

Mtodos geis de Desenvolvimento de Software

Desenvolvimento gil de Software

Princpios do Manifesto gil

Copyleft Fabio Kon & Alfredo Goldman

Principais Mtodos geis

Nesta palestra nos concentraremos em :

Programao eXtrema (XP)

Outros mtodos geis interessantes:

A famlia Crystal de Mtodos

Copyleft Fabio Kon & Alfredo Goldman

Classificao de Projetos de Desenvolvimento de Software

(defeitos causam perdas de...)

Essential money (E) E6 Discretionary money D6 (D) Comfort (C)

- 500 - 1,000 Nmero de pessoas envolvidas +20%

Escopo da Famlia Crystal

Copyleft Fabio Kon & Alfredo Goldman

Principais Caractersticas da Famlia Crystal

Copyleft Fabio Kon & Alfredo Goldman

Reflection Workshops ao final de cada fase.

Copyleft Fabio Kon & Alfredo Goldman

Mais perguntas na reflexo

Copyleft Fabio Kon & Alfredo Goldman

OOPSLA 96, PLoP 98

Nome principal: Kent Beck Tambm importante: Ward Cunningham

Alguns odeiam, outros amam.

Modelo Tradicional de Desenvolvimento de Software

Premissas Bsicas do Modelo Tradicional

O que est por trs deste modelo?

requisitos desenho testes anlise implementao produo

E se a realidade hoje em dia fosse outra?

Copyleft Fabio Kon & Alfredo Goldman

E se essa fosse a realidade?

A atitude dos desenvolvedores de software seria completamente diferente:

E essa a nova realidade !

A Quem se Destina XP?

E Se Eu No Me Encaixo Nesses Casos?

Ou voc 100% eXtremo ou no eXtremo. No d pr ser 80% XP.

XP is like teenage sex.

Hoje no mais necessariamente assim.

Copyleft Fabio Kon & Alfredo Goldman

Copyleft Fabio Kon & Alfredo Goldman

As 4 Variveis do Desenvolvimento de Software

Copyleft Fabio Kon & Alfredo Goldman

Um Dia na Vida de um Programador XP

Um Dia na Vida de um Programador XP

Discute modificaes recentes no sistema

Discute histria do cliente

Um Dia na Vida de um Programador XP

Atos constantes no desenvolvimento:

Testes de funcionalidades (Functional tests)

Testes das unidades do sistema

Testes das funcionalidades

Copyleft Fabio Kon & Alfredo Goldman

XP no se baseia em documentaes detalhadas e extensas (perde-se sincronia).