Programacao Extrema (Xp) Explicada

Autor(es): Kent Beck
Visualizações: 593
Classificação: (0)

Livro fora de catálogo

FORMATOS DISPONíVEIS

27 capítulos

Formato Comprar item avulso Adicionar à Pasta

1. Risco: O Problema Básico

PDF Criptografado

CAPÍTULO

1

Risco: O Problema Básico

O desenvolvimento de software tem falhas na entrega e falhas nos valores entregues. Essas falhas têm impactos econômicos e humanos enormes. Precisamos achar uma nova maneira de desenvolver software.

O

problema básico no desenvolvimento de software é o risco. A seguir estão alguns exemplos de risco:

• Deslizes no cronograma – o dia de entrega chega e você tem de dizer ao cliente que o software não ficará pronto antes de seis meses.

• Projeto cancelado – depois de vários deslizes, o projeto é cancelado sem ter chegado fase de produção.

• O sistema “azeda” – o software é colocado em fase de produção com sucesso, mas, depois de uns dois anos, o custo de se fazer modificações ou a taxa de erros cresce tanto que o sistema deve ser substituído.

• Taxa de erros – o software é colocado em fase de produção, mas a taxa de erros

é tão alta que ele não é usado.

• Negócio mal compreendido – o software é colocado em fase de produção, mas não resolve o problema original;

• Modificações nos negócios – o software é colocado em fase de produção, mas o problema de negócio cuja resolução para o software foi projetado foi substituído seis meses atrás por um outro problema de negócios mais urgente.

 

2. Um Episódio de Desenvolvimento

PDF Criptografado

CAPÍTULO

2

Um Episódio de Desenvolvimento

A programação quotidiana inicia-se com uma tarefa conectada de forma clara a uma funcionalidade que o cliente deseja, segue com testes, passando pela implementação e pelo projeto, terminando na integração. Um pouco de cada uma das atividades do desenvolvimento de software está incluída em cada episódio.

A

ntes, porém, daremos uma pequena amostra de aonde estamos indo. Este capítulo é a história do pulso da XP – o episódio de desenvolvimento. Aqui o programador implementa uma tarefa de engenharia (a menor unidade do cronograma) e a integra com o resto do sistema.

Eu olho para a minha pilha de cartões de tarefas. O primeiro deles diz “Exportar retenções deste trimestre”. Na reunião em pé desta manhã, lembro de você ter dito que tinha terminado o cálculo do trimestre. Eu pergunto se você (meu colega hipotético) tem tempo para me ajudar a exportar. “Claro”, você responde. A regra diz que se você recebe um pedido de ajuda, você precisa dizer “sim”. Nós acabamos de nos tornar parceiros de programação.

 

3. A Economia no Desenvolvimento de Software

PDF Criptografado

CAPÍTULO

3

A Economia no

Desenvolvimento de Software

Precisamos desenvolver nosso software economicamente mais valioso gastando dinheiro mais devagar, obtendo rendimento mais rapidamente e aumentando a provável expectativa de vida produtiva do nosso projeto. Mas o mais importante de tudo é aumentar as opções de decisões de negócios.1

S

omando as entradas e saídas do fluxo de caixa do projeto, podemos analisar de forma simples o que torna o projeto de software valioso. Levando em consideração o efeito das taxas de juros, podemos calcular o valor líquido atualizado dos fluxos de caixa. Podemos refinar nossas análises multiplicando os fluxos de caixa descontados pela probabilidade do projeto sobreviver para pagar ou ganhar aqueles fluxos de caixa.

Com estes três fatores,

• entrada e saída do fluxo de caixa

• taxa de juros

• mortalidade do projeto

podemos criar uma estratégia para maximizar o valor econômico do projeto. Podemos fazer isso:

• gastando menos, o que é difícil porque todo mundo começa com mais ou menos as mesmas ferramentas e habilidades;

 

4. Quatro Variáveis

PDF Criptografado

CAPÍTULO

4

Quatro Variáveis

Vamos controlar quatro variáveis em nossos projetos – custo, tempo, qualidade e escopo. Dentre estas, o escopo nos fornece a forma mais valiosa de controle.

T

emos aqui um modelo de desenvolvimento de software através da perspectiva de um sistema de variáveis de controle. Neste modelo, existem quatro variáveis no desenvolvimento de software:

• custo

• tempo

• qualidade

• escopo

A forma como o jogo de desenvolvimento de software é jogado neste modelo é a seguinte: forças externas (clientes, gerentes) ficam encarregadas de definir os valores de três dessas variáveis. O time de desenvolvimento fica com o valor resultante da quarta variável.

