Métodos Ágeis e Programação extrema

(1)

Copyleft by Fabio Kon & Alfredo Goldman 1

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

Copyleft by Fabio Kon & Alfredo Goldman 2 / 83 Outubro de 2003

Novos ventos no mundo do

desenvolvimento de software

O

Sociedade demanda

Ogrande quantidade de sistemas/aplicações Osoftware complexo, sistemas distribuídos,

heterogêneos

Orequisitos mutantes (todo ano, todo mês, todo dia) O

Mas, infelizmente,

Onão há gente suficiente para desenvolver tanto software com qualidade.

Problemas

O

Com metodologias de desenvolvimento

OSupõem que é possível prever o futuro OPouca interação com os clientes OÊnfase em burocracias (documentos,

formulários, processos, controles rígidos, etc.) OAvaliação do progresso baseado na evolução

da burocracia e não do código O

Com software

OGrande quantidade de erros OFalta de flexibilidade

Como resolver esse impasse?

O

Melhores Tecnologias

OComponentes (melhoram a reutilização) OMiddleware (aumenta a abstração)

O

Melhores Metodologias

OMétodos Ágeis (foco deste mini-curso) Ooutras... (não abordadas aqui)

O que é desenvolvimento de

software (A. Cookburn)?

Processo Reprodutível ???

O

Pode existir um processo pré-definido?

OAlguns pensam que além de possível isto é

necessário! OAbordagem CMM

O5 níveis (inicial, sistematizado, definido, gerencial e otimizado)

(2)

Processo Reprodutível ???

(extraído de artigo da PLoP’98)

O

Suposições para “sistematizado/definido”

OProblema. ∃ fase para definição de requisitos

OPodem não ser bem definidos, ou mudar

OSolução. Especificação completa da arquitetura

OAlém do problema acima, envolve processo criativo

ODesenvolvedores.

OSão humanos (logo, diferentes)

OAmbiente.

OPressão de cronograma, prioridades e clientes mudam

Métodos Ágeis

OMovimento iniciado por programadores experientes e consultores em desenvolvimento de software.

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

OManifesto Ágil:

•Assinado por 17 desenvolvedores em Utah em fevereiro/2001.

O Manifesto do

Desenvolvimento Ágil de Software

O

Indivíduos e interações

são mais

importantes que

processos e ferramentas.

O

Software funcionando

é mais importante

do que

documentação completa e detalhada

.

O

Colaboração com o cliente

é mais

importante do que

negociação de contratos

.

O

Adaptação a mudanças é mais importante

do que

seguir o plano inicial

.

Princípios do Manifesto Ágil

OMaior prioridade: satisfazer o cliente entregando, antes e sempre sistemas com valor.

OEstar preparado para requisitos mutantes. O quê fornece uma vantagem competitiva.

OEntregar versões funcionais em prazos curtos. OPessoal de negócios e desenvolvedores juntos. OConstruir projetos com indivíduos motivados, dando

um ambiente de trabalho e confiando neles. OTroca de informações através de conversas diretas.

Princípios do Manifesto Ágil

OMedir progresso através de software funcionando. ODesenvolvimento sustentável.

OCuidados com o nível técnico e bom desenho. OSimplicidade é essencial.

OAs melhores arquiteturas, requisitos e desenho aparecem de equipes que se auto organizam. ODe tempos em tempos, o time pensa em como se

tornar mais efetivo, e ajusta o seu comportamento de acordo.

Uma Boa Metáfora para

Desenvolvimento de Software

O

“Um jogo Cooperativo de Invenção e

Comunicação”. Alistair Cockburn.

O

Como um grupo de pessoas escalando

uma montanha em conjunto.

OJogo cooperativo, finito, onde se busca alcançar um objetivo.

(3)

Dois Objetivos Principais do

Desenvolvimento de Software

O

Entregar software que funcione.

O

Preparar o terreno para o próximo projeto.

Epifanias Ágeis

OO gerente de projeto concorda em prosseguir sem que todos os requisitos estejam bem definidos. OOs desenvolvedores concordam em prosseguir

sem ter todos os requisitos documentados. OO 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.

Mais Epifanias Ágeis

OOs membros da equipe sabem que alguém vai ajudar quando ocorrerem problemas.

OO gerente de TI sente o trabalho de equipe nas áreas de trabalho.

OOs gerentes percebem que não precisam dizer a equipe o que fazer, ou garantir o que vai ser feito. OA equipe percebe que ninguém vai dizer o quê

fazer, isto faz parte do trabalho da equipe. ONão existem mais a impressão de divisão (testers

and programmers), todos são desenvolvedores.

