UNIVERSIDADE FEDERAL DO RIO DE JANEIRO NCLEO DE COMPUTAO ELETRNICA

UM ESTUDO DE CASO DA ADOO DAS PRTICAS E VALORES DO EXTREME PROGRAMMING

VINCIUS MANHES TELES

IM-NCE/UFRJ Mestrado em Informtica

Orientador: Carlo Emmmanoel Tolla de Oliveira, Ph.D.

Rio de Janeiro 2005

Copyright (C) 2005 by Vincius Manhes Teles (vinicius@improveit.com.br) permitido fazer cpias exatas e distribuir este documento em qualquer meio, desde que esta nota seja preservada. Pede-se que correes ou comentrios sejam sempre enviados para o autor. permitido criar e distribuir trabalhos derivados deste, desde que o trabalho original seja mencionado. Esse documento pode ser obtido na Internet no endereo: http://www.improveit.com.br/xp/dissertacaoXP.pdf

UM ESTUDO DE CASO DA ADOO DAS PRTICAS E VALORES DO EXTREME PROGRAMMING

VINCIUS MANHES TELES

Dissertao submetida ao corpo docente da Coordenao do Instituto de Matemtica e Ncleo de Computao Eletrnica da Universidade Federal do Rio de Janeiro - UFRJ, como parte dos requisitos necessrios obteno do grau de Mestre em Informtica.

Aprovada por: Prof.________________________________ (Orientador) Carlo Emmanoel Tolla de Oliveira, Ph.D., UFRJ

Prof.________________________________ Lgia Alves Barros, D.Sc., UFRJ

Prof.________________________________ Alfredo Goldman vel Lejbman, Ph. D., USP

Rio de Janeiro, 28 de maro de 2005

MANHES TELES, VINCIUS.

UM ESTUDO DE CASO DA ADOO DAS PRTICAS E VALORES DO EXTREME PROGRAMMING / Vincius

Manhes Teles. Rio de Janeiro: UFRJ / IM / DCC, 2005. 180 pp. Dissertao (Mestrado em Informtica) Universidade Federal do Rio de Janeiro - UFRJ, IM / DCC, 2005. Orientador: Prof. Carlo Emmanoel Tolla de Oliveira 1. Extreme Programming. 2. Engenharia de Software. I. IM/NCE/UFRJ. II. Ttulo (srie).

AGRADECIMENTOS

minha esposa, Patrcia Figueira, por sua enorme pacincia, por todas as noites em que se privou da minha companhia, por suportar meu mau humor na correria da ltima hora, por todas as alegrias que preenchem o nosso dia-a-dia e pelo seu apoio incondicional. Ao meu orientador, Prof. Carlo Emmanoel Tolla de Oliveira por aceitar e apoiar o tema da dissertao, pelas sugestes de leitura, pela disponibilidade e pelas observaes. Profa. Ligia Alves Barros por seus ensinamentos, pacincia, disponibilidade e, sobretudo, pelas inmeras crticas construtivas que fez em torno deste trabalho. Ao Prof. Alfredo Goldman vel Lejbman pela disponibilidade de vir ao Rio de Janeiro para a defesa desta dissertao, pelo tempo dedicado e pelo trabalho que vem executando na disseminao do XP no Brasil. Ao Oswaldo Areal, do Grupo XP Rio, que pacientemente revisou grande parte do texto. Aos meus alunos do curso de Cincia da Computao da UFRJ que, atravs de seus questionamentos, me levaram a estudar mais, pesquisar mais, e aprimorar meus conhecimentos sobre Extreme Programming. Aos meus amigos Rodrigo Fernandes, Gilson Tavares, Renato Fiche Junior, Maurcio Emanuel Dourado Cescato e Eduardo Bastos Leite por questionarem o XP inicialmente e forarem o aprimoramento de minha argumentao. E, mais tarde, por apoiarem a aplicao do XP de forma entusistica e determinada.

4 A toda a equipe da Improve It, pela coragem de adotar o XP, pelo talento demonstrado na utilizao das prticas, por acreditar, por tentar, por melhorar continuamente e por mostrar que possvel conduzir projetos de software com XP de maneira primorosa. Sobretudo, obrigado por todas as vezes que vocs conseguiram, usando o XP, facilitar a vida de nossos clientes. Aos clientes da Improve It, por nos concederem a oportunidade de experimentar o XP. comunidade XP do Brasil, que atravs de encontros, congressos e discusses na Internet me ajudaram a consolidar o aprendizado que deu origem a este trabalho. Aos companheiros da comunidade internacional Kent Beck, Mary Poppendieck, Ron Jeffries, Ward Cunningham e Laurie Williams, por tudo o que aprendi com vocs em nossos encontros e atravs de suas publicaes. Ao meu editor, Rubens Prates, da Novatec Editora, pela oportunidade que me concedeu de escrever um livro sobre XP. Aos funcionrios da Secretaria do Departamento de Cincia da Computao do IM/UFRJ, em especial querida Tia Deise Lobo Cavalcante pelo seu carinho e ateno ao longo de todo o mestrado e da graduao. Aos funcionrios da Biblioteca do Ncleo de Computao Eletrnica da UFRJ, em especial a Raquel de Melo Porto, pela presteza, profissionalismo e por me ajudarem a localizar e obter os artigos de que necessitei. Finalmente, um muitssimo obrigado a minha me, Vera Lcia Martins Manhes, por ter criado e cultivado todas as condies para que eu chegasse at aqui. E por tantas outras coisas que jamais poderei agradecer suficientemente.

RESUMO

TELES, Vincius Manhes, Um Estudo de Caso da Adoo das Prticas e Valores do Extreme Programming. Orientador: Carlo Emmanoel Tolla de Oliveira. Rio de Janeiro : UFRJ/IM, 2005. Dissertao (Mestrado em Informtica).

Estudos demonstram que a maioria dos projetos de software falha, seja porque no cumprem o oramento, ou no cumprem o cronograma, ou as funcionalidades no atendem s necessidades dos usurios ou porque todos estes fatores esto presentes em conjunto. Este trabalho prope que a adoo do conjunto formado pelas prticas e valores do Extreme Programming possa fornecer um mecanismo eficaz para elevar as chances de sucesso em diversos projetos de software. Como forma de validao, se conduziu uma detalhada reviso da literatura e um estudo de caso apresentado, no qual o Extreme Programming foi utilizado durante o perodo de um ano em um projeto comercial com resultados positivos.

ABSTRACT

TELES, Vincius Manhes, Um Estudo de Caso da Adoo das Prticas e Valores do Extreme Programming. Orientador: Carlo Emmanoel Tolla de Oliveira. Rio de Janeiro : UFRJ/IM, 2005. Dissertao (Mestrado em Informtica).

Previous works show that the majority of software projects fail due to over budget, delays, features that don't address stakeholders needs or all of these issues together. This work proposes the adoption of Extreme Programmings set of practices and values as a way to improve the chances of success in several software projects. In order to validate this proposal, a detailed research has been conducted and a study case is presented in which Extreme Programming has been used for one year in a commercial project with positive results.

SUMRIO

p.

1 INTRODUO

2 A CRISE DO SOFTWARE

12

3 A NATUREZA DO SOFTWARE 3.1 Complexidade 3.2 Conformidade 3.3 Maleabilidade 3.4 Invisibilidade 3.5 Inexistncia de princpios bsicos 3.6 Rpida evoluo tecnolgica 3.7 Baixo custo de manufatura 4 METFORAS E O DESENVOLVIMENTO DE SOFTWARE 4.1 A indstria de produo em massa 4.2 O desenvolvimento de software como trabalho do conhecimento 4.3 A produo enxuta

17 17 19 20 21 22 22 22 25 26 30 38

8 4.4 Processos de desenvolvimento de software 5 EXTREME PROGRAMMING 5.1 Valores 5.2 Prticas 6 ESTUDO DE CASO 6.1 Introduo 6.2 Portal de Aprimoramento Esportivo 6.3 Extreme Programming no projeto 6.4 Modelo Conceitual de Aferio de Habilidades 6.5 Tratamento de Mudanas no Sistema de Atletas 6.6 Integrao com o Sistema de Treinos 6.7 Cadastros 6.8 Relatrios 6.9 Histrico de Ciclos Passados 6.10 Documentao 6.11 Anlise de cada prtica do XP no projeto 6.12 Quadro de Acompanhamento Dirio 6.13 Consideraes finais 7 CONCLUSO 47 55 57 69 125 125 126 128 129 133 136 142 145 147 150 151 163 171 174

1 INTRODUO
Desenvolver software uma atividade arriscada. Segundo as estatsticas, os maiores riscos so: Gastos que superam o oramento; Consumo de tempo que supera o cronograma; Funcionalidades que no resolvem os problemas dos usurios e Baixa qualidade dos sistemas desenvolvidos.

H algumas dcadas a indstria de software vem buscando tcnicas de desenvolvimento que possam reduzir os riscos dos projetos de software e tornar essa atividade mais produtiva. Um marco neste sentido a criao da disciplina de Engenharia de Software em 1968. De l para c, inmeras propostas foram feitas para melhorar o desempenho dos projetos, comeando pelo processo de desenvolvimento linear e seqencial (em cascata) desenvolvimento. O Extreme Programming (XP) um dos representantes destes processos e foi criado por Kent Beck em 1997 em um projeto para a Chrysler (fabricante de veculos norte-americana). O XP composto por um conjunto reduzido de prticas de desenvolvimento que se organizam em torno de quatro valores bsicos. Essas prticas possuem fortes inter-relacionamentos formando um conjunto de elevada sinergia. Esta dissertao se prope a mostrar que este conjunto de prticas pode representar uma forma eficaz de melhorar o desempenho de diversos projetos de software. Em particular, visa demonstrar que embora as prticas sejam teis isoladamente, a caracterstica mais importante do XP o conjunto. Assim, se optou por at chegar aos atuais processos geis de

10

fazer um trabalho mais amplo, envolvendo todas as prticas e no apenas uma anlise isolada de algumas delas. Para isso, fez-se uma detalhada reviso da literatura, buscando justificar cada uma das prticas sugeridas pelo XP e enfatizando o forte relacionamento de interdependncia entre elas. Alm disso, apresentado um estudo de caso de um projeto que utilizou todas estas prticas por mais de um ano. O Extreme Programming no nasceu no meio acadmico e, embora existam conferncias dedicadas ao assunto h alguns anos, o nmero de publicaes ainda reduzido quando comparado ao de outras reas da Informtica. Na indstria, os resultados de sua adoo tm sido animadores, mas a comunidade cientfica tem demonstrado um posicionamento ctico visto que diversas prticas propostas contrariam conceitos amplamente difundidos e utilizados tanto nas universidades, quanto na indstria. Dada a controvrsia existente em torno do XP, optou-se por realizar uma reviso de literatura criteriosa e to embasada quanto possvel em autores e trabalhos de prestgio. Por esta razo, os captulos se utilizam intencionalmente de um elevado nmero de citaes com o objetivo de apresentar bases tericas relevantes para a adoo dos valores e prticas propostos pelo Extreme Programming. O segundo captulo apresentar uma anlise dos problemas recorrentes que esto presentes na maioria dos projetos de software h algumas dcadas. Em seguida, o terceiro captulo far uma anlise da natureza do desenvolvimento de software com o objetivo de compreender quais so as maiores dificuldades que afetam os desenvolvedores de sistemas. O quarto captulo analisar a forma como as solues para os projetos de software vm sendo organizadas ao longo do tempo. Elas se baseiam em

11

metforas que precisam ser compreendidas e analisadas para estabelecer a validade de utiliz-las. O quinto captulo apresentar os valores e prticas do Extreme Programming. O sexto captulo apresentar o estudo de caso e finalmente o stimo captulo far a concluso da dissertao.

12

2 A CRISE DO SOFTWARE
O termo crise do software vem sendo usado na indstria de software desde 1968, quando houve a primeira admisso aberta da existncia de uma crise latente na rea (DIJKSTRA, 1972, traduo nossa). Naquele ano, ocorreu a Conferncia da OTAN sobre Engenharia de Software (NATO Software Engineering Conference) em Garmisch, Alemanha, que considerado atualmente o momento histrico do nascimento da disciplina de Engenharia de Software (BRYANT, 2000; EISCHEN, 2002). Diversos autores utilizam o termo crise do software, embora alguns o faam com alguma ressalva, como o caso de Pressman (1997, p.16, traduo nossa) que considera que temos uma crise que vem nos acompanhando h 30 anos e essa uma contradio de termos. (...) O que ns temos de fato uma calamidade crnica. O Standish Group, uma empresa localizada em Massachusetts, EUA, publica desde 1994 um estudo chamado de CHAOS Report. Trata-se de um amplo levantamento envolvendo milhares de projetos na rea de tecnologia da informao. Atualmente, seus dados esto entre os mais utilizados para quantificar a crise do software. O CHAOS Report do ano 2000 (THE STANDISH GROUP INTERNATIONAL, 2001) apresenta uma coletnea de dados envolvendo 280 mil projetos de software nos Estados Unidos, os quais revelaram que: Em mdia, os atrasos representaram 63% mais tempo do que o estimado; Os projetos que no cumpriram o oramento custaram em mdia 45% mais e No geral, apenas 67% das funcionalidades prometidas foram efetivamente entregues.

13

O Standish Group classifica o resultado final de um projeto nas seguintes categorias: Mal sucedido; Comprometido e Bem sucedido.

Em 2000, o resultado final da pesquisa mostrou a seguinte distribuio entre os projetos:

Figura 2.1: estatstica sobre o resultado final de projetos de software. Tais nmeros, embora desastrosos, mostram um avano em relao aos resultados do primeiro levantamento realizado em 1994:

14

Figura 2.2: evoluo do resultado final de projetos de software ao longo dos anos. Na terceira Conferncia Internacional sobre Extreme Programming, que ocorreu na Itlia em 2002, Jim Johnson, presidente do Standish Group, apresentou um estudo revelador sobre a utilizao das funcionalidades nos projetos que foram pesquisados pelo Standish Group (JOHNSON, 2002). Os resultados demonstram que 45 por cento das funcionalidades encontradas em um sistema tpico jamais so usadas e 19 por cento raramente so usadas:

15

Figura 2.3: estatstica sobre a utilizao de funcionalidades. Alm de as estatsticas mostrarem, em nmeros, o significado do que vem sendo chamado h quase quarenta anos de crise do software, a anlise de casos isolados demonstra a existncia de grandes variaes nos resultados dos projetos. o caso, por exemplo, de dois sistemas desenvolvidos na rea governamental dos EUA. H alguns anos, os estados americanos da Flrida e Minnesota se lanaram no desafio de criar um Sistema de Informaes para o Bem Estar das Crianas (Statewide Automated Child Welfare Information System SACWIS). Cada estado adotou uma abordagem distinta e a diferena de resultados significativa. Na Florida, o desenvolvimento do sistema teve incio em 1990 e foi estimado em oito anos a um custo de US$ 32 milhes. Em 2002, a Florida j havia gasto US$ 170 milhes e o sistema foi re-estimado para ser finalizado em 2005 a um custo de US$ 230 milhes. Por sua vez, Minnesota comeou a desenvolver essencialmente o mesmo sistema em 1999 e o finalizou no incio de 2000 ao custo de US$ 1,1 milho. A diferena de produtividade de 200:1(POPPENDIECK & POPPENDIECK, 2003).

16

Ao analisar os fatores que levam tantos projetos de software a fracassarem e outros (poucos) a serem bem sucedidos, relevante avaliar o que significa desenvolver um software. Quais so os fatores que caracterizam o desenvolvimento de software e diferenciam os projetos desta rea?

17

3 A NATUREZA DO SOFTWARE
A compreenso dos fatores que levam crise do software passa primeiramente pela compreenso da natureza do software e como ele vem sendo tratado ao longo dos anos. Essa anlise envolve duas partes: os aspectos bsicos que caracterizam o software e as metforas que so utilizadas no desenvolvimento do mesmo. O estudo detalhado do software aponta para as seguintes caractersticas (BROOKS, 1995; BRYANT, 2000; BUHRER, 2000; KRUTCHTEN, 2001): Complexidade; Conformidade; Maleabilidade; Invisibilidade; Ausncia de leis bsicas; Imaturidade e Baixo custo de manufatura.

3.1 Complexidade Frederick Brooks, apresenta no artigo No silver bullet: essences and accidents of Software Engineering (1987) o que considera como sendo as propriedades essenciais do software e comea tratando do problema da complexidade. Ele considera que sistemas de software normalmente possuem uma quantidade elevada de elementos distintos, o que os torna mais complexos que qualquer outro tipo de construo humana. Quando as partes de um software so semelhantes, as mesmas costumam ser agrupadas em mtodos, classes e outros elementos. Assim, medida que um sistema

18

cresce em tamanho, cresce tambm a quantidade de partes distintas. Esse comportamento difere profundamente de outras construes, tais como computadores, prdios ou automveis, nos quais se encontram elementos repetidos em abundncia. Isso leva os programas a terem um nmero extremamente elevado de estados. Computadores, por exemplo, so produtos bastante complexos que contm uma elevada quantidade de estados. Softwares, por sua vez, costumam ter uma quantidade bem maior de estados. Outro problema est ligado necessidade de escalar. Fazer um software escalar no significa apenas repetir os mesmos elementos em tamanho maior. Normalmente necessrio o aumento no nmero de elementos distintos, elevando ainda mais a quantidade de estados de um sistema, e o que pior, de forma no linear. Brooks acredita que grande parte dos problemas clssicos relacionados ao desenvolvimento de sistemas deriva diretamente da complexidade que est na essncia de qualquer software e sua correspondente elevao no linear com o aumento de tamanho. A complexidade dificulta a comunicao entre os membros da equipe de desenvolvimento e torna difcil enumerar e compreender todos os possveis estados do programa, resultando em falta de confiabilidade. Por sua vez, a complexidade das funes gera dificuldades para invoc-las, tornando os sistemas difceis de serem utilizados. A complexidade estrutural tambm torna difcil estender os programas para que incorporem novas funcionalidades sem criar efeitos colaterais. Alm disso, difcil ter uma viso geral do software, o que impede que se alcance integridade conceitual no mesmo. Finalmente, o esforo de aprendizado e transmisso de conhecimento se torna

19

bastante elevado, razo pela qual trocas de pessoal costumam acarretar prejuzos significativos. A complexidade do software colabora e explica, em parte, os resultados apresentados no captulo anterior. E importante compreender que, segundo Brooks, trata-se de um problema que est na essncia do software. Isso significa que no existem ferramentas ou tcnicas que possam evit-lo. Elas naturalmente podem ajudar a tratar a complexidade, mas a alta complexidade sempre estar presente nos projetos de software. Segundo Weinberg (1971, p.15, traduo nossa), (...) programar no apenas um comportamento humano; comportamento humano complexo. 3.2 Conformidade A complexidade um problema que tambm afeta outras reas de conhecimento, como por exemplo a fsica. Esta, alm de lidar com objetos extremamente complexos, eventualmente chega ao ponto de lidar com elementos no nvel fundamental das partculas. Apesar disso, o fsico se baseia na convico de que existam princpios unificadores, os quais, uma vez descobertos, facilitam a compreenso e o tratamento dos problemas. Alm disso, princpios fsicos tendem a ser estveis. Infelizmente, sistemas de software no costumam existir em conformidade com princpios fundamentais e estveis. Grande parte da complexidade com a qual o desenvolvedor deve lidar arbitrria. Ela imposta sobre ele por instituies e sistemas humanos, com os quais o software precisa estar em conformidade. Tal conformidade dinmica, visto que os sistemas humanos mudam com o tempo, as pessoas mudam e o software passa a ter que se adequar a novas realidades (BROOKS, 1987).

20

3.3 Maleabilidade O software, por ser digital, possui uma maleabilidade extremamente elevada e infinitamente superior quela encontrada em outros tipos de produtos, como aqueles compostos por elementos fsicos. Isso gera presses permanentes por mudanas nos sistemas. Fazendo um comparativo, observa-se que construes tais como prdios, carros e computadores tambm sofrem presses por mudanas. Entretanto, por serem formadas de elementos fsicos, os custos das mudanas so melhores compreendidos e observados, o que reduz os caprichos daqueles que as desejam. Software, por sua vez, apenas pensamento, o que o torna infinitamente malevel. Isso notado pelas pessoas de um modo geral, que naturalmente pressionam por mais mudanas, por considerarem que as mesmas tero um custo reduzido (BROOKS, 1987). A maleabilidade do software difere, portanto, daquela encontrada na engenharia civil. Se voc constri uma ponte, voc no tem este tipo de flexibilidade. Voc no pode dizer Hum, agora que eu j vejo os pilares, eu gostaria que essa ponte fosse colocada duas milhas rio acima (KRUTCHTEN, 2001, traduo nossa). Na situao ilustrada acima, qualquer pessoa seria capaz de avaliar o enorme custo de mover a ponte de uma posio para a outra, o que tenderia a reduzir ou eliminar completamente a mudana. Mas, no caso do software, a sua maleabilidade torna as mudanas muito mais fceis e menos custosas. Seus usurios tm a exata percepo de que infinitamente mais fcil alterar um software que a posio de uma ponte, o que os leva a solicitar mudanas com mais freqncia e mais intensidade.

21

3.4 Invisibilidade Ao elaborar um projeto, diversos profissionais tm a oportunidade de utilizar uma importante ferramenta: abstraes geomtricas. Um arquiteto, por exemplo, tem a possibilidade de utilizar uma planta baixa que o ajuda, bem como ajuda seu cliente a avaliar espaos, fluxos de trnsito, disposio de elementos, entre outros. Com ela, torna-se simples identificar contradies e omisses. Ao capturar a realidade geomtrica, em uma abstrao geomtrica correspondente, o arquiteto tem a sua disposio uma ferramenta que facilita e melhora o seu trabalho. J o software, invisvel e impossvel de ser visualizado, visto que sua realidade no se encontra inserida de modo intrnseco no espao. Assim, no possui uma representao geomtrica disposio, da mesma forma que terras possuem mapas, por exemplo. Ao se tentar diagramar a estrutura de um software, notamos que ela constituda no por um, mas por vrios grafos direcionados de forma genrica, superpostos uns sobre os outros. Os vrios grafos podem representar o fluxo de controle, o fluxo de dados, padres de dependncia (...) (BROOKS, 1987, traduo nossa). Brooks acredita que, embora tenha havido avanos no sentido de simplificar as estruturas de software, elas continuam sendo praticamente impossveis de serem visualizadas. Isso gera uma deficincia para o desenvolvedor que acaba no podendo contar com uma importante ferramenta. Esta falta no apenas retarda o processo de design dentro de uma mente, como tambm prejudica severamente a comunicao entre mentes diferentes (BROOKS, 1987, traduo nossa).

22

3.5 Inexistncia de princpios bsicos Como j vimos, o software no possui leis fundamentais como a fsica, tornando difcil pensar sobre ele sem efetivamente constru-lo. Alm disso, os poucos padres de engenharia de software que conhecemos se baseiam apenas em boas prticas, enquanto cdigos de construo em outras disciplinas se originam em slidos princpios fsicos (KRUTCHTEN, 2001, traduo nossa). 3.6 Rpida evoluo tecnolgica As tcnicas de desenvolvimento de software, ferramentas e o prprio ambiente de software mudam em um ritmo profundamente acelerado. Isso torna difcil consolidar uma base de conhecimento e pressiona os profissionais a se treinarem e re-treinarem permanentemente. Portanto, os profissionais parecem conviver com um eterno recomeo, pois aquilo que aprenderam h pouco tempo, perde a utilidade com enorme rapidez. Alm disso, a engenharia de software, ao contrrio de outras disciplinas, no se beneficia de centenas ou at mesmo milhares de anos de experincia (KRUTCHTEN, 2001, traduo nossa). 3.7 Baixo custo de manufatura Quando os desenvolvedores de software tratam do design de um aplicativo, normalmente esto se referindo a uma descrio de alto nvel das estruturas do sistema. Freqentemente acreditam que elaborar este design a parte complexa, enquanto a codificao uma parte mecnica. Comparando com uma fbrica de automveis, como se elaborar o design se assemelhasse ao trabalho do engenheiro que projeta um novo modelo, enquanto a codificao o trabalho mecnico de produzir tal modelo no cho de fbrica.

23

Segundo Krutchten (2001), isso no corresponde realidade. Praticamente todo o trabalho do desenvolvedor, incluindo a codificao, representa um esforo de design. Usando a comparao anterior, praticamente todo o trabalho de desenvolvimento de software pode ser comparado ao trabalho do engenheiro que projeta um novo automvel. A manufatura de um automvel, ou seja, o trabalho realizado no cho de fbrica para reproduzir o mesmo modelo inmeras vezes, buscando eliminar variaes, corresponde em software ao trabalho de compilar, empacotar e gerar um CD, por exemplo. Este o trabalho que pode, automatizado, e essencialmente o trabalho que se assemelha ao que feito na linha de produo de uma indstria, com uma importante diferena: o custo. Manufaturar um software tem um custo extremamente baixo. Comparando-se com uma indstria automobilstica, por exemplo, quase como se no existisse custo de manufatura. Quase todo o investimento est associado ao design. Uma vez projetado, o software pode ser replicado infinitas vezes, fazendo-se uma cpia de arquivos, gerandose um CD ou transferindo-se o aplicativo pela Internet (KRUTCHTEN, 2001). Projetar um novo modelo de automvel um trabalho essencialmente difcil, pouco previsvel, demorado e com potencial limitado de ser acelerado. So necessrias vrias idas e vindas durante o projeto (POPPENDIECK & POPPENDIECK, 2003). A automao no exerce um efeito to drstico na velocidade de elaborao do projeto, quanto exerce na manufatura do automvel. A partir das caractersticas que analisamos, podemos compreender que sempre haver uma crise do software, pois a causa de muitos dos problemas est na prpria natureza do software (BRYANT, 2000, traduo nossa). O que certamente podemos

24

fazer reconhecer estas caractersticas e buscar

solues que as levem em

considerao, de modo a atenuar os problemas que as equipes de desenvolvimento costumam vivenciar.

25

4 METFORAS E O DESENVOLVIMENTO DE SOFTWARE

H dcadas, a crise do software vem inspirando estudiosos e profissionais a criarem propostas para solucion-la. De um modo geral, tais solues carregam metforas que procuram lanar luz sobre a natureza do software e possveis abordagens para trat-la. Como mostra Bryant (2000), a prtica de desenvolvimento de software inevitavelmente fundada sobre metforas. A prpria palavra software uma metfora. A compreenso das metforas, que vm sendo usadas historicamente, pode ser til para o entendimento de diversos fatores que colaboram para a crise do software, ao mesmo tempo em que pode nos ajudar a visualizar novas solues, atravs do uso de novas metforas. A tenso entre sua invisibilidade e intangibilidade por um lado e sua complexidade por outro, praticamente exige mecanismos e aluses metafricas (BRYANT, 2000, traduo nossa). Ao longo dos anos, a metfora que mais vem influenciando o processo de desenvolvimento de software a da engenharia. Software vem sendo visto como um processo de construo e de fabricao. Em tal metfora, utilizam-se termos tais como construo, desenvolvimento, manuteno, prototipagem, entre outros (BRYANT, 2000). Um dos efeitos mais marcantes da crise do software, a busca permanente por solues que possam tornar os projetos: Mais produtivos; Mais previsveis e Com resultados de melhor qualidade.

26

Felizmente, outras disciplinas se depararam com esta mesma busca no passado. Algumas foram extremamente bem sucedidas, tendo alcanado os trs objetivos descritos acima. Em particular, vale a pena analisar a indstria de produo em massa, que vem melhorando continuamente nestes quesitos h alguns sculos (DRUCKER, 1999; TOFFLER, 2001). 4.1 A indstria de produo em massa Alvin Toffler (2001) avalia a histria da humanidade como uma sucesso de ondas de mudana em marcha, as quais focalizam a nossa ateno no apenas para as continuidades histricas (por mais importantes que sejam), mas tambm as descontinuidades, ou seja, as inovaes e interrupes.
Comeando com a simplssima idia de que o aparecimento da agricultura foi o primeiro ponto decisivo do desenvolvimento social humano, e de que a revoluo industrial foi a segunda grande ruptura, olha cada um destes acontecimentos no como um discreto evento no tempo, mas como uma onda de mudana avanando a uma certa velocidade (TOFFLER, 2001, p.27).

A Revoluo Industrial, que nos lanou na Segunda Onda de mudanas, trouxe consigo uma srie de regras, consistindo em seis princpios inter-relacionados (...). Nascendo naturalmente da desunio da produo e do consumo, estes princpios afetavam todos os aspectos da vida (...) (TOFFLER, 2001, p.59). Os seis princpios bsicos apontados por Toffler (2001) so: Padronizao; Especializao; Sincronizao; Concentrao; Maximizao e

27

Centralizao.

4.1.1 Padronizao A padronizao foi um princpio inventado por um construtor de mveis chamado Thonet que (...) descobriu que, em vez de fabricar cem cadeiras, cada uma diferente da outra, muito mais lucrativo faz-las todas iguais: o desperdcio menor, a produo mais rpida e a menor custo (MASI, 2000, p.59). Pelos seus mritos, tal princpio foi levado s ltimas conseqncias por Frederick Winslow Taylor no incio do sculo XX. Ele props que o trabalho podia ser cientfico, caso fosse possvel padronizar os passos executados pelos trabalhadores para executarem suas atividades. Sobretudo, Taylor acreditava que havia uma maneira melhor (padro) de realizar cada tarefa, uma ferramenta melhor (padro) para executla com ela e um tempo estipulado (padro) no qual podia ser completada (TOFFLER, 2001, p.61). 4.1.2 Especializao Em 1776, no auge da Revoluo Industrial, Adam Smith publicou um dos mais famosos e importantes livros de economia: A riqueza das naes. No incio da obra, ele aborda o princpio da especializao, declarando que o maior aprimoramento das foras produtivas do trabalho, e a maior parte da habilidade, destreza e bom senso com os quais o trabalho em toda parte dirigido ou executado, parecem ter sido resultados da diviso do trabalho (SMITH, 1996, p.65). A diviso do trabalho uma das caractersticas mais importantes do processo de industrializao devido ao enorme aumento de produtividade que acabou

28

proporcionando. Como exemplo, Toffler faz referncia Smith, que ao visitar uma fbrica de alfinetes ofereceu o seguinte relato:
Um trabalhador nico de velho estilo, efetuando todas as operaes necessrias sozinho, escreveu, podia produzir apenas um punhado de alfinetes por dia no mais de 20 e talvez nem um. Em contraste, Smith descrevia uma manufatura que ele tinha visitado, na qual se exigiam 18 operaes diferentes efetuadas por dez trabalhadores especializados, cada um efetuando apenas uma ou algumas fases. Juntos, conseguiam produzir mais de 48 mil alfinetes por dia mais de quatro mil e oitocentos por trabalhador (TOFFLER, 2001, p.62).

4.1.3 Sincronizao O princpio da sincronizao est associado necessidade de reunir os trabalhadores em um local no qual se encontram os meios de produo, ou seja, na fbrica. Isso causa a necessidade de que as pessoas estejam juntas ao mesmo tempo e, portanto, tenham os mesmos horrios.
Se fssemos artesos numa oficina de vasos, cada um fabricaria um vaso inteiro. Se, ao contrrio, trabalhssemos numa linha de montagem, voc enroscaria um parafuso e, cinco segundos depois, eu deveria apertar outro: logo, deveramos ambos estar presentes no instante em que a cadeia se inicia (MASI, 2000, p.61).

Alm da interdependncia intensificada, mquinas caras no podem ficar ociosas e operam ao seu ritmo prprio (TOFFLER, 2001, p.64). Por essa razo, a pontualidade se torna essencial e toda a fbrica precisa operar em sincronia, de acordo com o ritmo estabelecido pelas mquinas. 4.1.4 Concentrao A concentrao (ou economia de escala) se baseia na idia de que (...) se eu concentro dez empresas de mil pessoas numa nica megaempresa [sic] de dez mil pessoas, ser necessrio um nmero menor de dirigentes, de empregados, de fiscais e o lucro ser maior (MASI, 2000, p.66). Naturalmente, as fontes de economia podem

29

englobar tambm outros fatores, tais como a reutilizao de equipamentos, o maior poder de barganha com fornecedores e maior capacidade de impor preos vantajosos no mercado. 4.1.5 Maximizao A maximizao est presente na tentativa de maximizar o lucro das empresas, bem como o tamanho e a taxa de crescimento das mesmas. Neste sentido, Taylor concebe a frmula E = P/H, que quer dizer que a eficincia (E) igual a P, de produo, dividido por H, horas de trabalho (MASI, 2000, p.65). A busca por maior produtividade gerou efeitos importantes no mundo inteiro, a um tal ponto que autores como Peter Drucker consideram que a acentuada elevao da produtividade ao longo do sculo XX foi a responsvel pela atual existncia de pases desenvolvidos.
Menos de uma dcada depois que Taylor examinou o trabalho e analisou-o, a produtividade do trabalhador manual iniciou sua ascenso sem precedentes. Desde ento, ela tem subido regularmente taxa de 3,5% ao ano, o que significa que aumentou 50 vezes desde Taylor. Nesta realizao baseiam-se todos os ganhos econmicos e sociais do sculo XX. A produtividade do trabalhador manual criou aquelas que hoje chamamos de economias desenvolvidas. Antes de Taylor, isso no havia todas as economias eram igualmente subdesenvolvidas. Hoje, uma economia subdesenvolvida, ou mesmo emergente, aquela que ainda no tornou produtivo o trabalhador manual (DRUCKER, 1999, p.112).

Analisando a citao de Drucker, fundamental notar o uso da expresso trabalhador manual e, sobretudo o fato de que o aumento de produtividade ao qual ele se refere diz respeito apenas ao trabalhador manual. Voltaremos a este assunto nas prximas sees, quando comearemos a analisar a produtividade do trabalho de desenvolvimento de software.

30

4.1.6 Centralizao Da mesma forma que a Segunda Onda trouxe consigo a forte diviso entre produo e consumo (TOFFLER, 2001), criou tambm a diviso entre planejamento e execuo, isto , deixou claro que existem aqueles que pensam (e conseqentemente mandam) e aqueles que fazem (e, portanto, obedecem). Utiliza-se a premissa de que (...) a organizao deve ter a forma de uma pirmide: o vrtice sabe tudo e pode tudo. Entre quem pensa e quem executa, a diviso cristalina (MASI, 2000, p.66). 4.2 O desenvolvimento de software como trabalho do conhecimento No incio deste captulo, apontamos a busca por solues que possam tornar os projetos de desenvolvimento de software mais produtivos, mais previsveis e com resultados de melhor qualidade. Esses objetivos, entre outros, foram alcanados com sucesso pela indstria de produo em massa utilizando os princpios explicados nas sees anteriores, que esto presentes no cotidiano. Desde 1776, quando Adam Smith defendeu a diviso do trabalho em A riqueza das naes, racionalizar a produo vem servindo como um mtodo provado para elevar a qualidade, reduzir custos e aumentar a eficincia (EISCHEN, 2002). Uma questo relevante que se poderia levantar se no seria possvel utilizar estes mesmos princpios no desenvolvimento de software e obter os mesmos resultados positivos. Esse questionamento no novo. Ele acompanha a indstria de software h bastante tempo. Muitos acreditam que possvel mapear estes princpios no desenvolvimento de software e cada vez mais encontramos metforas que procuram aproxim-lo do processo de produo de uma fbrica, culminado inclusive na atual idia de fbrica de software to extensamente divulgada no mercado.

31