Alguns gerentes e clientes acreditam que podem definir o valor de todas as quatro variáveis. “Você vai terminar estes requisitos até o primeiro dia do próximo mês com exatamente esta equipe. E a qualidade é fator primordial aqui, então o produto terá o nosso padrão habitual.” Quando isso acontece, a qualidade sempre desaparece (o que, na verdade, é o padrão habitual), já que ninguém faz um bom trabalho sob muito estresse. É provável também que o tempo fique fora de controle. Você obtém um software de baixa qualidade, e atrasado.

 

5. O Custo das Modificações

PDF Criptografado

40

PROGRAMAÇÃO EXTREMA EXPLICADA

Eu decidi naquele momento que nunca deixaria um problema chegar até a fase de produção. Não senhor, eu iria encontrar os problemas o mais cedo possível. Resolveria cada possível problema antecipadamente. Eu iria ver e rever meu código. De jeito nenhum eu iria custar ao meu empregador U$ 100.000.

O problema é que essa curva não é mais válida. Ou melhor, com uma combinação de tecnologia e práticas de programação, é possível obter uma curva que é bem o contrário disso. Hoje em dia, as histórias são possivelmente como a seguinte, que aconteceu comigo recentemente em um sistema de gerenciamento de contratos de seguro de vida.

17:00 – Descubro que aparentemente a maravilhosa função do nosso sistema com a qual uma única transação pode ter débitos de muitas contas e créditos para muitas contas simplesmente não é usada. Cada transição vem de uma conta e vai para outra. É possível simplificar o sistema como mostra a Figura 2?

17:02 – Peço para Massimo sentar-se comigo para examinar a situação. Escrevemos uma consulta. Cada uma das 300 mil transações no sistema tem uma única conta de débito e uma única conta de crédito.

 

6. Aprendendo a Dirigir

PDF Criptografado

CAPÍTULO

6

Aprendendo a Dirigir

Precisamos controlar o desenvolvimento de software fazendo muitos pequenos ajustes, e não uns poucos grandes ajustes, tal qual como quando conduzimos um carro. Isso significa que nós precisaremos de feedback para saber quando estamos saindo do caminho, precisaremos de muitas oportunidades para fazer correções além de fazer essas correções a um custo razoável.

A

gora nós já temos a forma geral do problema – o custo extremamente elevado do risco e a oportunidade de gerenciar esse risco por meio de opções – e do recurso necessário para formar a solução: a liberdade para fazer modificações mais tarde durante o ciclo sem aumentar o custo significativamente. Agora precisamos nos focar na solução. A primeira coisa de que precisamos é uma metáfora, uma história compartilhada, para a qual podemos voltar em períodos de estresse ou de decisão nos ajudar a mantermos o caminho certo.

Lembro-me claramente do dia em que comecei a aprender a dirigir. Minha mãe e eu estávamos na Rodovia Interestadual 5, perto de Chico, na Califórnia, um trecho de estrada reto e nivelado que se perde no horizonte. Eu estava no assento do passageiro e minha mãe fez com que eu segurasse o volante. Ela me deixou sentir como o movimento do volante afetava a direção do carro. E então ela me disse: “É assim que se dirige. Alinhe o carro no meio da pista, em direção ao horizonte”.

 

7. Quatro Valores

PDF Criptografado

CAPÍTULO

7

Quatro Valores

Nós teremos êxito quando tivermos um estilo que contempla um conjunto consistente de valores que servem para necessidades tanto humanas quanto comerciais: comunicação, simplicidade, feedback e coragem.

A

ntes que possamos transformar a história sobre aprender a dirigir em um conjunto de práticas para desenvolvimento de software, precisamos de algum parâmetro para saber se estamos no caminho certo. De nada adiantaria inventar um novo estilo de desenvolvimento para, no final, descobrir que não gostamos dele ou que ele não funciona.

Metas individuais de curto prazo freqüentemente entram em conflito com metas sociais de longo prazo. As sociedades aprenderam a lidar com esse problema desenvolvendo um conjunto de valores a serem compartilhados, apoiados por mitos, rituais, punições e recompensas. Sem esses valores, o homem tende a voltar-se para seus próprios interesses de curto prazo.

Os quatro valores da XP são:

• comunicação

• simplicidade

• feedback

• coragem

Comunicação

O primeiro valor da XP é a comunicação. Quando analisamos os problemas que ocorreram nos projetos, vemos que muitos deles foram provocados por alguém que não conversou com outro alguém sobre alguma coisa importante. Algumas vezes, o programador não fala para os outros sobre uma mudança fundamental no projeto.

 

8. Princípios Básicos

PDF Criptografado