Principais Métodos Ágeis

O

Daremos uma visão geral

OCrystal (uma família de métodos) OScrum

O

Abordaremos mais detalhadamente

OProgramação eXtrema (XP)

O

Não abordaremos

OAdaptive Software Development OFeature Driven Development, etc.

A família Crystal de Métodos

O

Criada por Alistair Cockburn

O

http://alistair.cockburn.us/crystal

O

Editor da série

Agile Software Development

da Addison-Wesley.

Pequeno histórico

O

Foi contratado em 1990 pela IBM

Odocumentar a metodologia de desenvolvimento Ooptou por entrevistar as diversas equipes O

Resultado:

OPedidos de desculpa por não utilizar ferramentas

Oe entregar software funcionando

OExplicações sobre como metodologias foram seguidas a risca

(4)

Conclusões (resumo)

O

Pode-se trocar documentação escrita por

conversas face a face

O

Quanto mais se entrega software

funcionando e testado, menos depende-se

da documentação escrita (promissórias)

Classificação de Projetos de

Desenvolvimento de Software

Número de pessoas envolvidas

C ri tic al id ad e (de fei tos ca usa m pe rda s de ... ) Comfort (C) Essential money (E) Life (L) +20% . . . _{Prioridade para responsabilidade legal}

1 - 6 - 20 - 40 - 100 - 200 - 500 - 1,000

C6 C20 C40 C100 C200 C500 C1000

D6 D20 D40 D100 D200 D500 D1000

E6 E20 E40 E100 E200 E500 E1000

L6 L20 L40 L100 L200 L500 L1000

Prioridade para Produtividade & Tolerância

Discretionary money

(D)

Escopo da Família Crystal

Red

C6 C20 C40 C80

D6 D20 D40 D80

E6 E20 E40 E80

Clear Yellow Orange

L6 L20 L40 L80

Principais Características

da Família Crystal

O Filosofia básica:

O ênfase em comunicação

O leve nos produtos gerados (evitar “peso morto”)

O Princípios:

O Precisamos de menos produtos intermediários se

possuímos:

O canais de comunicação informal ricos e rápidos O entrega freqüente de código funcionando

O uso dos pontos fortes das pessoas (conversas, olhar a sua

volta, interagir com outros)

O estar ciente dos pontos fracos das pessoas (baixa disciplina,

falta de cuidado)

Políticas Clear e Orange

ODesenvolvimento incremental

Ocom freqüência regular

OAcompanhamento com marcos

Oinício, revisão 1, revisão 2, teste, entrega

OEnvolvimento direto do usuário

OTestes de regressão de funcionalidades automáticos ODuas/três visões de usuários por versão

OWorkshops para ajustes no produto e na metodologia no início e meio de cada incremento

Adaptação da Metodologia

OEm cada caso, escolha a metodologia mais leve possível que pode fazer o que você precisa. OQuanto maior o projeto (número de pessoas),

maior burocracia será necessária e pior será a produtividade.

(5)

Oficinas de Reflexão

(Reflection Workshops)

O

Perguntas:

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

Resultado:

O 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

Mais perguntas na reflexão

OO quê fizemos de bom e de ruim ? OQuais são as nossas prioridades OO quê mantivemos de mais importante OO quê podemos mudar para a próxima vez ? OO quê podemos adicionar/tirar ?

OApós 2 ou 3 versões incrementais, a metodologia deve começar a convergir para uma metodologia tolerável para o projeto.

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.

Origens de Scrum

O

Jeff Suttherland

Ohttp://jeffsutherland.com O

Ken Schwaber

Ohttp://www.controlchaos.com O

Conferências

OOOPSLA 96, PLoP 98 O

Inspiração

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

Fundamentos de Scrum 1/2

O

Desenvolvimento de software a partir de

padrões de projeto (

design patterns

)

O

Mas, o que é isto ???

O quê são padrões ?

O

No final dos anos 70, o arquiteto

Christopher Alexander escreveu dois livros

com a idéia.

O

Cada padrão descreve um problema

recorrente no nosso ambiente e, em

seguida, o princípio de sua solução.

O

A solução pode ser aplicada diversas vezes,

nunca da mesma maneira.

(6)

Fundamentos de Scrum

O

Desenvolvimento de software depende

muito de criatividade e de trabalho

O

Logo, não é um bom candidato a

processos pré-definidos

Omodelo de controle de processo empírico O

O desenvolvimento nem sempre será

repetitivo e bem definido

O

Mas existem padrões que podem ser

usados

Ênfases

O

Comunicação

O

Trabalho em equipe

O

Flexibilidade

O

Fornecer Software funcionando