Em janeiro de 2005, uma busca pela expresso fbrica de software no Google1 gerou como resultado 333 mil referncias, dentre as quais era possvel identificar uma grande quantidade de empresas brasileiras que atuam no desenvolvimento de software, desde pequenas a grandes. Utilizando-se o equivalente em ingls, ou seja, a expresso software factory, o Google retornou 10.2 milhes de referncias. Tais nmeros do uma idia da extenso desta metfora e da importncia que lhe dedicada atualmente. Seu uso facilmente compreensvel quando observamos os resultados da produo industrial e o tremendo impacto gerado pelos princpios descritos anteriormente sobre o trabalho manual (DRUCKER, 1999). A expresso trabalho manual nos chama a ateno para a possibilidade de existncia de outros tipos de trabalho, os quais podem ou no ser beneficiados pelos princpios da industrializao em massa, ou Segunda Onda, para usar as palavras de Toffler (2001). Outro tipo de trabalho que est cada vez mais presente na sociedade contempornea o trabalho do conhecimento. Compreender a diferena entre trabalho manual e trabalho do conhecimento relevante tendo em vista o fato de que (...) grande parte da discusso atual (...) parece assumir que programar similar produo industrial, o programador sendo visto como (...) um componente que precisa ser controlado (...) e que pode ser substitudo facilmente (COCKBURN, 2002, p.237, traduo nossa). Diversos autores defendem a teoria de que existem pelo menos dois grupos de trabalhadores bastante distintos: os trabalhadores manuais e os trabalhadores do conhecimento, utilizando-se a nomenclatura adotada por Drucker (1999). Entre estes autores destacam-se Cockburn (2002), DeMarco (2001), DeMarco e Lister (1999;

Ferramenta de busca na Internet.

32

1987), De Masi (2000), Drucker (1999), Poppendieck e Poppendieck (2003) e Toffler (2001). Os trabalhadores do conhecimento existem h bastante tempo, mas ao longo da Segunda Onda, isto , da Era Industrial, o nmero de trabalhadores manuais era maior e mais significativo do ponto de vista de resultados para a sociedade. Entretanto, medida em que avanamos pela Terceira Onda, conforme a nomenclatura de Toffler (2001), ou a Sociedade Ps-industrial, segundo De Masi (2000) ou a Revoluo da Informao, segundo Drucker (1999), os trabalhadores do conhecimento esto se tornando rapidamente o maior grupo isolado da fora de trabalho de todos os pases desenvolvidos (DRUCKER, 1999, p.116). Os desenvolvedores de software encontram-se entre os trabalhadores do conhecimento (COCKBURN, 2002; DEMARCO & LISTER, 1987; POPPENDIECK & POPPENDIECK, 2003). Portanto, fundamental avaliar os fatores que podem ser utilizados para elevar a produtividade, a previsibilidade e a qualidade do trabalhador do conhecimento, os quais, no so, necessariamente, os mesmos que regem o trabalho manual. De fato, como veremos adiante, tais fatores, embora ainda no sejam to bem conhecidos, parecem se distanciar profundamente daqueles tradicionalmente usados para os trabalhadores manuais. Segundo Drucker (1999), existem seis fatores essenciais que determinam a produtividade do trabalhador do conhecimento. So eles: 1. Definir qual a tarefa a ser feita; 2. Permitir que os prprios trabalhadores se auto-gerenciem. Ou seja, assegurar que eles tenham autonomia e responsabilidade sobre o que produzem;

33

3. Assegurar que os trabalhadores tenham a oportunidade de inovar; 4. Aprendizado e ensino contnuo; 5. Qualidade um fator to o mais importante que a quantidade produzida e 6. Os trabalhadores do conhecimento precisam ser tratados como ativos e no como custo. Alm disso, precisam querer trabalhar para a organizao. Portanto os princpios apresentados anteriormente, sobre a produtividade do trabalhador manual, no se aplicam ao trabalho do conhecimento, podendo inclusive prejudic-lo.
O que os empregadores da Terceira Onda precisam cada vez mais, por conseguinte, so homens e mulheres que aceitem responsabilidade, que compreendam como o seu trabalho combina com o dos outros, que possam manejar tarefas cada vez maiores, que se adaptem rapidamente a circunstncias modificadas e que estejam sensivelmente afinados com as pessoas em volta deles. (...) A firma da Terceira Onda exige pessoas que sejam menos prprogramadas e mais criativas. (...) Tais pessoas so complexas, individualistas, orgulhosas das maneiras como diferem umas das outras. (...) Elas procuram significado juntamente com recompensa financeira (TOFFLER, 2001, p.378).

De Masi (2000) cita a Wiener Werksttte como exemplo de uma organizao que sabia alcanar elevada produtividade para trabalhadores do conhecimento utilizando premissas praticamente opostas quelas propostas por Taylor. Tratava-se de uma cooperativa em Viena onde se produzia, por exemplo, cartes postais, papel de parede, talheres, mveis e at mesmo bairros inteiros. Nela, o processo de criao e produo era completamente diferente daqueles de Taylor: escassa diviso do trabalho, pouca padronizao, pouca especializao, pouca sincronizao, pouca centralizao, pouca maximizao. Com resultados (...) extraordinrios (MASI, 2000, p.69).

34

4.2.1 Definir a tarefa Os trabalhadores manuais so programados pela tarefa que executam e normalmente executam um conjunto reduzido de tarefas repetidas vezes. As tarefas realizadas por um trabalhador do conhecimento, entretanto, costumam ser maiores, mais complexas e pouco estruturadas. Alm disso, no dia-a-dia, um trabalhador do conhecimento solicitado a fazer inmeras tarefas distintas. Os engenheiros esto constantemente sendo afastados de sua tarefa por terem de redigir um relatrio ou reescrev-lo, serem solicitados para uma reunio etc (DRUCKER, 1999, p.118). Drucker (1999) considera que, diante desta realidade, o aspecto mais importante da produtividade do trabalhador do conhecimento a capacidade de priorizar. Trabalhadores do conhecimento, incluindo os desenvolvedores de software, se envolvem em uma infinidade de atividades diferentes, as quais evoluem e mudam dinamicamente ao longo do tempo. Para obter a mxima produtividade, necessrio que eles saibam priorizar e concentrar o mximo de esforos naquilo que mais pode fazer diferena para a organizao ou seu projeto a cada dia de trabalho. 4.2.2 Qualidade A produtividade do trabalho manual est fortemente atrelada ao volume produzido, desde que se respeitem os padres mnimos de qualidade. O mesmo no acontece com o trabalho do conhecimento, pois neste caso, a qualidade a essncia da produo. Por exemplo, ao julgar o desempenho de um professor, no questionamos quantos alunos pode haver em uma classe, mas quantos deles aprendem algo e esta uma pergunta de qualidade (...) (DRUCKER, 1999, p.117).

35

O trabalhador do conhecimento deve executar suas atividades de modo a atingir no apenas a qualidade mnima, mas sim a mxima qualidade possvel. A questo da quantidade s comea a fazer sentido depois de se alcanar o maior nvel de qualidade. No caso do desenvolvimento de software, por exemplo, onde tcnicas, ferramentas e ambientes de software evoluem em ritmo extremamente acelerado, atingir alta qualidade est diretamente associado a um processo de aprimoramento contnuo. Portanto, a produtividade do desenvolvedor de software est profundamente associada a sua capacidade de executar suas atividades com qualidade elevada e continuar aprendendo tanto quanto possvel medida que as executa. 4.2.3 O trabalhador do conhecimento como ativo Na lgica do trabalho manual, acredita-se comumente que o trabalhador um custo e, ao mesmo tempo uma pea da engrenagem que constitui os sistemas de negcio de uma organizao. Com exceo do custo de turnover2, o gerenciamento de trabalhadores, baseado em milnios de trabalho quase totalmente manual, ainda assume que (...) um trabalhador manual igual a outro (DRUCKER, 1999, p.121). A perda de um trabalhador manual gera custos de recontratao, re-treinamento etc, bem como a possibilidade de se perder a experincia dessa pessoa. Apesar disso, o trabalhador manual ainda visto como um custo e basicamente como uma pea intercambivel. No caso do trabalhador do conhecimento a situao bem mais grave. O trabalhador manual no possui os meios de produo. Portanto, sua experincia s valiosa no local em que trabalha, ela no portvel. Por sua vez, os trabalhadores do

Custo de substituio de um trabalhador.

36

conhecimento possuem os meios de produo. O conhecimento que est entre suas orelhas um ativo enorme e totalmente porttil. Pelo fato de possurem seus meios de produo, eles so mveis (DRUCKER, 1999, p.121).
Hoje, se sou um publicitrio e estou tentando criar um slogan, quando saio do escritrio e volto para casa, levo o trabalho comigo: na minha cabea. A minha cabea no pra de pensar e s vezes acontece que posso achar a soluo para o slogan em plena noite, ou debaixo do chuveiro, ou ainda naquele estado intermedirio entre o sono e o despertar (MASI, 2000, p.205).

A perda de um trabalhador do conhecimento tem conseqncias mais srias, porque significa tambm a perda do meio de produo e de todo o aprendizado obtido ao longo do tempo. Portanto, o trabalhador do conhecimento precisa ser encarado como um ativo que deve ser mantido na organizao. Se os custos de substituio so elevados para o trabalhador manual, eles so significativamente maiores para os trabalhadores do conhecimento. 4.2.4 Motivao No trabalho do conhecimento (tambm chamado de trabalho intelectual por De Masi) o trabalho pouco estruturado e no existe uma linha de produo que imponha o ritmo de trabalho. Portanto, preciso que cada trabalhador decida produzir com a mxima qualidade no ritmo mais gil possvel. Por esta razo, no trabalho intelectual a motivao tudo (MASI, 2000, p.223). Segundo Cockburn (2002, p.63, traduo nossa), existem trs tipos de recompensa que podem manter a motivao intrnseca de uma pessoa: orgulho no trabalho, orgulho de realizar e orgulho da contribuio. Brooks (1995), por sua vez, acredita que o trabalho de desenvolvimento de software proporciona 5 tipos de satisfaes:

37

A satisfao de montar coisas; A satisfao de montar coisas que so teis para outras pessoas; O fascnio de montar objetos que se assemelham a quebracabeas; A satisfao de estar sempre aprendendo coisas no repetitivas e O prazer de trabalhar em um meio to malevel pensamento puro que, apesar de malevel, existe, se move e trabalha de uma forma diferente dos objetos do mundo fsico (BROOKS, 1995, p.230, traduo nossa).

Se motivao essencial para elevar a produtividade do trabalhador do conhecimento, precisamos compreender que fatores levam uma pessoa a ficar motivada ou desmotivada. De um modo geral, no fcil motivar algum, pois necessrio que a prpria pessoa seja capaz de se motivar. Entretanto, relativamente fcil reduzir ou eliminar a motivao de um trabalhador do conhecimento. O trabalhador do conhecimento precisa compreender o propsito daquilo que faz. Voc no pode lhe dizer para fazer alguma coisa porque voc o chefe e voc diz que precisa ser feito. (...) Voc no pode lhe impor objetivos que no lhe faam sentido (DEMARCO, 2001, p.28, traduo nossa). Alm disso, no se pode estruturar as atividades de um trabalhador do conhecimento. Ele tem que ser o prprio responsvel pela forma como o trabalho conduzido. Alem disso, tem que saber o que deve ser feito e porque. A essncia da Administrao Cientfica de Taylor ensinar ao trabalhador manual a melhor forma de executar uma tarefa. Ou seja, estruturar a atividade fundamental. No trabalho do conhecimento ocorre o inverso. No se pode estruturar a atividade e, sobretudo, no se pode estrutur-la de uma forma que no d ao trabalhador a chance de crescer. Crescimento essencial para ele, to essencial quanto o contra-

38

cheque. Voc no pode mais esperar que ele trabalhe sem desafios significativos (...) (DEMARCO, 2001, p.28, traduo nossa). A preocupao em padronizar a forma de execuo das atividades de um trabalhador do conhecimento tambm se mostra ineficaz porque acabamos nos concentrando na mecnica da atividade que uma parte pouco significativa em relao ao trabalho como um todo. A forma como o trabalho executado dentro dos ns do organograma no nem de perto to importante quanto estabelecer quo ampla e rica so as conexes [entre os trabalhadores] (DEMARCO, 2001, p.108, traduo nossa). Ao lidar com atividades mais complexas, os trabalhadores do conhecimento normalmente necessitam da ajuda de diversos colegas para atingir seus objetivos. Por essa razo, a riqueza da comunicao, do relacionamento e da colaborao entre os trabalhadores do conhecimento mais relevante que a forma como as atividades so estruturadas. Por isso a preocupao em padronizar o modo de trabalho pouco eficaz e, eventualmente, prejudicial. Especialmente quando os padres adotados prejudicam o fluxo de comunicao ou reduzem as chances de se executar um trabalho de alta qualidade do qual se possa ter orgulho. 4.3 A produo enxuta A mesma indstria automobilstica que levou a industrializao em massa s ltimas conseqncias atravs do Taylorismo criou, algumas dcadas depois, um processo de produo diferente, que aborda de maneira diferente o trabalho do conhecimento. Desta vez, ao invs da Ford, os conceitos vieram da Toyota, no Japo. Na dcada de 1940, a Toyota buscou formas de produzir automveis com maior agilidade e qualidade, mas com custos mais reduzidos. Alm disso, precisava viabilizar um modelo de produo que no fosse em massa, visto que naquele momento no havia

39

demanda no Japo para absorver uma oferta baseada na produo em massa. Assim a Toyota criou a produo enxuta (lean production, em ingls) que foi se aperfeioando ao longo de dcadas e atualmente mais conhecida pelo termo just-in-time (POPPENDIECK & POPPENDIECK, 2003). Atualmente, a Toyota uma das montadoras de automveis mais lucrativas do mundo. Ela fabrica produtos excelentes, cresce rapidamente, tem altas margens de lucratividade e fatura muito dinheiro (BECK & ANDRES, 2005, p.135, traduo nossa). Entretanto, utiliza um conjunto de prticas completamente diferente daquelas sugeridas por Taylor. Ela procura eliminar esforos desnecessrios em cada passo de fabricao de seus automveis, na crena de que eliminando desperdcios se consegue avanar mais rapidamente. A produo enxuta mencionada nesta obra por conter princpios que esto na base dos processos geis de desenvolvimento de software como o Extreme Programming. Ela caracterizada por um conjunto de sete (POPPENDIECK & POPPENDIECK, 2003): 1. Eliminar desperdcios; 2. Amplificar o aprendizado; 3. Adiar decises ao mximo; 4. Entregar o mais rapidamente possvel; 5. Delegar poder equipe; 6. Incorporar integridade e 7. Ver o todo. Estes princpios incorporam os fatores citados anteriormente sobre a produtividade do trabalhador do conhecimento. Por esta razo, existe uma chance de princpios bsicos

40

que processos de desenvolvimento de software baseado nos mesmos possam efetivamente elevar a produtividade e a qualidade dos projetos de desenvolvimento. 4.3.1 Eliminar desperdcios Ao analisar a produtividade do trabalhador manual, Taylor buscou formas de eliminar desperdcios e, portanto, obter maior produtividade. A forma utilizada por ele foi avaliar o modo de trabalho dos operrios e lhes ensinar a melhor forma de executar as tarefas. Esse modelo funcionou e ao adot-lo a Ford elevou tanto a sua produtividade que praticamente levou falncia todas as fbricas artesanais de automveis que existiam na poca (em torno de quinhentas) (POPPENDIECK & POPPENDIECK, 2003). O Sistema de Produo da Toyota, por sua vez, tambm priorizou a reduo de desperdcios, porm adotou estratgias diferentes. Ela procurou colocar o cliente final no centro do problema e analisar toda a cadeia produtiva desde o momento em que o automvel comeava a ser produzido at o momento de ser entregue ao cliente. Observando a cadeia, procurou identificar tudo aquilo que era feito e que no gerava resultados perceptveis para o cliente final. Se alguma coisa assim fosse identificada, seria considerada um desperdcio e, portanto, eliminada. A nfase foi em tentar reduzir, tanto quanto possvel, a quantidade de trabalho executada e os subprodutos envolvidos, de modo a concentrar esforos exclusivamente naquilo que pudesse gerar um resultado objetivo e perceptvel para o cliente final.
Desperdcio tudo aquilo que no adiciona valor ao produto, valor tal como percebido pelo cliente. (...) Se um componente est colocado em uma estante pegando poeira, isso desperdcio. Se um ciclo de desenvolvimento coletou requisitos em um livro que est pegando poeira, isso desperdcio. Se uma planta industrial produz mais coisas do que imediatamente necessrio, isso desperdcio. Se os desenvolvedores codificam mais funcionalidades que o imediatamente necessrio, isso desperdcio, transferir o desenvolvimento de um

41

grupo para outro desperdcio. O ideal descobrir o que o cliente deseja e ento fazer ou desenvolver isso e entregar exatamente o que ele quer, virtualmente de imediato. O que quer que atrapalhe a rpida satisfao da necessidade do cliente um desperdcio (POPPENDIECK & POPPENDIECK, 2003, p.xxv, traduo nossa).

O Sistema de Produo da Toyota tambm busca eliminar desperdcios fazendo com que o estoque seja mnimo, ou simplesmente inexistente, e as entregas sejam efetuadas com a maior velocidade possvel. O objetivo disso receber feedback rapidamente sobre o produto produzido. Acredita-se que quanto mais curto for o ciclo de feedback, maior ser o aprendizado e mais chances existiro para aprimorar o produto e o processo de produo. Alm disso, eventuais falhas podero ser descobertas cedo, facilitando a correo e tornando-as menos custosas. Portanto, toda a produo organizada em torno da idia de aprendizado, melhoria contnua e deteco rpida de falhas. 4.3.2 Amplificar o aprendizado Ao contrrio da abordagem adotada por Taylor, a Toyota partiu da premissa de que a melhor forma de se executar um trabalho no esttica, mas sim dinmica. Sendo assim, busca fazer com que os operrios aprendam cada vez mais, se tornem cada vez mais habilidosos e, portanto, capazes de criar formas inovadoras e mais eficazes de realizar suas tarefas medida que ganhem mais experincia e conhecimento. Alm disso, acredita que ningum tem mais informaes para aprimorar o trabalho do cho de fbrica quanto as pessoas que esto l executando o trabalho. Ao fazer isso, a Toyota se afasta da idia da separao entre planejamento e execuo que faz parte do modelo Taylorista. Na Toyota, o operrio responsvel por planejar, executar e aprimorar continuamente a forma de fazer ambas as coisas. O supervisor deixa de ser responsvel pelo planejamento centralizado e assume o papel de

42

treinador. Ele busca assegurar que a equipe tenha o aprendizado mais rico possvel ao longo do trabalho (POPPENDIECK & POPPENDIECK, 2003).
Desenvolver como criar uma receita, enquanto produzir como preparar o prato. Receitas so criadas por chefs experientes que desenvolveram o instinto para o que funciona e a capacidade de adaptar os ingredientes disponveis conforme a ocasio. Ainda assim, at mesmo os grandes chefs produzem inmeras variaes de um novo prato medida que iteram na direo da receita que ter um excelente sabor e ser fcil de reproduzir. No se espera que os chefs atinjam a receita perfeita na primeira tentativa; espera-se que eles produzam diversas variaes sobre o mesmo tema como parte natural do processo de aprendizagem (POPPENDIECK & POPPENDIECK, 2003, p.xxv, traduo nossa).

Visto que o desenvolvimento de software envolve experimentao e aprimoramento, a idia de amplificar o conhecimento bastante relevante. Existe ainda o desafio adicional de que equipes de desenvolvimento costumam ser numerosas e os resultados bem mais complexos do que receitas. Alm disso, a rpida evoluo tecnolgica torna ainda mais essencial a adoo de formas de se amplificar o conhecimento em um projeto de software. 4.3.3 Adiar decises ao mximo Ao se projetar um novo produto, tal como um software, existem decises que podem ser afetadas por mudanas que venham a ocorrer ao longo do projeto. Por exemplo, mudanas ocorridas na economia ou de regras legislativas podem resultar na necessidade de mudanas em um projeto de software que vinha sendo conduzido dentro de uma instituio bancria. O desenvolvimento de software tradicionalmente afetado por diversas mudanas ao longo dos projetos. O Sistema de Produo da Toyota trabalha com o princpio de adiar decises at o ltimo momento responsvel, ou seja, aquele a partir do qual a no tomada da deciso traria prejuzos diretos ao projeto. O objetivo aguardar at que informaes mais

43

concretas estejam disponveis para a equipe. Desta forma, procura-se reduzir a necessidade de re-trabalho em funo de decises tomadas cedo demais e que mais tarde possam ser foradas a mudar em funo de mudanas nas circunstncias (POPPENDIECK & POPPENDIECK, 2003).
Prticas de desenvolvimento que permitam adiar a tomada de decises so eficazes em domnios que envolvem incerteza, porque elas provm uma abordagem baseada em opes. Diante de incertezas, a maioria dos mercados econmicos desenvolve opes para prover uma forma de o investidor evitar se trancar em decises at que o futuro esteja mais perto e mais fcil de prever. Adiar decises valioso porque possvel tomar melhores decises quando elas so baseadas em fatos e no especulaes. Em um mercado em evoluo, manter decises de design em aberto mais valioso que se comprometer cedo demais. Uma estratgia chave para adiar compromissos durante o desenvolvimento de um sistema complexo incorporar a capacidade de mudana no prprio sistema (POPPENDIECK & POPPENDIECK, 2003, p.xxvi, traduo nossa)

O Extreme Programming trabalha com este conceito evitando a implementao de funcionalidades baseadas em especulaes. Alm disso, usa o desenvolvimento iterativo para assegurar que a equipe se concentre apenas em um conjunto reduzido de funcionalidades a cada iterao, deixando que o tempo traga maiores informaes sobre as funcionalidades futuras. 4.3.4 Entregar o mais rapidamente possvel Feedback um conceito chave na filosofia just-in-time, porque quanto mais rico e mais rpido for o feedback, maior ser o aprendizado. Quando uma equipe capaz de fazer entregas rpidas, mesmo que cada uma se refira apenas a um conjunto reduzido de funcionalidades, possvel aprender e aprimorar o que est sendo produzido, bem como a forma de produo.
No desenvolvimento, o ciclo de descoberta crtico para o aprendizado: faa o design, implemente, obtenha feedback, melhore. Quanto mais curtos so estes ciclos, mais se pode aprender. A velocidade assegura que os clientes obtenham o que desejam agora e

44

no aquilo que eles precisavam ontem. Isso tambm permite que eles adiem a tomada de decises sobre o que eles realmente querem at que eles saibam mais (POPPENDIECK & POPPENDIECK, 2003, p.xxvi, traduo nossa).

difcil adiar decises quando as entregas demoram demais a ocorrer. Se uma equipe de desenvolvimento s capaz de efetuar entregas a cada seis meses, uma vez que se defina o escopo de um perodo de seis meses de trabalho, o cliente pode vir a ter que aguardar no mnimo seis meses antes de ver qualquer mudana de idia ser colocada em prtica. Por outro lado, se a equipe faz entregas a cada duas semanas, mudanas de rumo podem ser incorporadas mais rapidamente, o que permite adiar decises sem que isso gere conseqncias indesejveis (POPPENDIECK & POPPENDIECK, 2003). 4.3.5 Delegar poder equipe Como pudemos observar anteriormente, importante que o trabalhador do conhecimento possa definir a forma de executar suas tarefas. Ou seja, essencial que ele tenha o domnio sobre o processo de desenvolvimento e, portanto, tenha a oportunidade de aprimor-lo ao longo do tempo com o objetivo de obter a melhor qualidade possvel.
Executar atividades com a mxima qualidade depende de obter os detalhes corretamente e ningum entende melhor dos detalhes que as pessoas que efetivamente executam o trabalho. Envolver desenvolvedores nos detalhes das decises tcnicas fundamental para alcanar a excelncia. As pessoas na linha de frente combinam o conhecimento do detalhe do ltimo minuto com o poder de muitas mentes. Quando equipados com a qualificao tcnica necessria e guiados por um lder, eles tomaro melhores decises tcnicas e melhores decises de processo que qualquer um possa tomar por eles. Pelo fato de as decises serem adiadas e a execuo ser rpida, no possvel para uma autoridade central orquestrar as atividades dos trabalhadores (POPPENDIECK & POPPENDIECK, 2003, p.xxvi, traduo nossa).

45

Este mais um princpio no qual a produo enxuta se afasta da idia de diviso entre planejamento e execuo. Ao invs disso, procura-se assegurar que o conhecimento gerado no cho de fbrica circule da melhor maneira possvel, se enriquea e retorne para o cho de fbrica rapidamente na forma de melhorias no processo. 4.3.6 Incorporar integridade Outra forma de reduzir desperdcios assegurar que o produto tenha elevada integridade perceptvel e conceitual. A integridade perceptvel alcanada quando um usurio pensa Isso! exatamente o que eu quero. Algum entrou na minha cabea! (POPPENDIECK & POPPENDIECK, 2003, p.xxvii, traduo nossa). Ou seja, quando o software possui uma interface intuitiva e fcil de utilizar, cujos conceitos se relacionam de maneira harmnica. Tal nvel de integridade importante para reduzir desperdcios na medida em que reduz ou elimina possveis chamados dos usurios contendo dvidas ou reclamaes. Alm disso, eleva a satisfao do usurio final. A integridade conceitual, por sua vez, significa que os conceitos centrais do sistema trabalham em conjunto como um todo harmnico e coeso; e um fator crtico para a criao da percepo de integridade (POPPENDIECK & POPPENDIECK, 2003, p.xxvii, traduo nossa). Em outras palavras, a partes se encaixam de maneira coerente, tornando fcil re-conectar os componentes e reduzindo as chances de defeitos. Ambos so fatores que geram reduo de desperdcios.
. Software ntegro possui uma arquitetura coerente, alcana uma pontuao elevada em usabilidade e adequao ao propsito e manutenvel, adaptvel e extensvel. Pesquisas revelam que a integridade deriva de liderana sbia, qualificao significativa, comunicao eficaz e disciplina sadia; processos, procedimentos e

46

medies no so substitutos adequados (POPPENDIECK & POPPENDIECK, 2003, p.xxvii, traduo nossa).

Os demais princpios so essenciais para se alcanar integridade, na medida em que ajudam a reduzir os ciclos de feedback e, portanto, procuram amplificar o aprendizado. 4.3.7 Ver o todo Para que um software alcance integridade perceptvel e conceitual, importante que o todo seja harmnico. Portanto, no desejvel que um determinado aspecto do projeto seja extremamente otimizado, enquanto outros tenham comportamentos deficientes. Para atingir integridade, o equilbrio mais importante que o comportamento individual das partes envolvidas. necessrio que a equipe de desenvolvimento seja capaz de ter a viso do todo permanentemente.
Integridade em sistemas complexos requer profunda qualificao em muitas reas diferentes. Um dos problemas mais intratveis no desenvolvimento de produtos que especialistas em qualquer rea (banco de dados ou interface grfica, por exemplo) tm a tendncia de maximizar o desempenho de uma parte do produto representando a sua prpria especialidade ao invs de focar no desempenho geral do sistema. Com bastante freqncia, o bem comum acaba sofrendo se as pessoas se comprometem primariamente com seus prprios interesses especializados. Quando indivduos ou organizaes so medidos de acordo com suas contribuies especializadas, ao invs do desempenho geral, provvel que ocorra sub-otimizao (POPPENDIECK & POPPENDIECK, 2003, p.xxvii, traduo nossa).

Para solucionar os problemas de sub-otimizao equipes just-in-time procuram elevar o nvel das medies. Procura-se medir o resultado final e no as partes individuais, ou seja a ateno voltada para o equilbrio do conjunto. Alm disso, utilizam-se os demais princpios para estabelecer um fluxo de comunicao rico que ajude a equipe a ter a viso do todo (POPPENDIECK & POPPENDIECK, 2003).

47

4.4 Processos de desenvolvimento de software Como vimos no segundo captulo, o termo crise do software acompanha a indstria de software desde 1968, quando ocorreu a conferncia da OTAN que cunhou o nome Engenharia de Software. O termo Engenharia de Software, deu origem a uma disciplina dentro da rea de computao, embora originalmente tivesse sido criado apenas como uma provocao, conforme os relatos de Peter Naur e Brian Randell.
O termo engenharia de software foi escolhido deliberadamente para ser provocativo, cuja implicao era a necessidade de que a manufatura de software fosse baseada nos tipos de fundamentos tericos e disciplinas prticas que so tradicionais em ramos estabelecidos da engenharia (MCBREEN, 2002, p.xv, traduo nossa).

A Engenharia de Software surgiu com o objetivo de atender s necessidades da OTAN para o desenvolvimento de grandes sistemas de defesa. Em princpio, seu escopo no envolvia projetos de aplicaes comerciais que, de um modo geral, so bem menores e precisam entrar em produo em pouco tempo. Nestes casos, so raros os projetos desenvolvidos por equipes de mais de 20 pessoas e a maioria dos desenvolvedores trabalha em equipes com menos de 10 membros (MCBREEN, 2002, p.xvi, traduo nossa). Segundo o IEEE Standard Computer Dictionary, a engenharia de software a aplicao de uma abordagem sistemtica, disciplinada e mensurvel para

desenvolvimento, operao e manuteno de software; isto , a aplicao da engenharia ao software (MCBREEN, 2002, p.7, traduo nossa). O objetivo desta abordagem alcanar na rea de software o mesmo nvel de previsibilidade, determinismo e acerto presente em outros ramos da engenharia. A Engenharia de Software deu origem a diversos processos de desenvolvimento. O mais conhecido e antigo deles o processo linear e seqencial de desenvolvimento,

48

tambm conhecido como cascata. Ele organiza os projetos de software em quatro grandes etapas realizadas seqencialmente: anlise, design, codificao e testes. Ainda hoje, este o modelo de desenvolvimento mais conhecido e amplamente utilizado (PRESSMAN, 1997). Ele pode ser relacionado facilmente aos princpios da produo em massa utilizados por Taylor. A evoluo seqencial do projeto se assemelha a uma fbrica onde requisitos so tratados como matrias primas que so transformadas medida que avanam pela linha de produo. Cada transformao gera um conjunto de artefatos a serem utilizados em etapas posteriores da fabricao. Procura-se assegurar que cada artefato seja produzido corretamente para que o resultado final possa ser alcanado com a mesma previsibilidade e determinismo de uma fbrica. Portanto, evitar variaes fundamental. Dentro do projeto, grande parte dos artefatos representada por documentos criados para direcionar o trabalho que ser executado mais adiante na cadeia de produo, os quais so produzidos por profissionais especializados. Normalmente o processo de planejamento feito no incio da cadeia, enquanto espera-se que os artefatos produzidos ao longo do projeto permitam que as ltimas etapas da cadeia sejam produzidas de forma cada vez mais mecnica e determinstica. Portanto, observam-se dois princpios fundamentais da racionalizao do trabalho manual: a especializao e a centralizao.
Durante um projeto, trs habilidades diferentes so necessrias: Analistas para documentar os requisitos; Projetistas para criar a especificao do design e Programadores para escrever o cdigo. A cada etapa, os autores de cada documento tm que adicionar detalhes extras porque no sabem quem ir ler o documento mais adiante. Sem saber que tipo de conhecimento em comum pode ser assumido, a nica coisa segura a fazer adicionar o mximo de detalhes e referncias cruzadas que o autor conhea. Os revisores

49

precisam, ento, analisar o documento para confirmar que ele esteja completo e sem ambigidades. Documentao completa gera outro desafio: os membros da equipe precisam assegurar que os documentos permaneam consistentes quando ocorrem mudanas nos requisitos ou mudanas de design feitas durante a codificao. (...) Como as mudanas se tornam muito caras devido necessidade de atualizao dos documentos, acabam sendo controladas e evitadas (MCBREEN, 2002, p.6, traduo nossa).

A utilizao de um processo seqencial, baseado na criao de artefatos, uma tentativa de disciplinar o desenvolvimento e buscar os nveis de previsibilidade desejados. Entretanto, freqentemente o resultado obtido apenas formalismo e no disciplina. Em parte isso ocorre porque como j vimos, mudanas so constantes em projetos de software e o modelo seqencial de desenvolvimento gera uma necessidade de control-las, o que, por sua vez, leva a um conflito de interesses entre clientes e equipes de desenvolvimento. Alm disso, esse modelo revela poucas chances para a aquisio e utilizao de feedback ao longo do desenvolvimento, elevando os riscos de que o projeto entregue algo que no resolva as necessidades dos usurios, mesmo seguindo um planejamento e controlando o processo. DeMarco (DEMARCO & BOEHM, 2002) acredita que o foco na gerao de artefatos, ao invs de ajudar, acabou se tornando uma forma de agravar os problemas da crise do software. Segundo ele, Depois de quase 20 anos de obsesso por processos (...), o processo que encontro tipicamente em empresas clientes se tornou excessivamente baseado em documentaes, gerando a enxurrada de documentos que se tornou endmica (...). Ao longo do tempo, a indstria de software criou alternativas para o processo de desenvolvimento em cascata. Algumas mantiveram parte das caractersticas do modelo seqencial, enquanto outras se baseiam em formas completamente diferentes de se tratar os projetos de software.

50