CAPÍTULO

8

Princípios Básicos

A partir dos quatro valores, nós derivamos aproximadamente uma dúzia de princípios para guiar nosso novo estilo. Vamos conferir as práticas de desenvolvimento propostas para ver se elas estão à altura desses princípios.

O

capítulo Aprendendo a Dirigir nos aconselha a fazer diversas pequenas mudanças e a nunca desviar os olhos da estrada. Os quatro valores – comunicação, simplicidade, feedback e coragem – nos dão os critérios para uma solução de sucesso. No entanto, os valores são muito vagos para nos ajudar a decidir quais práticas usar. Precisamos transformar os valores em princípios concretos que possam ser usados.

Esses princípios vão nos ajudar a escolher entre as alternativas. Daremos preferência às alternativas que melhor atendam aos princípios. Cada princípio incorpora os valores. Um valor pode ser vago. O que é simples para uma pessoa pode ser complexo para outra. Um princípio é mais concreto. Ou você tem feedback rápido ou não.

Aqui estão os princípios fundamentais:

 

9. De Volta ao Básico

PDF Criptografado

CAPÍTULO

9

De Volta ao Básico

Queremos fazer tudo que for necessário para ter um desenvolvimento de software estável e previsível. Porém, não temos tempo para nada extra.

As quatro atividades básicas do desenvolvimento são codificar, testar, escutar e projetar.

O

capítulo Aprendendo a Dirigir mais os quatro valores – comunicação, simplicidade, feedback e coragem – nos fornecem diversos princípios. Agora estamos prontos para começar a construir uma disciplina de desenvolvimento de software. O primeiro passo é decidir sobre o escopo. O que tentaremos prescrever?

Que tipo de problemas iremos abordar e que tipo de problemas iremos ignorar?

Lembro-me de quando comecei a programar em BASIC. Eu tinha alguns livros de exercícios que cobriam os fundamentos da programação. Quando eu terminei todos os exercícios (o que não demorou muito) eu queria tentar resolver um problema mais desafiador. Resolvi que tentaria escrever um jogo tipo Star Trek, parecido com o que eu tinha jogado no Lawrence Hall of Science em Berkeley, mas mais divertido.

 

10. Uma Rápida Visão Geral

PDF Criptografado

66

PROGRAMAÇÃO EXTREMA EXPLICADA

Primeiramente, aqui estão todas as práticas:

• O Jogo do Planejamento – Determine brevemente o escopo da próxima versão combinando prioridades de negócio e estimativas técnicas. Quando a realidade se opuser ao planejamento, atualize o planejamento.

• Entregas freqüentes – Coloque um sistema simples rapidamente em produção , e depois libere novas versões em ciclos curtos.

• Metáfora – Guie o desenvolvimento com uma simples história, compartilhada por todos, sobre como o sistema funciona como um todo.

• Projeto simples – O sistema deve ser projetado da maneira mais simples possível em qualquer momento. A complexidade desnecessária é removida assim que for descoberta.

• Testes – Os programadores escrevem testes de unidade continuamente, os quais devem executar sem falhas para que o desenvolvimento prossiga. Os clientes escrevem testes demonstrando que as funções estão terminadas.

• Refatoração – Os programadores reestruturam o sistema sem alterar seu comportamento a fim de remover duplicidade, melhorar a comunicação, simplificar e acrescentar flexibilidade.

 

11. Como Isso Poderia Dar Certo?

PDF Criptografado

CAPÍTULO

11

Como Isso Poderia Dar Certo?

As práticas apóiam umas às outras. O ponto fraco de uma é compensada pelos pontos fortes das outras.

M

as espere aí! Nenhuma das práticas descritas anteriormente é única ou original. Todas têm sido usadas desde a codificação dos primeiros programas.

Quando os seus pontos fortes tornaram-se aparentes, a maioria deles foi abandonada por práticas mais complicadas e mais caras. Então por que a XP não é uma abordagem simplista do software? Antes de continuarmos, é melhor convencermos a nós mesmos de que essas práticas simples não nos prejudicarão como prejudicaram os projetos de software a décadas atrás.

O colapso da curva exponencial do custo das modificações trouxe todas essas práticas de volta ao jogo. Cada uma dessas práticas tem os mesmos pontos fracos de antes, mas e se esses pontos fracos fossem agora compensados pelos pontos fortes das outras práticas? Nós talvez possamos ir adiante fazendo as coisas de maneira simples.

Este capítulo apresentará as práticas sob uma outra perspectiva, desta vez focada no que normalmente torna a prática insustentável e mostrando como as outras práticas impedem que os seus efeitos negativos sobrecarreguem o projeto. Este capítulo também apresenta como toda a história da XP poderia dar certo.

 