Oincrementalmente

Principais Padrões em Scrum

O

Backlog

O

Equipes

O

Sprints

O

Encontros Scrum

O

Revisões Scrum/Demos

Backlog

O

Lista de todas as funcionalidades desejadas

O

É gerada incrementalmente

OComeça pelo básico, o extra aparece com o tempo

O

Pode conter

OTarefas diretas, casos de uso e histórias (a la XP) O

A lista é priorizada pelo Dono do projeto

OCliente, depto de marketing, ...

O Backlog inicial

O

Deve conter características que agreguem

algum valor de negócio ao produto.

O

Novos requisitos aparecem quando o

cliente vê o produto.

O

A arquitetura do sistema surge enquanto

o projeto surge e é refatorado.

Equipes

O

Sem nível hierárquico nem papéis

OMas com várias especialidades O

Estão todos no mesmo barco

O

Geralmente equipes pequenas (até 10)

OExistem casos com equipes maiores (800 !) OUsa-se também Scrum hierárquico

O

Comunicação é essencial

OEncontro Scrum diário

(7)

Sprint

O

Unidades básicas de tempo (até 30 dias)

O

Começa com um encontro

Sprint

OTarefas do Backlog são priorizadas OA equipe seleciona tarefas que podem ser

completadas durante o próximo Sprint

OAs mesmas podem ser quebradas para o

Backlog do Sprint

OCada tarefa recebe um responsável na equipe ONão há mudança nas tarefas durante o Sprint

Encontro Scrum 1/2

O

Pequenos encontros diários da equipe

Ogeralmente pela manhã

Ogalinhas e porcos (só os porcos falam) Otodos os porcos devem participar O

Questões que aparecem devem ser

resolvidas durante o dia e não na reunião

O

Os encontros iniciais são geralmente mais

longos

Encontro Scrum 2/2

O

Questões que devem ser respondida por

cada porco:

O1) O quê você fez ontem? O2) O quê você vai fazer hoje? O3) Quais os problemas encontrados? O

Ajuda a manter as promessas

O

Evita: Como um projeto atrasa um ano?

OUm dia por vez ...

OQualquer deslize pode ser corrigido de imediato

Local do encontro

OSempre o mesmo local e hora OPode ser o local de

desenvolvimento OPessoas sentadas ao

redor de uma mesa OA sala já deve estar

arrumada antes OPunições (atrasos/faltas) OTodos devem participar OGalinhas ficam na periferia OPode ser em pé OSala bem equipada,

quadro branco, etc.

Revisão do Sprint

O

No final de cada

Sprint

é feita uma

reunião com todos os interessados

O

Geralmente

ONa forma de demonstração

OInformal (preparação rápida, sem projetor,..) ODeve ser o resultado natural de um Sprint O

O projeto é comparado com os objetivos

iniciais do

Sprint

Scrum Master 1/2

O

Faz com que a equipe viva os valores e

práticas de Scrum

O

Protege a equipe de:

ORiscos e interferências externos OExcesso de otimismo

O

Resolve os problemas que aparecerem

Ologísticos

(8)

Scrum Master 2/2

O

Mantém o

Backlog

do

Sprint

OTarefas completadas

OIdentifica eventuais problemas

O

Mantém um gráfico de “quanto falta”

0 20 40 60 80 100 horas

Scrum (de forma gráfica)

Scrum final

O

Um último

Sprint

para “fechar” o produto

O

O objetivo é:

OPreparar a versão de produção OO foco é a eliminação de erros

O

Não faz parte do Scrum padrão

OMas é bem usado na prática

Programação eXtrema

XP

O

Metodologia de desenvolvimento de

software aperfeiçoada nos últimos 5 anos.

O

Ganhou notoriedade a partir da

OOPSLA’2000.

O

Nome principal: Kent Beck.

Reações a XP

O

Alguns odeiam, outros amam.

O

Quem gosta de programar ama!

O

Deixa o bom programador livre para fazer

o que ele faria se não houvesse regras.

O

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

3. Implementação

4. Testes

5. Produção / Manutenção

(9)

Premissas Básicas do Modelo

Tradicional

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

OÉ necessário fazer um estudo minucioso e elaborar uma descrição detalhada da

arquitetura antes de começar a implementá-la. OÉ necessário testar o sistema completamente

antes de mandar a versão final para o cliente.

O que está por trás deste

modelo?

Custo de mudança

s

requisitos desenho testes análise implementação produção

E se a realidade hoje em

dia fosse outra?

Custo de mudança

s

tempo

E se essa fosse a realidade?

O

A atitude dos desenvolvedores de

software seria completamente diferente:

OTomaríamos as grandes decisões o mais tarde possível.

OImplementaríamos agora somente o que precisamos agora.

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

E essa é a nova realidade !

(pelo menos em muitos casos)

O

Orientação a Objetos: facilita e cria

oportunidades para mudanças.

O

Técnicas de Refatoração.

O

Testes automatizados: nos dão

segurança quando fazemos mudanças.

O

Prática / cultura de mudanças:

aprendemos técnicas e adquirimos

experiência em lidar com código mutante.

A Quem se Destina XP?

O

Grupos de 2 a 10 programadores

O

Projetos de 1 a 36 meses (calendário)

O

De 1000 a 250 000 linhas de código

O

Papéis:

OProgramadores (foco central)(sem hierarquia) O“Treinador” ou “Técnico” (coach)

O“Acompanhador” (tracker) OCliente

(10)

E Se Eu Não Me Encaixo

Nesses Casos?

O

Você ainda pode aprender muito sobre

desenvolvimento de software.

O

Terá elementos para repensar as suas

práticas.

O

No início se dizia:

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

OXP is now like teenage sex.

O

Hoje não é mais necessariamente assim.

As 12 Práticas de XP

(versão 2000)

• Planejamento • Fases Pequenas • Metáfora • Design Simples • Testes • Refatoramento • Programação Pareada • Propriedade Coletiva • Integração Contínua • Semana de 40 horas

• Cliente junto aos desenvolvedores

• Padronização do código

Princípios Básicos de XP

OFeedback rápido

OSimplicidade é o melhor negócio OMudanças incrementais

OCarregue a bandeira das mudanças / não valorize o medo (Embrace change) OAlta qualidade

As 4 Variáveis do

Desenvolvimento de Software

• Tempo

• Custo

• Qualidade

• Escopo (foco principal de XP)

Um Projeto XP

O

Fase de Exploração

Oduração: até 20% do tempo total. Otermina quando a primeira versão do

software é enviada ao cliente.

Oclientes escrevem “historias” (story cards). Oprogramadores interagem com clientes e

discutem tecnologias.

ONão só discutem, experimentam diferentes tecnologias e arquiteturas para o sistema. OPlanejamento: 1 a 2 dias.

Histórias X casos de uso

O

Caso de uso: Autenticação caixa automático

OAtor: Cliente

ODescriçã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...

O

Várias historinhas

O O sistema mostra telas de boas vindas

O O sistema verifica se o cartão é válido

O Implementar sistema de leitura de senha

O Verificação de senha

O Releitura de senha se a mesma não confere

(11)

Um Dia na Vida de um

Programador XP

O

Escolhe uma história do cliente.

O

Procura um par livre.

O

Escolhe um computador para programação

pareada (

pair programming

).

O

Seleciona uma tarefa claramente

relacionada a uma característica (

feature

)

desejada pelo cliente.

Um Dia na Vida de um

Programador XP

O

Discute modificações recentes no sistema

O

Discute história do cliente

O

Testes

O

Implementação

O

Desenho

O

Integração

Um Dia na Vida de um

Programador XP

O

Atos constantes no desenvolvimento:

OExecuta testes antigos.

OBusca oportunidades para simplificação. OModifica desenho e implementação

incrementalmente baseado na funcionalidade exigida no momento.

OEscreve novos testes.

OEnquanto todos os testes não rodam a 100%, o trabalho não está terminado.

OIntegra novo código ao repositório.

Testes

O

Fundamento mais importante de XP.

O

É o que dá segurança e coragem ao grupo.

O

Testes de unidades

(Unit tests)

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

O

Testes de funcionalidades

(Functional tests)

Oescritos pelos clientes para testar a

funcionalidade do sistema.

Testes

O

Testes das unidades do sistema

OTem que estar sempre funcionando a 100%. OSão executados várias vezes por dia. OExecutados à noite automaticamente. O

Testes das funcionalidades

OVão crescendo de 0% a 100%.

OQuando chegam a 100% acabou o projeto.

O Código

O

Padrões de estilo adotados pelo grupo

inteiro.

O

O mais claro possível.

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

Comentários sempre que necessários.

O

Comentários padronizados.

(12)

Programação Pareada

OErro de um detectado imediatamente pelo outro (grande economia de tempo).

OMaior diversidade de idéias, técnicas, algoritmos. OEnquanto um escreve, o outro pensa em

contra-exemplos, problemas de eficiência, etc.

OVergonha de escrever código feio (gambiarras) na frente do seu par.

OPareamento de acordo com especialidades. • Ex.: Sistema Multimídia Orientado a Objetos

Propriedade Coletiva

do Código

O