O Rational Unified Process (RUP), por exemplo, traz avanos em relao ao desenvolvimento em cascata, embora mantenha conceitos herdados do taylorismo. Ele um framework de processo bastante abrangente que, como tal, pode ser instanciado para atender s necessidades dos mais diversos tipos de projetos de software (JACOBSON, BOOCH et al., 1999). O RUP organizado em torno do conceito de melhores prticas. Ele prov um vasto arcabouo de prticas que procuram indicar a melhor forma de se realizar diversos tipos de atividades nos projetos de software. Neste sentido, ele se aproxima da abordagem taylorista que tambm buscava identificar as melhores formas de estruturar o trabalho dentro de uma fbrica. A proposta que, ao iniciar um projeto que utilizar o RUP, a equipe de desenvolvimento selecione dentre as melhores prticas disponveis no arcabouo, aquelas que fazem sentido para o projeto em questo. Embora seja uma proposta intuitivamente justificvel e louvvel, existem alguns problemas prticos que foram levantados por Boehm e Turner ((2003). Em seu arcabouo, o RUP engloba tambm um vasto conjunto de artefatos, alm de melhores prticas. Determinar que prticas e artefatos devem ser adotados em um projeto uma atividade que pode ser bem feita por pessoas com treinamento, conhecimento e experincia no RUP. Entretanto, raro encontrar pessoas com essas caractersticas nos projetos de software. Na falta delas, os membros das equipes de projeto tendem a adotar um conjunto desnecessariamente abrangente de prticas e artefatos temendo retirar elementos que possam fazer falta mais tarde, o que freqentemente leva burocratizao dos projetos.

51

No objetivo do RUP tornar os projetos pesados e enfadonhos, entretanto, o que Boehm e Turner observam que abordagens baseadas em boas prticas como o RUP (entre outras), freqentemente levam os projetos a se burocratizarem devido forma como os membros da equipe adotam os conceitos. O desconhecimento e a inexperincia normalmente se tornam um convite para o excesso, embora este no seja o objetivo destes tipos de processos. Outra questo contraditria na idia de melhores prticas est no fato de que no existem melhores prticas em absoluto. A avaliao do que vem a ser uma melhor prtica normalmente precisa levar em conta o contexto em que a prtica utilizada. Pois, enquanto em determinados casos a prtica pode se mostrar perfeita, em outros, pode se revelar desastrosa devido a caractersticas do projeto. Alm de se basear em um conjunto de boas prticas, o RUP orientado a casos de uso, centrado na arquitetura, iterativo e incremental (JACOBSON, BOOCH et al., 1999). Os casos de uso so utilizados pelas equipes para capturar os requisitos funcionais e indicar que atores utilizaro as funcionalidades implementadas. Muitas equipes encaram os casos de uso como o mecanismo essencial para o levantamento dos requisitos, o que problemtico, porque significa que freqentemente os casos de uso sero interpretados como elementos completos e suficientes para a implementao das funcionalidades. Basear a compreenso dos requisitos em canais de comunicao escritos problemtico, conforme veremos no prximo captulo. Ao ser centrado na arquitetura, o RUP tambm incentiva (direta ou indiretamente) as equipes a estabelecerem a arquitetura do software antes de comear a implementao do mesmo. Portanto, a utilizao de casos de uso para os requisitos e a elaborao de documentos que descrevem a arquitetura antes da implementao

52

freqentemente levam equipes a adotarem um modelo de desenvolvimento bastante semelhando ao cascata, embora exista uma diferena fundamental na proposta do RUP: o desenvolvimento iterativo e incremental. Em princpio, o RUP estabelece o desenvolvimento iterativo e incremental como forma de incorporar feedback e aprendizado ao processo de desenvolvimento. Entretanto, comum equipes adotarem o RUP com iteraes muito longas ou simplesmente executarem o projeto inteiro em uma nica iterao. Nestes casos, o que se observa a equipe executando um projeto de acordo com o processo em cascata, mas basicamente usando os artefatos do RUP para organizar a documentao. Uma das maiores falhas do processo de desenvolvimento em cascata e de outras propostas de desenvolvimento baseadas em princpios tayloristas a incapacidade de levar em conta o fator humano de forma apropriada. Como vimos anteriormente, Taylor tornou produtivo o trabalho manual, mas seus princpios no so aplicveis para o trabalho do conhecimento, em especial o desenvolvimento de software.
Um bom software no se origina de ferramentas CASE, programao visual, prototipagem rpida ou tecnologia de objetos. Um bom software resultado de pessoas. Assim como o caso de softwares ruins. (...) j que software criado por pessoas e usado por pessoas, uma melhor compreenso das pessoas como executam o trabalho e como trabalham em conjunto a base para um melhor desenvolvimento de software e para criarmos softwares melhores (CONSTANTINE, 2001, p.xvii, traduo nossa).

Na dcada de 1990, alguns profissionais da indstria de software comearam a propor novos processos de desenvolvimento que fossem mais adequados para lidar com os aspectos humanos dos projetos de software. Em fevereiro de 2001, 17 profissionais experientes se reuniram em Utah (EUA) para discutir suas prticas de desenvolvimento e suas propostas alternativas para evitar os processos de desenvolvimento excessivamente baseados em documentaes e formalismos. Naquele momento,

53

decidiram organizar suas propostas sob um nome comum: desenvolvimento gil de software. Isto foi feito pelo lanamento do Manifesto pelo Desenvolvimento gil de Software3. O manifesto estabelece um conjunto de valores que so adotados nos projetos geis: Indivduos e interaes ao invs de processos e ferramentas; Software funcionando ao invs de documentao abrangente; Colaborao com o cliente ao invs de negociao de contratos e Responder a mudanas ao invs de seguir um plano.

A proposta que, embora exista valor nos itens direita, os processos geis valorizam mais os itens que esto esquerda. Atualmente, estes so os principais processos geis conhecidos: Scrum, Dynamic Systems Development Method (DSDM), Crystal Methods, Feature-Driven Development (FDD), Lean Development (LD), Extreme Programming e Adaptative Software Development (HIGHSMITH, 2002). Uma das principais diferenas dos processos geis em relao aos seus antecessores o conceito chamado de barely sufficient, ou seja, mnimo necessrio. Enquanto abordagens como o RUP (entre outras) procuram estabelecer um arcabouo de melhores prticas, os processos geis sugerem o uso de um conjunto bastante reduzido de prticas. Tal conjunto pode se revelar suficiente em muitos projetos comerciais que envolvam equipes reduzidas, tais como os que foram mencionados no incio desta seo. O objetivo comear os projetos de software de forma simples, com poucas prticas e avaliar os resultados. Caso prticas ou artefatos faltem ao projeto, deve-se

http://www.agilemanifesto.org.

54

busc-los em outras propostas metodolgicas. Com isso, procura-se evitar as chances de que um projeto seja iniciado com um conjunto desnecessariamente elevado de prticas e artefatos que possam torn-lo burocrtico. A nfase passa a ser de s trazer elementos novos para o projeto quanto os mesmos realmente se mostram necessrios (BOEHM & TURNER, 2003; COCKBURN, 2002; HIGHSMITH, 2002). O prximo captulo apresentar o Extreme Programming que representa um dos processos geis mais conhecidos e utilizados.

55

5 EXTREME PROGRAMMING
Os principais fundamentos do XP tiveram origem nas tradies do desenvolvimento em Smalltalk e datam de meados da dcada de 80, quando Kent Beck e Ward Cunningham trabalhavam na Tektronixs, Inc. Prticas, tais como, refatorao, programao em par, mudanas rpidas, feedback constante do cliente,

desenvolvimento iterativo, testes automatizados, entre outras, so elementos centrais da cultura da comunidade Smalltalk. Olhando deste ponto de vista, XP pode ser considerado o modo de agir do Smalltalk generalizado para outros ambientes. Entre 1986 e 1987, comearam a surgir algumas contribuies fundamentais para aquilo que viria a ser o XP, uma dcada depois. De 1986 a 1996, Kent e Ward desenvolveram um amplo conjunto de boas prticas que foram condensadas sucintamente no padro de linguagem Episodes. Este padro foi publicado em 1996 sob o ttulo Pattern Languages of Program Design 2. Ainda neste mesmo perodo, entre 1989 e 1992, surgiram importantes avanos em refatorao. Nesta rea, destaca-se a tese de Bill Opdyke, Refactoring ObjectOriented Frameworks. Este trabalho demonstrou como pessoas como Kent e Ward obtinham ganhos de produtividade utilizando a refatorao. Alguns anos mais tarde, por volta de 1996, Kent publicou o livro Smalltalk Best Practices Patterns. Este livro tambm apresentou boas tcnicas de desenvolvimento, grande parte das quais foi combinada no trabalho de Martin Fowler et al. (2000). O desenvolvimento orientado a testes uma tcnica que derivou diretamente das tcnicas de refatorao. O primeiro artigo publicado sobre este conceito foi escrito por Kent Beck para a SmalltalkReport. Neste artigo, ele introduziu o framework SmallUnit.

56

A partir de ento, o artigo mais importante sobre o assunto, intitulado Test Infected, descreveu o JavaUnit na Dr. Dobbs. Ainda nas questes tcnicas, a comunidade XP tradicionalmente conhecida por utilizar padres (patterns) fortemente. Este um outro aspecto importante no surgimento do XP, j que Kent e Ward comearam a aplicar os conceitos de padres em 1987, quando escreveram um dos primeiros artigos sobre o assunto para a OOPSLA87 (Conference on Object-Oriented Programming, Systems, Languages, and Applications). Em 1996, todas as partes que foram sendo agregadas ao longo de uma dcada comearam a se fundir. No incio daquele ano, Kent trabalhava como consultor para problemas de desempenho em SmallTalk, quando foi chamado para analisar o desempenho do projeto de converso da folha de pagamento da Chrysler para SmallTalk. O sistema em questo, conhecido como C3, ou Chrysler Comprehensive Compensation System (Sistema de Compensao Abrangente da Chrysler), conhecido como o bero do XP e foi onde Kent Beck utilizou pela primeira vez, em conjunto, as prticas que atualmente formam a estrutura do Extreme Proramming (BECK & ANDRES, 2005; TELES, 2004). Neste captulo e no seguinte, procuraremos mostrar que o conjunto de prticas e valores do Extreme Programming coeso e possui caractersticas que permitem utilizar o XP como uma alternativa vlida na busca por maiores taxas de sucesso nos projetos de software. Este captulo apresenta cada valor e prtica do XP com base em inmeras publicaes que apiam o uso dos mesmos. O enfoque deste captulo no porqu dos conceitos propostos pelo Extreme Programming. Atualmente existem boas publicaes explicando o que so os valores e as prticas do XP, alm de demonstrarem como utiliz-los. Sendo assim, decidimos

57

investir esforos sobretudo em explicar o porqu dos conceitos propostos pelo XP, apresentando brevemente o que so, mas sem entrar em detalhes sobre como utiliz-los. Caso contrrio, o escopo deste captulo seria excessivamente amplo e o texto maior que o necessrio para o propsito desta dissertao. No captulo seguinte, apresentaremos um estudo de caso que valida, ao menos em um projeto em particular, que a proposta do XP realmente capaz de gerar resultados positivos. 5.1 Valores 5.1.1 Feedback A compreenso das necessidades dos usurios uma das atividades mais difceis e importantes de serem realizadas pelos desenvolvedores de um software, pois ela direciona todos os demais esforos. Entretanto, compreender os requisitos freqentemente difcil, bem como costuma ser complexo para os prprios usurios transmiti-los corretamente. Segundo Brooks (1987, traduo nossa), nenhuma outra parte do trabalho conceitual to difcil quanto estabelecer detalhadamente os requisitos tcnicos, incluindo todas as interfaces (...) Nenhuma outra parte mais difcil de corrigir mais tarde.
Portanto, a funo mais importante que os construtores de software podem desempenhar por seus clientes a extrao e o refinamento iterativo dos requisitos do produto. Porque a verdade que os clientes no sabem o que querem. Eles normalmente no sabem que questes precisam ser respondidas e eles quase nunca pensaram no problema no nvel de detalhe que precisa ser especificado. (...) As dinmicas das aes so difceis de imaginar. Portanto (...) necessrio dar espao para uma interao abrangente entre o cliente e o designer como parte da definio do sistema (BROOKS, 1987, traduo nossa).

58

Na opinio de Brooks, os clientes no tm como prever corretamente as funcionalidades de que necessitaro. Por isso, fundamental que haja uma forte interao com os desenvolvedores ao longo do projeto.
Eu daria um passo alm e afirmaria que, na verdade, impossvel para os clientes, mesmo aqueles trabalhando com engenheiros de software, especificar completamente, precisamente e corretamente os requisitos exatos de um produto de software moderno antes de ter construdo e tentado algumas verses do produto que esto especificando (BROOKS, 1987, traduo nossa).

A compreenso das necessidades dos usurios um processo de aprendizado contnuo no qual os desenvolvedores aprendem sobre os problemas do negcio e os usurios tomam conhecimento das dificuldades e limitaes tcnicas. Um princpio psicolgico bem conhecido indica que para maximizar a taxa de aprendizado, a pessoa precisa receber feedback sobre quo bem ou mal ele est indo (WEINBERG, 1971, p.102, traduo nossa). Amplificar o aprendizado importante porque ajuda a acelerar a convergncia entre as necessidades e a compreenso das mesmas por parte dos desenvolvedores. Alm disso, acelera o entendimento dos usurios sobre as possibilidades da tecnologia e suas limitaes. A convergncia ainda mais rpida quando os ciclos de feedback so encurtados. Um dos maiores pontos que aceleram a melhoria do desempenho de um sistema (...) a minimizao das [suas] defasagens (SENGE, 2002, p.119-121).
A psicologia do aprendizado ensina que o tempo entre uma ao e o correspondente feedback crtico para o aprendizado. Experimentos com animais mostram que mesmo pequenas diferenas no tempo de feedback resultam em enormes diferenas de aprendizado. (...) Portanto, um dos princpios obter feedback, interpret-lo, e colocar o que foi aprendido de volta dentro do sistema o mais rapidamente possvel. As pessoas de negcio aprendem como o sistema pode contribuir da melhor forma e retornam este aprendizado em dias ou semanas, ao invs de meses ou anos. Os programadores aprendem como fazer o design, implementar e testar o sistema da melhor forma possvel e retornam este aprendizado em segundos ou minutos ao invs de dias, semanas ou meses (BECK, 2000, p.37, traduo nossa).

59

Por estas razes, o Extreme Programming organizado em ciclos curtos de feedback que possibilitem aos usurios solicitar funcionalidades e aprender sobre elas atravs de software funcionando em prazos curtos. Esse processo envolve a priorizao de poucas funcionalidades a serem implementadas de cada vez e a simplificao das mesmas na medida do possvel. O objetivo se torna apresentar a funcionalidade ao usurio rapidamente, de modo que ele possa, cedo, detectar eventuais falhas, quando tende a ser mais barato corrigi-las. A razo bsica para estratgias incrementais e iterativas permitir que os inevitveis erros das pessoas sejam descobertos relativamente cedo e reparados de forma metdica (COCKBURN, 2002, p.49, traduo nossa). Trabalhando com ciclos de feedback curtos, o Extreme Programming procura assegurar que pouco trabalho seja efetuado e concludo de cada vez. A equipe segue adiante apenas se o resultado estiver correto. Caso surjam falhas, as mesmas so corrigidas logo, antes de iniciar o desenvolvimento de outras funcionalidades. A

utilizao de lotes reduzidos de trabalho assegura que eventuais falhas tendero a ser corrigidas com maior rapidez exatamente porque o escopo do trabalho reduzido, o que significa que menos coisas podem dar errado. 5.1.2 Comunicao Projetos de software normalmente envolvem a presena de pelo menos duas pessoas, um usurio e um desenvolvedor, o que causa a necessidade de comunicao entre elas. No mnimo, cabe ao usurio comunicar o que necessita que seja produzido e ao desenvolvedor comunicar as consideraes tcnicas que afetam a soluo e a velocidade de implementao da mesma.

60

Muitos projetos envolvem no apenas duas pessoas, mas sim grupos maiores que podem ser compostos por diversos usurios e desenvolvedores. Com freqncia, equvocos no processo de comunicao, causam desentendimentos ou compreenso incorreta de algum aspecto do projeto.
Como os socilogos sabem, comunicao intrinsecamente difcil, mediada por cdigos que so sempre contextuais, normas, culturas e percepes. (...) A construo de requisitos bsicos, por exemplo, envolve um processo de comunicao de conhecimento tcito, o que explica grande parte da dificuldade no desenvolvimento de software. Traduzir conhecimento de um contexto para outro, como traduzir qualquer lngua, no envolve apenas gramtica bsica e regras sintticas, mas tambm questes de significado e inteno que so contextuais e subjetivas. (...) De um modo geral, software oferece um exerccio de traduzir algoritmos existentes na natureza, organizaes ou prticas para a forma digital. Grande parte deste conhecimento de domnio tcito, indefinido, no codificado e desenvolvido ao longo do tempo, freqentemente sem ser explcito at mesmo para os indivduos que participaram do processo. Ainda mais importante, este conhecimento e as prticas so dinmicos, evoluindo constantemente e se transformando (EISCHEN, 2002, p.39, traduo nossa).

A transmisso de conhecimento tcito representa um desafio significativo para as equipes de desenvolvimento, o qual pode ser solucionado de forma mais ou menos eficaz dependendo dos mecanismos de comunicao adotados no projeto. A forma de se transmitir uma idia exerce uma grande influncia na compreenso correta da mesma (TELES, 2004, p.48). Quando uma pessoa est na presena de outra e transmite uma idia atravs de um dilogo, o interlocutor tem acesso a vrios elementos que compem a comunicao, tais como expresses faciais, gestos, postura, palavras verbalizadas e tom de voz. A mesma conversa por telefone, seria desprovida de todos os elementos visuais. Portanto, a comunicao por telefone, por exemplo, menos rica em elementos que um dilogo presencial, o que torna mais difcil compreender a idia transmitida.

61

A riqueza do meio de comunicao exerce influncia ainda maior quando se observa a transmisso de conhecimento tcito. Imaginemos uma situao na qual uma pessoa ao telefone tenta ensinar a seu interlocutor como dar um lao no cadaro de seu tnis. Usando o telefone, as chances de sucesso so reduzidas. Entretanto, se os interlocutores estivessem na presena um do outro, seria fcil demonstrar como dar um lao atravs de um exemplo. Alm disso, medida que o aprendiz fizesse algumas tentativas, o mentor poderia fornecer feedback de modo a corrigir eventuais erros. Em muitos projetos, os usurios executam atividades cotidianas de modo tcito, com efeitos semelhantes ao exemplo acima. Sendo assim, tm dificuldades em explicar o que fazem usando um meio de comunicao pouco rico (como telefone, ou email, por exemplo), mas so capazes de mostrar o que fazem com alguma facilidade se a comunicao puder ocorrer atravs de um dilogo presencial. Essa uma das razes pelas quais o Extreme Programming prioriza mecanismos de comunicao mais ricos.
Uma equipe XP faz um excelente uso de comunicao osmtica, comunicao face-a-face, correntes de conveco no fluxo da informao e radiadores de informao nas paredes. A disponibilidade consistente de especialistas significa que o tempo entre uma pergunta e sua resposta curto. O tempo e a energia gastos para descobrir uma informao demandada baixo; a taxa de disperso da informao alta (COCKBURN, 2002, p.167, traduo nossa).

Projetos XP procuram envolver ativamente seus usurios (ou ao menos um representante dos mesmos) fazendo com que se tornem parte integrante da equipe de desenvolvimento. Na prtica, isso significa que o usurio (ou seu representante) est presente no mesmo local onde os desenvolvedores trabalham, possibilitando que eles tenham acesso rpido e direto a um ou mais especialistas no domnio do negcio. Isso ajuda a acelerar o fluxo de informaes e permite que a comunicao se baseie prioritariamente em dilogos presenciais.

62

A rapidez na comunicao um aspecto relevante, pois o ritmo de progresso de um projeto est ligado ao tempo que se leva para transmitir uma informao da mente de uma pessoa para outra (COCKBURN, 2002, p.77, traduo nossa). Alm disso, os custos de um projeto crescem na proporo do tempo necessrio para as pessoas se compreenderem (COCKBURN, 2002, p.81, traduo nossa). A proximidade dos participantes auxilia os processos de comunicao. Mas o XP tambm emprega outros mecanismos, como os radiadores de informao (COCKBURN, 2002) que, alm de facilitar a comunicao, ajudam a colocar em prtica um modelo de auto-direcionamento do processo de desenvolvimento.
Um radiador de informao mostra informaes onde transeuntes podem v-la. Com radiadores de informao, eles no precisam ficar perguntando; a informao simplesmente chega a eles medida que passam pelo local (COCKBURN, 2002, p.84, traduo nossa).

[Radiadores de informao so uma forma de] controle visual, ou gesto vista. Se o trabalho ser autodirecionado, ento todos precisam ser capazes de ver o que est acontecendo, o que precisa ser feito, que problemas existem, que progresso est sendo alcanado. O trabalho no pode ser auto-direcionado at que controles visuais simples, apropriados para o domnio, sejam colocados em uso, atualizados e usados para direcionar o trabalho (POPPENDIECK & POPPENDIECK, 2003, p.76, traduo nossa).

Outro fator que influencia a qualidade da comunicao a quantidade de pessoas envolvidas. Com cada aumento no tamanho [da equipe], torna-se mais difcil para as pessoas saber o que os outros esto fazendo e como no sobrepor, duplicar ou interferir no trabalho um do outro (COCKBURN, 2002, p.151, traduo nossa). Por esta razo, projetos XP procuram contar com um nmero reduzido de participantes (freqentemente menor que uma dzia de pessoas) (BECK, 2000).
O limite essencial no o nmero de ferramentas ou falta de organizao, mas sim comunicao. O aumento da quantidade de linhas de comunicao e a qualidade das mesmas, e no o nmero de

63

pessoas, complica o desenvolvimento de software (EISCHEN, 2002, p.39, traduo nossa).

5.1.3 Simplicidade Como vimos anteriormente, estudos do Standish Group revelam que 45 por cento das funcionalidades encontradas em um sistema tpico jamais so usadas e 19 por cento raramente so utilizadas, totalizando 64 por cento de funcionalidades que poderiam nem sequer ter sido implementadas. Em outras palavras, os projetos de software freqentemente investem grande parte dos recursos (tempo, pessoas e dinheiro) em esforos desnecessrios. Em diversos projetos observa-se a ocorrncia de trs fenmenos que ajudam a esclarecer as razes dos resultados acima: O escopo fixado no incio e alteraes no mesmo so evitadas; Os desenvolvedores criam solues genricas para facilitar possveis alteraes que possam ocorrer no escopo e Os desenvolvedores produzem funcionalidades adicionais na tentativa de antecipar o que o usurio certamente ir solicitar no futuro. Todos os casos acima derivam de preocupaes legtimas e justificveis dos clientes e desenvolvedores. No primeiro caso, o cliente teme no receber todas as funcionalidades que imagina necessitar, o que o leva a fixar o escopo. Nos ltimos dois casos, o desenvolvedor teme que o cliente pea alteraes tardias no sistema que possam gerar atrasos. Assim, procura tornar o software mais flexvel, de modo que mudanas possam ser implementadas ajustando-se parmetros para evitar recodificar partes do sistema. Alm disso, tenta antever funcionalidades que provavelmente sero

64

necessrias (embora o cliente ainda no perceba isso) e as implementa de modo que, quando o cliente as solicitar, j estaro prontas. Estas preocupaes so justificveis, porm as abordagens utilizadas apresentam problemas. Fixar o escopo arriscado, porque significa que tanto as funcionalidades realmente teis, quanto as desnecessrias sero implementadas. A diferena entre elas s costuma ser notada ao longo do projeto, medida que os usurios conseguem obter feedback do software. Portanto, uma alternativa a adoo de um modelo de desenvolvimento iterativo, com iteraes curtas, no incio das quais o cliente possa priorizar as funcionalidades (POPPENDIECK & POPPENDIECK, 2003).
Visto que os clientes normalmente no sabem direito o que desejam no incio do projeto, eles tendem a pedir tudo o que acham que podem vir a precisar, especialmente se eles pensarem que s tero uma nica chance de pedir. Esta uma das melhores maneiras que conhecemos para aumentar o escopo do projeto muito alm do necessrio para alcanar a misso geral do projeto (POPPENDIECK & POPPENDIECK, 2003, p.32-33, traduo nossa).

Para que uma equipe de desenvolvimento possa trabalhar com iteraes curtas, necessrio que ela seja capaz de receber um pequeno escopo de funcionalidades no incio de cada iterao e implement-las completamente dentro de um curto prazo de tempo. Isso cria a necessidade de concentrar esforos apenas no essencial para implementar as funcionalidades da iterao, evitando generalizaes que ainda no se mostrem necessrias e a criao de funcionalidades que ainda no tiverem sido solicitadas pelos usurios. Existem vantagens nesta abordagem, pois (...) adicionar suporte para futuras funcionalidades de forma desnecessria complica o design e eleva o esforo para desenvolver incrementos subseqentes (BOEHM & TURNER, 2003, p.41, traduo nossa).

65

Simplicidade e comunicao possuem uma maravilhosa relao de apoio mtuo. Quanto mais voc comunica, mais claramente voc capaz de ver o que precisa ser feito e mais confiana voc tem sobre o que realmente no precisa ser feito. Quanto mais simples o seu sistema, menos voc precisa comunicar sobre ele, o que leva comunicao mais completa, especialmente se voc for capaz de simplificar o sistema suficientemente a ponto de necessitar de menos programadores (BECK, 2000, p.31, traduo nossa).

Os desenvolvedores de um projeto XP procuram implementar as funcionalidades priorizadas para cada iterao com a maior qualidade possvel, porm com foco apenas naquilo que claramente essencial. Generalizaes que no se provem imediatamente necessrias so evitadas, pois se voc mantiver o sistema suficientemente simples o tempo todo, qualquer coisa que voc coloque nele ser inserido facilmente e na menor quantidade de lugares possvel (JEFFRIES, ANDERSON et al., 2001, p.76, traduo nossa). Ao invs de tentar prever que mudanas o usurio solicitar e, portanto, que generalizaes sero teis, os desenvolvedores procuram simplificar o sistema, tornando-o mais fcil de ser alterado no futuro. Como programadores, nos habituamos a antecipar problemas. Quando eles aparecem mais tarde, ficamos felizes. Quando no aparecem, nem notamos (BECK, 2000, p.104-105, traduo nossa). Alm disso, equipes XP se baseiam no princpio de que funcionalidades extras adicionam complexidade e no flexibilidade (POPPENDIECK & POPPENDIECK, 2003, p.59, traduo nossa). Sendo assim, procuram adiar a incluso de qualquer funcionalidade at que ela realmente seja priorizada e solicitada pelo cliente.
Pode parecer uma boa idia colocar algumas funcionalidades extras no sistema para o caso de se tornarem necessrias. (...) Isso pode parecer inofensivo, mas, ao contrrio, trata-se de um srio desperdcio. Cada fragmento de cdigo no sistema precisa ser rastreado, compilado, integrado e testado a cada vez que o cdigo sofre uma interveno, e ento, precisa ser mantido durante toda a vida do software. Cada fragmento de cdigo eleva a complexidade e uma parte que pode

66

falhar (POPPENDIECK & POPPENDIECK, 2003, p.6, traduo nossa).

5.1.4 Coragem

Existem temores que costumam assombrar os participantes de um projeto de software. Beck e Fowler (2001) destacam alguns destes medos que exercem influncia significativa nos processos de desenvolvimento. Clientes temem: No obter o que pediram; Pedir a coisa errada; Pagar demais por muito pouco; Jamais ver um plano relevante; No saber o que est acontecendo e Fixarem-se em suas primeiras decises e no serem capazes de reagir a mudanas nos negcios. Desenvolvedores, por sua vez, temem: Ser solicitados a fazer mais do que sabem fazer; Ser ordenados a fazer coisas que no faam sentido; Ficar defasados tecnicamente; Receber responsabilidades, sem autoridade; No receber definies claras sobre o que precisa ser feito; Sacrificar a qualidade em funo de prazo; Ter que resolver problemas complicados sem ajuda e

67

No ter tempo suficiente para fazer um bom trabalho.

Equipes XP reconhecem estes temores e buscam formas de lidar com eles de maneira corajosa. Ter coragem em XP significa ter confiana nos mecanismos de segurana utilizados para proteger o projeto. Ao invs de acreditar que os problemas no ocorrero e fazer com que a coragem se fundamente nesta crena, projetos XP partem do princpio de que problemas iro ocorrer, inclusive aqueles mais temidos. Entretanto, a equipe utiliza redes de proteo que possam ajudar a reduzir ou eliminar as conseqncias destes problemas. O cliente teme no obter o que pediu, ou ainda pior, pedir a coisa errada. Para proteg-lo, o XP adota iteraes curtas (normalmente de uma a trs semanas) e fixas (se a equipe opta por duas semanas, por exemplo, todas as iteraes do projeto tero sempre esta durao). Desta forma, ao final de cada iterao, possvel avaliar se a equipe implementou o que foi pedido e se o que foi pedido realmente fazia sentido. O problema no eliminado em funo do desenvolvimento iterativo. O cliente pode ter solicitado algo errado no incio da iterao ou a equipe pode ter implementado de forma incorreta, mas isso descoberto cedo. Como a iterao curta, poucas funcionalidades so implementadas. Portanto, caso haja um erro, o mesmo se refere a um conjunto reduzido de funcionalidades, o que facilita eventuais correes e evita que a equipe invista muitos recursos em funcionalidades incorretas, caso o cliente tenha errado ao solicit-las (POPPENDIECK & POPPENDIECK, 2003). O desenvolvimento iterativo tambm ajuda a lidar com o medo que o cliente tem de pagar demais por muito pouco. Ao receber funcionalidades com freqncia, em prazos curtos, o cliente passa a ter diversas oportunidades de avaliar o trabalho da

68

equipe com base em feedback concreto: software executvel. Assim ele pode decidir se continua ou no a empregar aquela equipe ou se prefervel trocar (TELES, 2004). Alm disso, o feedback constante, produzido ao longo das iteraes, faz com que o cliente possa saber exatamente o que est acontecendo no projeto. Finalmente, o processo de planejamento no esttico. A cada incio de iterao o planejamento geral do projeto revisado e atualizado com base em informaes mais recentes. Isto , o processo de planejamento contnuo e procura incorporar feedback ao longo do tempo. Isso permite a elaborao de planos para cada iterao que tm maiores chances de acerto. Alm disso, no processo de priorizao, o cliente pode incorporar novas decises de negcios de forma natural (BECK & FOWLER, 2001). Desenvolver software de forma iterativa e incremental no tem apenas vantagens. Tambm gera alguns riscos, como por exemplo o de introduzir falhas em algo que vinha funcionando corretamente. Por isso, o XP adota a prtica de desenvolvimento orientado a testes como mecanismo bsico de proteo. O desenvolvimento orientado a testes uma forma de lidar com o medo durante a programao (BECK, 2003, p.x, traduo nossa). Ele leva os desenvolvedores a criar uma base de testes automatizados que possam ser executados toda vez que um novo fragmento de cdigo adicionado ao sistema. Embora isso no impea a ocorrncia de erros, representa um instrumento til para detect-los rapidamente, o que agiliza a correo e evita que eventuais bugs se acumulem ao longo do tempo. Os desenvolvedores temem no saber solucionar alguns problemas e no serem capazes de se atualizar tecnicamente. O XP utiliza a programao em par para permitir que os membros da equipe de desenvolvimento aprendam continuamente uns com os

69

outros. Alm disso, a possibilidade de contar sempre com a ajuda imediata de um colega gera maior confiana na capacidade de resolver os desafios apresentados pelo cliente. Finalmente, a programao em par estabelece um processo permanente de inspeo de cdigo, o que serve como uma rede de proteo adicional contra eventuais erros cometidos durante a codificao de novas funcionalidades ou alterao de outras previamente existentes (WILLIAMS & KESSLER, 2003). Outra preocupao permanente dos desenvolvedores no ter tempo suficiente para realizar um trabalho de qualidade. O XP trata essa questo dividindo claramente a responsabilidade por decises tcnicas e de negcio. O cliente tem soberania nas decises de negcio. Portanto, ele decide que funcionalidades devem ser implementadas e em que ordem. Os desenvolvedores, por sua vez, tm autoridade e responsabilidade sobre as decises tcnicas. Portanto, so eles que estimam os prazos. Isso ajuda a lidar com o medo de ter que cumprir prazos impossveis impostos por pessoas que no possuam a qualificao tcnica para estimar o esforo de um determinado trabalho de programao (BECK & FOWLER, 2001). 5.2 Prticas 5.2.1 Cliente Presente Imaginemos que uma pessoa esteja muito acima de seu peso ideal e decida buscar a orientao de uma nutricionista para formular uma dieta e ajudar a reduzir o peso. Na primeira consulta, a pessoa pergunta nutricionista quanto tempo ser necessrio para que ela perca dez quilos. Infelizmente no existe uma resposta exata para esta pergunta, pois o resultado final depende do trabalho de ambas as partes. Da mesma forma que a nutricionista precisa ser capaz de elaborar uma dieta adequada, o

70

paciente deve ter a disciplina de segui-la. O resultado s alcanado se ambos fizerem sua parte corretamente. O desenvolvimento de software possui caractersticas semelhantes. Tanto o cliente, quanto os desenvolvedores tm um papel a cumprir. O melhor e mais participativo cliente no ser capaz de obter o software desejado se a equipe de desenvolvimento no implementar corretamente o que pedido e a melhor equipe no ser capaz de produzir o software certo se o cliente no for capaz de especific-lo adequadamente e prover feedback ao longo do projeto. Infelizmente, deficincias na participao do cliente tm sido apontadas como um dos principais fatores a gerar falhas nos projetos de software.
A falta de envolvimento dos usurios tradicionalmente tem sido a causa nmero um das falhas nos projetos. No sentido oposto, a contribuio nmero um para o sucesso de um projeto tem sido envolvimento dos usurios. Mesmo quando entregue no prazo e dentro do oramento, um projeto pode falhar se no tratar das necessidades e expectativas dos usurios (THE STANDISH GROUP INTERNATIONAL, 2001, p.4, traduo nossa).

O XP se preocupa com esta questo e procura solucion-la trazendo o cliente para fazer parte da equipe de desenvolvimento. Em termos prticos, isso significa colocar o cliente fisicamente prximo aos desenvolvedores ou mover os desenvolvedores para prximo do cliente.
Ter especialistas de domnio disposio o tempo todo significa que o tempo de feedback entre a soluo ser imaginada e depois avaliada o mais curto possvel, freqentemente de minutos ou algumas poucas horas. Tal rapidez no feedback significa que a equipe de desenvolvimento ganha uma compreenso mais profunda das necessidades e hbitos dos usurios e comete menos erros quando cria novas idias. Eles tentam mais idias diferentes, o que faz com que o produto final fique melhor. Havendo boa dose de colaborao, os programadores iro testar as idias dos especialistas de domnio e oferecer contrapropostas. Isso ir aperfeioar as prprias idias do cliente sobre como o sistema deve se parecer (COCKBURN, 2002, p.179, traduo nossa).

71

A presena do cliente ao longo do desenvolvimento viabiliza o ciclo contnuo de feedback entre ele e os desenvolvedores. Este ciclo permite que pequenas mudanas sejam feitas ao longo do desenvolvimento, de forma rpida. importante lembrar que o tempo de feedback fundamental. Ou seja, se a equipe recebe feedback do cliente rapidamente, ela aprende com mais preciso a idia que o cliente est transmitindo e vice-versa. Para que isso funcione, necessrio que haja proximidade fsica entre clientes e desenvovedores. Existem muitos estudos que mostram que a comunicao reduzida enormemente pela separao. Mover colegas um andar abaixo reduz a comunicao quase tanto quanto se os movssemos para o outro lado do mundo (JEFFRIES, ANDERSON et al., 2001, p.18, traduo nossa). A reduo da distncia entre cliente e desenvolvedores tambm produz outro efeito benfico: a melhoria na relao de confiana entre as partes envolvidas. Estar prximo fisicamente permite que o cliente perceba mais facilmente os esforos da equipe de desenvolvimento. Alm disso, a reduo no tempo para a obteno de resultados tambm ajuda a elevar a satisfao do cliente, o que tambm melhora os relacionamentos (TELES, 2004). Envolver o cliente na equipe, embora tenha efeitos positivos nos projetos, nem sempre possvel ou fcil. Boehm e Turner (2003), Emam (2003) e Teles (2004) apresentam situaes nas quais pode ser difcil ou invivel a introduo desta prtica. 5.2.2 Jogo do Planejamento Como se observou anteriormente, estatsticas demonstram que muitos projetos dedicam esforos significativos implementao de funcionalidades que no so

72

utilizadas mais tarde. Portanto, decidir o que implementar uma das atividades mais importantes a serem conduzidas durante o desenvolvimento de um sistema.
Tempo o inimigo de todos os projetos. Visto que o escopo impacta na durao do projeto, ambos esto associados. Minimizando o escopo, o tempo reduzido e portanto as chances de sucesso crescem (THE STANDISH GROUP INTERNATIONAL, 2001, p.4, traduo nossa).

Os estudos do Standish Group demonstram a importncia do conceito de triagem para o desenvolvimento de software. Segundo Yourdon (2004), as funcionalidades de um sistema podem ser categorizadas em tem que ser feita, deveria ser feita e poderia ser feita. Cabe aos membros do projeto assegurar que as funcionalidades que tm que ser feitas sejam implementadas em primeiro lugar.
Assumindo que a regra familiar 80-20 seja verdadeira, a equipe de projeto pode ser capaz de entregar 80 por centro do benefcio do sistema implementando 20 por cento dos requisitos se ela implementar os 20 por cento corretos (YOURDON, 2004, p.117, traduo nossa).

O planejamento usado em XP para assegurar que a equipe esteja sempre trabalhando no mais importante, a cada momento do projeto.
No planejamos para prever o futuro. Os negcios e o software mudam rpido demais para que previses sejam possveis. Planejamos porque: Precisamos assegurar que estamos sempre trabalhando naquilo que a coisa mais importante que precisamos fazer; Precisamos coordenar com outras pessoas e Quando eventos inesperados acontecem, precisamos compreender as conseqncias para os dois primeiros (BECK & FOWLER, 2001, p.2-3, traduo nossa).

O XP considera o planejamento uma atividade contnua a ser desempenhada ao longo de todo o projeto. O maior valor no est nos planos gerados, mas sim no exerccio de cri-los. Como muitos, ns gostamos da citao de Eisenhower: Na preparao para a batalha, descobri que planos so inteis, mas planejar indispensvel

73

(BECK & FOWLER, 2001, p.xiii, traduo nossa). Por esta razo, os planos e as prioridades so revisados com freqncia. Projetos XP procuram dividir o tempo disponvel para o projeto utilizando dois conceitos: releases e iteraes. O XP tem releases que tomam alguns poucos meses, que se dividem em iteraes de duas semanas, que se dividem em tarefas que tomam alguns dias (BECK & FOWLER, 2001, p.21, traduo nossa). O planejamento aloca histrias (fragmentos de funcionalidades) em releases e iteraes. Elas so registradas em pequenos cartes, fceis de serem manipulados pelo cliente e pelos desenvolvedores. No planejamento do release, o cliente escolhe histrias equivalentes a alguns poucos meses de trabalho, tipicamente se concentrando em um lanamento pblico (BECK & FOWLER, 2001, p.39, traduo nossa). Esta idia ilustrada na figura 5.1.

Figura 5.1: release e iteraes em um projeto XP.

Em cada ciclo de release, o cliente controla o escopo, decidindo o que fazer e o que adiar, de modo a prover o melhor release possvel na data acertada. O trabalho se encaixa no cronograma baseado no valor para o negcio, dificuldade e a velocidade de implementao da equipe (JEFFRIES, ANDERSON et al., 2001, p.55, traduo nossa).

Um release representa um marco no tempo no qual um conjunto coeso de funcionalidades finalizado e lanado para consumo de seus usurios. No espao de tempo de um release (que normalmente de meses) a equipe implementa

74

funcionalidades em iteraes curtas e fixas que fornecem cadncia ao processo de desenvolvimento.

Uma iterao um incremento de software til que projetado, programado, testado, integrado e entregue durante um espao de tempo curto e fixo. (...) Este software ser aprimorado em iteraes futuras, mas se trata de cdigo funcionando, testado e integrado desde o incio. Iteraes fornecem um aumento dramtico de feedback em relao ao desenvolvimento de software seqencial, portanto, promovendo comunicao muito mais ampla entre clientes e desenvolvedores, e entre as vrias pessoas que possuem interesses no sistema. (...) Problemas de design so expostos cedo, e medida que mudanas acontecem, tolerncia a mudanas construda no sistema (POPPENDIECK & POPPENDIECK, 2003, p.28, traduo nossa).

O final de uma iterao representa um ponto de sincronizao no projeto, um momento no qual o cliente e os desenvolvedores avaliam as funcionalidades produzidas e re-avaliam as prioridades para as iteraes seguintes. Alm disso, permite que eventuais falhas sejam detectadas antes de seguir adiante com o desenvolvimento.
Que as pessoas cometam erros, em princpio, no nos surpreende. De fato, exatamente por isso que o desenvolvimento iterativo e incremental foi inventado. (...) A razo para utilizar estratgias incrementais e iterativas permitir que os inevitveis erros das pessoas sejam descobertos relativamente cedo e corrigidos de forma apropriada (COCKBURN, 2002, p.47-48, traduo nossa).

As funcionalidades so representadas atravs de histrias, que refletem necessidades do cliente e so suficientemente pequenas para que os programadores possam implementar um pequeno conjunto delas a cada iterao. Uma histria deve ser compreensvel pelo cliente e pelos desenvolvedores, testvel, valiosa para o cliente (...) (BECK & FOWLER, 2001, p.45, traduo nossa).
A maioria dos mtodos geis expressa os requisitos em termos de histrias informais ajustveis. Mtodos geis contam com seus ciclos rpidos de iteraes para determinar as mudanas necessrias nas funcionalidades desejadas e para corrigi-las na iterao seguinte. Determinar o conjunto de requisitos mais prioritrios a ser includo na iterao seguinte feito de forma colaborativa por clientes e

75

desenvolvedores. Os clientes expressam suas necessidades mais fortes e os desenvolvedores avaliam que combinao de funcionalidades vivel de ser includa na iterao seguinte (...). Negociaes estabelecem os contedos da iterao seguinte (BOEHM & TURNER, 2003, p.37-38, traduo nossa).

Como j foi mencionado anteriormente, o XP atribui aos clientes a responsabilidade de priorizar as histrias e aos desenvolvedores a responsabilidade de estim-las. A estimativa representa o custo esperado para uma determinada histria. Esta informao importante para que o cliente possa priorizar de maneira adequada. O valor de negcio depende daquilo que voc obtm, quando obtm e quanto custa. Para decidir o que fazer e quando, os clientes precisam saber o custo daquilo que pedem (JEFFRIES, ANDERSON et al., 2001, p.14-15, traduo nossa).
O cliente: Define as histrias; Decide qual o valor de negcio de cada histria e Decide que histrias sero construdas no release. Os programadores: Estimam quanto tempo ser necessrio para construir cada histria; Advertem o cliente sobre riscos tcnicos significativos e Medem o progresso da equipe para fornecer um oramento geral para o cliente (BECK & FOWLER, 2001, p.40, traduo nossa).

As estimativas so geradas com base em experincias passadas dos desenvolvedores. Ou seja, eles observam as histrias que ainda precisam ser implementadas e procuram identificar outras que j tenham sido finalizadas no passado e que sejam semelhantes s histrias que ainda sero desenvolvidas no futuro.
O melhor guia para estimar o futuro olhar alguma coisa que aconteceu no passado que seja parecida com a coisa futura. Ento simplesmente assuma que a histria se repetir. Freqentemente isso acontece (BECK & FOWLER, 2001, p.57-58, traduo nossa).

Segundo Beck e Fowler (2001, p.95, traduo nossa), a nica coisa que se sabe sobre um plano que as coisas no sairo de acordo com ele. Portanto, preciso

76

monitorar a iterao em intervalos regulares. Atrasos, por exemplo, podem ser detectados cedo caso haja um processo permanente de monitoramento, pois o fato que o projeto atrasa, um dia de cada vez (BROOKS, 1995, p.154, traduo nossa). O progresso da iterao monitorado diariamente utilizando-se ferramentas como o quadro de acompanhamento dirio (ver seo 6.13) proposto por Teles (2004). Um dos principais objetivos de seu uso determinar a velocidade da equipe em uma iterao e a carga de trabalho que cada histria efetivamente consumiu. A velocidade representa basicamente a quantidade de trabalho que a equipe capaz de entregar em uma iterao. No incio de uma iterao, o modelo de planejamento do XP assume que a equipe ser capaz de entregar a mesma quantidade de histrias efetivamente implementadas na iterao anterior. Se ao final, isso no acontecer, o nmero ajustado, passando a refletir mais uma vez o nmero de histrias que a equipe efetivamente entregou (BECK & FOWLER, 2001). A velocidade utilizada como um oramento que apresentado ao cliente no incio de cada iterao, quando os desenvolvedores declaram, por exemplo, que o cliente poder alocar at seis histrias na iterao que se inicia. Ao longo do projeto a velocidade tende a convergir rapidamente para um valor que se mantm quase constante durante todo o desenvolvimento. Variaes existem, mas costumam ser reduzidas. O desenvolvimento baseado em iteraes curtas uma forma de elevar as chances de convergir para um sistema que efetivamente atenda s necessidades de seus usurios dentro do tempo disponvel para o projeto. Alm disso, os processos de replanejamento baseados em feedback e na velocidade da equipe geram maior previsibilidade sobre os resultados do projeto.
Uma boa estratgia para atingir convergncia trabalhar nos itens de mais alta prioridade primeiro, deixando os menos prioritrios irem

77

para baixo na lista de pendncias. Entregando funcionalidades de alta prioridade primeiro, provvel que voc entregue a maior parte do valor de negcio bem antes de toda a lista ser cumprida (...). Esta abordagem para a gerncia do projeto pode parecer que ir levar a resultados imprevisveis, mas na prtica exatamente o oposto que acontece. Uma vez que se estabelea um histrico de entregas de software funcionando, fcil projetar a quantidade de trabalho que ser feito em cada iterao medida que o projeto avana (POPPENDIECK & POPPENDIECK, 2003, p.32-33, traduo nossa).

5.2.3 Stand up meeting Um projeto de desenvolvimento de software pode ser compreendido como um sistema humano composto por elementos tais como clientes, desenvolvedores, gerentes, entre outros. O bom funcionamento do projeto depende do bom funcionamento de cada um de seus componentes, bem como da interao entre os mesmos.
Um sistema consiste de partes interdependentes que interagem em conjunto para atingir um propsito. Um sistema no apenas a soma de suas partes o produto de suas interaes. As melhores partes no necessariamente formam o melhor sistema; a habilidade de um sistema de atingir o seu propsito depende de quo bem as partes trabalham em conjunto, no apenas quo bem atuam individualmente (POPPENDIECK & POPPENDIECK, 2003, p.153, traduo nossa),

Com o objetivo de assegurar que as partes trabalhem bem em conjunto, o XP utiliza uma breve reunio diria chamada de stand up meeting4. Ela procura alinhar os membros da equipe informando os resultados obtidos no dia anterior e permitindo que os participantes priorizem as atividades do dia que se inicia. Um dia de trabalho de uma equipe XP sempre comea com um stand up meeting. (...) Primeiramente, ele serve para que todos os membros da equipe comentem rapidamente o trabalho que executaram no dia anterior (TELES, 2004, p.87). Isso gera visibilidade de tudo o que ocorre na equipe para cada um de seus membros, o que permite identificar rapidamente problemas e solues que foram encontrados no dia

O termo em ingls significa reunio em p. Fazer com que as pessoas permaneam em p durante a reunio uma forma de incentiv-las a concluir a reunio rapidamente.

78

anterior. uma forma de disseminar conhecimento e assegurar que as pessoas tenham acesso s informaes mais recentes medida que o projeto prossegue. Projetos XP procuram assegurar que a equipe trabalhe sempre naquilo que mais prioritrio primeiro. Por isso, existem diversos ciclos de planejamento e o stand up meeting usado para o planejamento dirio das atividades da equipe. Alm de disseminar informaes sobre o dia anterior, a equipe prioriza o trabalho a ser feito no dia que se inicia.
No fim do stand up meeting, cada membro da equipe sabe o que dever fazer ao longo do dia. importante notar que a deciso sobre o que fazer ao longo do dia no tomada por uma nica pessoa. Essa deciso tomada em equipe. Isso faz sentido, porque quando todos se renem, possvel ter uma viso de todo o desenvolvimento e no apenas da uma parte. Desta forma, factvel decidir com mais eficcia quais so as prioridades do dia (TELES, 2004, p.88).

O stand up meeting uma reunio que fora uma aproximao dos desenvolvedores de forma diria e contnua. Ele diminui os tempos de feedback, na medida em que cada desenvolvedor reporta as atividades executadas no dia anterior. Isso permite que toda a equipe tenha conhecimento rapidamente dos desafios que foram enfrentados por cada membro, das solues criadas, das idias colocadas em prtica e dos problemas que precisam ser tratados com urgncia.
Estas reunies curtas so excelentes para desenvolver o esprito de equipe e comunicar, bem como para determinar quem ir fazer par com quem durante o dia, a manh ou a tarde (WILLIAMS & KESSLER, 2003, p.5, traduo nossa).

Tal reunio s pode ser feita com freqncia diria, se todos os desenvolvedores estiverem trabalhando prximos uns aos outros e compartilhando um mesmo ambiente. A reduo do tempo de feedback dentro da equipe evita que problemas sejam prolongados, visto que o stand up meeting tambm usado para que a equipe priorize em conjunto as atividades que devem ser executadas a cada dia.

79

Percebemos que reunies dirias curtas so inestimveis para dar a cada pessoa uma idia do que os outros esto fazendo. (...) Cada pessoa diz brevemente o que fez no dia anterior e o que est fazendo hoje. Problemas e anncios importantes para a equipe tambm so passados. (...) O objetivo do stand up meeting comunicar problemas e no resolv-los. (...) Tudo que demandar qualquer coisa alm de um breve anncio deve ser reservado para outra sesso onde apenas aqueles interessados no assunto devem estar presentes (BECK & FOWLER, 2001, p.105, traduo nossa).

5.2.4 Programao em Par Williams e Kessler (2003, p.3, traduo nossa) definem a programao em par como sendo um estilo de programao no qual dois programadores trabalham lado a lado em um computador, continuamente colaborando no mesmo design, algoritmo, cdigo e teste. A programao em par utilizada por todos os desenvolvedores durante toda a durao de um projeto XP. Esta tcnica implementa uma das diversas redes de proteo que os projetos XP utilizam para reduzir os riscos de eventuais falhas. Quando um programador desenvolve em par, ele conta com a presena de outro desenvolvedor que faz uma inspeo imediata de todo o cdigo que produzido. Isso importante porque numerosos experimentos confirmaram que o olho tem uma tendncia de ver o que ele espera ver (WEINBERG, 1971, p.162, traduo nossa). Sendo assim, possui uma capacidade quase infinita de no ver o que no quer ver. (...) Programadores, se deixados com seus prprios aparelhos, iro ignorar os erros mais escandalosos (...) que qualquer outra pessoa consegue ver em um instante (WEINBERG, 1971, p.56, traduo nossa). Na medida em que um nico caractere faltando ou incorreto pode consumir literalmente dias para ser encontrado (WILLIAMS & KESSLER, 2003, p.3, traduo

80

nossa), a oportunidade de identificar problemas cedo pode significar economia no tempo dedicado depurao nos projetos e capaz de reduzir a incidncia de bugs.
Inspees de cdigo foram introduzidas h mais de 20 anos como uma maneira econmica de detectar e remover defeitos de software. Resultados e estudos empricos (Fagan, 1976) consistentemente proferem a eficcia das revises. Entretanto, a maioria dos programadores acha as inspees desagradveis e no satisfatrias. (...) A teoria sobre porque as inspees so eficazes se baseia no conhecimento proeminente de que quanto mais cedo um defeito encontrado em um produto, mais barato o seu conserto (WILLIAMS & KESSLER, 2003, p.27, traduo nossa).

A programao em par torna o processo de inspeo parte natural do dia-a-dia da equipe de desenvolvimento. Isso permite que ela consiga utilizar inspees com freqncia sem incorrer nos problemas que tornam as inspees tradicionalmente desagradveis.
Revises em pares (tambm conhecidas como inspeo do cdigo) representam uma das formas mais eficazes para encontrar defeitos em software. As evidncias que do suporte s revises em pares remontam a mais de duas dcadas e ningum mais questiona seus benefcios. (...) (...) apesar das evidncias em relao ao valor das inspees, existem indicaes de que inspees de software tradicionais no so to prevalentes na prtica. A programao em par uma forma de institucionalizar as revises em pares dentro dos projetos de software, o que seria uma grande melhoria para a maioria dos projetos (EMAM, 2003, p.12, traduo nossa).

Alguns nmeros ilustram o valor de se identificar defeitos cedo. Watts Humphrey coletou dados da indstria (WILLIAMS & KESSLER, 2003) que demonstram que o tempo normalmente alocado a depurao de um nico bug costuma ser elevado, de modo que identific-lo cedo pode reduzir significativamente os gastos com depurao.
Tipicamente, durante os testes do sistema leva-se metade (Humphrey, 1995) ou dois (Humphrey, 1997) dias de trabalho para corrigir cada defeito. Dados da indstria relatam que de 33 a 88 horas so gastas em cada defeito encontrado no campo (Humphrey, 1995). Quando cada

81

defeito evitado durante o desenvolvimento do cdigo pode poupar um tempo de correo que varia em 0,5 e 88 horas, a programao em par rapidamente se transforma em uma alternativa que poupa tempo e dinheiro (WILLIAMS & KESSLER, 2003, p.39, traduo nossa).

Mesmo quando eventuais problemas aparecem no sistema, a programao em par ajuda a acelerar a depurao. O simples fato de ter uma pessoa ao lado freqentemente ajuda a encontrar a soluo do problema mais rapidamente.
[Uma] tcnica eficaz explicar o seu cdigo para outra pessoa. Isso normalmente far com que voc explique o bug para si mesmo. (...) Uma outra pessoa ir fazer perguntas e provavelmente far com que voc se explique freqentemente. As perguntas e respostas podem levar a grandes revelaes (WILLIAMS & KESSLER, 2003, p.28, traduo nossa).

Outro aspecto importante da programao em par o fato freqentemente observado de que duas pessoas pensando sobre um mesmo problema conseguem explorar mais cenrios de solues e adotar aqueles mais simples e eficazes. Durante o desenvolvimento em par, os programadores mantm um dilogo constante, isto , eles discutem novas idias e abordagens continuamente (WILLIAMS & KESSLER, 2003, p.18, traduo nossa).
Os pares consideram muito mais solues possveis para um problema e convergem mais rapidamente para a soluo que ser implementada. De acordo com os pesquisadores Nick Flor e Edwin Hutchins, o feedback, debate e troca de idias entre parceiros reduzem significativamente a probabilidade de proceder com um design ruim (WILLIAMS, KESSLER et al., 2000, p.20, traduo nossa).

Ao explorar mais cenrios e escolher solues mais simples, os desenvolvedores ajudam a manter o sistema mais simples como um todo. O que ajuda a torn-lo mais fcil de compreender, manter e modificar ao longo do tempo. Alm disso, optar por solues mais simples freqentemente leva a reduo no tempo de desenvolvimento das funcionalidades, o que ajuda a acelerar o progresso da equipe.

82

A programao em par tambm til no processo de aprendizado dos desenvolvedores, o que relevante visto que o negcio da programao se baseia mais do que qualquer outro em aprendizado sem fim (WEINBERG, 1971, p.193, traduo nossa). Durante o trabalho dos pares, o conhecimento passado constantemente entre os parceiros, desde dicas de utilizao das ferramentas at regras da linguagem de programao (...) os pares se revezam no papel de professor e aluno (WILLIAMS & KESSLER, 2003, p.29, traduo nossa).
A reviso contnua que decorre da programao colaborativa cria um mecanismo educacional nico porque os parceiros vivenciam um aprendizado sem fim. O processo de analisar e criticar artefatos de software produzidos por outras pessoas um mtodo poderoso de aprendizado sobre linguagens, domnios de aplicao e assim por diante (Johnson, 1998). O aprendizado que transcende estas revises contnuas previne a ocorrncia de defeitos futuros e a preveno de defeitos mais eficaz que qualquer forma de remoo de defeitos. A reviso contnua que decorre da programao colaborativa, na qual cada parceiro trabalha sem cessar para identificar e resolver problemas, gera tanto eficincia tima em termos de remoo de defeitos, quanto o desenvolvimento de habilidades para a preveno dos mesmos (WILLIAMS & KESSLER, 2003, p.29, traduo nossa).

O aprendizado atravs da programao em par particularmente eficaz porque no est isolado. Ele est ocorrendo dentro do contexto de um problema maior que voc precisa resolver (TELES, 2004, p.95). Segundo Weinberg (1971, p.195-196, traduo nossa), nenhum momento ser mais propcio para aprender do que aquele no qual a necessidade do aprendizado sentida de maneira mais forte (...). A existncia de um problema, dentro de um contexto bem definido, atua como uma forte motivao para que o programador aprenda algo para que seja capaz de solucionar o problema. A presena imediata de um colega que tenha conhecimentos importantes sobre o problema em questo torna o processo de aprendizado imediato. O problema que gerou a necessidade do aprendizado faz com que o aprendiz dedique

83

grande ateno e interesse quilo que est sendo ensinado. Isso eleva a capacidade de absoro do contedo, bem como a fixao dos conceitos. Outro fator que exerce influncia a prpria contribuio que o programador est dando ao projeto com a soluo que busca construir.
Lave e Wenger (1991) estudaram vrios tipos de aprendizagem. Eles enfatizam a importncia de que o aprendiz participe ativamente, que ele tenha um trabalho legtimo para fazer, e que ele trabalhe na periferia se movendo consistentemente para um trabalho mais elevado. Lave e Wenger enfatizam a importncia de que o aprendiz trabalhe dentro da linha de viso do especialista (WILLIAMS & KESSLER, 2003, p.29, traduo nossa).

De forma semelhante, a programao em par (...) tambm uma tima estratgia de gesto do conhecimento uma excelente maneira de passar conhecimento tcito pela equipe (WILLIAMS & KESSLER, 2003, p.16, traduo nossa). Como observamos anteriormente, a disseminao de conhecimento tcito essencial para o bom andamento de um projeto.
(...) programao em par funciona para o XP porque encoraja a comunicao. Gosto de pensar na analogia com um copo dgua. Quando uma informao importante aprendida por algum na equipe, como se colocssemos uma gota de tintura na gua. J que os pares se revezam o tempo todo, a informao se difunde rapidamente atravs da equipe, da mesma forma que a tintura se espalha atravs da gua. Ao contrrio da tintura, entretanto, a informao vai ficando mais rica e mais intensa medida que se espalha e enriquecida pela experincia e idias de todas as pessoas da equipe (BECK, 2000, p.101, traduo nossa).

A programao em par tambm eleva a robustez da equipe, permitindo que ela supere melhor a perda ou a adio de um novo membro. Com a programao em par, o risco do projeto associado perda de um programador chave reduzido porque existem vrias pessoas familiarizadas com cada parte do sistema (WILLIAMS & KESSLER, 2003, p.41, traduo nossa). Alm disso, novos desenvolvedores podem comear a contribuir mais cedo.

84

Tradicionalmente, pessoas novas em uma organizao so apresentadas a diferentes partes de um sistema por uma pessoa experiente da equipe. Este tempo dedicado ao treinamento custa diversas horas valiosas do membro experiente. Durante estas horas, nem a pessoa nova, nem o treinador esto contribuindo no sentido de completar o projeto (WILLIAMS & KESSLER, 2003, p.42, traduo nossa).

Em uma equipe XP, o novo membro ir trabalhar em par com diversas pessoas da equipe, em vrias partes do sistema. Nestes momentos, a pessoa que estiver atuando como seu mentor ir produzir mais lentamente, porm continuar produzindo. O novo programador, por sua vez, tender a aprender os conceitos mais rapidamente devido s razes explicadas anteriormente sobre a eficcia da programao em par para o processo de aprendizado. Alm disso, a programao em par ajuda a assegurar que o novo membro aprenda rapidamente o mtodo de trabalho da equipe.
De um modo geral, ns nos comportamos da mesma forma que vemos as pessoas se comportarem a nossa volta, portanto, um grupo de programao funcionando tender a socializar novos membros para sua filosofia de programao (WEINBERG, 1971, p.61, traduo nossa).

A programao em par tambm tende a gerar maior aderncia ao processo de desenvolvimento escolhido pela equipe. Isso vale tanto para desenvolvedores novos, quanto para aqueles que j esto na equipe h mais tempo. Em XP, isso particularmente relevante, pois embora seja um processo de desenvolvimento simples e com pouca formalidade, um processo significativamente disciplinado (COCKBURN, 2002).
Outra caracterstica poderosa da programao em par que algumas das prticas no funcionariam sem ela. Sob estresse, as pessoas recuam. Elas deixariam de escrever os testes, no iriam refatorar5 e

5 Do ingls refactor. A palavra no existe em portugus, porm alguns livros de XP recentes trazem a expresso refatorar como um neologismo, que adotado nesta dissertao para facilitar a leitura, evitar o uso do termo em ingls e se alinhar s demais publicaes que j utilizam o termo.

85

evitariam integrar. Com o seu parceiro olhando, contudo, existem boas chances de que mesmo que voc esteja ignorando uma destas prticas, o seu parceiro no estar. (...) as chances de ignorar o seu compromisso com o restante da equipe bem menor trabalhando em par que se voc estivesse trabalhando sozinho (BECK, 2000, p.102, traduo nossa).

Um efeito conhecido como presso do par costuma estar presente durante a programao em par e exerce influncia sobre a produtividade dos desenvolvedores. A responsabilidade compartilhada com outra pessoa faz com que os programadores se concentrem mais e melhor naquilo que esto produzindo. Os programadores admitem trabalhar com mais afinco e de forma mais inteligente nos programas porque no querem decepcionar seus parceiros (WILLIAMS & KESSLER, 2003, p.21, traduo nossa).
(...) ter um parceiro trabalhando com voc durante a maior parte do dia minimiza distraes e interrupes. Um desenvolvedor dificilmente ir bater papo sobre questes de lazer ao telefone enquanto uma pessoa estiver sentada ao seu lado esperando que termine. Da mesma forma, algum dificilmente ir interromper duas pessoas no meio de uma discusso. Portanto, a quantidade de tempo no produtivo que recuperado pode levar a um aumento de produtividade (EMAM, 2003, p.12, traduo nossa).

Alm de elevar a concentrao e reduzir interrupes por terceiros, a presso do par tambm evita os bloqueios mentais e distraes seja porque um parceiro mantm o outro na trilha certa (e no distrado) ou porque um dos parceiros consegue ultrapassar o bloqueio mental (WILLIAMS & KESSLER, 2003, p.18-19, traduo nossa). Isso tambm ajuda a recuperar um tempo que, de outra forma, seria improdutivo. Embora a programao em par oferea oportunidades de melhoria nos projetos, a reao intuitiva de muitas pessoas rejeitar a idia (...) porque assumem que haver um aumento de cem por cento de programador-hora colocando dois programadores para

86

fazer o trabalho que um pode fazer (WILLIAMS & KESSLER, 2003, p.38, traduo nossa). Entretanto, pesquisas demonstram que isso no ocorre na prtica. Williams e Kessler (2003) executaram experimentos, com resultados estatisticamente significativos, demonstrando que a programao em par eleva o nmero de programador-hora em apenas 15 por cento. Entretanto, conseguiram validar estatisticamente os relatos que alegam que a programao em par um meio acessvel de produzir software de mais elevada qualidade (WILLIAMS & KESSLER, 2003, p.9, traduo nossa). Ou seja, apesar da ligeira elevao no consumo de recursos, os resultados mostraram que os desenvolvedores que trabalharam em par geraram um nmero significativamente menor de defeitos, produziram menos cdigo para solucionar o mesmo problema e tiveram resultados mais consistentes (WILLIAMS, KESSLER et al., 2000).
Trabalhando em sintonia, os pares completaram suas atribuies de 40% a 50% mais rapidamente. No mercado atual, obter um produto de qualidade to rapidamente quanto possvel uma vantagem competitiva que pode at significar a prpria sobrevivncia. Consertar defeitos depois de lanar os produtos para os clientes pode custar muito mais que encontr-los e consertlos durante o desenvolvimento. Os benefcios de ter um produto lanado mais rapidamente, com gastos menores de manuteno e que melhora a satisfao dos clientes supera qualquer aumento na quantidade de programador-hora que possa resultar dos pares (WILLIAMS, KESSLER et al., 2000, p.22-24, traduo nossa).

Finalmente, a programao em par tambm ajuda a elevar a motivao dos desenvolvedores, tornando o trabalho mais divertido e facilitando a comunicao. Em nossa recente pesquisa pela Web, perguntamos, Que benefcios voc encontrou na programao em par? A resposta mais comum foi: muito mais divertido (WILLIAMS & KESSLER, 2003, p.21, traduo nossa). Naturalmente, quanto mais

87

agradvel e divertido for o trabalho de programao, mais produtivo o mesmo tender a ser.
Na pesquisa on-line com programadores profissionais que trabalham em par, 96% afirmaram que gostavam mais do trabalho em relao a quando programavam sozinhos. Ns entrevistamos seis vezes os 41 programadores que trabalharam de forma colaborativa em pares no experimento da universidade. Consistentemente, mais de 90% deles afirmaram que gostavam mais de trabalhar em par que sozinhos. Adicionalmente, virtualmente todos os programadores profissionais pesquisados afirmaram que ficavam mais confiantes em suas solues quando programavam em par. Quase 95% dos estudantes ecoaram esta afirmao. Existe uma correlao natural entre estas duas medidas de satisfao. Isto , os pares gostavam mais se seu trabalho porque ficavam mais confiantes com o resultado final (WILLIAMS, KESSLER et al., 2000, p.24, traduo nossa).

O trabalho dirio executado com diferentes pessoas freqentemente ajuda a aproxim-las e a quebrar barreiras de comunicao. Isso envolve inclusive a aproximao no nvel pessoal que tambm gera benefcios ao longo do desenvolvimento.
medida que os membros da equipe se conhecem melhor, eles se tornam muito mais propensos a falar entre eles sobre questes pessoais e tcnicas. As barreiras de comunicao entre cada pessoa comeam a cair. As pessoas passam a considerar as outras muito mais acessveis. (...) O relacionamento e a confiana construdo entre os membros da equipe geram em cada um a coragem de pedir conselhos e orientao sem se sentirem vulnerveis e insuficientes. Alm disso, eles se sentem melhor sobre o trabalho que fazem porque conhecem seus companheiros de equipe no nvel pessoal (WILLIAMS & KESSLER, 2003, p.43, traduo nossa).

Apesar de seus benefcios, a programao em par pode se revelar problemtica em pelo menos duas circunstncias: a presena de programadores com ego excessivamente elevado e competio entre os membros da equipe.
Um programador que genuinamente veja seu programa como uma extenso do seu prprio ego no ir tentar encontrar todos os erros naquele programa. Ao contrrio, tentar provar que o programa est correto mesmo que isso signifique fazer vista grossa para erros que

88

so monstruosos para outros olhos (WEINBERG, 1971, p.55, traduo nossa).

Alm disso, fazer par com uma pessoa de ego excessivamente elevado costuma ser difcil e propenso a conflitos. Por sua vez, programar em par em ambientes competitivos pouco vivel porque o processo de ensino e aprendizado fica bloqueado em funo da competio.
O ato de ensinar simplesmente no pode ocorrer se as pessoas no se sentirem seguras. Em uma atmosfera de competio, voc seria maluco se deixasse algum ver voc aprendendo com outra pessoa; seria uma clara indicao de que voc conhece menos que o seu mentor sobre um determinado assunto. Da mesma forma, voc seria louco de ensinar outra pessoa, j que esta pessoa poderia eventualmente usar seus ensinamentos para passar a sua frente (DEMARCO & LISTER, 1999, p.182-183, traduo nossa).

5.2.5 Cdigo Coletivo Complementando a programao em par, equipes XP tambm praticam o conceito de cdigo coletivo: todas as classes e mtodos pertencem equipe e qualquer membro da equipe pode melhorar o que for necessrio (JEFFRIES, ANDERSON et al., 2001, p.122, traduo nossa). O desenvolvedor no apenas programa em par com diferentes pessoas ao longo do tempo, como tambm tem acesso a todas as partes do cdigo, inclusive aquelas que ele no programou. Alm disso, tem o direito de fazer qualquer alterao que considerar necessria sem ter que pedir permisso. Naturalmente, seus colegas tambm podem alterar o seu cdigo sem lhe pedir (BECK, 2000). Isso significa que os desenvolvedores tm a oportunidade de trabalhar com pessoas diferentes e em partes diferentes do cdigo. Existe um revezamento dirio em ambos os aspectos. Assim se estabelece mais uma rede de proteo, visto que os programadores podem revisar e alterar o cdigo escrito em diferentes partes do sistema,

89

por diferentes pessoas. Como alteraes no cdigo podem causar erros, a prtica de cdigo coletivo s pode ser adotada com segurana se a equipe investir em testes automatizados. Cdigo coletivo aquela idia aparentemente maluca de que qualquer pessoa pode alterar qualquer fragmento de cdigo no sistema a qualquer momento. Sem os testes, voc estaria morto tentando fazer isso (BECK, 2000, p.99-100, traduo nossa). Esta prtica tambm protege o projeto ajudando a tornar a equipe mais robusta, na medida em que os desenvolvedores se habituam a trabalhar nas mais variadas partes do sistema. Sendo assim, todo o trabalho fica menos suscetvel de ser afetado se algum ficar doente (...) ou faltar (...). Isso no apenas reduz as variaes no cronograma, mas tambm eleva as chances de ter algum por perto quando o cdigo tiver que ser modificado (WEINBERG, 1971, p.59-60, traduo nossa). A adoo do cdigo coletivo tambm permite que a equipe avance mais rapidamente porque ningum precisa esperar at que outra pessoa aparea para consertar alguma coisa. O cdigo permanece mais limpo porque os programadores no so forados a contornar uma deficincia em um objeto criando um outro (JEFFRIES, ANDERSON et al., 2001, p.122, traduo nossa). Alm disso, a equipe tem razes genunas para manter o cdigo simples ao longo do projeto.
Um dos efeitos do cdigo coletivo que cdigo complexo no sobrevive por muito tempo. Visto que todos esto acostumados a olhar todas as partes do sistema, tal cdigo ser encontrado logo, ao invs de tardiamente. Quando for encontrado, algum ir tentar simplificlo. (...) A propriedade coletiva do cdigo tem a tendncia de evitar que cdigos complexos entrem no sistema em primeiro lugar. Se voc sabe que outra pessoa ir olhar para o que voc est escrevendo dentro de pouco tempo (em algumas horas), voc ir pensar duas vezes antes de colocar no sistema uma complexidade que voc no conseguir justificar (BECK, 2000, p.99-100, traduo nossa).

90

5.2.6 Cdigo Padronizado

Em projetos XP, os programadores codificam seguindo um padro de cdigo acordado. No importa muito o formato. O que realmente importa que todos os membros da equipe adotem o padro e o utilizem sempre. (...) no so as

especificidades (...) que contam; a sua familiaridade com elas (JEFFRIES, ANDERSON et al., 2001, p.79, traduo nossa).
Padres de cdigo (...) so importantes porque levam a uma maior consistncia dentro do seu cdigo e o cdigo de seus colegas de equipe. Mais consistncia leva a um cdigo mais simples de compreender, o que por sua vez significa que mais simples desenvolver e manter (AMBLER, 2000, p.1, traduo nossa).

A adoo de um padro ajuda a simplificar a comunicao, a programar em par e a tornar o cdigo coletivo. Da mesma forma, a prpria programao em par e a prtica de cdigo coletivo ajudam a assegurar que a equipe ir seguir o padro adotado. Como o cdigo passa por vrios nveis de reviso, fcil detectar e corrigir qualquer cdigo fora do padro. Porm para assegurar que o padro realmente seja usado, qualquer padro envolvido deve surgir e evoluir no nvel das prprias pessoas que realizam o trabalho. A propriedade do padro deve estar nas mos daqueles que realizam o trabalho (DEMARCO, 2001, p.109, traduo nossa). 5.2.7 Design Simples Existem pelo menos quatro coisas que os usurios de um software esperam dele: Que faa a coisa certa; Que funcione; Que seja fcil de utilizar e Que possa evoluir com o tempo.

91

As prticas do XP se complementam formando um conjunto que busca atingir estes objetivos. Para assegurar que o sistema esteja fazendo a coisa certa e esteja funcionando, o desenvolvimento executado em iteraes curtas nas quais se implementa um pequeno conjunto de histrias. O feedback gerado ao final de cada iterao permite que os usurios avaliem se o sistema realmente est fazendo a coisa certa e se est funcionando. Adotar iteraes curtas, portanto, um mecanismo importante para atingir parte destes objetivos, entretanto, impe um desafio. Como fazer a anlise, design, implementao, teste e depurao de um conjunto de funcionalidades em uma ou duas semanas? Isso s possvel se os desenvolvedores mantiverem o design da aplicao suficientemente simples (BECK, 2000). A facilidade de uso, por sua vez, conquistada quando se consegue desenvolver um software que tenha integridade perceptvel e integridade conceitual. Um programa limpo e elegante tem que apresentar a cada um de seus usurios um modelo mental coerente (...). A integridade conceitual, como percebida pelo usurio, o fator mais importante na facilidade de uso (BROOKS, 1995, p.255-256, traduo nossa).
Integridade conceitual significa que os conceitos centrais de um sistema operam em conjunto como um todo equilibrado e coeso. Os componentes se encaixam e funcionam bem em conjunto; a arquitetura alcana um equilbrio eficaz entre flexibilidade, manutenibilidade, eficincia e presteza. A arquitetura de um sistema de software se refere forma como o sistema estruturado para prover as funcionalidades e caractersticas desejadas. Uma arquitetura eficaz o que leva um sistema a ter integridade conceitual (POPPENDIECK & POPPENDIECK, 2003, p.135, traduo nossa).

Criar uma arquitetura de software que possua integridade conceitual um feito importante que pode ser ameaado caso o sistema sofra alteraes freqentes. Algumas mudanas vlidas de objetivos (e de estratgia de desenvolvimento) so inevitveis e

92

melhor estar preparado para elas que assumir que elas no viro (BROOKS, 1995, p.241, traduo nossa). Portanto, embora o desenvolvimento iterativo seja til para alcanar alguns dos objetivos do projeto, parece ser uma proposta arriscada quando se deseja construir um sistema fcil de ser utilizado e que tambm possa evoluir ao longo do tempo. Na prtica, entretanto, as iteraes provm oportunidades para que a arquitetura seja revisada, aprimorada e amadurea com o tempo.
(...) clientes de um sistema de software geralmente no so capazes de definir o que iro perceber como sendo ntegro, assim como eles no sabem descrever de forma precisa o que desejam em um carro. Os clientes sabem quais so seus problemas, mas com bastante freqncia, no conseguem descrever a soluo. Eles sabero reconhecer um bom sistema quando o encontrarem, mas eles no conseguem visualiz-lo previamente. Para piorar as coisas, medida que suas circunstncias mudarem, tambm mudaro suas percepes sobre a integridade do sistema (POPPENDIECK & POPPENDIECK, 2003, p.130-131, traduo nossa).

A arquitetura de um sistema precisa ser capaz de evoluir porque a necessidade de mudanas a nica constante encontrada no desenvolvimento, visto que o software se encontra inserido em uma matriz cultural de aplicaes, usurios, leis e equipamentos de hardware (...) [que] muda continuamente e (...) fora mudanas no software (BROOKS, 1995, p.184, traduo nossa).
medida que novas funcionalidades so adicionadas a um sistema para manter a integridade perceptvel, as caractersticas subjacentes da arquitetura para acomodar as funcionalidades de maneira coesa tambm precisam ser modificadas (POPPENDIECK & POPPENDIECK, 2003, p.128-129, traduo nossa).

Dados da indstria indicam que entre 50 e 70 por cento de todo o esforo gasto em um programa sero gastos depois que o mesmo for entregue para o usurio pela primeira vez (PRESSMAN, 1997, p.18, traduo nossa). Isso representa uma razo adicional para que a equipe de desenvolvimento encontre mecanismos para facilitar mudanas futuras. Uma forma de fazer isso tentar prever o que precisar mudar e

93

tornar o sistema mais genrico de modo a se ajustar mais facilmente a tais mudanas previstas. Entretanto, generalizaes freqentemente elevam a complexidade do sistema e muitas vezes as previses no se materializam. Outra forma de resolver essa questo utilizar o feedback das iteraes para detectar as generalizaes necessrias e tornar a arquitetura naturalmente tolerante a mudanas.
A maior parte dos sistemas de software dinmica ao longo do tempo; bem mais da metade dos gastos em uma aplicao ocorrero depois de ela entrar em produo. Os sistemas devem ser capazes de se adaptar a mudanas tanto de negcio, quanto tcnicas de forma econmica. Uma das abordagens chave para incorporar mudanas em uma infraestrutura de informao assegurar que o prprio processo de desenvolvimento incorpore mudanas continuamente. (...) Um processo de design tolerante a mudanas tem mais chances de criar como resultado um sistema tolerante a mudanas (POPPENDIECK & POPPENDIECK, 2003, p.134, traduo nossa).

Equipes XP procuram assegurar que o design seja mantido simples e eventuais flexibilidades sejam adiadas at que se tornem efetivamente necessrias em funo das histrias solicitadas pelos usurios. Portanto, os desenvolvedores no tentam prever mudanas futuras, nem procuram antecipar as flexibilidades que sero necessrias. Eles esperam o feedback das iteraes para receber informao concreta sobre onde a arquitetura precisa ser sofisticada.
Observar onde as mudanas ocorrem ao longo do desenvolvimento iterativo d uma boa indicao de onde o sistema provavelmente precisar de flexibilidade no futuro. (...) Se um sistema desenvolvido permitindo que o design v emergindo atravs de iteraes, o design ser robusto, adaptando-se mais prontamente para os tipos de mudana que ocorrem ao longo do desenvolvimento. Ainda mais importante, a habilidade de se adaptar ser construda dentro do sistema de modo que medida que mais mudanas ocorram aps o seu lanamento, elas possam ser prontamente incorporadas. (POPPENDIECK & POPPENDIECK, 2003, p.52, traduo nossa).

94

Temendo a incapacidade de adaptar o sistema no futuro, diversas equipes de desenvolvimento criam solues desnecessariamente complexas para problemas que possivelmente no iro nem aparecer no futuro. Nestes casos, os desenvolvedores enveredam em um trabalho especulativo que consome recursos do projeto, eleva a complexidade do cdigo e o potencial de ocorrncia de erros. Alm disso, um design complicado mais difcil de comunicar que um simples. Devemos, portanto, criar uma estratgia de design que gere o design mais simples possvel, consistente com nossos demais objetivos (BECK, 2000, p.103, traduo nossa).
(...) cada programa tem um nvel apropriado de cuidado e sofisticao dependendo dos usos para os quais ser colocado em prtica. Trabalhar acima deste nvel , em certo sentido, ainda menos profissional que trabalhar abaixo. (...) Freqentemente, contudo, o programador no consegue ajustar suas atividades para o problema que tem nas mos porque ele no sabe exatamente que problema tem nas mos. Isto , ele assume que certas coisas so desejadas talvez com base naquilo que ele sabe fazer, ou com base naquilo que foi desejado no ltimo trabalho que ele programou mas ele nunca descobre o que era desejado at o trabalho ser finalizado (WEINBERG, 1971, p.127, traduo nossa).

As equipes XP procuram adiar decises de design tanto quanto possvel. Ou seja, implementam o design mais simples e comunicativo possvel para os problemas de hoje. Sofisticaes que possam ser necessrias para acomodar necessidades futuras no so implementadas at que se atinja um ponto no desenvolvimento no qual a equipe ir implementar de fato as histrias que demandem tais sofisticaes. Desta forma, se reduz as chances de adicionar cdigo desnecessrio e elevar a complexidade do sistema cedo demais (POPPENDIECK & POPPENDIECK, 2003). O problema desta abordagem que algumas alteraes podem acabar se revelando custosas no futuro.
Em 1987, Barry Boehm escreveu Encontrar e corrigir um problema de software aps a entrega custa 100 vezes mais que encontrar e corrigir o problema em fases iniciais de design. Esta observao se tornou a lgica por traz de colocar a anlise de requisitos e o design no incio do projeto, embora o prprio Boehm encorajasse o

95

desenvolvimento incremental. Em 2001, Boehm notou que para sistemas pequenos o fator de escalada pode ser algo mais prximo de 5:1 do que 100:1; e mesmo em sistemas grandes, boas prticas arquiteturais podem reduzir significativamente o custo de mudana confinando funcionalidades que so provveis de sofrerem alteraes em reas pequenas e bem encapsuladas (POPPENDIECK & POPPENDIECK, 2003, p.50, traduo nossa).

Se o custo de alterar o software se elevar exponencialmente ao longo do tempo, a abordagem iterativa pode ser arriscada e muito custosa. Entretanto, se for possvel mant-lo baixo, tal abordagem pode ser incorporada nos projetos de software com resultados positivos.
Nem todas as mudanas so iguais. Existem algumas poucas decises arquiteturais bsicas nas quais voc precisa acertar no comeo do desenvolvimento, porque elas fixam restries do sistema para toda a vida do mesmo. Exemplos podem ser a escolha da linguagem, decises de camadas a serem usadas na arquitetura ou a escolha de interagir com um banco de dados existente tambm utilizado por outras aplicaes. Estes tipos de decises podem ter uma taxa de escalada no custo de 100:1. (...) A maior parte das mudanas em um sistema no tem necessariamente que ter um alto fator de escalada do custo. (...) Uma nica curva ou fator de escalada do custo enganoso. Ao invs de um nico grfico mostrando uma nica tendncia para todas as mudanas, um grfico mais apropriado tem ao menos duas curvas da escalada do custo, como mostrado na figura [5.2] (POPPENDIECK & POPPENDIECK, 2003, p.49-51, traduo nossa).

96

Figura 5.2: custo de uma mudana em um software ao longo do tempo.

Equipes XP se baseiam na idia de que em determinadas circunstncias, o crescimento exponencial no custo de mudana do software ao longo do tempo pode se tornar linear (BECK, 2000, p.21, traduo nossa). Tal idia se fundamenta, entre outros, nos seguintes fatores: Avanos ocorridos na microinformtica; A adoo da orientao a objetos; O uso da refatorao para aprimorar e simplificar o design; e A adoo de testes automatizados.
A revoluo do microcomputador mudou a forma como se constri software. (...) Computadores individuais velozes agora so ferramentas rotineiras do desenvolvedor de software (...). O computador pessoal de hoje em dia no apenas mais veloz que o supercomputador de 1960, mais rpido que as estaes Unix de 1985. Tudo isso significa que compilar rpido at mesmo na mquina mais humilde, e grandes quantidades de memria eliminaram esperas por montagens baseadas em acessos a disco. Grandes quantidades de memria tambm tornam razovel manter tabelas de smbolos na memria com o cdigo objeto, de modo que depurao em alto nvel sem re-compilao se tornou rotina (BROOKS, 1995, p.281-282, traduo nossa).

Computadores velozes permitem, entre outras coisas, executar testes automatizados em poucos segundos cada vez que uma nova funcionalidade ou modificao inserida no sistema. Isso significa que possvel obter feedback mais rapidamente e detectar falhas mais cedo. Alm disso, inmeras tecnologias importantes passaram a ser utilizadas nas ltimas dcadas na tentativa de reduzir o custo da mudana, tais como a orientao a objetos, melhores linguagens, melhor tecnologia de banco de dados, melhores prticas de programao, melhores ambientes e ferramentas, bem como novas notaes (BECK, 2000, p.23, traduo nossa).

97

Programadores de equipes XP desenvolvem o hbito de refatorar o cdigo permanentemente, com o objetivo de mant-lo simples ao longo do tempo. As oportunidades de refatorao so identificadas utilizando-se as revises freqentes que so causadas pelas prticas de programao em par e cdigo coletivo. Finalmente os testes automatizados ajudam a equipe a identificar rapidamente se uma mudana no sistema causou algum tipo de erro. Quanto mais rpido o erro identificado, menor o tempo de depurao e menor o custo associado mudana. Portanto, o XP se baseia na idia de que a curva de mudana se mantm constante ao longo do tempo e a adoo de suas prticas colabora para que essa idia seja verdadeira (BECK, 2000).
(...) quando o cdigo suficientemente simples, tudo o que escrevemos deve: 1. Passar em todos os testes; 2. Expressar todas as idias que temos que expressar; 3. Dizer tudo uma vez e apenas uma vez; e 4. Ter o nmero mnimo de classes e mtodos que seja consistente com as recomendaes acima (JEFFRIES, ANDERSON et al., 2001, p.83, traduo nossa).

5.2.8 Desenvolvimento Orientado a Testes Sistemas computacionais e projetos de software costumam vivenciar diversas dificuldades ao longo do tempo. Um dos problemas mais caros e recorrentes a incidncia de defeitos.
De acordo com a mais recente estimativa do Departamento de Comrcio americano, os softwares defeituosos custam 60 bilhes de dlares por ano s economia americana. No Brasil, no h dados confiveis, mas especialistas acreditam que uns 8 bilhes de reais ou cerca de 0,6% do PIB no seria um nmero muito distante da realidade.(...) H quatro anos a Mars Climate Orbiter foi perdida quando entrava na atmosfera de Marte. Mal programado, o software embutido na sonda misturou medidas em ps com metros e, por um problema to simples, provocou um prejuzo de 125 milhes de dlares. (TEIXEIRA, 2004).

O problema ocorrido no software da Mars Climate Orbiter, que relatado com maiores detalhes em (ISBELL, HARDIN et al., 1999) e (SORID, 1999), um exemplo

98

de quo custosas podem ser as conseqncias dos defeitos em sistemas computacionais. Embora tais conseqncias normalmente sejam mais crticas depois que o sistema j se encontra em produo, elas tambm tm efeitos danosos no dia-a-dia dos projetos. Quando um defeito identificado, faz-se necessrio depurar o software. Depurao a parte difcil e lenta da programao de sistemas, e ciclos [de feedback] demorados representam o pior problema da depurao (BROOKS, 1995, p.245, traduo nossa). Ela demorada porque os programadores se esquecem do que fizeram. Se escrevo um programa hoje e o testo em uma semana, minhas recordaes sobre como o escrevi tero se perdido (...). Portanto (...) no serei capaz de imaginar rapidamente onde est o problema (JEFFRIES, ANDERSON et al., 2001, p.32, traduo nossa).
Se voc observar como os programadores passam o tempo, ir descobrir que codificar na verdade representa uma pequena frao. Algum tempo gasto tentando descobrir o que precisa ser feito, algum tempo gasto projetando, mas a maior parte do tempo gasta depurando. (...) Consertar o bug normalmente rpido, mas descobrir o que o est causando um pesadelo. Ento, quando voc corrige um bug, sempre existe a chance de que outro aparea e que voc no venha a notar at que j tenha se passado bastante tempo (FOWLER, 2000, p.89, traduo nossa).

Por isso, essencial que as equipes de desenvolvimento sejam capazes de reduzir a incidncia de bugs e o custo associado depurao e eliminao dos mesmos. Isso vlido durante o projeto, porm ainda mais relevante durante a manuteno do sistema.
O problema fundamental com a manuteno de programas que consertar um defeito tem uma chance substancial (20-50 por cento) de introduzir outro. Assim, o processo todo dois passos para frente e um para trs. Por que os defeitos no so corrigidos de forma mais limpa? Primeiro, mesmo um defeito sutil se revela como uma falha local de algum tipo. De fato, ele freqentemente possui ramificaes ao redor do sistema, normalmente nada bvias. Qualquer tentativa de repar-lo com o mnimo de esforo ir corrigir a parte local e bvia, mas os efeitos do

99

reparo que alcanam outras partes do sistema sero ignorados. Segundo, aquele que faz o reparo normalmente no a pessoa que escreveu o cdigo, e freqentemente um programador jnior ou um programador em treinamento (BROOKS, 1995, p.122, traduo nossa).

Equipes XP lidam com estes problemas utilizando uma tcnica conhecida como desenvolvimento orientado a testes. Ela consiste em escrever um mecanismo de teste automatizado antes de codificar cada histria e cada mtodo do sistema (BECK, 2000). Trata-se de uma tcnica preventiva utilizada durante todo o projeto e a manuteno. A preveno usada porque (...) antes da questo de como resolver problemas vem a questo de evitar problemas. (...) um programador que evita problemas mais inteligente que aquele que traz problemas para si mesmo (WEINBERG, 1971, p.164165, traduo nossa).
Ao invs de esperar at o final [do desenvolvimento], muito mais barato, no longo prazo, adotar um modelo do tipo pague medida que for usando. Escrevendo testes com o cdigo medida que voc avana, no h nenhuma correria no final e voc experimenta menos bugs ao longo do projeto na medida em que est sempre trabalhando com cdigo testado. Reservando um pouquinho mais de tempo o tempo todo, voc minimiza o risco de necessitar de uma quantidade enorme de tempo no final (HUNT & THOMAS, 2003, p.9, traduo nossa).

Os testes automatizados procuram comprovar que as solicitaes dos usurios esto sendo atendidas de forma correta. De tudo o que podemos esperar de um programa, primeiro e mais importante, que ele esteja correto. Em outras palavras, deveria gerar as sadas corretas para cada entrada possvel (WEINBERG, 1971, p.17, traduo nossa). Alm disso, os testes verificam se as histrias continuam funcionando ao longo do tempo, pois (...) alm de assegurar que o cdigo faa o que voc quer, voc precisa assegurar que o cdigo faa o que voc quer o tempo todo (HUNT & THOMAS, 2003, p.5, traduo nossa).

100

Testes so mais valiosos quando o nvel de estresse se eleva, quando as pessoas esto trabalhando muito, quando o julgamento humano comea a falhar. Portanto, os testes tm que ser automatizados retornando uma indicao sobre o funcionamento do sistema do tipo polegar para cima ou polegar para baixo (BECK, 2000, p.116, traduo nossa).

Os desenvolvedores se concentram em dois aspectos durante a programao. O cdigo deve se manter limpo e precisa funcionar.
O objetivo cdigo limpo que funcione por uma srie de razes: Cdigo limpo que funcione uma forma previsvel de desenvolver. Voc sabe quando terminou sem ter que se preocupar com uma longa lista de bugs; Cdigo limpo que funcione lhe d a chance de aprender todas as lies que o cdigo tem para ensinar (...); Cdigo limpo que funcione melhora a vida dos usurios do nosso software; Cdigo limpo que funcione permite que seus colegas de equipe possam confiar em voc e que voc possa confiar neles e Escrever um cdigo limpo que funcione faz com que o desenvolvedor se sinta melhor (BECK, 2003, p.viii, traduo nossa).

O XP se concentra sobretudo em dois tipos de testes: o teste de unidade e o teste de aceitao. O primeiro tenta assegurar que cada componente do sistema funcione corretamente. O segundo procura testar a interao entre os componentes, as quais do origem s funcionalidades (BECK, 2000). Os testes de unidade so escritos antes de cada mtodo produzido no sistema. a forma utilizada pelos desenvolvedores para saber se o mtodo ir funcionar ou no. Quando um desenvolvedor codifica, ele deve obter feedback imediato para saber se o cdigo funciona como desejado. Em outras palavras, deve haver um teste para cada mecanismo que o desenvolvedor implementar (POPPENDIECK & POPPENDIECK, 2003, p.146, traduo nossa).

101

Feedback imediato importante porque evita que os defeitos passem muito tempo despercebidos. Como se observou anteriormente, depurar costuma ser custoso porque o desenvolvedor esquece o que fez, por que fez e o contexto em torno da funcionalidade que se encontra defeituosa. Ao depurar tudo isso precisa ser recordado. Sendo assim, quanto mais tempo se passa entre o momento em que o erro introduzido e o momento em que identificado, maior tende a ser o tempo de depurao (TELES, 2004). O feedback imediato gerado pelos testes de unidade ajuda a reduzir este tempo e, portanto, freqentemente consegue acelerar a depurao. Mas, isso tudo s possvel se os testes forem automatizados.
Se os testes no forem automatizados ou se tomarem muito tempo, eles no sero executados com suficiente freqncia. Grandes lotes de mudanas sero implementados antes de testar, o que tornar muito mais provvel a ocorrncia de falhas e ser bem mais difcil identificar que mudana fez com que os testes falhassem (POPPENDIECK & POPPENDIECK, 2003, p.147, traduo nossa).

Os testes de aceitao (tambm conhecidos como testes funcionais) so escritos para assegurar que o sistema como um todo funciona. (...) Eles tipicamente tratam o sistema inteiro como uma caixa preta tanto quanto possvel (FOWLER, 2000, p.97, traduo nossa). Estes testes so escritos pelo cliente ou com a orientao do cliente, pois ele a pessoa que conhece o negcio e, portanto, os resultados que devem ser produzidos pelo sistema.
Os clientes escrevem teste para uma histria de cada vez. A pergunta que eles precisam se fazer : O que necessitaria ser verificado antes que eu tivesse a confiana de que esta histria est finalizada? Cada cenrio que eles imaginam se transforma em um teste, neste caso, um teste funcional (BECK, 2000, p.118, traduo nossa).

Como os clientes normalmente no so capazes de escrever e automatizar os testes de aceitao por conta prpria, uma equipe XP de qualquer tamanho carrega

102

consigo pelo menos um analista de teste dedicado. O trabalho dele traduzir as idias de testes, s vezes vagas, do cliente em testes reais, automatizados e isolados (BECK, 2000, p.118-119, traduo nossa). Por maiores que sejam os investimentos em testes unitrios e funcionais, equipes XP eventualmente encontram bugs que no so detectados pelos testes. Nestes casos, os desenvolvedores criam testes que exponham os defeitos antes de corrigi-los. Desta forma, se protegem do caso em que um mesmo bug volte a ocorrer no futuro. Se ocorrer, ser identificado rapidamente.
Como boa prtica, o programa de teste deveria ser construdo antes que a correo fosse feita no programa de produo. Em primeiro lugar, haver uma tendncia absolutamente humana de esquecer sobre o problema assim que o programa de produo estiver funcionando corretamente, portanto temos que impor uma pequena disciplina sobre ns mesmos. Possivelmente mais importante, entretanto, a chance de que o mero ato de construir o caso de teste nos faa descobrir o problema (WEINBERG, 1971, p.196-197, traduo nossa).

Novas funcionalidades e eventuais correes inseridas em um cdigo tm o potencial de adicionar novos defeitos no mesmo. Por essa razo, aps cada correo [ou adio de funcionalidade], deve-se executar a base de casos de teste inteira para assegurar que o sistema no foi danificado de uma forma obscura (BROOKS, 1995, p.242-243, traduo nossa). Ainda segundo Brooks (1995, p.246, traduo nossa), vale a pena construir diversas protees de depurao e cdigo de teste, talvez at mesmo 50 por cento do produto que est sendo depurado. Isso particularmente verdadeiro no caso de se desenvolver o software de forma iterativa.
Se voc desenvolve software em iteraes (...) voc ir fazer mudanas srias no cdigo aps ele ter sido escrito. Isso perigoso (...). Para fazer mudanas de forma segura, necessrio haver uma forma imediata para encontrar e corrigir conseqncias indesejveis. A forma mais eficaz de facilitar mudanas ter uma base de testes automatizados (...). Uma base de testes ir encontrar conseqncias indesejveis imediatamente e se for boa, tambm ir indicar a causa

103

do problema (POPPENDIECK & POPPENDIECK, 2003, p.147-148, traduo nossa).

Infelizmente, impossvel testar absolutamente tudo, sem que os testes se tornem to complicados e propensos a erros quanto o cdigo de produo. suicdio no testar nada. (...) Voc deve testar coisas que possam vir a quebrar (BECK, 2000, p.116-117, traduo nossa). A idia de Beck que ao longo do tempo, e com a prtica, os desenvolvedores de um projeto se tornem cada vez mais capazes de identificar que tipo de situaes tendem a gerar mais erros. So nelas que eles iro concentrar os maiores esforos de teste. uma abordagem com boas chances de funcionar, especialmente levando-se em conta que (...) 80 por centro dos defeitos podem ser rastreados para 20 por cento de todas as possveis causas (...) (PRESSMAN, 1997, p.203, traduo nossa).
Os programadores escrevem testes mtodo aps mtodo. Um programador escreve um teste sob as seguintes circunstncias: Se a interface de um mtodo no muito clara, voc escreve um teste antes de escrever o mtodo; Se a interface for clara, mas voc imagina que a implementao ser um tanto complicada, voc escreve um teste antes de escrever o mtodo; Se voc imaginar uma circunstncia incomum na qual o cdigo deva funcionar, voc escreve um teste para comunicar a circunstncia; Se voc encontrar um problema mais tarde, voc escreve um teste que isole o problema e Se voc estiver prestes a refatorar algum cdigo, no tiver certeza sobre a forma como ele deve funcionar, e ainda no houver um teste para o aspecto do comportamento em questo, voc escreve um teste primeiro (BECK, 2000, p.117118, traduo nossa).

O processo bsico de criao de testes e implementao de funcionalidades simples. Ele se baseia nos passos descritos adiante:
1. Rapidamente adicione um teste; 2. Execute todos os testes e veja o novo falhar; 3. Faa uma pequena mudana;

104

4. Execute todos os testes e veja-os funcionar e 5. Refatore para remover duplicaes (BECK, 2003, p.5, traduo nossa).

Cada vez que um novo elemento precisa ser inserido no cdigo de produo, o programador comea escrevendo um teste que deve falhar enquanto o novo fragmento de cdigo de produo no for inserido. Ele verifica se o teste realmente falha e em seguida adiciona o novo cdigo de produo. Se tudo correr bem, o novo teste deve, ento, funcionar, bem como todos os demais que existiam anteriormente no sistema. Havendo uma falha nos testes, o programador ir depurar o cdigo e corrigi-lo at que todos os testes funcionem. Para fazer o cdigo funcionar, permitido cometer qualquer tipo de pecado. Uma vez funcionando, o programador faz uma reviso do novo cdigo em busca de duplicaes e oportunidades de refatorao. Desta forma, primeiro, resolvemos a parte que funciona do problema. Depois resolvemos a parte do cdigo limpo (BECK, 2003, p.15, traduo nossa). Escrever um teste antes de cada histria tambm representa uma forma de aprimorar a anlise sobre as caractersticas dela. Pois a necessidade de implementar um teste fora o desenvolvedor a buscar maiores detalhes sobre o comportamento da funcionalidade (BECK, 2000). Trata-se de um aspecto importante, visto que a tarefa crucial fazer com que o produto seja definido. Muitas, muitas falhas se relacionam exatamente com aqueles aspectos que nunca foram bem especificados (BROOKS, 1995, p.142, traduo nossa). O desenvolvimento orientado a testes tambm produz efeitos positivos no design da aplicao. Isso ocorre porque o desenvolvedor se coloca no papel de consumidor de

105

seu prprio cdigo e a necessidade de implementar o teste o fora a simplificar a implementao do cdigo de produo.
(...) escrevendo os testes primeiro, voc se coloca no papel do usurio do seu cdigo, ao invs de desenvolvedor do seu cdigo. A partir desta perspectiva, voc normalmente consegue obter um sentimento muito melhor sobre como uma interface ser realmente utilizada e pode ver oportunidades para melhorar seu design (HUNT & THOMAS, 2003, p.115, traduo nossa).

A necessidade de automatizar os testes leva necessidade de tornar o design mais fcil de ser testado. Normalmente, isso leva a melhorias no design. Ou seja, a simples necessidade de criar um teste automatiza uma maneira de forar os desenvolvedores a tornarem o cdigo mais simples e freqentemente melhor elaborado.
Quanto mais complexo um objeto for, mais difcil ser test-lo completamente. Mas o inverso tambm verdade: quanto mais simples um objeto ou mtodo for, mais fcil ser test-lo. Quando estamos testando um objeto e podemos identificar coisas que podem quebrar, mas parecem impossveis de serem testadas, deixamos a presso por testar tudo que possa quebrar fluir de volta para o design. Talvez possamos simplificar este objeto, quebr-lo e torn-lo mais fcil de testar. Normalmente podemos simplificar o cdigo e torn-lo mais fcil de testar. No processo, tornamos o cdigo mais simples de entender e mais provvel de estar correto. Ganhamos em todos os lados. Ganhamos um cdigo melhor e testes melhores (JEFFRIES, ANDERSON et al., 2001, p.234-235, traduo nossa).

Outro aspecto que ajuda a melhorar o design a freqente utilizao de uma tcnica conhecida como programao por inteno associada criao dos testes automatizados. A idia principal da programao por inteno a comunicao, especificamente a comunicao da nossa inteno para qualquer um que esteja lendo o cdigo (ASTELS, 2003, p.45, traduo nossa). Sendo assim, codifique o que voc deseja e no como fazer o que voc deseja. (...) [Os desenvolvedores] executam uma pequena tarefa criando os testes primeiro, sempre expressando a inteno no cdigo, ao invs do algoritmo (JEFFRIES, ANDERSON et al., 2001, p.107, traduo nossa).

106

Ao escrever o teste primeiro, o programador age como se ele j pudesse encontrar no cdigo de produo todos os elementos (classes, mtodos etc) de que ir precisar. Isso certamente no verdade, porque o teste escrito antes de se implementar o cdigo da funcionalidade. Entretanto, agindo como se o cdigo de produo j estivesse l e escrevendo da forma mais natural que lhe parea, o desenvolvedor procura expressar claramente suas intenes utilizando as interfaces que lhe paream mais razoveis para resolver o problema em questo. Em princpio, tal cdigo de teste provavelmente no ser nem mesmo compilvel. S depois de expressar adequadamente a sua inteno que o desenvolvedor ir tentar implementar as interfaces que imaginou dentro do cdigo de produo. Alm de proteger o sistema, os testes automatizados tambm ajudam a equipe de desenvolvimento a document-lo. Os testes representam exemplos de utilizaes do cdigo e, portanto, podem ser bastante teis para ajudar a compreend-lo. Alm disso, ao contrrio da documentao escrita, o teste no perde o sincronismo com o cdigo (a no ser, naturalmente, que voc pare de execut-lo) (HUNT & THOMAS, 2003, p.6-7, traduo nossa).
No chega a ser surpresa que seja difcil, se no impossvel, manter a documentao precisa sobre como o software foi construdo. (...) Entretanto, se um sistema possui uma base de testes abrangente que contenha tanto testes dos desenvolvedores, quanto testes dos clientes, estes testes sero, de fato, um reflexo preciso de como o sistema foi construdo. Se os testes forem claros e bem organizados, eles sero um recurso valioso para compreender como o sistema funciona a partir do ponto de vista do desenvolvedor e do cliente (POPPENDIECK & POPPENDIECK, 2003, p.148-149, traduo nossa).

O desenvolvimento orientado a testes, embora contenha idias relevantes para melhorar os projetos de software, pode se revelar um problema caso reduza a velocidade de desenvolvimento. Em princpio, isso o que parece ocorrer, na medida em que a

107

automao dos testes um exerccio que no executado em grande parte dos projetos de software, os quais j sofrem problemas de atraso sem considerar a criao destes testes. Imagine-se o que aconteceria se tivessem tambm que cri-los. A prtica, entretanto, revela que a adoo de testes automatizados acelera o processo de desenvolvimento e o torna mais previsvel. Descobri que escrever bons testes acelera enormemente a minha programao(...). Isso foi uma surpresa para mim e contra-intuitivo para a maioria dos programadores (FOWLER, 2000, p.89, traduo nossa). Em termos gerais, equipes XP acreditam que a nica forma de se mover rapidamente e com confiana tendo uma rede de testes, tanto de unidade, quanto de aceitao (JEFFRIES, ANDERSON et al., 2001, p.33, traduo nossa).
Os testes exercem diversos papis fundamentais durante o processo de desenvolvimento de software. Primeiro, os testes comunicam sem ambigidade como as coisas devem funcionar. Segundo, eles provm feedback indicando se o sistema realmente funciona da forma esperada. Terceiro, os testes fornecem os mecanismos de proteo que possibilitam aos desenvolvedores fazer mudanas ao longo do processo de desenvolvimento (...). Quando o desenvolvimento termina, a base de testes fornece uma representao precisa de como o sistema efetivamente foi construdo (POPPENDIECK & POPPENDIECK, 2003, p.145-146, traduo nossa).

5.2.9 Refatorao Sistemas mudam ao longo do tempo, especialmente quando so desenvolvidos de forma iterativa. Nesta obra j tivemos a oportunidade de identificar inmeras razes que levam necessidade de alteraes em um software, as quais normalmente so acompanhadas de riscos e oportunidades. Podem ser teis para resolver novos problemas dos usurios, mas podem fazer com que partes do sistema deixem de funcionar ou que sua estrutura se deteriore.

108

Tradicionalmente, os reparos tendem a destruir a estrutura, elevar a entropia e a desordem de um sistema (BROOKS, 1995, p.243, traduo nossa). Alm disso, sem melhoria contnua, qualquer sistema de software ir sofrer. As estruturas internas iro se calcificar e se tornar frgeis (POPPENDIECK & POPPENDIECK, 2003, p.141, traduo nossa). Por esta razo, projetos XP investem diariamente no aprimoramento do design e na identificao de pontos da arquitetura que estejam se degradando. medida que so encontrados, so corrigidos atravs de uma tcnica conhecida como refatorao. A refatorao o processo de fazer mudanas em um cdigo existente e funcional sem alterar seu comportamento externo. Em outras palavras, alterar como ele faz, mas no o que ele faz. O objetivo aprimorar a estrutura interna (ASTELS, 2003, p.15, traduo nossa). Tal processo conduzido permanentemente por todos os desenvolvedores como uma forma disciplinada de limpar o cdigo minimizando a chance de introduzir bugs (FOWLER, 2000, p.xvi, traduo nossa).
A necessidade de refatorao aparece medida que a arquitetura evolui, amadurece e novas funcionalidades so solicitadas pelos usurios. Novas funcionalidades podem ser adicionadas ao cdigo uma de cada vez, mas geralmente elas estaro relacionadas umas com as outras e freqentemente ser melhor adicionar um mecanismo arquitetural para dar suporte ao novo conjunto de funcionalidades. Isso comumente acontece de forma natural como uma refatorao para remover duplicao quando voc adiciona o segundo ou terceiro de um conjunto de itens relacionados (POPPENDIECK & POPPENDIECK, 2003, p.141-142, traduo nossa).

Durante a refatorao de um cdigo, cada passo simples, at mesmo simplista. (...) Apesar disso, o efeito cumulativo destas pequenas mudanas podem melhorar significativamente o design (FOWLER, 2000, p.xvi-xvii, traduo nossa). Fazendo isso, os desenvolvedores procuram evitar situaes nas quais os programas se tornem difceis de serem modificados, pois o compilador no se importa se o cdigo

109

feio ou limpo. Mas, quando mudamos o sistema, existe um humano envolvido e humanos se importam. Um sistema mal projetado difcil de alterar (FOWLER, 2000, p.6, traduo nossa). Portanto, o objetivo elaborar programas que sejam fceis de ler, tenham toda a lgica em um e apenas um lugar, no permitam que mudanas ameacem o comportamento existente e permitam que lgicas condicionais sejam expressas da maneira mais simples possvel (FOWLER, 2000, p.60, traduo nossa). importante observar que a integridade conceitual sofre medida que o design se deteriora. Como vimos anteriormente, a integridade conceitual um fator essencial para tornar o sistema fcil de ser utilizado. Alm disso, (...) [a] integridade conceitual de um produto no apenas o torna mais fcil de usar, como tambm facilita a sua construo e o torna menos sujeito a bugs (BROOKS, 1995, p.142, traduo nossa). Sendo assim, a adoo da prtica de refatorao procura manter a integridade conceitual fazendo com que o sistema mantenha as seguintes caractersticas ao longo do tempo:
1. Simplicidade Em quase todas as reas, um design simples e funcional o melhor design. (...) 2. Clareza O cdigo deve ser fcil de entender por todos aqueles que iro eventualmente trabalhar com ele. (...) 3. Adequao ao uso Todo design deve alcanar o propsito para o qual foi criado. (...) 4. Ausncia de repetio Cdigo idntico jamais deveria existir em dois ou mais lugares. (...) 5. Ausncia de funcionalidades extras Quando o cdigo no mais necessrio, o desperdcio envolvido em mant-lo elevado (...) (POPPENDIECK & POPPENDIECK, 2003, p.142-143, traduo nossa).

A evoluo do design ao longo das iteraes com base no uso da refatorao uma forma diferente de abordar o desenvolvimento de software, visto que tradicionalmente espera-se que o design seja criado antes de se iniciar a implementao do sistema. Entretanto, utilizando as prticas do XP voc descobre que o design, ao

110

invs de ocorrer todo no incio, ocorre continuamente durante o desenvolvimento. Voc aprende construindo o sistema como melhorar o design (FOWLER, 2000, p.xvi-xvii, traduo nossa).
O historiador da engenharia Henry Petroski escreveu extensivamente sobre como o design realmente acontece. Os engenheiros comeam com alguma coisa que funcione, aprendem com suas fraquezas e melhoram o design. As melhorias no se originam apenas na tentativa de atender s demandas dos clientes ou da adio de funcionalidades; as melhorias tambm so necessrias porque sistemas complexos possuem efeitos que no so bem compreendidos durante o perodo de design. Escolhas sub-otimizadas constituem uma parte intrnseca do processo de criao de designs complexos no mundo real. No razovel esperar um design perfeito que preveja todas as possveis contingncias e efeitos em cascata decorrentes de simples mudanas. O pesquisador de design Donald Norman nota que necessrio cinco ou seis tentativas para realmente atingir um produto correto (POPPENDIECK & POPPENDIECK, 2003, p.140, traduo nossa).

Equipes XP normalmente no alocam um tempo especial do projeto para refatorar. Diversas pequenas refatoraes so executadas diariamente, medida que novas funcionalidades so produzidas, sempre que os desenvolvedores identificam a necessidade de melhorar o cdigo. Existem trs situaes que so particularmente crticas:
1. Quando existe duplicao; 2. Quando percebemos que o cdigo e/ou a sua inteno no est clara e 3. Quando detectamos code smells, isto , sutis (ou no to sutis) indicaes da existncia de um problema (ASTELS, 2003, p.15, traduo nossa).

Duplicao de cdigo costuma ser um problema recorrente em diversos projetos e uma das principais razes para o design se degradar rapidamente. Alm disso, reduzem significativamente o ritmo de trabalho da equipe de desenvolvimento.
Cdigos mal projetados normalmente demandam mais cdigo para fazer a mesma coisa, freqentemente porque o cdigo literalmente faz a mesma coisa em diversos lugares. Portanto, um importante aspecto de melhoria do design eliminar duplicao no cdigo. A importncia

111

disso reside nas modificaes futuras. Reduzir a quantidade de cdigo no far o sistema rodar mais rapidamente (...) entretanto, faz uma grande diferena na hora de uma modificao (FOWLER, 2000, p.55, traduo nossa).

Por essa razo, equipes XP utilizam um princpio conhecido como DRY Dont Repear Yourself (no se repita). Trata-se de uma tcnica fundamental que exige que cada fragmento de conhecimento no sistema tenha uma nica, no ambgua e definitiva representao (HUNT & THOMAS, 2003, p.32, traduo nossa). Os desenvolvedores tambm dedicam ateno significativa semntica do cdigo. Por esta razo, procuram utilizar nomes que faam sentido, evitam abreviaes, adotam um cdigo padronizado e seguem outras diretrizes que ajudam a melhorar a forma como o cdigo comunica sua inteno (FOWLER, 2000). Por sua vez, o conceito de code smells amplamente utilizado pela comunidade XP para se referir a caractersticas do cdigo que indicam qualidade inferior aceitvel (ASTELS, 2003, p.18, traduo nossa).
Quando voc descobre que tem que adicionar uma funcionalidade ao programa e o cdigo do programa no est estruturado de uma forma conveniente para adicion-la, primeiro refatore o programa para tornar mais fcil a adio da funcionalidade, em seguida a adicione (FOWLER, 2000, p.7, traduo nossa).

A ateno constante com a melhoria do cdigo tambm usada como forma de torn-lo auto-explicativo, reduzindo os investimentos necessrios em documentao e os riscos de que a mesma se torne obsoleta. Para fazer com que a documentao seja mantida, crucial que ela seja incorporada ao programa fonte, ao invs de mantida em um documento separado (BROOKS, 1995, p.249, traduo nossa). Embora os programadores possam utilizar comentrios para documentar o cdigo fonte, os mesmos so evitados. Quando voc sentir a necessidade de escrever

112

um comentrio, primeiro tente refatorar o cdigo de modo que qualquer comentrio se torne suprfluo (FOWLER, 2000, p.88, traduo nossa). Essa recomendao se baseia na idia de que a maioria dos comentrios desnecessria se o cdigo for escrito de modo que a inteno esteja clara. Se e quando escrevermos comentrios, devemos assegurar que eles comuniquem o porqu e no o como (ASTELS, 2003, p.54, traduo nossa).
Uma heurstica que seguimos que sempre que sentimos a necessidade de comentar alguma coisa, escrevemos um mtodo ao invs do comentrio. Este mtodo contm o cdigo sobre o qual se faria o comentrio mas nomeado de acordo com a inteno do cdigo, ao invs de indicar como ele faz o que faz (FOWLER, 2000, p.77, traduo nossa).

Apesar dos aparentes benefcios da refatorao, um problema que pode surgir a velocidade do desenvolvimento. Em princpio, o esforo de refatorao parece representar um re-trabalho e um custo adicional para o projeto, na medida em que seria prefervel projetar o design correto desde o incio. Como os projetos de software normalmente sofrem com prazos curtos, pode ser que simplesmente no haja tempo disponvel para refatorar.
Ns argumentamos que no h tempo para no refatorar. O trabalho apenas avanar mais lentamente medida que o cdigo se torne mais complexo e obscuro. Como sugerido na figura [5.3], incorrer em dbitos de refatorao ir aniquilar a produtividade da equipe.

113

Figura 5.3: melhoria contnua do design sustenta a produtividade.

Refatorao no desperdcio; ao contrrio, um mtodo chave para evitar desperdcios provendo valor de negcio para os clientes. Uma base de cdigo bem projetada a fundao de um sistema que consiga responder s necessidades dos clientes tanto durante o desenvolvimento, quanto durante a vida til do sistema (POPPENDIECK & POPPENDIECK, 2003, p.144-145, traduo nossa).

Equipes XP acreditam que refatorar diariamente ajuda a manter um ritmo acelerado de desenvolvimento. H uma percepo de que seja relativamente fcil avanar rapidamente sem refatorao no incio do projeto, mas quanto mais a base de cdigo cresce, mais a produtividade comprometida. A falta de tempo freqentemente usada como desculpa para no refatorar, entretanto a refatorao que no feita imediatamente acaba tendo que ser feita mais tarde, quando ela se torna mais custosa e a presso de tempo se torna ainda maior (HUNT & THOMAS, 2000).
(...) um bom design essencial para o desenvolvimento rpido do software. De fato, o objetivo bsico de se ter um bom design permitir o desenvolvimento rpido. Sem um bom design, voc consegue avanar rapidamente por um tempo, mas logo o design ruim comea a te atrasar. Voc gasta tempo buscando e corrigindo bugs ao invs de adicionar novas funcionalidades. As mudanas consomem mais tempo medida que voc tenta compreender o sistema e encontrar o cdigo duplicado. Novas funcionalidades precisam de mais codificao (FOWLER, 2000, p.57, traduo nossa).

114

Por maiores que sejam os benefcios aparentes da refatorao, toda mudana no cdigo traz consigo o potencial de que algo deixe de funcionar. Por essa razo, a adoo da prtica de refatorao s pode ocorrer em projetos que produzam testes automatizados. Uma ferramenta chave que anda de mos dadas com a refatorao, e de fato a torna vivel so os testes automatizados (POPPENDIECK & POPPENDIECK, 2003, p.144-145, traduo nossa).

5.2.10 Integrao Contnua Equipes XP normalmente so compostas por diversos programadores, trabalhando em pares de acordo com a prtica de cdigo coletivo. Isso cria dois problemas prticos. O primeiro que sempre que diversos indivduos esto trabalhando na mesma coisa, ocorre uma necessidade de sincronizao

(POPPENDIECK & POPPENDIECK, 2003, p.34-35, traduo nossa). O segundo que os pares precisam ser capazes de evoluir rapidamente sem interferir no trabalho uns dos outros. Portanto, enquanto desenvolve, voc quer fingir que o nico programador no projeto. Voc quer marchar adiante em velocidade mxima ignorando a relao entre as mudanas que voc efetua e as mudanas que os demais esto fazendo (BECK, 2000, p.97-98, traduo nossa). Esta questo resolvida no XP utilizando-se uma prtica conhecida como integrao contnua. Os pares trabalham de forma isolada, porm integram o que produzem com a verso mais recente do cdigo de produo, diversas vezes ao dia. Isto , os pares se sincronizam com freqncia medida que terminam pequenas atividades de codificao (BECK, 2000).

115

Toda vez que um par integra seu cdigo, h um risco de que identifique um erro na integrao. Isto , existe a chance, por exemplo, de que dois pares distintos tenham efetuado alteraes conflitantes em uma mesma linha do cdigo.
O esforo necessrio para resolver as colises no pode ser muito grande. Isso no um problema. A refatorao constante tem o efeito de dividir o sistema em muitos objetos e mtodos pequenos. Isso reduz as chances de que dois pares de programadores mudem a mesma classe ou mtodo ao mesmo tempo. Se eles fizerem isso, o esforo necessrio para reconciliar as mudanas ser pequeno, porque cada um representa apenas algumas horas de desenvolvimento (BECK, 2000, p.98-99, traduo nossa).

De um modo geral, os pares procuram descobrir estes eventuais conflitos to cedo quanto possvel, pois quanto mais esperamos, pior as coisas vo ficando. (...) um bug introduzido ontem bem fcil de encontrar, enquanto dez ou cem introduzidos semanas atrs podem se tornar quase impossveis de serem localizar (JEFFRIES, ANDERSON et al., 2001, p.78-79, traduo nossa). Integrando rapidamente, os pares tambm asseguram que o lote de trabalho a ser integrado ser pequeno. Afinal, no se consegue produzir muita coisa em um espao de tempo curto, como por exemplo de uma ou duas horas. Desta forma, se houver um erro na integrao, o mesmo ser referente a um lote pequeno de trabalho, onde menos coisas podem falhar. Portanto, o tempo para corrigir eventuais problemas tende a ser pequeno (POPPENDIECK & POPPENDIECK, 2003).
Builds6 mais freqentes so melhores; eles fornecem feedback muito mais rpido. Builds e testes executados durante os builds devem ser automatizados. Se no forem, o prprio processo de build ir introduzir erros e a quantidade de trabalho manual tornar proibitiva a execuo suficientemente freqente dos builds. (...) O princpio geral que se os builds e os teste tomarem muito tempo, eles no sero utilizados, portanto, invista em torn-los rpidos. Isso gera uma preferncia por builds mais freqentes, com testes menos

Build o processo de compilar, montar e empacotar o programa.

116

abrangentes, mas ainda assim importante executar todos os testes noite ou nos finais de semana (POPPENDIECK & POPPENDIECK, 2003, p.35, traduo nossa).

O processo de integrao serial, isto , somente um par pode integrar o seu cdigo de cada vez. Isso assegura que eventuais erros de integrao estaro sempre relacionados a um nico par: aquele que est integrando no momento. Somente aps assegurar que a integrao est perfeita, todos os testes executam com sucesso e o sistema encontra-se em um estado consistente poder outro par fazer a integrao (BECK, 2000). 5.2.11 Releases Curtos O XP considera que um projeto de software um investimento. O cliente investe uma certa quantidade de recursos na expectativa de obter um retorno dentro de certo prazo (TELES, 2004, p.185). O volume de retorno depende do valor de negcio produzido e do tempo em que o mesmo entregue. O XP procura maximizar o retorno dos projetos assegurando que o maior valor de negcio possvel seja entregue ao final de cada release e que cada release tenha uma durao curta. Isso feito atravs do processo contnuo de priorizao que seleciona sempre as histrias de maior valor para serem implementadas primeiro. Alm disso, procura antecipar o retorno entregando software rapidamente. Neste sentido, trabalha com a prtica de releases curtos, que consiste em colocar o sistema em produo com freqncia, em prazos curtos, normalmente de dois ou trs meses. Isso costuma ser bem-vindo, porque clientes gostam de entregas rpidas. (...) entrega rpida normalmente se traduz em aumento de flexibilidade no negcio (POPPENDIECK & POPPENDIECK, 2003, p.70-71, traduo nossa).

117

Entrega rpida uma abordagem baseada em opes para o desenvolvimento de software. Permite que voc mantenha as suas opes em aberto at que voc tenha reduzido incertezas e possa tomar decises mais informadas e baseadas em fatos

(POPPENDIECK & POPPENDIECK, 2003, p.70-71, traduo nossa). Todo investimento implica no consumo de algum recurso na esperana de que o retorno seja maior, de modo a pagar o que foi consumido e gerar uma sobra (o retorno lquido). No caso de software, por exemplo, os projetos consomem dinheiro na forma de pagamentos efetuados para a equipe de desenvolvimento, entre outros. Espera-se, naturalmente, que o software produzido gere um valor superior ao montante de dinheiro gasto ao longo do projeto. As despesas de um projeto implicam a existncia de um fluxo de caixa, ou seja, uma agenda de pagamentos e eventuais retornos (TELES, 2004). Trabalhando com releases curtos e priorizao permanente, a equipe procura assegurar que os primeiros releases gerem a maior parte do valor do sistema (por conterem, em princpio, as funcionalidades com maior valor para o negcio). Portanto, espera-se que o maior retorno esteja concentrado mais prximo do incio do projeto, quando o cliente normalmente ainda no efetuou a maior parte dos desembolsos. Colocando releases em produo rapidamente, o cliente tem a oportunidade de receber feedback concreto sobre o real potencial de retorno do projeto. Portanto, tem a chance de decidir cedo, quando ainda no gastou muito, se continua ou no com o projeto e particularmente se continua ou no investindo na mesma equipe de desenvolvimento. Portanto, a adoo de releases curtos funciona como uma estratgia de gesto de risco do projeto (TELES, 2004).
Entregar rapidamente significa (...) que as empresas tm menos recursos atrelados a trabalho em andamento (...) Uma grande pilha de trabalho em andamento contm riscos adicionais, alm da obsolescncia. Problemas e defeitos, ambos pequenos e grandes, freqentemente se mantm escondidos em pilhas de trabalho

118

parcialmente finalizado. Quando os desenvolvedores criam uma grande quantidade de cdigo sem testar, os defeitos se empilham. Quando o cdigo desenvolvido, mas no integrado, a parte mais arriscada do esforo continua l. Quando um sistema est finalizado, mas no est em produo, o risco continua. Todos estes riscos podem ser significativamente reduzidos encurtando-se a cadeia de valor

(POPPENDIECK & POPPENDIECK, 2003, p.70-71, traduo nossa). Entre outras vantagens, releases curtos e freqentes provm benefcio cedo para o cliente enquanto fornecem feedback rpido para os programadores (JEFFRIES, ANDERSON et al., 2001, p.49, traduo nossa). Eles tm a chance de aprender o que a comunidade de usurios, como um todo, pensa a respeito do sistema. Ao longo do desenvolvimento de um projeto XP, comum os programadores interagirem diariamente com um representante dos usurios. Mas, sempre existe a possibilidade de que esta pessoa no represente adequadamente o interesse geral de toda a comunidade de usurios (BOEHM & TURNER, 2003). Uma forma de descobrir isso colocando o software em produo o quanto antes. Pois, se houver falhas na representao, sero mais fceis e rpidas de serem corrigidas se o release no contiver um nmero excessivamente grande de funcionalidades.
Uma das coisas mais importantes que voc pode fazer em um projeto XP liberar releases cedo e com freqncia. (...) Voc no quer perder a chance de aprender o que os usurios realmente querem. Voc no quer perder o aumento na confiana que vir quando voc mostrar s pessoas que fez alguma coisa til (JEFFRIES, ANDERSON et al., 2001, p.50, traduo nossa).

5.2.12 Metfora Uma equipe de desenvolvimento formada por diversos programadores convive, entre outros, com o desafio de manter a integridade conceitual do sistema mesmo havendo diversos projetistas criando estruturas novas na arquitetura ao longo do tempo.

119

Isso pode ser resolvido caso exista um mecanismo capaz de alinhar o pensamento dos diversos projetistas assegurando que todos compartilhem uma viso nica de como adicionar e manter as funcionalidades do sistema. O XP utiliza o conceito de metfora para atingir este objetivo.
(...) a maioria dos sistemas reflete falta de unidade conceitual (...). Usualmente isso se origina (...) da separao do design em muitas tarefas feitas por muitas pessoas. (...) a integridade conceitual a considerao mais importante do design de um sistema. melhor que um sistema omita certas funcionalidades anmalas e melhoramentos, e refletir um conjunto uniforme de idias de design do que ter um sistema que contenha muitas idias boas, mas independentes e disjuntas (BROOKS, 1995, p.42, traduo nossa).

Cockburn (2002, p.227, traduo nossa) sugere que (...) a programao deveria ser vista como uma atividade atravs da qual os programadores formam ou atingem uma certa idia, uma teoria, sobre os problemas que tm nas mos. Ele se baseia no trabalho de Peter Naur que v a programao como sendo a construo de uma teoria. Usando as idias de Naur, o trabalho do designer no passar adiante o design, mas passar adiante as teorias que serviram para direcionar o design (COCKBURN, 2002, p.227, traduo nossa). Tais teorias representam a viso geral que rege as decises sobre como as estruturas sero organizadas no software. Segundo Naur:
1. O programador, tendo a teoria do programa, consegue explicar como a soluo se relaciona com as questes do mundo real que ele procura tratar. (...) 2. O programador, tendo a teoria do programa, consegue explicar porque cada parte do programa o que (...). 3. O programador, tendo a teoria do programa, capaz de responder construtivamente a qualquer requisio de modificao do programa, de modo a suportar as questes do mundo real de uma nova maneira (COCKBURN, 2002, p.231-232, traduo nossa).

120

No XP, este mesmo conceito utilizado, mas procura envolver o uso de metforas, visto que elas (...) exercem um papel ativo no pensamento e na cognio. Em particular, as metforas so vistas (...) como aspectos cruciais na disseminao e compreenso de novas idias e conceitos (BRYANT, 2000, traduo nossa).
Kent Beck sugeriu que til para uma equipe de design simplificar o design geral de um programa para se adequar a uma nica metfora. Exemplos podem ser, Este programa realmente se parece com uma linha de produo, com as coisas sendo adicionadas ao chassis ao longo da linha (...) Se a metfora for boa, as muitas associaes que os projetistas criam em torno dela se revelam apropriadas para a situao de programao deles. Esta exatamente a idia de Naur de passar adiante a teoria do design. (...) Uma metfora compartilhada apropriada permite que uma pessoa suponha precisamente onde outra pessoa da equipe adicionou cdigo e como se encaixar com o cdigo dela (COCKBURN, 2002, p.239, traduo nossa).

Esta forma de utilizao de metforas um mecanismo poderoso para manter a integridade conceitual de um sistema e, portanto, torn-lo mais fcil de ser utilizado. Um exemplo recorrente de uso eficaz de uma metfora so as interfaces grficas baseadas em janelas. Elas representam um exemplo sublime de uma interface de uso que possui integridade conceitual, conquistada pela adoo de um modelo mental familiar, a metfora da escrivaninha [desktop] (...) (BROOKS, 1995, p.260-261, traduo nossa). 5.2.13 Ritmo Sustentvel Segundo Brooks (1995, p.14, traduo nossa), mais projetos de software saem de curso por falta de tempo do que por qualquer das outras causas combinadas. Quando isso acontece, os projetos normalmente adotam duas estratgias: a utilizao de recursos no limite mximo e a adoo de horas-extras de trabalho.

121

O XP, por sua vez, evita as duas abordagens utilizando a prtica de ritmo sustentvel. Em sntese, ela recomenda que os membros da equipe de desenvolvimento trabalhem apenas durante o tempo regulamentar, ou seja, oito horas por dia, e evitem horas-extras tanto quanto possvel. Alm disso, sugere-se que os prazos sejam mantidos fixos e as cargas de trabalho sejam ajustadas (atravs de priorizao) para se adequar aos prazos (BECK & FOWLER, 2001). No livro Slack, Tom DeMarco (2001) faz uma anlise aprofundada sobre a busca cada vez mais intensa das empresas por eficincia mxima, que se traduz em empregar o menor nmero de funcionrios possvel e mant-los plenamente ocupados o tempo todo. Ele apresenta inmeras evidncias demonstrando que os efeitos obtidos acabam sendo o inverso do desejado. Na prtica as organizaes precisam incorporar algum nvel de folga em suas estruturas para que possam operar de maneira adequada. O mesmo ocorre com os projetos de software. Jamais executaramos os servidores das nossas salas de computao com utilizao plena por que no aprendemos essa lio no desenvolvimento de software (POPPENDIECK & POPPENDIECK, 2003, p.81, traduo nossa)?
(...) utilizao plena no prov nenhum valor para a cadeia de valor como um todo; de fato, normalmente faz mais mal que bem. (...) Assim como uma rodovia no consegue prover servios aceitveis sem alguma folga na sua capacidade, voc provavelmente no estar provendo aos seus clientes o nvel mais elevado de servio se no tiver alguma folga em sua organizao (POPPENDIECK & POPPENDIECK, 2003, p.81, traduo nossa).

A adoo de horas-extras, por sua vez, se baseia na idia subjacente de que os seres humanos possuem um comportamento linear e consistente. Isso no se materializa na prtica.
Se humanos fossem lineares, poderamos dobrar a produo de uma pessoa dobrando alguma entrada. Como a natureza determina,

122

entretanto, nem dobrar as recompensas oferecidas, nem a ameaa de punio ou mesmo o tempo utilizado tem um efeito confivel de dobrar a qualidade do pensamento de uma pessoa, velocidade de pensamento, produtividade da programao ou motivao (COCKBURN, 2002, p.44, traduo nossa).

Seres humanos no se comportam como mquinas, portanto se cansam e produzem resultados indesejveis em funo da fadiga. Alm disso, hora-extra como acelerar em uma corrida: faz algum sentido nos ltimos cem metros da maratona (...), mas se voc comear a acelerar no primeiro quilmetro, estar simplesmente perdendo tempo (DEMARCO & LISTER, 1987, p.16, traduo nossa). Dentre os efeitos colaterais, destacam-se:
Qualidade reduzida; Esgotamento pessoal; Maior rotatividade e Uso ineficaz do tempo durante as horas regulares de trabalho (DEMARCO, 2001, p.64, traduo nossa).

Apesar destes efeitos e de eles serem facilmente observveis, horas-extras so usadas excessivamente. como se representassem a nica soluo vivel para atingir os prazos de um projeto.
Historicamente, tem sido aceito semanas de trabalho de 80 horas, vidas pessoais sacrificadas e ficar at tarde no escritrio como caractersticas essenciais de sucesso. (...) Estes hbitos inevitavelmente levam ao esgotamento, e para as empresas de software, o custo pode ser substancial. Empregados que experimentem esgotamento extremo podem deixar seus empregos ou ter srios problemas de sade, o que cria custos de substituio quando os empregados que esto saindo so experientes. Existe evidncia demonstrando que engenheiros de software que passam por altos nveis de estresse mental e fsico tendem a produzir mais defeitos. Isso resulta em menor qualidade de software (EMAM, 2003, p.6, traduo nossa).

Para muitos gerentes de projeto, a adoo de horas-extras uma soluo intuitiva para elevar a produtividade da equipe de desenvolvimento. Entretanto, hora-

123

extra por um longo perodo uma tcnica de reduo de produtividade. Reduz o efeito de cada hora trabalhada (DEMARCO, 2001, p.63, traduo nossa).
Como sugerido pela figura [5.4], a produtividade lquida pode eventualmente aumentar durante as primeiras 20 horas de hora-extra. Mas cedo ou tarde, todo mundo alcana um ponto em que os resultados diminuem; e, em algum ponto, a produtividade comea a diminuir devido a erros crescentes e falta de concentrao. De fato, existe um ponto em que o membro da equipe se torna um produtor negativo lquido, porque o esforo de re-trabalho causado por erros e defeitos excede a contribuio positiva de novo software desenvolvido (YOURDON, 2004, p.99-100, traduo nossa).

Figura 5.4: produtividade lquida versus horas trabalhadas por semana. Por estas razes, o XP procura assegurar que a equipe trabalhe apenas durante as horas regulamentares. As presses de tempo so tratadas atravs do processo de priorizao e o ajuste do escopo de cada iterao para a real capacidade de entrega da equipe. Como essa capacidade pode variar ao longo do tempo, ela permanentemente monitorada e ajustada medida que o projeto avana. Quando estiver sobrecarregado, no pense nisso como se no tivesse tempo suficiente; pense nisso como tendo coisas demais para fazer. Voc no pode se conceder mais tempo, mas pode se permitir fazer menos coisas (BECK & FOWLER, 2001, p.25, traduo nossa).

124

Repito que a melhor maneira para se obter uma produtividade mais alta numa empresa, e uma melhor qualidade de vida fora dela, deixando o escritrio assim que acaba o horrio de expediente normal e no oferecendo aos respectivos chefes mais tempo do que aquele estipulado pelo contrato e pago pela empresa (MASI, 2000, p.183).

125

6 ESTUDO DE CASO
O estudo de caso representa o resultado de um projeto de desenvolvimento de software que utilizou os valores e prticas do Extreme Programming durante um perodo de quatorze meses. O projeto teve teor comercial e foi desenvolvido no Brasil. Por se tratar de um sistema comercial protegido por um acordo de sigilo, fizemos algumas adaptaes de modo que fosse possvel relatar os acontecimentos e os resultados da adoo do XP sem revelar aspectos que pudessem comprometer o sigilo das informaes. Nosso acesso s informaes reflete a participao do autor da dissertao no projeto, durante toda a sua durao. Isso permitiu vivenciar seu dia-a-dia e forneceu acesso aos artefatos que serviram de base para coletar os dados aqui apresentados. As informaes especficas sobre as caractersticas do sistema e do cliente no sero apresentadas. Ao invs disso, usaremos uma metfora com o objetivo de descrever caractersticas do projeto sem apresentar o escopo real do mesmo, mas mostrando a influncia do Extreme Programming sobre sua conduo. Sendo assim, os nomes utilizados deste ponto em diante so pseudnimos, embora a metfora tenha sido escolhida de modo a estabelecer uma relao prxima com as caractersticas reais do projeto. 6.1 Introduo O Comit Olmpico da Rssia responsvel por todos os atletas da Rssia que participam de jogos olmpicos ou esto sendo preparados para tal. Ele congrega dez mil atletas que esto distribudos em diversas cidades da Rssia.

126

Durante dcadas, a antiga Unio Sovitica dominou os resultados dos jogos olmpicos se posicionando quase sempre como a primeira ou segunda colocada em nmero de medalhas de ouro conquistadas. Mais recentemente, com o seu desmembramento, a Rssia herdou a maior parte dos atletas e comeou a sofrer a concorrncia de outras naes que vm se fortalecendo rapidamente, como a China. Como resultado, nas ltimas olimpadas a Rssia perdeu a sua tradicional liderana para a China, ficando em terceiro lugar no ranking de medalhas de ouro. Esse fato desencadeou a reao do Comit Olmpico da Rssia com o objetivo de reverter este resultado nos jogos olmpicos de 2008 e os prximos que se seguiro. Diversos estudos foram realizados e geraram iniciativas que j foram ou esto sendo colocadas em prtica. Dentre elas se encontra o desenvolvimento de um Portal de Aprimoramento Esportivo. 6.2 Portal de Aprimoramento Esportivo O comit, atravs dos estudos realizados, percebeu a necessidade de estabelecer um processo contnuo de aferio das habilidades dos atletas atrelado a um planejamento de treinos para melhorar deficincias. O objetivo era aferir todos os atletas a cada seis meses, identificar suas principais deficincias e traar um plano de treinos para melhorar suas respectivas habilidades especficas. Esse objetivo esbarrava em diversos problemas prticos: Como aferir de maneira uniforme um total de dez mil atletas dispersos geograficamente? Como aferir habilidades especficas em uma gama de 35 esportes distintos?

127

Como adequar o processo de aferio s modalidades particulares de cada esporte?

Como permitir que os prprios atletas e seus treinadores participassem do processo de aferio e criao dos planos de condicionamento fsico sem envolvimento de um rgo centralizador?

O comit notou que havia a necessidade de utilizar um sistema computacional baseado em interface web que fosse capaz de organizar e dar acesso a informaes de modo a solucionar as dificuldades mencionadas. Assim, iniciou uma busca por produtos comerciais que j estivessem sendo usados por outros comits olmpicos para resolver essas questes. Foram encontrados diversos pacotes comerciais que permitiam fazer o planejamento dos treinos, entretanto no se encontrou nenhum que fosse capaz de oferecer o nvel de aferio desejvel. Em especial, nenhum se mostrou em conformidade com a necessidade de aferir habilidades especficas em esportes distintos. Sendo assim, o comit adquiriu um pacote para a parte de treinos e contratou os servios de uma empresa de consultoria para implementar um sistema para fazer aferies. Seguindo esta soluo, o Portal de Aprimoramento Esportivo se tornou o resultado da integrao de dois sistemas distintos: o Sistema de Aferies e o Sistema de Treinos. A consultoria contratada pelo comit adotou o Extreme Programming para o desenvolvimento do Sistema de Aferies, bem como para a integrao do mesmo com o Sistema de Treinos e outros sistemas legados. O projeto de desenvolvimento do Sistema de Aferies o escopo deste estudo de caso. Sistema de Aferies

128

Este sistema foi desenvolvido sobre a plataforma J2EE e interagia com outros dois sistemas do Comit Olmpico: o Sistema de Atletas e o Sistema de Treinos. O Sistema de Atletas armazena todo o cadastro de atletas e respectivos treinadores categorizados por esportes, modalidades especficas dentro de cada esporte e equipes. O Sistema de Treinos representa o pacote adquirido pelo Comit Olmpico para organizar os treinos disponveis para os atletas. 6.3 Extreme Programming no projeto A adoo do Extreme Programming neste projeto foi sugerida pela empresa de consultoria contratada para implement-lo. Inicialmente, o assunto se mostrou controverso e no houve completa aceitao da idia. Os representantes da rea de esportes do comit se mostraram receptivos, enquanto os membros da rea de tecnologia da informao (TI) resistiram idia. Dentro da consultoria tambm havia resistncia. Dois de seus scios apoiaram o uso do XP, enquanto a equipe de desenvolvedores se mostrou ctica. Atravs de um acordo envolvendo todos os interessados, decidiu-se experimentar as prticas do XP durante seis semanas. Caso funcionassem, poderiam ser mantidas durante todo o projeto. Se falhassem seriam substitudas. O projeto adotou iteraes fixas de duas semanas. Embora houvesse um escopo definido, o contrato no o fixou, permitindo com isso que eventuais alteraes pudessem ser incorporadas. As prximas sees apresentaro situaes especficas do projeto que foram selecionadas para ilustrar como o Extreme Programming colaborou para os resultados alcanados.

129

6.4 Modelo Conceitual de Aferio de Habilidades Na reunio inaugural do projeto, foram discutidos diversos assuntos entre a equipe de desenvolvimento e representantes do Comit Olmpico. Em especial, a ata desta reunio revela que o Gerente de Esportes e sua equipe haviam feito uma reviso completa da especificao do sistema. Segundo ele, a especificao estava em ordem e todas as definies conceituais estavam corretas e finalizadas. Ao longo do projeto, um funcionrio da rea de esportes foi designado para dar apoio dirio aos desenvolvedores, atuando como representante de todos os usurios. Ele era conhecimento como requerente. Por sua vez, uma pessoa da rea de tecnologia da informao foi designada para auxiliar os desenvolvedores nos aspectos de tecnologia do Comit Olmpico. Era chamado de requerente de TI. Na reunio de planejamento da primeira iterao, o requerente escreveu cartes contendo as histrias que deveriam ser implementadas com base na especificao do sistema. Depois de escrever histrias sobre todos os aspectos mais importantes do projeto, os participantes voltaram suas atenes para os cartes que seriam provveis candidatos de serem implementados na primeira iterao. Deste ponto em diante, passaram a reler tais cartes e rediscutir em detalhes cada uma das histrias. Os desenvolvedores no conheciam os requisitos do projeto at ento. Portanto, o requerente no apenas escreveu histrias, como tambm explicou cada uma delas diversas vezes para os desenvolvedores. Isso foi til, porque eles comearam a identificar diversos detalhes que ainda no haviam sido previstos pelo requerente e para os quais ainda no havia uma definio por parte dele. Nesta reunio, o requerente e outras pessoas do comit obtiveram um volume significativo de feedback por parte dos desenvolvedores e todos aprenderam mais sobre

130

as funcionalidades. A partir das discusses, vrios detalhes foram esclarecidos pelo requerente, o qual priorizou um conjunto de histrias para a primeira iterao. Elas envolviam os aspectos essenciais dos processos de aferio de habilidades especficas e no-especficas. Cada tipo de habilidade tinha um modelo prprio de aferio e coube aos desenvolvedores implementar os dois modelos logo na primeira iterao. Esta priorizao no foi a mais natural do ponto de vista tcnico, pois inseria j na primeira iterao funcionalidades que dependiam de dados que ainda no existiam, pois nem sequer havia funcionalidades previamente implementadas para o cadastramento dos mesmos. Como exemplo, podemos citar a falta do cadastro de esportes, atletas, habilidades, entre outros. Para lidar com essa questo, a equipe criou as tabelas que fossem necessrias e as preencheu diretamente com dados fictcios (temporrios) que pudessem ser utilizados para permitir a execuo do processo de aferio. Foram criadas tabelas para entidades tais como habilidades (especficas e no-especficas), modalidades esportivas, atletas, entre outras. Com esta simplificao, a equipe viabilizou a implementao das histrias mais prioritrias, de modo que o requerente pudesse receber feedback rpido sobre as mesmas. Ao final da iterao, houve uma reunio de encerramento com a presena dos requerentes. A equipe de desenvolvimento conseguiu implementar todas as histrias acordadas e apresentou o sistema para o requerente, que se mostrou satisfeito com o trabalho e o resultado final. Avaliando o sistema cuidadosamente, ele se deu conta de diversos detalhes que no haviam sido previstos inicialmente, mas que ficavam evidentes diante da

131

possibilidade de uso das funcionalidades. Tais detalhes foram listados por ele, que solicitou mudanas para a equipe de desenvolvimento. Alm dos detalhes de implementao, o requerente percebeu um problema mais srio. Embora o modelo conceitual de aferio de habilidades tivesse sido implementado tal como determinado na especificao, utilizando o sistema o requerente notou que havia equvocos conceituais neste modelo, os quais colocariam o sistema em risco se no fossem tratados. Inicialmente, ele no sabia que solues deveriam ser implementadas para corrigir o modelo conceitual, sendo assim levou a discusso de volta para o Comit Olmpico, de modo que pudesse ser debatida por toda a equipe de esportes. E para que a equipe de desenvolvimento no ficasse sem trabalho na iterao seguinte, o requerente priorizou algumas histrias menos importantes. Dentro do comit, os problemas do modelo conceitual foram debatidos entre esportistas espalhados por diversas cidades da Rssia. De um modo geral, todos perceberam os problemas apontados pelo requerente, cuja identificao foi possvel graas ao uso do sistema. Como o assunto no tinha solues triviais, a discusso se alongou por um tempo maior que o imaginado inicialmente. Durante a segunda iterao o requerente informou equipe de desenvolvimento que as novas definies no estariam prontas antes da reunio de planejamento da iterao seguinte. Em outras palavras, no seria possvel implementar as correes do modelo conceitual na terceira iterao. Na melhor das hipteses, isso s seria vivel a partir da quarta iterao. At l, a equipe teria que se dedicar a histrias menos prioritrias.

132

Na quarta iterao a equipe recebeu do requerente as mudanas do modelo conceitual, as quais foram priorizadas. Durante essa iterao, o novo modelo conceitual foi apresentado ao Diretor de Esportes, que no o aprovou. Ele sugeriu outras mudanas significativas e, no meio da iterao, a equipe de desenvolvimento foi informada deste fato. Finalmente, a quinta e a sexta iteraes acabaram sendo utilizadas para implementar o novo modelo conceitual que se revelou mais coerente e aderente necessidade do comit. Este episdio gerou um atraso em relao ao cronograma planejado no incio do projeto. Entretanto, importante notar o efeito do feedback e do aprendizado no resultado final do sistema. No incio do projeto, o Gerente de Esportes tinha bastante convico de que o modelo conceitual estava correto. Afinal, j havia sido investido um grande esforo durante o ano anterior para desenvolv-lo, inclusive com a participao de consultorias especializadas. Ao contrrio do trabalho efetuado no ano anterior, entretanto, ao longo das primeiras seis iteraes o requerente teve a oportunidade de receber feedback concreto atravs do uso do sistema. Assim, teve condies de notar falhas no modelo conceitual que passaram despercebidas anteriormente, levando o comit a corrigi-lo e aprimor-lo. Com isso, o processo de aferio de habilidades acabou se tornando mais intuitivo para os atletas. Estes acontecimentos demonstram a importncia da utilizao de iteraes curtas e feedback rpido. Outro fator que tambm foi relevante nas primeiras iteraes foi a proximidade fsica entre os desenvolvedores e o requerente, cujo local de trabalho se situava a menos de cinqenta metros do escritrio da equipe de desenvolvimento. Sempre que o requerente avanava nas definies conceituais, as mesmas eram

133

apresentadas para a equipe de desenvolvimento. Isso permitiu a realizao de inmeros debates sobre o novo modelo conceitual, antes de comear o seu desenvolvimento. Nestes debates, os desenvolvedores tiveram papel importante ao identificar aspectos que no eram notados pelo requerente. Em determinado momento da quarta iterao, por exemplo, o requerente passou quase trs dias discutindo e aprimorando o modelo conceitual com os desenvolvedores. A quantidade de itens discutidos e acertados foi elevada. Caso os envolvidos no estivessem prximos e tivessem que usar outros mecanismos de comunicao, ao invs do dilogo pessoal, face-a-face, certamente teria sido mais demorado convergir para uma soluo final em funo da quantidade e complexidade dos detalhes que mereciam a ateno de todos. 6.5 Tratamento de Mudanas no Sistema de Atletas O funcionamento do Sistema de Aferies depende de informaes do Sistema de Atletas. Por exemplo, para aferir um atleta necessrio identificar em que esporte ele atua e em qual modalidade. Essas informaes so essenciais para determinar que habilidades especficas o sistema ir utilizar para aferir o atleta. Por sua vez, quando um treinador deseja aferir um integrante de sua equipe, o software busca no Sistema de Atletas quais so os atletas subordinados quele treinador. Na dcima iterao do projeto, logo aps a realizao de um piloto que contou com a participao de 80 usurios, foi detectada uma falha no sistema quando um atleta mudava de modalidade, enquanto a sua aferio ainda no havia sido finalizada. comum um atleta treinar em modalidades parecidas, embora esteja associado a uma nica modalidade principal. s vezes, ele evolui tanto em uma modalidade paralela que esta acaba se tornando a principal.

134

Nestes casos, faz-se uma mudana no Sistema de Atletas para registrar o novo direcionamento do desportista. Isso cria um problema para o Sistema de Aferies quando a mudana de modalidade principal ocorre enquanto o atleta est no meio de uma aferio, que normalmente pode levar dias, ou at semanas, visto que o ciclo completo envolve a utilizao do sistema pelo atleta e seu treinador de forma assncrona. Nestas situaes, o sistema apresentava falha porque a aferio havia sido iniciada em uma modalidade e, de repente, o sistema notava que o atleta no se encontrava mais naquela modalidade principal, impedindo que o mesmo continuasse a ser aferido. Esta falha chamou a ateno do Requerente e da equipe de desenvolvimento sobre a possibilidade de problemas semelhantes acontecerem quando o sistema j estivesse definitivamente em produo. Depois de vrios estudos, todos notaram que o problema realmente poderia ocorrer em produo toda vez que um atleta mudasse de modalidade principal ou fosse transferido para outra equipe, por exemplo. A identificao deste problema foi importante, visto que a incidncia do mesmo se mostrou bastante elevada quando o sistema entrou em produo. Afinal, eram dez mil atletas sendo aferidos durante um perodo de dois meses. Muitos mudavam de modalidade principal e de equipe neste perodo de tempo. Inicialmente, nem os desenvolvedores, nem o requerente conseguiram propor uma soluo para esta questo. Sendo assim, ela foi registrada e levada para discusso interna no Comit Olmpico. Nada foi feito a este respeito, nem na dcima, nem na dcima primeira iterao. J na dcima segunda, a equipe de desenvolvimento realizou inmeros testes para identificar os problemas que as mudanas no Sistema de Atletas

135

poderiam acarretar nas funcionalidades que j estavam implementadas no Sistema de Aferies. Esse mapeamento foi repassado para o Comit, de modo que o requerente pudesse definir internamente as aes a serem realizadas para a correo do problema em cada uma das funcionalidades afetadas. Tal definio consumiu bastante tempo, de modo que, durante vrias iteraes, o problema foi deixado de lado, tendo sido finalmente priorizado para a dcima stima iterao. A soluo, por sua vez, s ficou concluda na dcima oitava iterao. Apesar da demora, em grande parte decorrente da complexidade do problema e da dificuldade de traar solues efetivas para o mesmo, a correo foi implementada antes de o sistema entrar em produo. Uma vez em produo, ela provou que funcionava, mas era ineficiente tamanha a quantidade de ocorrncias do problema no perodo reservado para o ciclo de aferies. Assim, o requerente aprimorou a abordagem e solicitou que a mesma fosse implementada na vigsima quarta iterao, perto do fim do projeto. Esta ltima soluo se mostrou eficiente e resolveu por definitivo o problema que j vinha acompanhando todos os envolvidos no projeto h quatorze iteraes. Sobre este episdio relevante notar que o problema das mudanas no Sistema de Atletas e sua respectiva soluo no foram previstos na especificao do projeto, ou seja, no faziam parte do escopo original. Apesar disso, tratava-se de um problema grave que, segundo o requerente, poderia ter tornado o Sistema de Aferies intil caso no fosse considerado e tratado. Isso demonstra que o feedback freqente, dentro de um modelo de desenvolvimento iterativo pode ser til para identificar problemas graves e, portanto, ajudar a reduzir os riscos de que o software implementado no atenda s reais

136

necessidades de seus usurios. Tambm mostra a importncia de permitir que o escopo incorpore o aprendizado gerado ao longo do projeto, o que s possvel quando existe algum nvel de flexibilidade no tratamento dele. 6.6 Integrao com o Sistema de Treinos Quando a aferio de um atleta concluda, inicia-se a preparao do Plano de Treinos. Trata-se de um planejamento dos treinos aos quais o atleta ser submetido nos meses seguintes com o intuito de melhorar a sua proficincia em habilidades especficas e no-especficas que tenham sido priorizadas pelo seu treinador. Ao final do processo de aferio, comum o atleta encontrar uma ou mais habilidades nas quais o seu nvel de proficincia encontra-se aqum do desejado. Quando isso acontece, o seu treinador prioriza as habilidades mais crticas, de modo que a montagem do Plano de Treinos possa envolver a escolha de exerccios que estejam associados diretamente s habilidades que foram priorizadas. Enquanto o Sistema de Aferio cuida da aferio de habilidades e da gerao do Plano de Treinos, o Sistema de Treinos faz a gesto de todos os treinos disponibilizados para os atletas. Ele armazena os treinos nos quais um determinado atleta est registrado, quanto j foi realizado, qual o desempenho obtido, bem como o histrico de todos os treinos j realizados pelo atleta. Portanto, necessria a integrao entre os dois sistemas para elaborar o Plano de Treinos de maneira completa, fazendo com que suas informaes sejam automaticamente refletidas no Sistema de Treinos. A integrao entre o Sistema de Aferio e o Sistema de Treinos j era prevista desde o incio do projeto. Entretanto, os trabalhos referentes a esta parte no comearam desde o incio. Nas primeiras sete iteraes, a equipe de desenvolvimento no implementou nenhuma funcionalidade que tivesse relao com o Sistema de Treinos.

137

Neste primeiro momento, a aferio de habilidades foi priorizada em detrimento do Plano de Treinos. A equipe de desenvolvimento poderia ter seguido outra abordagem na qual fizesse ao menos a preparao de uma infra-estrutura que pudesse acomodar as funcionalidades do Plano de Treinos e as conseqentes necessidades de integrao. Entretanto, seguiu as prticas do XP de manter o design simples e fazer com que a arquitetura evolusse com base nas necessidades das histrias priorizadas para cada iterao. Com isso, aguardou at a oitava iterao para iniciar os trabalhos relativos integrao com o Sistema de Treinos. As primeiras funcionalidades relativas ao Plano de Treinos comearam a ser implementadas na oitava iterao, quando o modelo conceitual de aferio de habilidades j se encontrava estvel. Isso beneficiou a implementao do Plano de Treinos, pois durante as discusses sobre o modelo conceitual de aferio, o requerente identificou e tratou de diversos pontos importantes sobre o modelo de gerao do Plano de Treinos. O feedback obtido pelo requerente em cada iterao facilitou a elaborao e o refinamento do modelo conceitual de gerao do Plano de Treinos. Os principais objetivos da integrao j estavam definidos desde a segunda iterao. Entretanto, a forma de implementar tais objetivos sofreu inmeras alteraes ao longo do projeto. Desde a segunda iterao a empresa responsvel pela implantao do Sistema de Treinos comeou a estudar a possibilidade de implantar uma verso do Sistema de Treinos no escritrio da equipe de desenvolvimento do Sistema de Aferies. Na nona iterao, a equipe de desenvolvimento ainda no conhecia o Sistema de Treinos, pois no tinha acesso ao mesmo. Para contornar este problema, seria necessrio

138

ter acesso ao Sistema de Treinos instalado no Comit Olmpico ou instalar uma cpia do mesmo no escritrio da equipe de desenvolvimento do Sistema de Aferies. Em funo de restries de segurana do comit, a segunda opo foi adotada. Mas, infelizmente o Sistema de Treinos no foi instalado imediatamente. Para contornar a falta de acesso a ele, a equipe de desenvolvimento comeou a implementar as funcionalidades relativas ao Plano de Desenvolvimento utilizando o conceito de mock objects (objetos fictcios que simulam o comportamento de objetos reais) (HUNT & THOMAS, 2003). Inicialmente, cada funcionalidade que envolvia acesso ao Sistema de Treinos utilizava uma interface que simulava o acesso ao mesmo, sempre fornecendo as respostas corretas. Desta forma, mais tarde, a implementao desta interface seria substituda pelo acesso real ao Sistema de Treinos. Atravs da simulao do acesso ao Sistema de Treinos, os desenvolvedores contornaram a ausncia do mesmo e permitiram que o requerente recebesse feedback rpido sobre as funcionalidades do Plano de Treinos. Isso foi importante, pois permitiu que inmeros refinamentos fossem feitos, muito antes de ter a integrao efetivamente operando. O Sistema de Treinos era um pacote adquirido pelo comit e implantado por uma empresa de consultoria. Durante o projeto de implementao do Sistema de Aferies, o Sistema de Treinos estava sendo instalado e personalizado em paralelo. A equipe de implantao do Sistema de Treinos no trabalhava fisicamente prxima equipe de desenvolvimento do Sistema de Aferies. Sendo assim, a comunicao entre as equipes era feita basicamente atravs de telefone ou e-mail, embora tenham ocorrido tambm algumas reunies presenciais ao longo do projeto. Nas

139

poucas vezes em que elas ocorreram, no envolveram todos os desenvolvedores do Sistema de Aferies. As atas demonstram que a partir da nona iterao, medida que o processo de integrao entre os sistemas se intensificava, cada vez surgiam mais dificuldades em funo de equvocos de compreenso das informaes. A integrao vinha sendo feita atravs da construo de uma API (Application Programming Interfaces Interface de Integrao entre Aplicativos) que era dividida em duas partes: uma cliente, sendo implementada pelos desenvolvedores do Sistema de Aferies e outra servidora, implementada pela equipe do Sistema de Treinos. Em diversos momentos a equipe do Sistema de Treinos implementou funcionalidades incorretas na API de integrao devido aos erros de comunicao. Alm disso, a distncia fsica levou a dificuldades de sincronizao entre as equipes, pois freqentemente as requisies da equipe do Sistema de Aferies no eram atendidas a tempo, ou ficavam sem resposta por um perodo longo. No incio da dcima quarta iterao, enquanto ainda havia diversas funcionalidades a serem implementadas que dependiam da integrao com o Sistema de Treinos, a equipe de desenvolvimento do Sistema Aferies foi informada de que o contrato entre o comit e a consultoria responsvel pela implantao do Sistema de Treinos estava para terminar. Sendo assim, era necessrio planejar da forma mais precisa possvel quais seriam as necessidades de integrao pendentes para que a equipe do Sistema de Treinos pudesse adicionar os itens pendentes API de integrao. Essa situao foi problemtica para todos os envolvidos no projeto, visto que o requerente ainda tinha dvidas sobre algumas das partes do sistema que envolviam a integrao. A tentativa de prever tudo se revelou difcil e preocupante.

140

Embora a equipe de desenvolvimento do Sistema de Aferies j pudesse contar com o Sistema de Treinos instalado em seu escritrio a partir de certo ponto do projeto, existiam diferenas entre o que estava instalado no comit e no escritrio da equipe de desenvolvimento. No comit, foram implementadas diversas configuraes

personalizadas. Infelizmente, tais configuraes demoravam a ser instaladas na verso que estava sendo usada no escritrio da equipe de desenvolvimento do Sistema de Aferies. Conseqentemente, a integrao deixava de funcionar em alguns casos devido a incompatibilidade de verses. Este tipo de problema comeou a ser vivenciado durante a dcima terceira iterao e continuou at a dcima quinta. No incio da dcima sexta o requerente percebeu a necessidade de fazer uma pequena alterao no processo de finalizao da preparao do Plano de Treinos. Entretanto, tal mudana envolvia mudanas na API de integrao, o que tornou-a invivel, visto que o contrato entre o comit e a equipe de implantao do Sistema de Treinos j havia sido finalizado. Na dcima sexta iterao teve incio um conjunto de testes de integrao para verificar se a API estava funcionando a contento. Nesta iterao, a equipe teve srios problemas com o Sistema de Treinos e no teve acesso ao seu suporte. Foi necessrio reinstalar o Sistema de Treinos e o cliente teve de estender o contrato com a sua equipe de implantao. Durante a dcima stima, dcima oitava e dcima nona iteraes a equipe de desenvolvimento continuou fazendo acertos e testes na integrao com o Sistema de Treinos. Na dcima nona iterao foi identificado um problema de lentido na integrao. Nesta iterao, finalmente se conseguiu mais ajuda da equipe de implantao do Sistema de Treinos.

141

Em funo dos problemas que ocorreram com o Sistema de Treinos, no foi possvel colocar em produo as funcionalidades de gerao do Plano de Treinos, o que desagradou bastante o requerente. Ao final da dcima nona iterao o desempenho da integrao ainda era insatisfatrio. Um dos problemas que a equipe fazia testes no ambiente de desenvolvimento que continha poucos dados. Quando a utilizao se dava em produo, com uma grande quantidade de dados cadastrados, o desempenho da API de integrao caia drasticamente. Na vigsima iterao a integrao ficou estvel e as funcionalidades do Plano de Treinos puderam entrar em produo. Na vigsima primeira iterao, mais uma vez, o requerente solicitou uma funcionalidade que envolvia mudana na integrao com o Sistema de Treinos. A equipe mostrou que isso implicaria em mudanas na API de integrao. Sendo assim, o requerente mais uma vez acabou tendo que desistir da mudana, embora ela fosse importante. Esses acontecimentos demonstram como comum que detalhes passem despercebidos quando se est especificando um sistema ou mesmo parte dele. Ao tornar necessrio que o requerente e a equipe de desenvolvimento previssem todas as necessidades de integrao muito cedo, criou-se um problema, visto que vrios detalhes no foram previstos e precisaram ser tratados mais adiante. A impossibilidade de alterar a API acabou prejudicando o comit. Outro problema deste episdio a distncia fsica entre a equipe do Sistema de Aferies e a equipe do Sistema de Treinos. Era mais difcil e demorado convergir sem que todos estivessem prximos e utilizassem canais de comunicao mais ricos.

142

6.7 Cadastros O Sistema de Aferies englobava diversas histrias, dentre as quais a elaborao de formulrios para cadastramento de dados. Embora tais cadastros fossem importantes para viabilizar as demais funcionalidades do sistema, eles no foram priorizados pelo requerente nas primeiras iteraes. No incio do projeto, o Requerente tinha particular interesse na implementao de funcionalidades que representassem os modelos de aferio de habilidades especficas e no-especficas. Sendo assim, nas primeiras iteraes, ele priorizou histrias que ajudariam a validar tais modelos, embora vrios dados importantes ainda no existissem cadastrados, tais como habilidades, esportes, modalidades esportivas, atletas, entre outros. A equipe de desenvolvimento optou por buscar formas de implementar as funcionalidades priorizadas criando mecanismos para contornar a dependncia de dados para os quais ainda no haviam sido implementados cadastros. O objetivo disso foi assegurar que o requerente obtivesse feedback rpido para as funcionalidades que considerava mais crticas, o que acabou se revelando valioso, como foi possvel observar nas sees anteriores. O mecanismo criado para solucionar essa questo foi batizado de Cadastrador pela equipe de desenvolvimento. O Cadastrador era um mdulo do sistema que podia ser executado parte, sempre que necessrio. Ele limpava diversas tabelas do banco de dados e as preenchia com valores fixos e fictcios que permitiam a utilizao das funcionalidades. Assim, a equipe de desenvolvimento assegurava a existncia dos cadastros necessrios j na primeira iterao, embora os dados fossem ainda

143

simplificados e fictcios. Isso permitiu ao requerente utilizar as funcionalidades na ordem em que foram priorizadas. Passada a primeira iterao, o requerente continuou demonstrando pouco interesse em implementar formulrios de cadastro, o que gerou preocupao no requerente de TI. Na reunio de planejamento da terceira iterao, ele sugeriu ento que diversos cadastros do sistema fossem implementados com o uso de planilhas em Excel, as quais poderiam ser carregadas no sistema fazendo algumas alteraes no Cadastrador. A idia foi aceita por todos, e a partir da quarta iterao o requerente j estava providenciando o preenchimento das planilhas seguindo um formato acordado com a equipe de desenvolvimento. No incio da quarta iterao o requerente de TI exerceu presso para que os cadastros de maior volume fossem priorizados, especialmente aqueles que pudessem ter necessidade de incluso, alterao e excluso aps a carga inicial em produo. A preocupao dele se baseava no fato de que nem a equipe de desenvolvimento, nem a equipe de esportes e nem mesmo a equipe de TI poderiam fazer modificaes diretamente na base de dados de produo do comit. Apesar do alerta, o requerente no priorizou os formulrios de cadastro. Durante a quinta iterao, as planilhas j estavam em pleno uso dentro do comit e vrios de seus departamentos estavam colaborando atravs do preenchimento das mesmas. Tal processo fluiu de forma positiva, embora alguns problemas tenham sido identificados. Havia dificuldades de compreenso da nomenclatura usada nas planilhas, j que o modelo conceitual de aferies estava sendo refinado em paralelo. Isso s vezes causava conflitos de nomenclaturas que dificultavam o preenchimento das planilhas. Apesar disso, o resultado foi positivo. Em retrospectiva realizada ao final da dcima

144

quarta iterao, o uso das planilhas foi apontado como um dos aspectos mais positivos do projeto. A implementao dos primeiros cadastros foi finalmente priorizada para a dcima quinta iterao. Os dois cartes priorizados neste sentido foram: Cadastro de Equipe Esportiva Cadastro de Perfil Esportivo

A anlise destas histrias revela duas questes. A primeira que o projeto foi capaz de entregar funcionalidades relevantes para o requerente durante catorze iteraes (aproximadamente sete meses) apesar de no haver sido implementado nenhum formulrio de cadastro em todo este perodo. A segunda o teor destes primeiros cadastros priorizados. Os conceitos de Equipe Esportiva e Perfil Esportivo no existiam no incio do projeto. Eles foram criados ao longo das inmeras discusses sobre os modelos de aferio de habilidades, sobretudo o de habilidades especficas. Nota-se com isso que a priorizao tardia dos cadastros se beneficiou de todo o aprendizado das iteraes anteriores para que os cadastros efetivamente implementados fizessem referncia a aspectos realmente importantes e estveis do sistema. Isso evitou re-trabalhos futuros e poupou tempo da equipe de desenvolvimento e do prprio requerente na hora de implementar os formulrios de cadastros. A utilizao de planilhas ocorreu durante a maior parte do projeto. Em alguns casos, o requerente teve dificuldades para entregar as planilhas preenchidas no prazo acordado com a equipe de desenvolvimento. A ata da reunio de planejamento da dcima stima iterao, por exemplo, mostra a equipe de desenvolvimento pressionando o requerente para fornecer tais planilhas o mais brevemente possvel. Isso levanta a

145

hiptese de que caso os formulrios de cadastro tivessem sido implementados desde as primeiras iteraes, o esforo poderia ter sido em vo, visto que o comit no era capaz de gerar os dados a serem cadastrados com agilidade. Novos cadastros foram priorizados para a dcima nona iterao. Desta vez, as histrias priorizadas foram: Cadastro de Habilidades Especficas Cadastro de Habilidades No-especficas

Mais uma vez, a implementao destes cadastros se beneficiou de todo o aprendizado anterior sobre os modelos de aferio de habilidades, que j estavam maduros nesta altura do projeto. Isso fez com que estes cadastros fossem implementados uma nica vez, sem necessidades de re-trabalho que teriam sido significativos nas primeiras iteraes, devido grande quantidade de alteraes efetuadas nos modelos conceituais de aferio. Alm dos cadastros mencionados anteriormente, apenas outros trs menos importantes foram implementados. A contagem final de cadastros revela um nmero inferior ao imaginado no incio do projeto. Alguns deixaram de fazer sentido em face das mudanas conceituais, enquanto outros foram eliminados por terem se mostrado desnecessrios ou de pouco valor. 6.8 Relatrios Assim como as funcionalidades de cadastro, os relatrios no foram implementados nas primeiras iteraes do projeto. No incio da dcima segunda iterao foi decidido que os relatrios a serem desenvolvidos teriam formato PDF. Na dcima nona iterao, foi priorizada a implementao do primeiro relatrio. Importante notar que se trata de uma iterao que teve incio logo aps a entrada do sistema em

146

produo. Para este relatrio, foi proposto que ele fosse implementado inicialmente de maneira mais simples, em HTML e, posteriormente, passasse a adotar tambm o formato PDF. Para a elaborao dos relatrios, houve um grande cuidado de definir o formato visual dos mesmos antes de iniciar a implementao. Para isso, os relatrios foram desenhados inicialmente com o uso de planilhas em Excel. Estes desenhos foram discutidos inmeras vezes com o requerente antes que qualquer relatrio comeasse a ser implementado. O objetivo neste caso foi usar prottipos para evitar re-trabalhos. Em retrospectiva no final da vigsima iterao, este modelo de validao e fechamento do formato visual dos relatrios foi apontado como um dos pontos mais positivos do projeto. Para a vigsima primeira iterao foi priorizado que se faria um estudo para adotar uma ferramenta que fosse capaz de gerar os relatrios em PDF. Entretanto, ao final desta mesma iterao, o Requerente decidiu que no haveria necessidade de gerar os relatrios em PDF e eles permaneceriam sendo implementados em HTML. O requerente acabou gostando dos relatrios em HTML, pois eles facilitavam a cpia das informaes. Freqentemente, o requerente tinha que copiar as informaes de um relatrio para uma planilha ou documento do Word, com o objetivo de preparar relatrios internos ao comit. Utilizando os relatrios em HTML, bastava marcar as partes do relatrio que interessavam, copiar e colar no Excel ou no Word. Essa facilidade, aliada a facilidade de implementar os relatrios em HTML e o fato de haver outras histrias mais prioritrias, fez com que o requerente eliminasse completamente as histrias que cuidariam de implementar os relatrios em PDF.

147

Para a vigsima terceira iterao, foram priorizados apenas relatrios. Depois desta iterao, outros relatrios foram implementados esporadicamente nas iteraes seguintes. Alm deles, foram implementados tambm acertos e pequenas alteraes nos relatrios previamente implementados. Mais uma vez, o feedback rpido permitiu que o requerente identificasse pequenos erros e aspectos que precisavam ser incorporados para melhorar as informaes apresentadas nos relatrios. Enquanto alguns destes aspectos se ocupavam basicamente do formato visual dos mesmos, outros tinham relao direta com o contedo apresentado. Os relatrios tambm se beneficiaram da maturidade das funcionalidades, em funo das mudanas nos modelos conceituais que foram feitas nas iteraes iniciais. 6.9 Histrico de Ciclos Passados O Sistema de Aferies usado semestralmente durante um perodo de dois meses que recebe o nome de ciclo. Fora do ciclo, o sistema usado basicamente pelo pessoal da rea de esportes ou por atletas do comit que tenham interesse em ver informaes histricas armazenadas no sistema. Desde o incio do projeto, o requerente e a equipe de desenvolvimento sabiam que haveria a necessidade de implementar funcionalidades especficas para o tratamento do histrico das informaes do sistema, visto que o comportamento esperado diferente daquele que os usurios encontram quando utilizam o sistema durante o ciclo. Tais funcionalidades no foram priorizadas nas primeiras iteraes. Nem mesmo foi priorizada a criao de uma infra-estrutura que pudesse acolher as funcionalidades associadas ao tratamento do histrico do sistema. O feedback recebido pelo requerente nas primeiras iteraes, que levou a inmeras alteraes nos modelos conceituais de aferio, fez com que ele priorizasse

148

funcionalidades relativas s aferies e deixasse o histrico em segundo plano, situao na qual ele permaneceu at a vigsima primeira iterao, embora desde a terceira j houvesse uma entidade do sistema, chamada Ciclo, associada a todas as partes do sistema que fossem sensveis ao tempo, tais como Aferies, Planos de Treinos, entre outros. Para a vigsima primeira iterao, foi priorizada uma histria que permitiria ao usurio navegar pela aferio de habilidades do ciclo anterior. Depois disso, o problema do tratamento de histrico s voltou a ser discutido na vigsima quinta iterao, j bem prximo ao final do projeto que teve um total de 27 iteraes. Nessa iterao, a equipe de desenvolvimento e o requerente fizeram um estudo detalhado para definir como seria implementado o histrico nas duas ltimas iteraes do projeto. A partir deste estudo, foram priorizadas as primeiras histrias para a vigsima sexta e as ltimas para a iterao seguinte. Toda a estrutura de armazenamento de histrico foi implementada na vigsima sexta iterao. Foram priorizadas as ltimas histrias relativas a histrico para a vigsima stima e todas elas envolviam a alterao de relatrios que j haviam sido criados previamente e, eventualmente, a criao de novos relatrios. Na vigsima stima iterao tambm foram feitos ajustes em funcionalidades ligadas ao histrico que j haviam sido implementadas na iterao anterior. Deve-se notar que o primeiro tratamento de uma questo relativa ao histrico s ocorreu na vigsima primeira iterao, quando o sistema j havia entrado em produo e grande parte das funcionalidades j estava madura. Assim como ocorreu no caso dos relatrios, a implementao do histrico tambm se beneficiou da maturidade das

149

funcionalidades, permitindo que o processo fosse concludo com rapidez nas duas iteraes finais do projeto. Finalmente, vlido observar tambm que para implementar as funcionalidades associadas ao histrico, a equipe de desenvolvimento foi levada a alterar a arquitetura do sistema, pois a mesma no havia sido preparada para armazenar informaes histricas. Nesta arquitetura no havia, por exemplo, tabelas destinadas ao armazenamento de informaes histricas e nem procedimentos destinados a preenchlas. A implementao do histrico foi bem sucedida apesar da aparente fragilidade de uma arquitetura que no havia sido preparada para contempl-lo. Atravs do uso da refatorao, a equipe de desenvolvimento conseguiu adaptar a arquitetura, inclusive fazendo alteraes significativas nas bases de dados que j continham informaes de produo armazenadas durante o primeiro ciclo de uso do sistema. Este episdio demonstra que possvel trabalhar com uma arquitetura evolutiva e utilizar a refatorao freqente para viabiliz-la, pois a utilizao desta prtica ao longo de todas as iteraes do projeto foi importante para tornar a arquitetura simples e fcil de ser alterada. Sem isso, a implementao das funcionalidades do histrico poderia ter sido mais demorada e, eventualmente, inviabilizada. Finalmente, vale notar tambm que a equipe modelou uma soluo simples para o problema do histrico. Na realidade, duas alternativas foram consideradas no incio das discusses, as quais envolveram todos os membros da equipe de desenvolvimento. Depois de dois dias de debates intensos e modelagens em conjunto utilizando quadro branco, a equipe chegou a uma terceira alternativa que se mostrou mais eficaz que as duas que vinham sendo debatidas at ento. Alm disso, se mostrou mais simples e

150

rpida de ser implementada. Neste caso, nota-se que a proximidade fsica entre os membros da equipe, o uso intenso do dilogo e a modelagem conjunta foram teis mais uma vez para simplificar as solues e acelerar a implementao das funcionalidades. 6.10 Documentao No incio do projeto, a equipe de desenvolvimento e o Comit Olmpico fizeram uma priorizao dos artefatos que deveriam ser gerados ao longo do projeto. Foram priorizados os seguintes itens: Diagrama de Classes; Javadoc; Plano de Testes de Aceitao; Manual do Usurio; Tutorial; Histrias; Modelo de Dados e Atas de Reunies.

Estes artefatos eram produzidos de forma incremental, assim como ocorria com o cdigo. Portanto, traziam novas informaes a cada iterao, de modo a refletir as novas histrias implementadas no sistema. No incio de cada iterao, a equipe e o requerente produziam apenas os cartes contendo as histrias da iterao. Os desenvolvedores implementavam as

funcionalidades at que nos ltimos dois dias da iterao o redator tcnico comeasse a atualizar as documentaes para refletir o que foi introduzido no cdigo ao longo da iterao.

151

Ao atualizar os artefatos no final da iterao, a equipe evitava problemas de sincronizao da documentao com o cdigo. Caso as documentaes fossem geradas no incio da iterao, alteraes no cdigo para refletir ajustes solicitados pelo requerente demandariam alteraes na documentao, tornando tais mudanas mais custosas. Deixando a atualizao dos documentos para o final da iterao, os mesmos passavam a refletir um cdigo mais estvel o que minimizava a necessidade de alteraes na documentao para refletir ajustes nas funcionalidades. 6.11 Anlise de cada prtica do XP no projeto Nesta seo, iremos analisar a influncia de cada prtica do XP neste projeto. Cliente Presente Antes de iniciar o projeto, a consultoria responsvel pelo desenvolvimento do Sistema de Aferies sugeriu que a equipe de desenvolvimento fosse alojada na sede do Comit Olmpico, na mesma sala do requerente. Entretanto, o comit no conseguiu disponibilizar um espao para esta finalidade. Assim, a consultoria montou um escritrio prximo sede do comit de modo que o requerente pudesse visitar a equipe de desenvolvimento com freqncia, bastando atravessar a rua. Infelizmente, o mesmo no foi possvel em relao ao requerente de TI, pois toda a rea de Tecnologia da Informao do comit ficava localizada em outro estado da Rssia. Para que o requerente de TI se encontrasse pessoalmente com a equipe, era necessrio tomar um vo com durao de uma hora, o que ele fazia uma vez a cada iterao. As iteraes sempre se iniciavam em uma tera-feira e terminavam em uma segunda-feira. Isso permitia que o requerente de TI tomasse um vo na segunda-feira de manh para acompanhar o encerramento da iterao e a validao das funcionalidades.

152

Passava uma noite na cidade da sede do comit, e acompanhava o planejamento da iterao durante a tera, de modo que pudesse tomar um vo de volta ao final do dia. O relacionamento com o requerente que ficava prximo equipe era mais freqente. Ele se encontrava com os desenvolvedores quase diariamente, o que permitia dilogos que duravam alguns minutos na maioria das vezes, chegando a algumas horas em situaes mais delicadas. No incio do projeto, as visitas do requerente no seguiam um planejamento bem definido. Ele visitava a equipe de forma ad hoc atendendo ao pedido dos desenvolvedores. Depois das primeiras iteraes isso mudou. O lder da equipe de desenvolvimento passou a utilizar a reunio de planejamento no incio de cada iterao para montar uma agenda de encontros com o requerente. Tal agenda indicava os dias da iterao nos quais o requerente visitaria a equipe, bem como o horrio das visitas. O objetivo era fazer com que o requerente j alocasse espao na sua agenda para a equipe e permitir que a equipe soubesse exatamente quando poderia contar com a presena do requerente para tirar dvidas. A proximidade fsica teve dois benefcios principais: permitiu que a equipe evitasse assumir premissas, fazendo validaes freqentes com o requerente; alm disso, ajudou a estreitar os laos de confiana entre a equipe e o requerente, o que foi importante para assegurar a colaborao mtua entre as partes. Durante as iteraes, o desenvolvimento das histrias seguia uma ordem bem definida. A cada nova histria, os desenvolvedores executavam as seguintes etapas: 1. A histria era discutida em conjunto por todos os desenvolvedores que buscavam identificar o maior nmero possvel de detalhes. Nessa fase, normalmente eles identificavam questes em aberto que eram anotadas

153

para serem perguntadas ao requerente assim que ocorresse a prxima visita dele. 2. Os desenvolvedores ajudavam o analista de testes a identificar testes de aceitao para a histria, os quais eram anotados e validados mais tarde com o requerente. Este, por sua vez, eventualmente acrescentava outros testes de aceitao para a histria. 3. Sempre que uma funcionalidade envolvia a criao ou alterao de uma tela do sistema (o que ocorria na maioria dos casos), a equipe desenhava a tela no quadro branco e validava com o requerente. Em seguida, o designer desenhava a tela utilizando ferramentas de tratamento de imagens, como o Photoshop. Este desenho tinha mais detalhes que aquele feito no quadro e permitia que o requerente fizesse ajustes visuais antes de a funcionalidade ser implementada. Feito isso, a mesma tela era desenhada em HTML (Hypertext Markup Language) puro, sem qualquer elemento dinmico e mais uma vez era mostrada para a validao do requerente. 4. Finalmente, a equipe comeava a implementar os aspectos dinmicos da funcionalidade, adicionando cdigo ao sistema. Esse processo assegurava que os testes de aceitao fossem planejados antes da implementao da funcionalidade, o que levava os desenvolvedores a identificar cedo todos os fluxos aceitveis e todas as excees que poderiam ser geradas e, portanto, teriam que ser tratadas. Assim, quando a implementao comeava, j era direcionada para cuidar dos fluxos aceitveis, bem como para tratar as excees, evitando que os usurios fossem surpreendidos por bugs do sistema caso tentassem executar operaes

154

indevidas. Tais operaes eram previstas no sistema e tratadas de modo que o usurio pudesse sempre receber uma mensagem adequada quando tentasse execut-las, ao invs de uma mensagem de erro genrica. Alm disso, a utilizao de prottipos cada vez mais refinados era til para permitir que o cliente visualizasse detalhes da funcionalidade de forma rpida, permitindo que ele pedisse ajustes e estes fossem incorporados com baixo custo. Ainda assim, era comum o requerente identificar ajustes aps a funcionalidade ser completamente implementada. Entretanto, tais ajustes eram mnimos depois de todos os que eram efetuados durante a apresentao dos prottipos. Cada um dos tipos de prottipos citados anteriormente costumava consumir uma mdia de poucos minutos at um mximo de uma ou duas horas para serem produzidos. Alm disso, costumavam ser validados pelo requerente em poucos minutos. Sem proximidade fsica, teria sido difcil utilizar este processo de trabalho, na medida em que as validaes tenderiam a demorar mais para acontecer. Alm disso, o uso de canais de comunicao menos ricos que os dilogos pessoais tornaria mais lenta a convergncia das solues. Apesar de no ter tido acesso permanente ao requerente, visto que ele no estava permanentemente na sala em que ocorria o desenvolvimento, a proximidade dos escritrios permitiu um bom uso da prtica de ter o cliente presente. J no caso do requerente de TI, as relaes eram um pouco mais complicadas devido distncia fsica. Havia contato dirio por telefone e email, mas esses canais freqentemente levavam a dificuldades de entendimento e pequenos atritos no relacionamento. A distncia tambm fazia com que o requerente de TI tivesse menor visibilidade do que

155

ocorria no dia-a-dia da equipe de desenvolvimento. Essa foi uma das razes pelas quais os relacionamentos de confiana eram menos fortes com o requerente de TI. A percepo geral dos desenvolvedores foi de que a confiana em uma prestao de servio, como o desenvolvimento de um software, est profundamente associada proximidade das partes e a visibilidade permanente do cliente sobre o que o prestador de servio est fazendo diariamente pelo avano do projeto. Jogo do Planejamento Como explicado anteriormente, o projeto teve 27 iteraes, cada uma com duas semanas de durao, as quais se iniciavam em uma tera-feira e terminavam em uma segunda-feira. No primeiro dia de cada iterao havia uma reunio de planejamento que era usada para que o requerente priorizasse as histrias a serem implementadas na iterao. No ltimo dia, o requerente validava todas as funcionalidades e percorria todo o plano de testes de aceitao elaborado e refinado ao longo da iterao que estava sendo finalizada. Nas reunies de planejamento, o requerente selecionava um conjunto de cartes contendo as histrias consideradas candidatas para serem implementadas na iterao. s vezes, criava novos cartes em funo do aprendizado obtido nas iteraes anteriores. Em outras situaes eliminava cartes que passassem a ser considerados desnecessrios. Os desenvolvedores estimavam os cartes candidatos. Isso era feito em conjunto, de modo que todos os desenvolvedores pudessem opinar sobre a quantidade de esforo necessria para cada carto. Alm disso, a estimativa era feita na presena do requerente e do requerente de TI, de modo que a equipe pudesse tirar dvidas sobre os detalhes da funcionalidade. Finalmente, todos os cartes eram limitados a um mximo

156

de trs dias de trabalho de um par de desenvolvedores. Cartes estimados acima deste nmero eram repassados de volta para o requerente para que fossem divididos. De posse das estimativas, o requerente selecionava um conjunto de cartes que pudesse lhe gerar o mximo de benefcio dentro do oramento disponibilizado pela equipe de desenvolvimento. O oramento era representado pela velocidade da equipe na iterao anterior. Para descobrir este valor, a equipe registrava seu progresso diariamente no quadro de acompanhamento dirio, que foi criado por ela mesma e explicado mais adiante na seo 6.13. Feita a priorizao, os cartes da iterao eram posicionados em um mural contendo trs colunas: no iniciados, em andamento e finalizados (TELES, 2004, p.254). A ordem em que eram colocados no mural refletia a ordem definida pelo requerente para o desenvolvimento dos mesmos. Tal ordenao era respeitada pelos desenvolvedores ao longo da iterao, de modo que as funcionalidades mais importantes para o requerente fossem sempre as primeiras implementadas. Ao final da reunio de planejamento, o lder da equipe de desenvolvimento escrevia uma ata contendo todos os assuntos discutidos na reunio, bem como a indicao dos cartes priorizados. Estas atas foram utilizadas para coletar inmeras informaes apresentadas neste estudo de caso. A finalizao de uma iterao era feita com a presena do requerente e do requerente de TI. Ambos utilizavam as funcionalidades implementadas na iterao e percorriam o plano de testes de aceitao para assegurar que todas as histrias tivessem sido implementadas corretamente. Nestes momentos, os requerentes normalmente pediam ajustes de ltima hora. Alguns deles eram implementados de imediato pelos

157

desenvolvedores, enquanto outros mais demorados acabavam se transformando em cartes para iteraes seguintes. Na reunio de finalizao a equipe de desenvolvimento tambm fazia uma retrospectiva (TELES, 2004, p.265) com a participao dos requerentes. Trata-se de uma tcnica estruturada para avaliao da iterao, de modo a indicar os aspectos da iterao que funcionaram bem e aqueles que precisariam ser melhorados. Ao final da retrospectiva, faz-se a priorizao dos principais pontos que necessitam de melhorias e todos propem aes para solucionar os problemas na iterao que se inicia. Tais aes ficam registradas no quadro branco de modo que a equipe possa recordar-se delas ao longo da iterao e coloc-las em prtica. Este mecanismo se revelou til para melhorar continuamente o sistema e a forma como a equipe se estruturava para implement-lo. Stand Up Meeting A equipe de desenvolvimento realizava a reunio de stand up meeting diariamente por volta das 9:20h da manh. Ela durava em torno de 10 a 20 minutos, nos quais se discutia tudo o que havia sido feito no dia anterior e se priorizava as atividades do dia que se iniciava. Alm disso, o stand up meeting tambm era usado para que os desenvolvedores atualizassem o Quadro e Acompanhamento Dirio. Estas reunies se mostraram teis e foram feitas diariamente, durante todo o projeto. Muitos problemas eram resolvidos rapidamente nestas reunies. Alm disso, os desenvolvedores conseguiam ter uma boa noo do todo a partir dos relatos de seus colegas. Programao em Par A programao em par foi utilizada durante todo o projeto, embora tivesse havido resistncias e dificuldades no incio. Dentro da consultoria que implementou o

158

sistema de aferies, havia pessoas que no apoiavam a programao em par e acreditavam que ela colaboraria para diminuir a velocidade do projeto. Por isso, sugeriram que todas as prticas do XP fossem adotadas, com exceo da programao em par. A sugesto foi rejeitada pelo coach (BECK, 2000) (responsvel tcnico) da equipe de desenvolvimento. Os desenvolvedores no estavam habituados a trabalhar em pares, portanto estranharam no incio. Na verdade, no estavam habituados a trabalhar com o XP e tinham duvidavam sobre o seu funcionamento. Para contornar esta situao, o coach pediu que a equipe desse um crdito de seis semanas para o XP. Ou seja, durante seis semanas a equipe utilizaria as prticas do XP sem restries. Em seguida, todos juntos fariam uma anlise das prticas e decidiriam se continuariam a us-las ou se adotariam outras estratgias de desenvolvimento. O coach assumiu o compromisso de adotar a estratgia que fosse definida pela equipe ao final deste perodo, desde que a equipe ao menos experimentasse as prticas do XP durante essas seis semanas. Apesar do desconforto inicial, os desenvolvedores aprenderam rapidamente a trabalhar em pares e a se adaptar a seus colegas. Isso foi facilitado pelo fato de que todos os desenvolvedores se conheciam antes deste projeto e j tinham trabalhado juntos durante anos em projetos anteriores. Assim, os laos de amizade contriburam para que eles alcanassem rapidamente um bom relacionamento ao trabalharem em par. O uso da programao em par parece ter contribudo para que a equipe produzisse menos bugs. Alm disso, os pares avanavam rapidamente de forma consistente. O lder de projeto, que estava entre as pessoas que se opuseram inicialmente programao em par, se transformou em defensor da idia aps observar os resultados da primeira iterao. Ao longo do tempo, ningum mais levantou dvidas

159

sobre a programao em par e ela permaneceu em uso durante todo o projeto. Passadas as seis semanas de experimentao solicitadas pelo coach, a equipe de desenvolvimento decidiu manter a programao em par, bem como todas as demais prticas do XP. Desenvolvimento Orientado a Testes O desenvolvimento orientado a testes normalmente representa a parte tcnica mais difcil do XP, especialmente para pessoas habituadas a trabalhar dentro da forma tradicional de desenvolvimento, isto , implementar e depois testar. Com esta equipe no foi diferente. Os desenvolvedores no possuam experincia, nem conhecimentos sobre como implementar testes automatizados. Desde o incio, eles conseguiram criar testes automatizados para as classes que faziam acesso ao banco de dados. Entretanto, no conseguiram fazer o mesmo para as demais classes do sistema. Portanto, houve deficincia na automao dos testes. Felizmente, o analista de testes executava testes manuais com boa freqncia, o que evitava uma incidncia elevada de bugs. A deficincia nos testes fez com que a equipe produzisse um nmero de bugs considerado significativo a cada iterao. Em mdia, ela produziu mais de dez bugs por iterao. Tais bugs costumavam ser detectados com rapidez pelo analista de testes, mas provvel que o nmero de bugs fosse menor e o trabalho de analista de testes menos intenso caso se tivesse conseguido implementar testes automatizados em todas as partes do sistema. Refatorao A equipe aprendeu rapidamente a utilizar a refatorao em seu dia-a-dia. Isso era facilitado pela utilizao de um ambiente de desenvolvimento que disponibilizava

160

diversos tipos de refatoraes de forma automatizada (IntelliJ 3.0), diminuindo a chance de que as refatoraes produzissem erros. A deficincia nos testes automatizados, entretanto, fez com que as refatoraes fossem desprovidas de um mecanismo de proteo essencial. Por isso, houve situaes em que refatoraes geraram bugs que no foram detectados rapidamente. Porm, na maioria dos casos, o suporte refatorao embutido no IntelliJ assegurou que as refatoraes ocorressem de forma segura. A arquitetura do sistema evoluiu de forma consistente com a utilizao da refatorao. De um modo geral, a equipe de desenvolvimento foi capaz de adapt-la rapidamente s necessidades das funcionalidades que iam surgindo no sistema. Durante um dia de trabalho, era comum os desenvolvedores executam uma grande quantidade de pequenas refatoraes medida que evoluam. Poucas eram as situaes em que os desenvolvedores faziam grandes refatoraes que consumiam muito tempo e geravam grandes impactos na arquitetura. Mesmo nestes casos, a equipe se surpreendeu diversas vezes com a rapidez com que algumas refatoraes foram executadas. Cdigo Coletivo A prtica de cdigo coletivo foi usada durante todo o projeto e no apresentou problemas. Tornar o cdigo coletivo permitiu que a equipe avanasse com agilidade, na medida em que no era necessrio esperar por outros desenvolvedores sempre que havia a necessidade de editar um arquivo do sistema. Alm disso, o revezamento entre as diversas funcionalidades permitiu que os desenvolvedores obtivessem vivncia em todos os aspectos do projeto. Cdigo Padronizado

161

Nos primeiros dias do desenvolvimento a equipe estabeleceu um padro para o cdigo do sistema. Isso foi facilitado pela utilizao da prtica de cdigo coletivo e da programao em par. Ambas ajudaram a assegurar que os desenvolvedores aderissem aos padres. Por sua vez, a padronizao do cdigo ajudou os desenvolvedores a manter o cdigo coletivo e a trabalhar em pares ao longo do desenvolvimento. Design Simples A cada iterao, a equipe de desenvolvimento implementava novas caractersticas na arquitetura do sistema que fossem suficientes para comportar apenas as funcionalidades da iterao. Ou seja, mesmo que cartes de iteraes futuras fossem conhecidos, a equipe no criava mecanismos para sustentar a construo futura dos mesmos. Isso se mostrou til visto que os modelos de aferio e planejamento de treinos sofreram fortes mudanas ao longo do projeto. Se a equipe tivesse investido muito cedo na criao de uma infra-estrutura para suportar cartes futuros, grande parte do esforo acabaria se perdendo e o comit demoraria mais para receber as funcionalidades consideradas prioritrias. Integrao Contnua O processo de integrao contnua era apoiado pela automao de builds e pela utilizao de um repositrio. Os builds eram automatizados com a utilizao da ferramenta Ant7, enquanto o repositrio era de responsabilidade do CVS8. Alm disso, a equipe mantinha uma mquina exclusivamente para integrao. Antes de iniciar qualquer atividade de desenvolvimento, os pares recuperavam todos os arquivos do projeto a partir do repositrio (check out) armazenando-os em um
7 8

http://ant.apache.org/ https://www.cvshome.org/

162

diretrio local de suas estaes de trabalho. Em seguida implementavam alteraes, adies e remoes no cdigo. De tempos em tempos, os pares iam at a mquina de integrao para integrar o cdigo que estavam editando com o cdigo gerado pelos demais desenvolvedores que j estivessem armazenados no repositrio. Este processo funcionou bem durante todo o projeto. s vezes ocorriam conflitos de integrao, mas tais situaes eram raras. Quando ocorriam, costumavam ser corrigidos com rapidez porque todos os desenvolvedores se sentavam prximos uns dos outros. Assim, os pares chamavam seus colegas para ajudar a solucionar os conflitos rapidamente, o que normalmente dava bons resultados. Metfora No incio do projeto, a equipe e o comit desenvolveram algumas metforas para se referirem a aspectos chaves dos processos de aferio. Em particular, pode-se citar a elaborao do conceito de gavetas para cada atleta, dentro das quais armazenavam-se fichas contendo os resultados das aferies, bem como os planos de treinos. Esta metfora era usada nas conversas com o requerente e as classes do sistema eram nomeadas de acordo com ela. O uso de metforas se revelou til para facilitar a comunicao dos conceitos mais importantes do projeto. Para criar tais metforas, a equipe procurou imaginar como os processos modelados para o sistema seriam executados no dia-a-dia caso no existisse computador. Da surgiu a idia de utilizar gavetas, fichas etc. Ritmo Sustentvel A equipe de desenvolvimento trabalhou de 9h s 18h durante praticamente todos os dias do projeto. Houve apenas cinco ocasies onde isso no aconteceu. Nestes casos, houve necessidade de permanecer no escritrio at mais tarde e em duas situaes foi

163

preciso que parte dos desenvolvedores fossem ao escritrio no fim-de-semana. De um modo geral isso ocorreu apenas quando o sistema estava sendo colocado em produo e teve como objetivo dar suporte equipe de TI do comit para que fosse capaz de instalar o sistema corretamente nos servidores de produo. Releases Curtos O Comit Olmpico utiliza os servios de duas empresas terceirizadas na rea de Tecnologia da Informao. Uma cuida da manuteno de todos os sistemas do comit, enquanto a outra responsvel por toda a infra-estrutura de hardware. Para que um projeto entre em produo, necessrio acionar estas duas empresas e fazer o sistema ser homologado por elas. Na prtica isso significa fazer com que o sistema passe por um conjunto de formalidades trabalhosas e demoradas. Por isso, a prtica de releases curtos no foi adotada neste projeto, embora a equipe de desenvolvimento quisesse utiliz-la. Houve uma entrada em produo na dcima nona iterao. Depois, foram feitos acertos e novas funcionalidades foram adicionadas nas iteraes seguintes. Estas entraram em produo mais rapidamente. A impossibilidade de utilizar a prtica de releases curtos foi prejudicial por ter privado a equipe de desenvolvimento do feedback de uma comunidade maior de usurios que poderiam ajudar a refinar ainda mais o sistema. 6.12 Quadro de Acompanhamento Dirio O quadro de acompanhamento dirio uma ferramenta de monitoramento do projeto que foi criada pela equipe de desenvolvimento ao longo deste projeto. Como j vimos, o processo de planejamento do Extreme Programming envolve os seguintes conceitos:

164

Histria; Carto; Estimativa; Dia ideal; Dia real; Velocidade e Tarefas extras.

Uma histria uma pequena funcionalidade que pode ser desenvolvida por uma dupla de desenvolvedores em poucos dias. Um software formado por um conjunto de histrias, as quais so escritas pelo cliente, com suas prprias palavras, em pequenos cartes. Cada histria estimada pela equipe de desenvolvimento, que registra a estimativa no canto superior esquerdo dos cartes (mais tarde, o realizado colocado no campo superior direito). Desta forma, observando cada carto, o cliente capaz de identificar a histria e seu respectivo custo na forma de tempo de desenvolvimento. As estimativas utilizam como unidade o conceito de dia ideal. Se uma histria estimada em um dia ideal, isso significa que uma dupla de desenvolvedores (devido ao uso da programao em par no XP) ser capaz de desenvolver a histria em um dia de trabalho, desde que no sejam interrompidos para executar outras atividades. Portanto, um dia ideal representa um dia de trabalho no qual o par pode se dedicar integralmente apenas ao desenvolvimento de histrias, sem se preocupar em atender telefonemas, participar de reunies, corrigir bugs etc (BECK, 2000). Ao fazer uma estimativa, o desenvolvedor projeta um mundo ideal, no qual ele possa se abstrair de interrupes e dedicar-se plenamento ao desenvolvimento da funcionalidade. Portanto, a estimativa no leva em conta fatores externos, nem qualquer tipo de interrupo. O que se busca o melhor caso. Entretanto, infelizmente o

165

desenvolvedor vive em um dia real, no qual existem interrupes que afetam a quantidade de histrias produzidas. Para lidar com isso, utiliza-se o conceito de velocidade da iterao. Um dia real composto por horas dedicadas ao desenvolvimento de histrias e horas dedicadas a tarefas extras, as quais representam um overhead para o projeto. A velocidade indica a quantidade de horas efetivamente teis, ou seja, que realmente levaram implementao de novas histrias. Portanto, a velocidade procura indicar quantos dias ideais estiveram contidos dentro de uma determinada iterao. Para compreender estes conceitos, pode-se utilizar um exemplo. Suponhamos uma iterao de duas semanas e uma equipe de quatro desenvolvedores. Neste caso:

1 iterao = 2 semanas = 10 dias teis 4 desenvolvedores = 2 pares 1 par / dia trabalhando exclusivamente em histrias = 1 dia ideal 2 pares / dia trabalhando exclusivamente em histrias = 2 dias ideiais 10 dias teis x 2 dias idias = 20 dias ideais

A cada iterao deste projeto, se tudo correr de maneira perfeita, a equipe ser capaz de implementar histrias que somem um mximo de 20 dias ideais. Este o limite mximo da iterao e s alcanado caso no existam tarefas extras ao longo da mesma. Se em uma determinada iterao a equipe tiver consumido 4 dias de um par para executar atividades extras, isso significar que a quantidade de dias ideais da iterao ter sido apenas 16, que representa o resultado de 20 (limite mximo) 4 (tarefas

166

extras). O valor 16, ou seja, a quantidade de dias ideais da iterao representa a sua velocidade. As histrias so estimadas em nmero de dias ideais. Por sua vez, a velocidade indica a quantidade de dias ideais de uma iterao. Portanto, este valor utilizado pelo cliente para indicar a quantidade de histrias que sero alocadas a cada iterao. Ele poder alocar histrias at que a soma de suas estimativas alcance a velocidade da iterao. A velocidade no um valor constante. Uma iterao pode ter uma quantidade maior ou menor de tarefas extras em relao a outra. Para que o cliente e a equipe possam se planejar adequadamente, necessrio que a equipe seja capaz de fornecer a velocidade da iterao que se inicia com a maior preciso possvel. A equipe verifica quantos dias ideais foram obtidos na iterao anterior e assume que esta quantidade se repetir na iterao corrente. Entretanto, para fazer isso, necessrio que a equipe seja capaz de medir a velocidade de cada iterao. Em outras palavras, necessrio que ela monitore o tempo dedicado s funcionalidades e o tempo dedicado s tarefas extras. O quadro de acompanhamento dirio uma ferramenta que pode ser utilizada de maneira simples para monitorar os acontecimentos da iterao. Ele dividido em duas partes: histrias e tarefas extras, como ilustrado na figura 4. A parte associada s histrias utilizada para registrar o tempo gasto no desenvolvimento de cada histria da iterao, enquanto a outra parte usada para indicar o tempo alocado s atividades extras. A tabela contm as seguintes colunas:

167

Estimativa utilizada apenas na parte associada s histrias. Armazena a quantidade de dias ideais estimados para cada histria da iterao. As histrias so listadas nas linhas da tabela em ordem de prioridade. Dias da iterao considerando-se uma iterao de duas semanas, haver dez dias teis de trabalho. Para cada dia, do primeiro ao dcimo, cria-se uma coluna. Total indica a quantidade total de tempo gasta com uma determinada histria ou tarefa extra.

No incio da iterao, o quadro de acompanhamento dirio se parece com o exemplo da figura 6.1. Apenas as histrias so preenchidas e suas respectivas estimativas.

Figura 6.1: quadro no incio da iterao. Ao longo da iterao, a equipe atualiza o quadro diariamente, de modo que, no meio da iterao, o quadro ir se parecer com o exemplo da figura 6.2.

168

Figura 6.2: quadro no meio da iterao. Ao final da iterao, o quadro ir se assemelhar aos exemplos das figuras 6.3 ou 6.4.

Figura 6.3: a quantidade de dias ideais permaneceu estvel, mas a equipe no implementou todas as funcionalidades. Na figura 6.3, a equipe herdou uma velocidade de 17 dias ideais, valor que acabou se repetindo ao final da iterao. Entretanto, algumas funcionalidades consumiram mais esforo que o previsto. O desvio entre a estimativa e o realizado tambm armazenado na tabela, na extrema direita. Essa informao til para que a

169

equipe estude as funcionalidades onde houve erros de estimativa e procure compreender o que os gerou, de modo a melhorar as estimativas futuras.

Figura 6.4: a quantidade de dias ideais foi alterada, mas a equipe implementou todas as funcionalidades. No exemplo da figura 6.4, a velocidade cai de 17 para 16 porque a quantidade de tarefas extras cresceu em relao iterao anterior. Entretanto, a equipe errou nas estimativas, desta vez, para cima. Assim, apesar de a velocidade ter diminudo, a equipe foi capaz de implementar todas as histrias previstas. O quadro de acompanhamento dirio desenhado a cada iterao em um quadro branco, de modo que seja permanentemente visvel e acessvel por todos os membros da equipe. A atualizao feita de forma rpida durante o stand up meeting. Cada par escreve no quadro a quantidade de tempo gasta no dia anterior com cada histria ou atividade extra. Para isso, utiliza-se a regra de que o mximo de tempo alocado a uma histria ou atividade extra em um dia 1 dia ideal. Por sua vez, o mnimo 0,25 dia ideal que equivale a duas horas de trabalho de um par. Fazendo isso, o quadro no fornece preciso absoluta sobre o que foi feito na iterao, mas o processo de registro da informao simplificado para diminuir ou

170

eliminar resistncias a sua utilizao. O objetivo facilitar para que se obtenha, ao menos, um bom retrato da iterao, mesmo que a preciso seja ligeiramente comprometida. O preenchimento do quadro durante o stand up meeting tambm utilizado como forma de assegurar que a equipe mantenha a disciplina em conjunto. Quando um desenvolvedor possui uma ficha para preencher tudo o que faz durante o dia e o tempo alocado a cada atividade, por exemplo, comum que ele se esquea de preencher ou simplesmente se recuse a faz-lo. Por outro lado, quando todos os desenvolvedores criam o hbito de preencherem o quadro, juntos, manter a disciplina torna-se mais fcil. Isso se comprovou no projeto, visto que os desenvolvedores efetivamente atualizaram o quadro todos os dias, durante todo o projeto. Ao final da iterao, a equipe pode registrar as informaes do quadro para que possam ser referenciadas futuramente. Isso pode ser feito com o uso de uma planilha eletrnica ou um editor de texto, por exemplo. Assim, os membros do projeto so capazes, entre outras coisas, de verificar todas as histrias implementadas no passado, o tempo efetivamente gasto em cada uma, os desvios em relao s estimativas e as tarefas extras realizadas. Este estudo de caso se baseou, em grande parte, nas informaes coletadas no quadro de acompanhamento dirio, que foram registradas a cada iterao, nas atas das reunies do jogo do planejamento. Retrospectivas As informaes extradas do quadro ao final da iterao atendem a vrios propsitos. O mais bsico indicar a velocidade que ser adotada na iterao seguinte. Entretanto, o quadro tambm usado para fornecer subsdios retrospectiva.

171

Ela representa um processo estruturado de reflexo da equipe de desenvolvimento, executado com a participao do cliente, sempre que possvel. A primeira etapa da retrospectiva consiste em enumerar e analisar os pontos positivos da iterao para que eles sejam lembrados pela equipe na iterao seguinte e sirvam de inspirao para manter as prticas que vem funcionando. Em seguida, a equipe enumera e analisa os pontos da iterao que precisam melhorar. Todas as pessoas indicam os problemas que vivenciaram e as conseqncias dos mesmos. A equipe prioriza em conjunto os pontos a melhorar, de modo a indicar quais os dois ou trs mais crticos (no mais que isso). Para cada um destes problemas, os participantes da retrospectiva propem e discutem aes que possam resolv-los na iterao seguinte (TELES, 2004). As informaes do quadro de acompanhamento dirio so importantes durante a retrospectiva, pois geram pistas para identificar os problemas mais crticos, como por exemplo uma iterao com excesso de atividades extras, ou uma histria que teve um desvio muito acentuado em relao ao estimado, ou um conjunto de histrias que acabou no sendo implementado. A retrospectiva um mecanismo de melhoria contnua que foi utilizado com sucesso ao longo deste projeto 6.13 Consideraes finais O Sistema de Aferies formado por 70 mil linhas de cdigo, 1.214 classes e 5.728 mtodos que foram gerados por uma equipe de 4 desenvolvedores durante um perodo de 55 semanas. Houve aproximadamente 550 dias teis disponveis para a equipe de desenvolvimento, dos quais 322 foram efetivamente utilizados para a implementao de funcionalidades. Os demais 228 dias foram consumidos em tarefas

172

extras ao longo do projeto. Portanto, apenas 58% do tempo foi efetivamente consumido na implementao de novas funcionalidades. Ao final do projeto, o sistema passou por um perodo de seis meses de garantia. Neste perodo, caso algum erro fosse detectado, a consultoria que desenvolveu o Sistema de Aferies seria responsvel por fazer correes. No total, a equipe de desenvolvimento teve que corrigir apenas trs bugs ao longo dos seis meses de garantia, sendo que o primeiro s foi identificado depois de quatro meses e meio de utilizao do sistema em produo. O sistema foi utilizado no primeiro ciclo por 97% do seu pblico alvo. Este nmero foi considerado alto pelo comit, visto que outros sistemas sazonais utilizados pelos atletas possuem taxa de utilizao mdia de apenas 60% do pblico alvo. Diversos atletas fizeram comentrios sobre o sistema e manifestaram a opinio de que o Sistema de Aferies era fcil e bonito, ao contrrio de outros sistemas que os atletas tinham dificuldades de utilizar e acabavam deixando de lado. O Comit Olmpico demonstrou elevada satisfao com o resultado final e elogiou a equipe de desenvolvimento inmeras vezes ao longo do projeto e mais enfaticamente no final do mesmo. Na ltima retrospectiva realizada, o requerente manifestou a opinio de que, aps este projeto, estava convencido da necessidade de que ele acompanhasse a equipe ao longo de todo o projeto e tivesse a oportunidade de alterar o escopo ao longo do tempo de modo a melhorar cada vez mais as funcionalidades, tornando-as mais intuitivas para os usurios. O resultado demonstrou que a utilizao das prticas do XP contribuiu para que o sistema solucionasse as necessidades reais do comit e fizesse isso de maneira

173

elegante e fcil de ser utilizada. Entretanto, no foi possvel fazer inferncias em relao influncia da utilizao do XP sobre o prazo e o custo do projeto. Antes de iniciar o projeto, o comit forou a consultoria a trabalhar com um prazo excessivamente curto para a implementao do projeto. Com o tempo, o comit percebeu a necessidade de alterar o escopo para incorporar mudanas no modelo conceitual de aferies e planejamento dos treinos, bem como outras mudanas menos significativas. Desta forma, o escopo da soluo final acabou sendo bastante diferente do original, apesar de o problema a ser resolvido ter se mantido estvel ao longo de todo o projeto. Os refinamentos consumiram um tempo que no havia sido previsto no cronograma inicial. Portanto, o projeto consumiu mais tempo que o imaginado originalmente e, conseqentemente, custou mais caro. Porm, difcil traar um paralelo entre o resultado final e o previsto no que se refere a custo e prazo visto que o escopo foi profundamente alterado. possvel levantar a hiptese de que a flexibilidade do escopo, normalmente encontrada em projetos XP, tenha sido responsvel pela elevao no prazo e no custo do projeto. Por outro lado, caso o escopo original tivesse sido mantido at o final, possvel que o sistema fosse entregue no prazo e no custo previsto, porm no fosse capaz de atender s necessidades dos seus usurios. Se ele se revelasse de pouca utilidade, o fato de alcanar o prazo e oramento previsto teria sido irrelevante, pois os problemas dos usurios continuariam sem soluo. Esperamos que outros trabalhos futuros possam ser mais conclusivos em relao influncia das prticas do XP nos prazos e custos dos projetos de software.

174

7 CONCLUSO

Este trabalho fez uma anlise dos problemas que tradicionalmente afetam os projetos de software, tais como atrasos, gastos superiores aos oramentos e funcionalidades que no solucionam os problemas dos usurios. O trabalho props a adoo das prticas e valores do XP como uma alternativa vivel para a resoluo destes problemas em diversos projetos de software. Atravs da reviso de literatura, procurou-se estabelecer bases tericas significativas para a adoo de cada uma das prticas e valores do XP. Foi mostrado que embora tais prticas sejam controversas em um primeiro momento, existem razes slidas pelas quais podem funcionar de fato. O estudo de caso apresentou um projeto que consumiu mais de um ano de trabalho com uma equipe de quatro desenvolvedores. Tal projeto utilizou todas as prticas do Extreme Programming. A avaliao dos resultados mostrou que o projeto foi capaz de gerar um conjunto de funcionalidades que atenderam s necessidades dos usurios de forma adequada. A equipe foi capaz de conduzir o projeto com baixo nvel de estresse e o relacionamento com os usurios se revelou positivo. Foi possvel estabelecer uma forte relao de confiana entre a equipe de desenvolvimento e seus usurios. Alm disso, o sistema apresentou elevada integridade, depois de sofrer inmeros aprimoramentos com base no feedback gerado ao final de cada iterao. No total, o projeto consumiu 70 mil linhas de cdigo que foram geradas por 4 desenvolvedores durante um perodo de 55 semanas. Houve aproximadamente 550 dias teis disponveis para a equipe de desenvolvimento, com aproveitamento de 58% deste

175

tempo para a implementao de novas funcionalidades. Durante o perodo de seis meses de garantia aps a concluso do projeto, foram identificados apenas trs bugs. O sistema, que tem utilizao sazonal, foi usado no primeiro ciclo por 97% do seu pblico alvo. Trata-se de um nmero elevado, visto que a outros sistemas sazonais do cliente tm taxa de utilizao mdia de apenas 60% do pblico alvo. Os usurios do sistema o consideraram fcil e bonito, o que gerou o elevado grau de utilizao observado. Devido intensidade das mudanas que ocorreram no escopo do projeto, no foi possvel estabelecer os efeitos da adoo do XP sobre o prazo e o custo do projeto. Sendo assim, espera-se que trabalhos futuros sejam capazes de obter outros dados de modo a comparar com os obtidos neste estudo de caso, em particular no que se refere ao prazo e ao custo.

176

REFERNCIAS

AMBLER, Scott W. Writing robust Java code: the AmbySoft Inc. coding standards for Java. 2000. Disponvel em: http://www.ambysoft.com/javaCodingStandards.pdf. Acesso em: 23/12/2004. ASTELS, David. Test-driven development: a practical guide. 1. ed. Upper Saddle River, NJ: Prentice Hall PTR, 2003. 562 p. BECK, Kent. Extreme Programming explained: embrace change. 1. ed. Reading, MA: Addison-Wesley, 2000. 190 p. BECK, Kent. Test-driven development: by example. 1. ed. Boston: Addison-Wesley, 2003. 240 p. BECK, Kent; ANDRES, Cynthia. Extreme Programming explained: embrace change. 2. ed. Upper Saddle River: Addison-Wesley, 2005. 189 p. BECK, Kent; FOWLER, Martin. Planning Extreme Programming. 1. ed. Boston: Addison-Wesley, 2001. 139 p. BOEHM, Barry; TURNER, Richard. Balancing agility and discipline: a guide for the perplexed. 1. ed. Boston: Addison-Wesley, 2003. 266 p. BROOKS, Frederick P. The mythical man-month: essays on software engineering, 20th anniversary edition. 2. ed. Reading, MA: Addison-Wesley, 1995. 322 p. BROOKS, Frederick P. No silver bullet: essences and accidents of Software Engineering. IEEE. Computer, v. 20, n. 4, 1987. p. 10-19. BRYANT, Antony,'It's engineering Jim ... but not as we know it': Software Engineering - solution to the software crisis, or part of the problem? In: International Conference on Software Engineering, 22., 2000, Limerick, Ireland. Anais... New York, NY: ACM Press, 2000. p. 78-87.

177

BUHRER, Koni. From craft to science: searching for first principles of software development. The Rational Edge, 2000. Disponvel em: http://www106.ibm.com/developerworks/rational/library/content/RationalEdge/dec00/FromCraftto ScienceDec00.pdf. Acesso em: 23/12/2004. COCKBURN, Alistair. Agile software development. 1. ed. Boston: Addison-Wesley, 2002. 278 p. CONSTANTINE, Larry L. The peopleware papers: notes on the human side of software. 1. ed. Upper Saddle River: Prentice Hall PTR, 2001. 346 p. DEMARCO, Tom. Slack: getting past burnout, busywork, and the myth of total efficiency. 1. ed. New York: Broadway Books, 2001. 227 p. DEMARCO, Tom; BOEHM, Barry. The agile methods fray. IEEE Computer, v. 35, n. 6, 2002. p. 90-92. DEMARCO, Tom; LISTER, Timothy R. Peopleware: productive projects and teams 2nd ed. 2. ed. New York, NY: Dorset House Pub. Co, 1999. 245 p. DEMARCO, Tom; LISTER, Timothy R. Peopleware: productive projects and teams. 1. ed. New York, NY: Dorset House Pub. Co, 1987. 188 p. DIJKSTRA, Edsger W. The humble programmer. ACM. Communications of the ACM, v. 15, n. 10, 1972. p. 859-866. DRUCKER, Peter. Desafio gerenciais para o sculo XXI. 1. ed. So Paulo: Pioneira, 1999. 168 p. EISCHEN, Kyle. Software development: an outsider's view. IEEE. Computer, v. 35, n. 5, 2002. p. 36-44. EMAM, Khaled E. Finding success in small software projects. Cutter Consortium Agile Project Management. Executive Report, v. 4, n. 11, 2003. FOWLER, Martin. Refactoring: improving the design of existing code. Upper Saddle River, NJ: Addison-Wesley, 2000. 421 p.

178

HIGHSMITH, James A. Agile software development ecosystems. 1. ed. Boston: Addison-Wesley, 2002. 404 p. HUNT, Andrew; THOMAS, David. The pragmatic programmer: from journeyman to master. 1. ed. Upper Saddle River: Addison-Wesley, 2000. 321 p. HUNT, Andrew; THOMAS, David. Pragmatic unit testing: in Java with JUnit. 1. ed: The Pragmatic Programmers, 2003. 176 p. ISBELL, Douglas; HARDIN, Mary; UNDERWOOD, Joan. Mars Climate orbiter team finds likely cause of loss. NASA Jet Propulsion Laboratory, 1999. Disponvel em: http://mars.jpl.nasa.gov/msp98/news/mco990930.html. Acesso em: 23/12/2004. JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James. The Unified software development process: the complete guide to the Unified Process from the original designers. 1. ed. Reading, MA: Addison-Wesley, 1999. 463 p. JEFFRIES, Ron; ANDERSON, Ann; HENDRICKSON, Chet. Extreme Programming installed. 1. ed. Boston: Addison-Wesley, 2001. 265 p. JOHNSON, Jim. "ROI, It's your job". Published Keynote Third International Conference on Extreme Progrmming, Alghero, Italy, May 26-29, 2002. Disponvel em: http://www.xp2003.org/talksinfo/johnson.pdf. Acesso em: 28/12/2004. KRUTCHTEN, Philippe. The nature of software: what's so special about software engineering. The Rational Edge, 2001. Disponvel em: http://www106.ibm.com/developerworks/rational/library/4700.html. Acesso em: 23/12/2004. MASI, Domenico de. O cio criativo. 1. ed. Rio de Janeiro: Sextante, 2000. 336 p. MCBREEN, Pete. Software craftsmanship: the new imperative. 1. ed. Upper Sadle River: Addison-Wesley, 2002. 187 p. POPPENDIECK, Mary; POPPENDIECK, Tom. Lean software development: an agile toolkit. 1. ed. Upper Saddle River, NJ: Addison-Wesley, 2003 PRESSMAN, Roger S. Software engineering: a practitioner's approach. 4. ed. New York: McGraw-Hill, 1997. 885 p.

179

SENGE, Peter M. A quinta disciplina: arte e prtica da organizao que aprende. 12. ed. So Paulo: Best Seller, 2002. 491 p. SMITH, Adam. A riqueza das naes: investigao sobre a sua natureza e suas causas. So Paulo: Nova Cultura, 1996. 479 p. SORID, Dan. Human error doomed Mars Climate Orbiter. Space.com, 1999. Disponvel em: http://www.space.com/news/orbiter_error_990930.html. Acesso em: 23/12/2004. TEIXEIRA, Srgio. O caador de defeitos. Exame, n. 814, 2004. TELES, Vincius Manhes. Extreme Programming: aprenda como encantar seus usurios desenvolvendo software com agilidade e alta qualidade. 1. ed. So Paulo: Novatec, 2004. 316 p. THE STANDISH GROUP INTERNATIONAL, Inc. Extreme chaos. The Standish Group International, Inc, 2001. Disponvel em: http://www.standishgroup.com/sample_research/PDFpages/extreme_chaos.pdf. Acesso em: 23/12/2004. TOFFLER, Alvin. A terceira onda: a morte do industrialismo e o nascimento de uma nova civilizao. 26. ed. Rio de Janeiro: Record, 2001. 491 p. WEINBERG, Gerald M. The psychology of computer programming. 1. ed. New York: Van Nostrand Heinhold Company, 1971. 288 p. WILLIAMS, Laurie; KESSLER, Robert. Pair programming illuminated. 1. ed. Boston, MA: Addison-Wesley, 2003. 265 p. WILLIAMS, Laurie; KESSLER, Robert; CUNNINGHAM, Ward, et al. Strengthening the case for pair programming. IEEE Software, v. 17, n. 4, 2000. p. 19-25. YOURDON, Edward. Death march. 2. ed. Upper Saddle River, NJ: Prentice Hall PTR, 2004. 230 p.