12. Estratégia de Gerenciamento

PDF Criptografado

CAPÍTULO

12

Estratégia de Gerenciamento

Vamos gerenciar o projeto como um todo usando princípios básicos de negócios – entrega em fases, feedback concreto e rápido, articulação clara das necessidades dos negócios do sistema e o uso de especialistas para tarefas especiais.

O

dilema do gerenciamento: por um lado, você gostaria que o gerente tomasse todas as decisões. Não há degradação de comunicação porque há apenas uma pessoa. Uma pessoa será responsável pelo gerenciamento superior.

Uma pessoa terá a visão. Mais ninguém precisa estar a par disso, porque todas as decisões virão de uma só pessoa.

Sabemos que essa estratégia não funciona, porque uma única pessoa não sabe o suficiente para tomar todas as decisões corretas. Estratégias de gerenciamento que são balanceadas no sentido de um controle centralizado são também difíceis de executar, porque requerem muito desgaste daqueles que estão sendo gerenciados.

Por outro lado, a estratégia oposta também não funciona. Você não pode simplesmente deixar que todos façam o que quiserem, sem supervisão. As pessoas inevitavelmente saem pela tangente. Alguém precisa ter uma visão maior do projeto e ser capaz de influenciá-lo quando ele sai de curso.

 

13. Estratégia de Ambiente de Trabalho

PDF Criptografado

CAPÍTULO

13

Estratégia de Ambiente de Trabalho

Criaremos uma área de trabalho aberta para o nosso time, com pequenos espaços privados nas áreas periféricas e uma área comum de programação no meio.

S

obre a Figura 5, Ron Jeffries comenta:

Essa figura nos mostra a área de trabalho do time do projeto C3 da

Folha de Pagamento da DaimlerChrysler. Duas grandes mesas com seis máquinas de desenvolvimento em cada uma delas. Pares de programadores sentam-se a qualquer máquina disponível para fazer seu trabalho. (Eles não posaram para essa foto, eles realmente trabalham juntos como mostra a imagem. O fotógrafo estava trabalhando com Chet, na mesa de trás, de costas para a câmera).

Nas duas paredes visíveis, estão quadros brancos que mostram testes funcionais que precisam de atenção, sessões CRC planejadas e, no quadro ao fundo, o Plano de Interação. As folhas de papel coladas acima dos quadros na esquerda são pequenas placas contendo as regras XP do grupo.

As paredes da esquerda e abaixo da câmera dispõem de pequenos cubículos, grandes o suficiente para caberem um telefone e um bloco de anotações.

 

14. Dividindo as Responsabilidades Técnicas e de Negócios

PDF Criptografado

CAPÍTULO

14

Dividindo as Responsabilidades

Técnicas e de Negócios

Outro ponto-chave da nossa estratégia é manter o pessoal técnico focado nos problemas técnicos e as pessoas de negócios focadas nos problemas de negócios. O projeto precisa ser dirigido pelas decisões de negócio, mas elas precisam ser informadas pelas decisões técnicas sobre custo e risco.

E

xistem dois modos comuns de errar na relação entre os Negócios e o Desenvolvimento. Se um deles ganha tiver demais, o projeto é prejudicado.

Os Negócios

Se os Negócios têm o poder, eles sentem que é apropriado determinar todas as quatro variáveis para o Desenvolvimento. “Isto é o que você vai fazer. Esta é a data em que tem que estar pronto. Não, você não vai ter nenhuma workstation nova. E é bom que seja da mais alta qualidade, ou vai sobrar pra você, malandro!”.

Neste cenário, os Negócios sempre definem demais. Alguns dos itens da lista de requisitos são absolutamente essenciais. Mas outros não são. E se o Desenvolvimento não tiver nenhum poder, ele não pode se opor; não podem forçar os Negócios a decidir qual é qual. Então o Desenvolvimento vai trabalhar obedientemente, de cabeça baixa, na tarefa impossível que lhe foi dada.

 

15. Estratégia de Planejamento

PDF Criptografado

CAPÍTULO

15

Estratégia de Planejamento

Planejaremos definindo rapidamente um plano geral, e então o refinaremos em períodos cada vez mais curtos – anos, meses, semanas, dias.

Faremos o plano de maneira rápida e barata, de forma que haverá pouca inércia quando precisarmos mudá-lo.

P

lanejar é o processo de adivinhar como será desenvolver um software com um cliente. Alguns dos propósitos do planejamento são:

• unir o time;

• decidir o escopo e as prioridades;

• estimar custo e cronograma;