Modelo tradicional: só autor de uma função

pode modificá-la.

O

XP: o código pertence a todos.

O

Se alguém identifica uma oportunidade

para simplificar, consertar ou melhorar

código escrito por outra pessoa, que o faça.

O

Mas rode os testes!

Refatoração

(Refactoring)

O

Uma [pequena] modificação no sistema

que não altera o seu comportamento

funcional

O

mas que melhora alguma qualidade

não-funcional:

Osimplicidade Oflexibilidade Oclareza Odesempenho

Exemplos de Refatoração

O

Mudança do nome de variáveis

O

Mudanças nas interfaces dos objetos

O

Pequenas mudanças arquiteturais

O

Encapsular código repetido em um novo

método

O

Generalização de métodos

•raizQuadrada(float x)⇒ raiz(float x, int n)

Sobre Refatoração

O

Catálogo de Refatorações de Martin

Fowler:

ORefactoring: Improvng the Design of Existing

Code. Addison-Wesley, 2000. O

Ferramentas para refatoração

automatizada embutidas no Eclipse,

Smalltalk Browser, Emacs, etc., etc.

O

www.refactoring.com

Cliente

O

Responsável por escrever “histórias”.

O

Muitas vezes é um programador ou é

representado por um programador do grupo.

O

Trabalha no mesmo espaço físico do grupo.

O

Novas versões são enviadas para produção

todo mês (ou toda semana).

O

Feedback

do cliente é essencial.

O

Requisitos mudam (e isso não é mau).

(13)

Coach

(treinador)

O

Em geral, o mais experiente do grupo.

O

Identifica quem é bom no que.

O

Lembra a todos as regras do jogo (XP).

O

Eventualmente faz programação pareada.

O

Não desenha arquitetura, apenas chama a

atenção para oportunidades de melhorias.

O

Seu papel diminui à medida em que o

time fica mais maduro.

Tracker

(Acompanhador)

OA “consciência” do time.

OColeta 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 OMantém histórico do progresso.

OFaz estimativas para o futuro.

Quando XP Não Deve Ser

Experimentada?

O

Quando o cliente não aceita as regras do jogo.

O

Quando o cliente quer uma especificação

detalhada do sistema antes de começar.

O

Quando os programadores não estão dispostos

a seguir (todas) as regras.

O

Se (quase) todos os programadores do time

são medíocres.

Quando XP Não Deve Ser

Experimentada?

O

Grupos grandes (>10 programadores).

O

Quando

feedback

rápido não é possível:

Osistema demora 6h para compilar. Otestes demoram 12h para rodar.

Oexigência de certificação que demora meses. O

Quando o custo de mudanças é

essencialmente exponencial.

O

Quando não é possível realizar testes

(muito raro).

Conclusão

Vencendo os Medos

O

Escrever código.

O

Mudar de idéia.

O

Ir em frente sem saber tudo sobre o futuro.

O

Confiar em outras pessoas.

O

Mudar a arquitetura de um sistema em

funcionamento.

O

Escrever testes.

As 12 Práticas de XP

(versão 2000)

• Planejamento • Fases Pequenas • Metáfora • Design Simples • Testes • Refatoramento • Programação Pareada • Propriedade Coletiva • Integração Contínua • Semana de 40 horas

• Cliente junto aos desenvolvedores

• Padronização do código

(14)

Práticas de XP

O

As práticas foram refatoradas

(veja www.extremeprogramming.org/rules.html) OMas a idéia é exatamente a mesma

ONovas práticas interessantes:

•Conserte XP quando a metodologia quebrar.

•Mova as pessoas.

•Client Proxy (by Klaus)

•Líbero (by Klaus)

Conclusão de XP

O

XP não é para todo mundo.

O

Mas todo mundo pode aprender com ela.

XP@Scrum



O

Aplicando XP com Scrum

OScrum: método de gerenciamento OXP: conjunto de práticas

O

Vantagens

OObjetivos por Sprint e não por história OEscalabilidade

OFácil implementação

Características Comuns dos

Métodos Ágeis

O

Coloca o foco

ONa entrega freqüente de sub-versões do software funcionando para o cliente.

ONos seres humanos que desenvolvem o software. O

Retira o foco de

OProcessos rígidos e burocratizados. ODocumentações e contratos detalhados. OFerramentas que são usadas pelos seres

humanos.

Maiores Informações

Prof. Dr. Fabio Kon [email protected] Prof. Dr. Alfredo Goldman [email protected]

www.ime.usp.br/~kon/presentations www.ime.usp.br/~gold

www.ime.usp.br/~xp www.xispe.com.br www.extremeprogramming.org