• dar a todos a confiança de que o sistema realmente pode ser feito;

• prover parâmetros (benchmark) para feedback.

Vamos recapitular os princípios que afetam o planejamento. (Alguns deles são princípios gerais do Capítulo 8 – Princípios Básicos. Outros são específicos do planejamento.)

• Faça apenas o planejamento necessário para o próximo período – usando qualquer nível de detalhamento, planeje apenas para o próximo período – ou seja, a próxima versão, o fim da próxima iteração. Isso não quer dizer que você não possa planejar a longo prazo. Você pode, mas não com muitos detalhes.

 

16. Estratégia de Desenvolvimento

PDF Criptografado

CAPÍTULO

16

Estratégia de Desenvolvimento

Ao contrário da estratégia de gerenciamento, a estratégia de desenvolvimento é um desvio radical da sabedoria convencional – nós cuidadosamente criaremos hoje a solução para os problemas de hoje, e acreditaremos que seremos capazes de resolver amanhã os problemas de amanhã.

A

XP usa a metáfora da programação para suas atividades – ou seja, tudo que você faz se parece, de alguma forma, com programação: programar em XP é como programar, com o acréscimo de algumas pequenas coisas, como testes automatizados. Entretanto, como o resto da XP, o desenvolvimento XP é enganosamente simples. Todas as partes são simples o suficiente para explicar, mas executálas é difícil. O medo surge. Sob pressão, velhos hábitos reaparecem.

A estratégia de desenvolvimento começa com o planejamento de iteração. A integração contínua reduz conflitos de desenvolvimento e cria um desfecho natural para um episódio de desenvolvimento. A propriedade coletiva encoraja todo o time a fazer todo o sistema de forma melhor. Finalmente, a programação em pares amarra o processo como um todo.

 

17. Estratégia de Projeto

PDF Criptografado

CAPÍTULO

17

Estratégia de Projeto

Continuamente nós refinaremos o projeto do sistema, partindo de um começo muito simples. Retiraremos todas as flexibilidades que não se provarem úteis.

D

e muitas maneiras, este é o capítulo mais difícil de escrever. A estratégia de projeto da XP é sempre ter o projeto mais simples que execute o conjunto de testes atual.

Bem, não foi tão ruim assim. O que há de errado com simplicidade? O que há de errado com conjuntos de testes?

A Coisa Mais Simples que Poderia Funcionar

Vamos voltar um pouco e aproximar-nos dessa resposta passo a passo. Todos os quatro valores fazem parte desta estratégia:

• Comunicação – Um projeto complicado é mais difícil de ser comunicado do que um simples. Devemos, portanto, criar uma estratégia de projeto que resulte no projeto mais simples possível, consistente com os nossos demais objetivos. Por outro lado, devemos criar uma estratégia de projeto que gere projetos comunicativos, em que os elementos do projeto comuniquem ao leitor aspectos importantes do sistema.

 

18. Estratégia de Testes

PDF Criptografado

CAPÍTULO

18

Estratégia de Testes

Escreveremos os testes antes de codificar, minuto a minuto. Preservaremos esses testes para sempre, e executaremos todos eles juntos freqüentemente. Também derivaremos testes sob a perspectiva do cliente.

Q

ue chato. Ninguém quer falar sobre testes. Teste é o enteado feioso do desenvolvimento de software. A questão é que todos sabem que testar é importante. Todos sabem que não fazem testes suficientes. E nós sentimos isso – nossos projetos não vão tão bem quanto deveriam, e sentimos que mais testes poderiam resolver o problema. Mas, então, nós lemos um livro sobre testes e ficamos atolados nos vários tipos e maneiras de testes. Não há como fazer tudo aquilo e ainda conseguir desenvolver algo.

Vejamos como são os testes na XP. Toda vez que um programador escreve um código, ele imagina que vai funcionar. Assim, toda vez que ele imagina que um código vai funcionar, ele pega essa confiança que surgiu do nada e a transforma em um artefato que é inserido no programa. A confiança lá fica, para o seu próprio uso. E porque ela está no programa, todos os outros também podem usá-la.

 

Carregar mais


Detalhes do Produto

Livro Impresso
Book
Capítulos

Formato
PDF
Criptografado
Sim
SKU
B000000042500
ISBN
9788577803064
Tamanho do arquivo
1,1 MB
Impressão
Desabilitada
Cópia
Desabilitada
Vocalização de texto
Não
Formato
PDF
Criptografado
Sim
Impressão
Desabilitada
Cópia
Desabilitada
Vocalização de texto
Não
SKU
Em metadados
ISBN
Em metadados
Tamanho do arquivo
Em metadados