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

VINCIUS MANHES TELES

DCC-IM/UFRJ Mestrado em Informtica

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

Rio de Janeiro 2005

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

VINCIUS MANHES TELES

Dissertao submetida ao corpo docente do Instituto de Matemtica e do 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.

Prof.________________________________ Lgia Alves Barros, D.Sc

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

Rio de Janeiro 2005

ii

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.

152 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).

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 podem 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 overbudget, 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 odds 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.

1INTRODUO...............................................................................................................9

2A CRISE DO SOFTWARE ..........................................................................................11

3A NATUREZA DO SOFTWARE...............................................................................15 3.1Complexidade.............................................................................................................15 3.2Conformidade.............................................................................................................17 3.3Maleabilidade..............................................................................................................17 3.4Invisibilidade...............................................................................................................18 3.5Inexistncia de princpios bsicos............................................................................19 . 3.6Rpida evoluo tecnolgica .....................................................................................19 3.7Baixo custo de manufatura .......................................................................................20

4METFORAS DO DESENVOLVIMENTO DE SOFTWARE ..............................22 4.1A indstria de produo em massa ..........................................................................23

4.1.1Padronizao......................................................................................................................................24 4.1.2Especializao....................................................................................................................................24 4.1.3Sincronizao.....................................................................................................................................25 4.1.4Concentrao.....................................................................................................................................25 4.1.5Maximizao......................................................................................................................................26 4.1.6Centralizao.....................................................................................................................................26

ii 4.2A racionalizao do desenvolvimento de software................................................27 .

4.2.1Definir a tarefa ...................................................................................................................................30 4.2.2Qualidade...........................................................................................................................................31 4.2.3O trabalhador do conhecimento como ativo......................................................................................32 . 4.2.4Motivao..........................................................................................................................................33

4.3A produo enxuta.....................................................................................................35

4.3.1Eliminar desperdcios .........................................................................................................................36 4.3.2Amplificar o aprendizado ...................................................................................................................37 4.3.3Adiar decises ao mximo .................................................................................................................38 4.3.4Entregar o mais rapidamente possvel ................................................................................................39 4.3.5Delegar poder equipe .......................................................................................................................40 4.3.6Incorporar integridade ........................................................................................................................41 4.3.7Ver o todo..........................................................................................................................................42

5EXTREME PROGRAMMING ...................................................................................43 5.1Valores.........................................................................................................................43

5.1.1Feedback............................................................................................................................................43 5.1.2Comunicao.....................................................................................................................................45 5.1.3Simplicidade......................................................................................................................................48 5.1.4Coragem.............................................................................................................................................51

5.2Prticas........................................................................................................................55
5.2.1Cliente Presente .................................................................................................................................55 5.2.2Jogo do Planejamento .......................................................................................... ..............................57 5.2.3Stand up meeting ................................................................................................................................62 5.2.4Programao em Par............................................................ ............................................................. 65 . 5.2.5Cdigo Coletivo.................................................................................................................................74 5.2.6Cdigo Padronizado ...........................................................................................................................75 5.2.7Design Simples ..................................................................................................................................76 5.2.8Desenvolvimento Orientado a Testes................................................................................................83 . 5.2.9Refatorao........................................................................................................................................93 5.2.10Integrao Contnua .........................................................................................................................99 5.2.11Releases Curtos ..............................................................................................................................101 5.2.12Metfora.........................................................................................................................................104 5.2.13Ritmo Sustentvel.........................................................................................................................106 .

6ESTUDO DE CASO....................................................................................................110

iii 6.1Definies...................................................................................................................111 6.2Linha do Tempo.......................................................................................................116 6.3Planejamento do Projeto .........................................................................................119

6.3.1Novidade e Complexidade ...............................................................................................................120 6.3.2Tamanho da Equipe ..........................................................................................................................121 6.3.3Aprendizado do Requerente .............................................................................................................122 6.3.4Projetos Paralelos .............................................................................................................................122

6.4Plataforma Tecnolgica...........................................................................................123 6.5Anlise do Projeto....................................................................................................123

6.5.1Modelo Conceitual de Verificao de Habilidades.........................................................................123 . 6.5.2Tratamento de Mudanas no Sistema de Atletas ..............................................................................128 6.5.3Integrao com o Sistema de Condicionamento dos Atletas ............................................................130 6.5.4Cadastros.........................................................................................................................................135 6.5.5Relatrios.........................................................................................................................................139 6.5.6Histrico de Ciclos Passados ..................................................... ...................................................... 140

7CONCLUSO.............................................................................................................144

1INTRODUO
Desenvolver software uma atividade arriscada, segundo as estatsticas que vm sendo produzidas h algumas dcadas. Os maiores riscos so:

Gastos que superam o oramento Consumo de tempo que supera o cronograma Funcionalidades que no refletem as necessidades dos usurios Baixa qualidade

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. Nos ltimos anos, os desenvolvedores de sistemas assistiram criao de processos de desenvolvimento conhecidos como Processos geis. Tais processos compartilham um conjunto de premissas que, em grande parte, contrastam com a linha de atuao de outros que os precederam. Um dos principais processos que se encontram nesta categoria o Extreme Programming, criado por Kent Beck em 1997 em um projeto na Chrysler. O Extreme Programming (XP) composto por um conjunto reduzido de prticas de desenvolvimento que se organizam em torno de quatro valores bsicos. Essas prticas possuem fortes interrelacionamentos 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. 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

0 elas. Alm disso, apresentado um estudo de caso de um projeto que utilizou todas estas prticas por aproximadamente um ano. O Extreme Programming no nasceu no meio acadmico e ainda existem poucas pesquisas demonstrando a validade de sua utilizao. 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 aceitos e utilizados tanto nas universidades, quanto na indstria. Em funo da controvrsia existente em torno do Extreme Programming, optou-se por realizar uma reviso de literatura criteriosa e to embasada quanto possvel em autores e trabalhos de prestgio. Por esta razo, os primeiros captulos se utilizam intencionalmente de um grande nmero de citaes com o objetivo de apresentar bases concretas para os valores e prticas propostos pelo Extreme Programming. Inicialmente, ser apresentada uma anlise dos problemas recorrentes que esto presentes na maioria dos projetos de software h algumas dcadas. Em seguida, busca-se fazer uma anlise da natureza do desenvolvimento de software com o objetivo de compreender quais so as maiores dificuldades. O captulo seguinte procura analisar a forma como as solues para os projetos de software vm sendo organizadas ao longo do tempo. Elas se baseiam em metforas que merecem ser revisadas. O trabalho continua apresentando o Extreme Programming e o estudo de caso. O foco principal do trabalho demonstrar a importncia e o potencial do conjunto. Embora fosse possvel observar e estudar partes separadas do processo, foi feita uma opo por estudar os efeitos obtidos pelo conjunto das prticas por se acreditar que a maior contribuio do XP no est nas prticas individualmente, mas sim na forma como so organizadas em um conjunto coeso.

2A 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, 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 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.

2 O Standish Group classifica o resultado final de um projeto nas seguintes categorias: Mal sucedido (Failed); Comprometido (Challenged); e Bem sucedido (Succeeded).

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 sejam desastrosos, mostram um avano razovel em relao aos resultados do primeiro levantamento do realizado em 1994:

Figura 2.2: evoluo do resultado final de projetos de software ao longo dos anos.

Na terceira Conferncia Iternacional 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:

4 Figura 2.3: estatstica sobre a utilizao de funcionalidades.

Alm das 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 de software. 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). Ao analisar os fatores que levam tantos projetos de software a fracassarem e outros (poucos) a serem to 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?

3A NATUREZA DO SOFTW ARE

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.1Complexidade 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, entre outros elementos. Assim, medida que um sistema cresce em tamanho, cresce tambm a quantidade de partes distintas. Esse comportamento

6 difere profundamente de outras construes, tais como computadores, prdios ou automveis, nos quais se encontram elementos repetidos em abundncia. Isso faz com que os programas tenham um nmero extremamente elevado de estados. Computadores, por exemplo, so produtos bastante complexos que contm uma elevada quantidade de estados. Entretanto, softwares costumam ter ordens de magnitude mais estados que computadores. 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 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,

7 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.2Conformidade 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 ter que 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). 3.3Maleabilidade 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.

8 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, as quais 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, Hmm, 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 tende a reduzir ou eliminar completamente determinadas mudanas. 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. 3.4Invisibilidade 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, tornase 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.

9 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 poderosa 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). 3.5Inexistncia de princpios bsicos Como j vimos, o software no possui leis fundamentais como a fsica, o que dificulta bastante pensar sobre ele sem efetivamente constru-lo. Alm disso, isso significa que 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.6Rpida 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 re-comeo,

0 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.7Baixo 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. 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 e 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

1 software pode ser replicado infinitas vez fazendo uma cpia de arquivos, gerando um CD ou transferindo 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 do projeto, como 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 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.

4METFORAS DO DESENVOLVIMENTO DE SOFTWARE

H dcadas a crise do software vem inspirando estudiosos e profissionais a criarem propostas de solues para solucion-la. De um modo geral, tais solues carregam metforas que procuram lanar luz sobre a natureza do software e as possveis solues de seus problemas. 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 de desenvolvimento de software: Mais produtivos; Mais previsveis; e Com resultados de melhor qualidade.

Felizmente, outras disciplinas se depararam com esta mesma busca no passado. Algumas foram extremamente bem sucedidas, tendo alcanado os trs objetivos descritos

3 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.1A 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 Centralizao.

4 4.1.1Padronizao 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 deste sculo. 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 execut-la com ela, e um tempo estipulado (padro) no qual podia ser completada (TOFFLER, 2001, p.61). 4.1.2Especializao Em 1776, no auge da Revoluo Industrial, Adam Smith publicou um dos mais famosos e importantes livros de economia: A riqueza das naes. Logo 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 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

5
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.3Sincronizao 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.4Concentrao A concentrao (ou economia de escala) se baseia na idia de que (...) se eu compacto 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 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.

6 4.1.5Maximizao 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 e sub-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. 4.1.6Centralizao 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

7 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.2A racionalizao do desenvolvimento de software No incio deste captulo, apontamos a busca por solues que possam tornar os projetos de desenvolvimento de software mais produtivos, mais previsveis em 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, na expectativa de obter os mesmos resultados positivos? Essa observao e essa pergunta no so novas. Na verdade, trata-se de um questionamento que acompanha a indstria de software h dcadas. 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. Em janeiro de 2005, uma busca pela expresso fbrica de software no Google gerou como resultado nada menos que 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

8 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). Compreender a diferena entre trabalho manual e trabalho do conhecimento uma atividade bastante 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; 1987), De Masi (2000), Drucker (1999), Poppendieck e Poppendieck (2003) e Toffler (2001).

9 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 Mais (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; 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

0 6. Os trabalhadores do conhecimento precisam ser tratados como ativos e no como custo. Alm disso, precisam querer trabalhar para a organizao. Uma das conseqncias diretas da ltima frase de Drucker que 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 eque 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). 4.2.1Definir 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

1 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.2Qualidade 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). 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

2 sua capacidade de executar suas atividades com qualidade elevada e continuar aprendendo tanto quanto possvel medida que as executa. 4.2.3O 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 turnover, 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 trabalham, ela no porttil. Por sua vez, os trabalhadores do 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

3 longo do trabalho. Portanto, o trabalhador do conhecimento precisa ser encarado como um ativo que deve ser mantido na organizao. Se os custos de turnover so elevados para o trabalhador manual, eles so significativamente maiores para os trabalhadores do conhecimento. 4.2.4Motivao 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:
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, por outro lado, existe, se move e trabalha de uma forma diferente dos objetos do mundo real (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

4 prpria pessoa seja capaz de se motivar. Entretanto, relativamente fcil desmotivar 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 o trabalho de um trabalhador do conhecimento. Ele tem que ser o prprio responsvel pela forma como o trabalho conduzido. Alm disso, tem 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-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 diagrama de trabalhadores no nem de perto to importante quanto estabelecer quo ampla e rica so as conexes (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

5 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 orgulhar. 4.3A produo enxuta A mesma indstria automobilstica que levou a industrializao em massa s ltimas conseqncias atravs do Taylorismo foi capaz de criar algumas dcadas depois um processo de produo diferente, que parece incorporar melhor o trabalho do

conhecimento. Desta vez, ao invs da Ford, a novidade veio 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 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). A produo enxuta mencionada nesta obra por conter princpios que esto na base de processos geis de desenvolvimento de software como o Extreme Programming. Ela caracterizada por um conjunto de sete princpios bsicos (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 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 que processos de desenvolvimento de software baseado nos mesmos possam efetivamente elevar a produtividade e a qualidade dos projetos de desenvolvimento. 4.3.1Eliminar 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 500) (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 sub-produtos 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

7
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 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. Portanto, toda a produo organizada em torno da idia de aprendizado e melhoria contnua. 4.3.2Amplificar 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 elementos 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

8 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.3Adiar decises ao mximo A 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

9 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 ativamente com este conceito buscando evitar 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.4Entregar 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

0
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.5Delegar 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).

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

1 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.6Incorporar 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 e 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 medies no so substitutos adequados (POPPENDIECK & POPPENDIECK, 2003, p.xxvii, traduo nossa).

2 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.7Ver o todo Para que um software alcance integridade perceptvel e conceitual, importante que o todo seja harmnico. Portanto, no vivel que um determinado aspecto do projeto seja extremamente otimizado, enquanto outros tm comportamento diferenciado. Para atingir integridade, o equilbrio mais importante que o comportamento individual das partes envolvidas. necessrio que a equipe 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 devenvolvimento 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. Ou seja, procura-se medir o resultado final e no as componentes. Portanto, procura-se concentrar ateno no equilbrio, ao invs das partes isoladas. Alm disso, procura-se utilizar os demais princpios para estabelecer um fluxo de comunicao rico que ajude a equipe a ter a viso do todo (POPPENDIECK & POPPENDIECK, 2003).

5EXTREME PROGRAMMING
5.1Valores 5.1.1Feedback 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 extensiva entre o cliente e o designer como parte da definio do sistema (BROOKS, 1987, traduo nossa).

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

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

5 rapidamente, de modo que ele possa detectar eventuais falhas cedo, 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 feeback 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.2Comunicao 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 elaborao da mesma. 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

6
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 a tarefa de compreender a idia transmitida. 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.

7 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. 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 que, alm de

8 facilitar a comunicao, ajudam a colocar em prtica um modeloe 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 autodirecionado 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 da mesma, e no o nmero de pessoas, complica o desenvolvimento de software (EISCHEN, 2002, p.39, traduo nossa).

5.1.3Simplicidade Na Terceira Conferncia Iternacional sobre Extreme Programming, que ocorreu na Itlia em 2002, Jim Johnson, presidente do Standish Group, apresentou um estudo

9 revelador sobre a utilizao das funcionalidades em projetos 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 utilizadas, totalizando 64 por centro 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 parmetros, ao invs de recodificando partes do sistema. Alm disso, tenta antever funcionalidades que provavelmente sero 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

0 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. 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 foram solicitadas pelos usurios. Existem vantagens nesta abordagem.
(...) 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).

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 a 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).

1 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 evitas, 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, tornandoo 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 falhar (POPPENDIECK & POPPENDIECK, 2003, p.6, traduo nossa).

5.1.4Coragem

2 Como foi explicado anteriormente 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 fazem sentido; Ficar para trs 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 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

3 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 vai embora 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 equipe com base em feedback concreto: software executvel. Assim ele pode decidir se continua ou no a utilizar 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

4 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 quebrar 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 mecanismo 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 outros. Alm disso, a possibilidade de contar sempre com a ajuda imediata de um colega gera maior confiana na capacidade de resolver os desafios que so 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

5 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, por exemplo. 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 (BECK & FOWLER, 2001). 5.2Prticas 5.2.1Cliente 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 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.

6
A falta de envolvimento dos usuriostradicionalmente temsido 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 contra-propostas. Isso ir aperfeioar as prprias idias do cliente sobre como o sistema deve se parecer (COCKBURN, 2002, p.179, traduo nossa).

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

7 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.2Jogo do Planejamento Como se observou anteriormente, estatsticas demonstram que muitos projetos dedicam esforos significativos implementao de funcionalidades que no so 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 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.

8
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 exatamente 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 rapidamente 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 (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

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

0 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 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 estimar 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:

1
Define as histrias; Decide qual o valor de negcio de cada histria; e Decide que estrias sero construdas no release. Os programadores: Estimam quanto tempo ser necessrio para construir cada estria; 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 que possuam semelhanas com as futuras.
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 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 proposto por Teles (2004). Um dos principais objetivos 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

2 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. Sendo assim, no incio de uma iterao os desenvolvedores declaram, por exemplo, que o cliente poder alocar 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 as necessidades de seus usurios dentro do temp disponvel para o projeto. Alm disso, os processos de re-planejamento 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 para baixo na lista de pendncias. Entregando funcionalidades de alta prioridade primeiro, provvel que voc v entregar 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.3Stand up meeting Um projeto de desenvolvimento de software pode ser compreendido como um sistema humano composto por elementos tais como clientes, desenvolvedores, gerentes,

3 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 meeting. 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 anterior. uma forma de disseminar conhecimento e assegurar que as pessoas tenham acesso as 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. Portanto, 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

4
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. Alm disso, ela 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 um, das solue criadas, da idias colocadas em prticas e dos problemas que precisam ser tradados 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 frequncia 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.
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 5.2.4Programao 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 a 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 nossa), a oportunidade de identificar problemas cedo pode significar uma 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 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 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

7
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 abordagem 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. 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).

8
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). E 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 a para seja capaz de solucionar o lgo problema. A presena imediata de um colega que tenha conhecimentos importantes sobre o problema em questo torna o processo de aprendizado imediato. E o problema que gerou a necessidade do aprendizado faz com que o aprendiz dedique grande ateno e interesse naquilo que est sendo ensinado. Isso eleva a capacidade de absoro do que est sendo ensinado, bem como a fixao dos conceitos. E 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.
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

0 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 relevante, pois embora seja um processo de desenvolvimento simples e com pouca formalidade, um processo significativamente disciplinado.
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 refatorar e 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 eles no querem decepcionar seus parceiros (WILLIAMS & KESSLER, 2003, p.21, traduo nossa).

1
(...) 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 so distrados) 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 100 por cento de programador-hora colocando dois programadores para 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).

2
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 consert-los 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 agradvel e divertido for o trabalho de programao, mais produtivo o mesmo tender a ser.
Na pesquisa online 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 colaborativamente 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.

3
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 pessoa (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 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 a outra pessoa, j que esta pessoa poderia eventualmente usar seus ensinamentos para passar a sua frente (DEMARCO & LISTER, 1999, p.182-183, traduo nossa).

4 5.2.5Cdigo 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 qualquer coisa que for necessria (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, por diferentes desenvolvedores. Como alteraes no cdigo podem causar erros, a prtica de cdigo coletivo s pode ser adotada com segurana se a equipe realmente 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).

5 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. E quando for encontrado, algum ir tentar simplific-lo. (...) 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) .

5.2.6Cdigo 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).

6 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.7Design 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.

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.

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

8
(...) 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 adicionadas (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 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 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

9
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).

0 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 desenvolvimento

1
incremental. Em 2001, Boehm notou que para sistemas pequenos o fator de escalada pode ser algo mais do tipo 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 mantlo 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).

2 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 nos seguintes fatores: Avanos ocorridos na microinformtica; 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 lincagens 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).

3 Desenvolvedores 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 refactoring 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.8Desenvolvimento 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).

4 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 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 dificultam significativamente o andamento dos projetos de desenvolvimento de software. 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 bem rpido, mas descobrir o que o est causando um pesadelo. E 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,

5
normalmente nada bvias. Qualquer tentativa de repar-lo com o mnimo de esforo ir corrigir a parte local e bvia, mas os efeitos do 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 trainee (BROOKS, 1995, p.122, traduo nossa).

Equipes XP lidam com estes problemas utilizando uma tcnica conhecida como desenvolvimento orientado a testes. A idia 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).

6
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 implemente (POPPENDIECK & POPPENDIECK, 2003, p.146, traduo nossa). Feedback imediato importante porque evita que os defeitos passem muito tempo despercebidos. Como se observou anteriormente, depurar costuma ser custoso porque o

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

8 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 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.118119, 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, ela primeiro cria um teste que exponha o defeito e s ento o corrige. Desta forma, se protege do caso em que o 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

9
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 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.116117, 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.117-118, traduo nossa).

O processo bsico de criao de testes e implementao de funcionalidades simples. Ele se baseia nos passos descritos adiante:

0
1. 2. 3. 4. 5. Rapidamente adicione um teste; Execute todos os testes e veja o novo falhar; Faa uma pequena mudana; Execute todos os testes e veja-os funcionar; e 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 a corrigi-la 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

1 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 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 , mais difcil test-lo completamente. Mas o inverso tambm verdade: quanto mais simples um objeto ou mtodo for, mais fcil 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 quer. (...) [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).

2 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 parecem mais razoveis para resolver o problema em questo. Em princpio, tal cdigo de teste provavelmente no ser nem capaz de compilar. 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 automao dos testes um exerccio que no executado em grande parte dos projetos de

3 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.9Refatorao 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. 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

4 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. 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 radicalmente 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 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

5 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. E, 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, 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 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

6
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-timas 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 porqueo cdigo literalmente faz a mesma coisa em diversos lugares. Portanto, um importante aspecto de melhoria do design eliminar duplicao no cdigo. A importncia 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

7 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 (cdigo que no cheira bem) 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 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).

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

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 consegue responder s necessidades dos clientes tanto durante o desenvolvimento, quanto durante a vida til do sistema (POPPENDIECK & POPPENDIECK, 2003, p.144-145, traduo nossa).

9 Equipes XP acreditam que a refatorao diria 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 .
(...) 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).

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.144145, traduo nossa).

5.2.10Integrao 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 voc desenvolve, voc quer fingir que o nico programador no projeto. Voc quer marchar adiante em velocidade

00 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). Toda vez que um par integra seu cdigo, existe o risco de que identifique um erro na integrao. Ou seja, existe a chance, por exemplo, de que dois pares distintos tenham efetuado alteraes conflitantes na mesma parte do cdigo.
O esforo necessrio para resolver as colises no pode ser muito grande. Isso no um problema. O refactoring constante tem o efeito de quebrar o sistema em muitos objetos e mtodos pequenos. Isso reduz as chances de que dois pares de programadores mudem amesma 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 se 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 muito 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

01 coisas podem falhar. Portanto, o tempo para corrigir eventuais problemas tende a ser pequeno (POPPENDIECK & POPPENDIECK, 2003).
Builds 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 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.11Releases 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.

02 Neste sentido, trabalha com a prtica de releases curtos. Essa prtica 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).

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. Espera-se, naturalmente, que o software produzido gere um valor superior ao 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

03 e particularmente se continua ou no investindo naquela equipe de projeto. 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 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).

04

5.2.12Metfora 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. 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 metforas 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:

05
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.231232, traduo nossa).

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

06 5.2.13Ritmo 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. O XP, por sua vez, evita as duas abordagens utilizando a prtica de ritmo sustentvel. Em sntese, recomenda-se que as pessoas 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). Em 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).

07 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, 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 dar uma acelerada 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

08
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, na prtica, horaextra 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,

09 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).
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).

10

6ESTUDO DE CASO
Por se tratarem de informaes confidenciais, as informaes especficas sobre as caractersticas do sistema no sero apresentadas. Ao invs disso, usaremos algumas metforas com o objetivo de descrever caractersticas do projeto sem apresentar o escopo real do mesmo, nem suas particularidades, mas mostrando a influncia do Extreme Programming sobre sua conduo. Sendo assim, todos a maior parte dos nomes utilizados deste ponto em diante ser fictcia, embora a metfora tenha sido escolhida de modo a estabelecer uma relao prxima com as caractersticas reais do projeto.. O cliente deste projeto o Comit Olmpico de Mato Grosso do Norte (um novo estado fictcio do Brasil). Ele cuida dos atletas deste recm-criado estado e busca aprimor-los para que tenham excelente desempenho nos jogos olmpicos. A equipe de desenvolvimento foi contratada para implementar o Sistema de Verificao e Planejamento de Condicionamento dos Atletas, o qual dever trabalhar em conjunto com o Sistema de Condicionamento dos Atletas dentro do Portal de Aperfeioamento Esportivo. O Sistema de Verificao e Planejamento de Condicionamento dos Atletas usado anualmente para fazer um levantamento das habilidades dos atletas. Neste levantamento, cada equipe esportiva define um conjunto de nveis de proficincia esperados para cada habilidade de seus atletas. Para cada atleta, observa-se as habilidades deficientes, faz-se uma priorizao e gera-se um Plano de Condicionamento que indica os exerccios que o atleta deve fazer no ano seguinte para aprimorar tais habilidades. Para que os exerccios possam ser efetuados e controlados, existe o Sistema de Condicionamento dos Atletas. Trata-se de um sistema que armazena e gerencia diversos tipos de exerccios.

11 importante que os dois sistemas se comuniquem de modo que os exerccios colocados no plano de condicionamento de um atleta em um dado ano sejam cadastrados no Sistema de Condicionamento dos Atletas. Alm disso, os exerccios efetivamente realizados so informados para o Sistema de Verificao e Planejamento de Condicionamento dos Atletas, para que passem a fazer parte do boletim de exerccios do atleta. Este estudo de caso trata do desenvolvimento do Sistema de Verificao e Planejamento de Condicionamento dos Atletas, doravante denominado apenas de Sistema de Verificao. O Sistema de Condicionamento dos Atletas foi implementado em outro projeto que foi executado em paralelo ao projeto do Sistema de Verificao. O projeto do Sistema de Verificao teve incio em 1992 (o ano tambm fictcio), quando o Cliente iniciou estudos internos para levantar as necessidades do projeto e dedicou esforos na busca de um sistema que j estivesse pronto no mercado e pudesse ser adquirido. Como no foi possvel encontr-lo, se decidiu iniciar um projeto para implementao do mesmo utilizando um fornecedor externo. No final de 1992 o fornecedor foi contratado e em fevereiro de 1993 o projeto teve incio e durou at abril de 1994. Com o objetivo de facilitar a compreenso de todas as partes envolvidas no projeto, a prxima seo ir apresentar um conjunto de definies e a seo seguinte a cronologia do projeto. 6.1Definies Definio de Organizaes: Cliente Organizao para a qual foi desenvolvido o Sistema de Verificao.

12 Suporte de Sistemas Empresa terceirizada, responsvel pela manuteno de todos os sistemas de informao do Cliente. Suporte de Infra-estrutura Empresa terceirizada, responsvel pela manuteno de toda a infra-estrutura de hardware, rede e

telecomunicaes do Cliente. Suporte do Sistema de Condicionamento Empresa responsvel pela implantao do Sistema de Condicionamento do Cliente. Consrcio Grupo formado por duas empresas que foram responsveis, em conjunto, pela execuo do projeto do Sistema de Verificao. Fornecedor de TI Empresa integrante do Consrcio, responsvel pela execuo das atividades de Tecnologia de Informao, em particular a implementao do Sistema de Verificao. Fornecedor Esportivo Empresa integrante do Consrcio, responsvel pela consultoria na rea esportiva.

Definio de Papis: Cliente o Diretor de Esportes Pessoa responsvel pela rea de Esportes. Sua participao na definio conceitual do sistema foi pequena, embora ele tivesse a mxima autoridade para decidir o que deveria ou no ser contemplado e, como deveria ser implementado. o Gerente de Esportes Sua participao foi ativa, embora um tanto limitada, ao longo de todo o projeto. A limitao teve como origem o excesso de atribuies deste gerente, o que dificultava a alocao de tempo para os assuntos referentes ao projeto. O Gerente de

13 Esportes possua elevada autoridade para decidir os aspectos conceituais do projeto. Entretanto, em algumas ocasies suas decises foram alteradas por determinao do Diretor de Esportes. o Requerente Pessoa diretamente subordinada ao Gerente de Esportes. O Requerente teve participao ativa e diria em todos os aspectos do projeto. Trata-se da pessoa ligada ao Cliente que teve maior participao e interao com a equipe do Consrcio. O Requerente era responsvel pelas definies conceituais do sistema e pelo acompanhamento dirio das atividades de desenvolvimento. Possua relativa autoridade sobre as definies conceituais, mas freqentemente necessitava da autorizao do Gerente de Esportes ou do Diretor de Esportes. o Requerente de TI Pessoa com cargo de Analista de Sistemas que acompanhou todo o projeto e foi responsvel por providenciar todos os recursos necessrios da rea de Tecnologia de Informao do Cliente. Alm disso, era responsvel pelas definies conceituais do projeto referentes ao uso da tecnologia, acesso a sistemas legados, padres tcnicos, definio de plataforma tecnolgica, acessos a bancos de dados, servidores e sistemas remotos, entre outros assuntos. Tambm era responsvel pela mediao entre a equipe do Consrcio e a Equipe de Suporte de Sistemas, Suporte de Infra-estrutura e Suporte do Sistema de Condicionamento. Suporte de Sistemas

14 o Analista do Suporte de Sistemas Pessoa responsvel por auxiliar a equipe do Consrcio em todos as relaes do projeto com sistemas legados do Cliente, bem como procedimentos padres adotados na manuteno dos sistemas. o DBA Pessoa responsvel pela manuteno das bases de dados do Cliente. Suporte de Infra-estrutura o Analista do Suporte de Infra-estrutura Pessoa responsvel por manter os servidores funcionando, bem como a infra-estrutura lgica dos servidores, isto , sistemas operacionais, servidores de aplicao, pacotes de melhorias de desempenho, entre outros. Suporte do Sistema de Condicionamento o Analista do Suporte do Sistema de Condicionamento Pessoa responsvel por manter o Sistema de Condicionamento

funcionando corretamente no Cliente e na localidade de desenvolvimento, onde a equipe do Consrcio se mantinha reunida implementando o Sistema de Verificao. Alm disso, era responsvel pela implementao da API de Integrao que permitia que o Sistema de Verificao fosse capaz de se comunicar com o Sistema de Condicionamento. Fornecedor de TI o Gerente de Projeto Pessoa responsvel por toda a equipe do Consrcio. Ele atuava nos aspectos administrativos do projeto e tinha como principais atribuies assegurar que todos os envolvidos se comunicassem de forma adequada e manter uma

15 agenda de encontros freqentes com pessoas do Cliente, especialmente o Requerente. o Analista de Testes Pessoa responsvel pela preparao dos planos de teste que eram executados a cada iterao para validar as funcionalidades que iam sendo geradas. Com o passar do tempo, toda a equipe do Consrcio passou a se envolver na elaborao dos planos de teste. Porm, alm da preparao do plano de testes, este profissional tambm era responsvel por execut-lo, uma vez que as funcionalidades ficavam prontas. o Redator Tcnico Pessoa responsvel por escrever e manter atualizada a maior parte das documentaes do projeto. o Coach Pessoa tecnicamente responsvel pelo projeto. Treinou todos os envolvidos no projeto nas prticas e valores do Extreme Programming. Alm disso, atuou permanentemente assegurando o cumprimento das prticas e auxiliando a equipe em aspectos tcnicos do projeto. o Desenvolvedor Profissional com pelo menos quatro anos de experincia em desenvolvimento de softwares corporativos, com pleno conhecimento da plataforma tecnolgica e plenamente habilitado a fazer anlise e modelagem de sistemas orientados a objetos. Havia quatro pessoas representando este papel no projeto. Fornecedor Esportivo o Consultor de Esportes Profissional da rea de esportes que tinha a responsabilidade de auxiliar o Requerente nas definies

16 conceituais do sistema. A sua participao foi parcial nos primeiros dois teros do projeto e esteve ausente no ltimo tero. Definio de Sistemas: Sistema de Verificao Trata-se do Sistema de Verificao e Planejamento do Condicionamento dos Atletas. Como j foi explicado anteriormente, o projeto que deu origem a este sistema o foco deste estudo de caso. Sistema de Condicionamento dos Atletas Tem o objetivo de controlar todos os exerccios oferecidos aos atletas do Cliente. O Sistema de Condicionamento dos Atletas se baseou em um pacote de software adquirido de uma empresa estrangeira. As caractersticas e

funcionalidades deste pacote foram personalizadas para as necessidades especficas do Cliente. O projeto de instalao e personalizao deste pacote ocorreu em paralelo ao projeto do Sistema de Verificao. Sistema de Atletas Armazena todas as informaes sobre os atletas do Cliente, incluindo itens tais como equipe esportiva em que atua, que tipo de modalidades em que compete, entre outras. O Sistema de Verificao depende fortemente de informaes do Sistema de Atletas, pois seu comportamento est diretamente atrelado s caractersticas de cada atleta. Por exemplo, para atletas amadores, existe um comportamento completamente diferente daquele relegado aos profissionais. 6.2Linha do Tempo O projeto de desenvolvimento do Sistema de Verificao comeou a ser tratado dentro do Cliente no incio de 1992. Em novembro de 1992 foi realizado um workshop

17 envolvendo diversas pessoas da rea de Esportes e Tecnologia da Informao do Cliente e integrantes da equipe do Consrcio que seria responsvel posteriormente pela execuo do projeto. O workshop foi utilizado para fazer um levantamento detalhado dos requisitos a serem considerados no projeto. Alm disso, serviu como forma de apresentar equipe do Consrcio todos os detalhes do projeto e promoveu um espao aberto para discusses e sugestes sobre os requisitos. Ao final do workshop, a equipe do Consrcio gerou um relatrio que serviu como base para a contratao do projeto de implementao do sistema. Aps o workshop, o Cliente iniciou a busca por uma empresa ou consrcio de empresas que pudesse se responsabilizar pela implementao do sistema. Essa busca consumiu alguns meses e a deciso final sobre o fornecedor foi alcanada na metade do ms de janeiro de 1993. Como j foi mencionado no pargrafo anterior, o Consrcio de empresas que participou do workshop acabou vencendo a concorrncia e foi contratado para executar o projeto. O Consrcio fez a proposta de utilizar o Extreme Programming (XP) neste projeto. Isso gerou uma diviso dentro do Cliente, visto que em princpio a rea de Esportes apoiava seu uso, enquanto a rea de Tecnologia da Informao (TI) no o aprovava. O grupo de Esportes tinha a percepo de que o XP permitiria maior participao do requerente. Por sua vez, o grupo de TI via a maior participao do requerente como um risco, visto que ele poderia fazer freqentes alteraes no escopo do projeto e, eventualmente, dificultar o cumprimento dos prazos e do oramento. Alm disso, o XP no se enquadrava dentro dos padres utilizados na rea de TI para a criao de sistemas.

18 Diante deste dilema, o Consrcio apresentou duas propostas distintas, embora ambas envolvessem a utilizao do Extreme Programming. Em uma foi oferecido um modelo de contrato de escopo fixo, isto , com escopo, prazo e custo fixados. J na outra, o Consrcio ofereceu um contrato de escopo priorizvel, que normalmente recomendado para projetos em XP. Este contrato fixa prazo e custo, mas permite alteraes no escopo de acordo com priorizaes feitas ao longo do projeto. O contrato de escopo fixo tende a ser mais arriscado para a empresa ou consrcio contratado, visto que existe um risco substancial de no se conseguir implementar o escopo fixado dentro do prazo e custo fixados. Em funo disso, comum que tais contratos cobrem valores mais elevados para remunerar o risco. Contratos de escopo priorizvel, por sua vez, so menos arriscados, exatamente por no fixarem o escopo. No caso deste projeto, a proposta de contrato de escopo fixo tinha valor significativamente superior proposta de escopo priorizvel. Essa foi uma das razes que levaram o Cliente a optar pelo contrato de escopo priorizvel e a utilizao do Extreme Programming. O projeto teve incio em fevereiro de 1993 com uma reunio inaugural nas dependncias do Cliente. Nesta ocasio, a equipe do Consrcio fez uma apresentao detalhada das prticas do XP para todos os presentes e explicou como seria a dinmica de trabalho ao longo do projeto. O Consrcio optou pela utilizao de iteraes de duas semanas, as quais teriam incio sempre em uma tera-feira e seriam concludas sempre em uma segunda-feira, quatorze dias aps o incio da iterao. A opo de finalizar as iteraes s segundasfeiras e iniciar a iterao seguinte nas teras resultou da necessidade de deslocamento de alguns participantes do projeto que precisavam vir de outras cidades nos dias das reunies. Da a opo por utilizar dois dias consecutivos da semana para reduzir custos com hospedagem e deslocamento areo.

19 O projeto contou com um total de vinte e sete iteraes. Portanto, comeou em fevereiro de 1993 e foi encerrado em maro de 1994. 6.3Planejamento do Projeto A definio inicial do escopo do projeto pode ser encontrada em dois documentos que o antecedem: o Relatrio Final do Workshop e a RFP (Request For Proposals). O primeiro contm um maior detalhamento sobre as necessidades do projeto, enquanto o ltimo basicamente resume o primeiro, alm de abordar os aspectos comerciais da contratao. Originalmente, o projeto envolvia a construo de dois sistemas: Sistema de Verificao e Planejamento do Condicionamento dos Atletas Sistema de Seleo de Novos Atletas

O Sistema de Verificao j foi comentado anteriormente e ser mais detalhado em outras sees deste captulo. O Sistema de Seleo de Novos Atletas, por sua vez, representa uma necessidade do Cliente que acabou no sendo atendida neste projeto. Ao longo das negociaes do contrato, o Cliente determinou que o prazo total do projeto deveria ser de nove meses, no mximo. Inicialmente, deveria ser implementado o Sistema de Verificao, a ser inaugurado em junho de 2003 e posteriormente o Sistema de Seleo de Novos Atletas, a ser inaugurado em setembro de 2003. Tais prazos eram bastante audaciosos e todas as partes envolvidas tinham conscincia da dificuldade de cumpri-los para a construo de sistemas to complexos. A razo dos prazos tinha relao com o cumprimento de metas definidas na diretoria qual estava subordinada a rea de Esportes do Cliente. Portanto, os prazos no refletiam consideraes tcnicas de viabilidade de execuo do projeto, mas sim determinaes internas associadas ao planejamento interno do Cliente.

20 A equipe do Consrcio, ao sugerir a utilizao de um contrato de escopo priorizvel, se eximiu da imposio de entregar todo o escopo (de ambos os sistemas) dentro dos prazos definidos. Ao invs disso, se comprometeu a entregar o que fosse mais prioritrio e coubesse dentro de cada prazo estabelecido pelo Cliente, que optou por aceitar a proposta, especialmente por razes econmicas, como mencionado anteriormente. O projeto comeou dedicando esforos exclusivamente ao Sistema de Verificao e aps alguns meses ficou claro que no seria possvel entregar ambos os sistemas. Por fim, o projeto inteiro acabou sendo direcionado exclusivamente para o Sistema de Verificao. Diversas razes podem ser apontadas na tentativa de compreender o que inviabilizou a implementao de ambos os sistemas. Dentre elas, merecem destaque as seguintes: Novidade e Complexidade Tamanho da Equipe Aprendizado do Requerente Projetos Paralelos

6.3.1Novidade e Complexidade O conceito de Portal de Aperfeioamento Esportivo no novo no Brasil e o Cliente deste projeto no foi o primeiro a adotar solues nesta rea. Entretanto, foi uma das primeiras organizaes brasileiras a incorporar seriamente o tratamento de habilidades especficas dentro de seu Portal de Aperfeioamento Esportivo. Uma habilidade especfica em futebol, por exemplo, pode ser chute a gol. J em vlei, pode ser bloqueio. Cada esporte tem um conjunto particular de habilidades especficas. O tratamento de habilidades especficas um assunto complexo porque:

21 Para cada atleta, preciso definir claramente o esporte e a categoria em que atua, de modo a identificar seu perfil esportivo e, conseqentemente, as habilidades especficas nas quais deve ser verificado; necessrio mapear todas as habilidades especficas do pblico alvo do sistema; e Torna-se necessrio indicar o nvel de proficincia esperada de cada habilidade especfica em cada esporte em que ela utilizada. No caso do Cliente deste projeto, o problema ainda mais grave por se tratar do comit olmpico de um estado grande, com atletas atuando em diversos esportes diferentes. Isso faz com que o universo de habilidades especficas seja extremamente vasto. Antes de iniciar este projeto, o Cliente fez inmeros levantamentos no Brasil e no exterior na tentativa de localizar um software que j fizesse isso, mesmo que fosse proprietrio. Tal software no foi encontrado, o que faz com que o resultado deste projeto possa ser avaliado como indito, ao menos para os participantes dele. O fato de ser indito torna o trabalho mais complicado em funo da existncia de muitos fatores e riscos desconhecidos. Isso leva a uma chance alta de alteraes no escopo ao longo do projeto, como de fato acabou acontecendo. 6.3.2Tamanho da Equipe A equipe de desenvolvimento contou apenas com quatro desenvolvedores e um coach. Todos eles possuam bastante experincia na plataforma tecnologia e na utilizao da orientao a objetos em sistemas corporativos de porte elevado. Entretanto, o nmero de pessoas se revelou pequeno diante da quantidade de trabalho.

22 6.3.3Aprendizado do Requerente Em funo de o projeto ter um carter indito e uma complexidade elevada, diversas alteraes foram efetuadas no escopo doSistema de Verificao. Algumas delas tratavam de aspectos conceituais e outras da forma de implementar as funcionalidades originalmente previstas. Grande parte das funcionalidades previstas no escopo original permaneceu presente at o final do projeto e eventualmente acabou sendo implementada. Entretanto diversos aspectos conceituais sofreram alteraes significativas em funo do aprendizado do Requerente ao longo do projeto. Alm das alteraes conceituais, observou-se um constante fluxo de mudanas relativas aos aspectos visuais, estticos e de interface de uso. Com o passar do tempo, a maior compreenso do sistema fez com que tais elementos fossem alterados diversas vezes com o objetivo de tornar o sistema mais simples e claro para seus futuros usurios. Conforme ser apresentado nas prximas sees, o modelo conceitual de verificao das habilidades, bem como o de montagem dos planos de condicionamento, evoluiu fortemente ao longo do projeto. Isso gerou diversos pontos de re-trabalho e, portanto, mais demora para atingir os prazos inicialmente estabelecidos. Este foi um dos fatores que colaborou para que, em determinado ponto, o Sistema de Seleo de Novos Atletas fosse completamente descartado e delegado a outro projeto no futuro. 6.3.4Projetos Paralelos O projeto do Sistema de Verificao tinha forte dependncia com outros projetos que estavam sendo executados em paralelo, no mesmo perodo de tempo: Projeto de Implantao do Sistema de Condicionamento dos Atletas Projeto de Implantao dos Servidores

23 Em diversos momentos, o projeto do Sistema de Verificao foi afetado negativamente por atrasos ocorridos nos projetos citados acima. Em especial, vale destacar o Projeto de Implantao dos Servidores, que lidava com a instalao e configurao dos ambientes de testes e produo. Houve atrasos sucessivos na liberao destes ambientes, bem como instabilidades nos mesmos aps terem sido instalados. 6.4Plataforma Tecnolgica O Sistema de Verificao foi desenvolvido sobre a plataforma Java J2EE. 6.5Anlise do Projeto As sees subseqentes apresentam uma anlise detalhada de alguns dos acontecimentos que marcaram o projeto e demonstram na prtica a adequao da proposta desta dissertao, ao menos no contexto deste estudo de caso em particular. informaes foram divididas em diferentes assuntos. 6.5.1Modelo Conceitual de Verificao de Habilidades Na reunio inaugural do projeto, foram discutidos diversos assuntos entre a equipe de desenvolvimento e representantes do Cliente. Em especial, a ata desta reunio revela que o Gerente de Esportes e sua equipe haviam feito uma reviso completa do relatrio do workshop, o qual continha as funcionalidades a serem desenvolvidas no projeto. Segundo ele, o relatrio estava completo e todas as definies conceituais estavam corretas e finalizadas. Alguns dias depois, foi feita a reunio de planejamento da primeira iterao que, na prtica, acabou consumindo dois dias. Durante essa reunio, o Requerente escreveu cartes contendo as estrias que deveriam ser implementadas, de acordo com a orientao do processo de desenvolvimento adotado, o Extreme Programming. O contedo dos cartes se baseava, naturalmente, no texto do relatrio do workshop. As

24 Depois de escrever estrias sobre todos os aspectos 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 os cartes e rediscutir em detalhes cada uma das estrias. Os desenvolvedores no conheciam os requisitos do projeto at ento. Portanto, o Requerente no apenas escreveu estrias, como tambm explicou cada uma delas diversas vezes para os desenvolvedores. Isso se foi interessante, porque os desenvolvedores 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 Cliente obtiveram um grande volume de feedback por parte dos desenvolvedores e todos aprenderam mais sobre as funcionalidades. A partir das discusses, vrios detalhes foram esclarecidos pelo Requerente, o qual priorizou um conjunto de estrias para a primeira iterao. Tais estrias envolviam os aspectos essenciais dos processos de verificao de habilidades especficas e no-especficas. Cada tipo de habilidade tinha um modelo prprio de verificao e coube aos desenvolvedores implementar os dois modelos logo na primeira iterao.

25 A priorizao do Requerente no foi a mais intuitiva do ponto de vista tcnico, pois inseria j na primeira iterao funcionalidades que dependiam de dados que ainda no existiam, pois nem sequer se tinha ainda funcionalidades para o cadastramento destas informaes. Para resolver esse problema, a equipe criou eventuais tabelas que fossem necessrias e as preencheu diretamente com dados falsos que pudessem ser utilizados logo no processo de verificao, tais como habilidades (especficas e no-especficas), modalidades esportivas, atletas, entre outras entidades. Fazendo isso, a equipe viabilizou a implementao das funcionalidades consideradas mais prioritrias, de modo que o Requerente pudesse receber feedback rpido sobre as mesmas. Ao final da iterao, aconteceu uma reunio de encerramento com a presena do Requerente. A equipe de desenvolvimento conseguiu implementar todas as estrias acordadas e apresentou o sistema para o Requerente, que se mostrou satisfeito com o trabalho e o resultado final. Avaliando o sistema cuidadosamente, o Requerente se deu conta de diversos detalhes que no haviam sido previstos inicialmente, mas que diante da possibilidade de uso do sistema, ficavam bastante evidentes. Tais detalhes foram listados por ele, que solicitou mudanas para a equipe de desenvolvimento. Alm dos detalhes de implementao, o Requerente percebeu um problema ainda mais srio. Embora o modelo conceitual de verificao de habilidades tivesse sido implementado tal como foi determinado, utilizando o sistema o Requerente notou que havia equvocos neste modelo, os quais colocariam o sistema em risco se no fossem tratados. Inicialmente, o Requerente no sabia que solues deveriam ser implementadas para corrigir o modelo conceitual, sendo assim levou a discusso de volta para o Cliente, de modo que pudesse ser debatida por toda a equipe de Esportes. E para que a equipe de

26 desenvolvimento no ficasse sem trabalho na iterao seguinte, o Requerente priorizou algumas estrias menos importantes. Dentro do Cliente, os problemas do modelo conceitual comearam a ser debatidos entre esportistas espalhados por diversas cidades do estado. De um modo geral, todos perceberam os problemas apontados pelo Requerente, cuja identificao s foi possvel graas ao uso do sistema. Como o assunto no tinha solues triviais, a discusso se alongou por um tempo bem 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 estrias menos prioritrias. 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. Por fim, a quinta e sexta iterao acabaram sendo utilizadas para implementar o novo modelo conceitual que acabou se revelando bem mais coerente e parecia solucionar de forma eficiente a necessidade do Cliente.

27 Este episdio gerou um atraso significativo em relao ao cronograma planejado no incio do projeto. Apesar disso, 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, ao longo das primeiras seis iteraes o Requerente teve a oportunidade de receber feedback concreto atravs do uso do sistema. Isso foi essencial para revelar falhas do modelo e levou o Cliente a corrigi-lo e aprimor-lo significativamente. Isso fez diferena no resultado final do sistema por tornar a verificao de habilidades mais intuitiva para os atletas, tal como ser mostrado mais adiante neste estudo de caso. O episdio descrito nesta seo demonstra a importncia da utilizao de iteraes curtas e feedback rpido, especialmente no caso deste projeto onde os requisitos eram inovadores e o Requerente no possua profunda experincia sobre o domnio do problema. 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. Toda vez que o Requerente avanava nas definies conceituais, as mesmas eram apresentadas para a equipe de desenvolvimento. Isso permitiu a realizao de inmeros debates sobre o novo modelo conceitual, muito antes de comear o seu desenvolvimento. Nestes debates, mais uma vez os desenvolvedores tiveram papel importante ao identificar aspectos que passavam despercebidos para o Requerente. Para se ter uma idia, em determinado momento da quarta iterao, o Requerente passou quase trs dias inteiros discutindo e aprimorando o modelo conceitual com os desenvolvedores. A

28 quantidade de itens discutidos e acertados foi enorme. 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.2Tratamento de Mudanas no Sistema de Atletas O funcionamento do Sistema de Verificao possui uma profunda dependncia das informaes do Sistema de Atletas do Cliente. Por exemplo, para fazer uma verificao, o Sistema de Verificao precisa identificar em que esporte ele atual e em qual modalidade. Essas informaes so essenciais para determinar que habilidades especficas sero apresentadas para o atleta. Por sua vez, para avaliar um integrante da equipe de um determinado treinador, o Sistema de Verificao precisa buscar no Sistema de Atletas quais so os atletas de um determinado treinador. Na dcima iterao, logo aps a realizao de um piloto que contou com a participao de 80 atletas, foi detectada uma falha no sistema quando um atleta muda de modalidade, enquanto a sua verificao ainda no havia sido finalizada. Uma verificao pode levar dias, ou at semanas, visto que o ciclo completo envolve aes do atleta e do seu treinador. Algumas executadas dentro do sistema, outras no. 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 inmeras discusses e estudos, todos notaram que o problema realmente poderia ocorrer com freqncia toda vez que um atleta mudasse de modalidade (sendo 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.

29 Em um primeiro momento, nem a equipe de desenvolvimento, nem o Requerente conseguiram propor uma soluo para esta questo. Sendo assim, ela foi registrada e levada para discusso interna no Cliente. Nada foi feito a este respeito, nem na dcima, nem na dcima primeira iterao. J na dcima segunda iterao, a equipe de desenvolvimento realizou inmeros testes para identificar os problemas que as mudanas no Sistema de Atletas poderiam acarretar nas funcionalidades do Sistema de Verificao desenvolvidas at aquele momento. Esse mapeamento foi repassado para o Cliente, 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 ele, a soluo foi implementada antes do sistema entrar em produo. Uma vez em produo, a soluo provou que funcionava, mas era ineficiente tamanha a quantidade de ocorrncias do problema no perodo reservado para o ciclo. Em funo disso, o Requerente aprimorou a soluo e solicitou que a mesma fosse implementada na vigsima quarta iterao do projeto, j bem prximo do seu fim. Esta ltima provou-se 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 mencionados na RFP do projeto. Portanto, no faziam parte do escopo original, inclusive porque jamais haviam sido previstos. Apesar

30 disso, trata-se de um problema srio que, segundo o Requerente, poderia ter tornado o Sistema de Verificao quase 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 necessidades de seus usurios. Tambm deixa claro a importncia de flexibilizar o escopo, de modo que os usurios e a equipe de desenvolvimento possam incorporar o aprendizado no software ao longo de todo o projeto. 6.5.3Integrao com o Sistema de Condicionamento dos Atletas Quando um atleta termina de fazer a sua verificao pessoa e o seu treinador termina de verific-lo, inicia-se a preparao do Plano de Condicionamento. Trata-se de um planejamento dos exerccios sero oferecidos ao atleta no ano que se inicia, com o intuito de melhorar a sua proficincia em habilidades especficas e no-especficas que tenham sido priorizadas. Ao final do processo de verificao, comum o atleta encontrar uma ou mais habilidades nas quais o seu nvel encontra-se aqum do desejado. Quando isso acontece, o seu treinador prioriza as habilidades mais crticas. A montagem do Plano de Condicionamento envolve a escolha de exerccios que estejam associados diretamente s habilidades que foram priorizadas. Enquanto o Sistema de Verificao cuida da verificao de habilidades e da gerao do plano de condicionamento, o Sistema de Condicionamento faz a gesto dos exerccios disponibilizados para os atletas. Portanto, necessria a integrao entre estes dois sistemas para elaborar o plano de condicionamento de maneira completa. A integrao entre o Sistema de Verificao e o Sistema de Condicionamento j era prevista desde o incio do projeto. Entretanto, os trabalhos referentes a esta parte no

31 comearam desde o incio. Nas primeiras sete iteraes, a equipe de desenvolvimento no implementou nenhuma funcionalidade que tivesse relao com o sistema de condicionamento. Neste primeiro momento, a verificao de habilidades foi priorizada em detrimento do plano de condicionamento. 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 condicionamento 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 funcionalidades de cada iterao. Com isso, aguardou at a oitava iterao para iniciar os trabalhos relativos integrao com o sistema de condicionamento. As primeiras funcionalidades relativas ao Plano de Condicionamento comearam a ser implementadas na oitava iterao, quando o modelo conceitual de verificao de habilidades especficas e no especficas j se encontrava mais estvel. Isso beneficiou a implementao do plano de condicionamento, pois durante as discusses sobre o modelo de verificao de habilidades, o Requerente identificou e tratou de diversos pontos importantes sobre o modelo de gerao do plano de condicionamento. O feedback obtido pelo Requerente em cada iterao facilitou a elaborao e o refinamento do modelo conceitual de gerao do plano de condicionamento. 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 o Suporte do Sistema de Condicionamento j estudava a possibilidade de implantar uma verso do Sistema de Condicionamento no escritrio da equipe de desenvolvimento.

32 Na nona iterao, a equipe de desenvolvimento ainda no conhecia o Sistema de Condicionamento, pois no tinha acesso ao mesmo. Para contornar este problema, seria necessrio ter acesso ao Sistema de Condicionamento instalado n Cliente ou instalar uma o cpia do mesmo no escritrio da Equipe de Desenvolvimento. Em funo de restries de segurana do Cliente, a segunda opo foi adotada. Mas, infelizmente o Sistema de Condicionamento 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 falsos que simulam o comportamento de objetos reais). Cada funcionalidade que envolvia acesso ao Sistema de Condicionamento utilizava uma interface que simulava o acesso ao mesmo, sempre fornecendo as respostas corretas. Desta forma, mais a frente, a implementao desta interface seria substituda pelo acesso real ao Sistema de Condicionamento. Atravs da simulao do acesso ao Sistema de Condicionamento, a equipe de desenvolvimento contornou a ausncia do mesmo e permitiu que o Requerente recebesse feedback rpido sobre as funcionalidades do plano de condicionamento. Isso foi importante, porque permitiu que inmeros refinamentos fossem feitos, muito antes de ter a integrao efetivamente operando. O Sistema de Condicionamento um sistema que foi adquirido de uma empresa terceirizada pelo Cliente. Durante o projeto de implementao do Sistema de Verificao, o Sistema de Condicionamento estava sendo instalado e personalizado por esta empresa terceirizada, qual chamada aqui de Suporte do Sistema de Condicionamento. A equipe do Suporte do Sistema de Condicionamento no trabalhava fisicamente prxima equipe de desenvolvimento do Sistema de Verificao. Sendo assim, a comunicao entre seus membros era feita basicamente atravs de telefone ou e-mail,

33 embora tenham ocorrido tambm algumas poucas reunies presenciais ao longo do projeto. Entretanto, nas poucas vezes em que elas ocorreram, no envolveram todos os desenvolvedores do Sistema de Verificao, apenas alguns deles. 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. Por exemplo, em alguns momentos o Suporte do Sistema de Condicionamento implementou coisas incorretas na API de integrao. Alm disso, a distncia fsica levou a diversas dificuldades de sincronizao entre as equipes, pois freqentemente as requisies da equipe do Sistema de Verificao no eram atendidas a tempo, ou ficavam sem resposta por bastante tempo. No incio da dcima quarta iterao, enquanto ainda havia diversas funcionalidades a serem implementadas que dependiam da integrao com o Sistema de Condicionamento, a equipe de desenvolvimento do Sistema Verificao foi informada que o contrato entre o Cliente e o Suporte do Sistema de Condicionamento estava prestes a terminar. Sendo assim, era necessrio planejar da forma mais precisa possvel quais seriam as necessidades de integrao pendentes para que o Suporte do Sistema de Condicionamento pudesse adicionar itens na API de integrao para viabilizar a mesma. Essa situao foi bastante desconfortvel 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 parecia bastante difcil e preocupante. Embora a equipe de desenvolvimento j pudesse contar com o Sistema de Condicionamento instalado em seu escritrio a partir de certo ponto do projeto, existiam diferenas entre o que estava instalado no Cliente e no escritrio da equipe de desenvolvimento. O Suporte Sistema de Condicionamento implementou diversas configuraes personalizadas na instalao do Cliente. Infelizmente, tais configuraes

34 demoravam a ser instaladas na verso que estava sendo usada no escritrio da equipe de desenvolvimento do Sistema de Verificao. 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 dcimaquinta. No incio da dcima-sexta iterao o Requerente percebeu a necessidade de fazer uma pequena alterao no processo de finalizao da preparao do plano de condicionamento. Entretanto, tal mudana envolvia mudanas na API de integrao com o Sistema de Condicionamento, o que tornou-a invivel, visto que o contrato entre o Cliente e o Suporte do Sistema de Condicionamento 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 mal funcionamento do Sistema de Condicionamento e no teve acesso ao seu suporte. Por conta disso, fez-se necessrio reinstalar o Sistema de Condicionamento e o cliente teve de estender o contrato com o Suporte do Sistema de Condicionamento. 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 Condicionamento. Na dcima nona iterao foi identificado um problema de lentido na integrao. Nesta iterao, finalmente se conseguiu mais ajuda do Suporte do Sistema de Condicionamento. Em funo dos problemas que ocorreram com o Sistema de Condicionamento, no foi possvel colocar em produo as funcionalidades de gerao do Plano de Condicionamento, o que desagradou bastante o Requerente. Ao final da dcima nona iterao o desempenho da integrao ainda era insatisfatrio. Um dos problemas que a

35 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 desenvolvida pelo Suporte do Sistema de Condicionamento caia drasticamente. Na vigsima iterao a integrao ficou estvel e as funcionalidades do Plano de Condicionamento 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 Condicionamento. A equipe mostrou que isso implicaria em mudanas na API de integrao. Sendo assim, o Requerente mais uma vez acabou tendo que desistir da funcionalidade. 6.5.4Cadastros O Sistema de Verificao englobava uma grande variedade de funcionalidades, 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 verificao de habilidades especficas e no-especficas. Sendo assim, nas primeiras iteraes, ele priorizou estrias que ajudariam a validar tais modelos, embora vrios dados importantes ainda no existissem cadastrados, tais como habilidades, perfis esportivos, 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

36 considerava mais crticas, o que acabou se revelando valioso, como foi possvel observar anteriormente. O mecanismo criado para solucionar a questo foi batizado internamente 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 que permitiam a utilizao das funcionalidades. Assim, a equipe de desenvolvimento assegurava a existncia de habilidades, modalidades esportivas, atletas, entre outros, j na primeira iterao. E isso permitiu ao Requerente utilizar as funcionalidades 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 teriam acesso a fazer modificaes diretamente na base de dados de produo do Cliente. Apesar do alerta, o Requerente no priorizou os formulrios de cadastro.

37 Durante a quinta iterao, as planilhas j estavam em pleno uso dentro do Cliente 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 verificaes 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 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 interessantes. A primeira que o projeto foi capaz de entregar funcionalidades importantes para o Requerente durante catorze iteraes (aproximadamente sete meses) apesar de no haver sido implementado um nico 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 verificao de habilidades, sobretudo o de habilidades especficas.

38 bastante relevante observar 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 do sistema. Isso evitou re-trabalhos futuros e poupou tempo da equipe de desenvolvimento e do prprio Requerente. 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 demonstra a equipe de desenvolvimento pressionando o Requerente para fornecer tais planilhas o mais brevemente possvel. Isso levanta uma hiptese

interessante. Caso os formulrios de cadastro tivessem sido implementados desde as primeiras iteraes, o esforo poderia ter sido em vo, visto que o Cliente no era capaz de gerar os dados a serem cadastrados com agilidade. Novos cadastros foram priorizados para a dcima nona iterao. Desta vez, as estrias 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 verificao 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 verificao. Alm dos cadastros mencionados anteriormente, apenas outros trs menos importantes foram implementados. A contagem final de cadastros revela um nmero

39 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.5.5Relatrios 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 de sada. 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 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 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. Na verdade, o Requerente acabou gostando dos relatrios em HTML, pois eles facilitavam a cpia das informaes.

40 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 Cliente. 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. 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.5.6Histrico de Ciclos Passados O Sistema de Verificao usado anualmente durante um perodo de trs meses (entre novembro e janeiro do ano seguinte) que recebe o nome de Ciclo. Fora do Ciclo, o sistema usado basicamente pelo pessoal da rea de Esportes ou por atletas do Cliente 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

41 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 verificao, fez com que ele priorizasse funcionalidades relativas s verificaes e deixasse o histrico para 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 Verificaes, Planos de Condicionamento, entre outros. Para a vigsima primeira iterao, foi priorizada uma histria que permitiria ao usurio navegar pela verificao 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. Nesta 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.

42 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 funcionalidades, permitindo que o processo fosse concludo com rapidez nas duas iteraes finais do projeto. Finalmente, vlido observar 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 muito menos procedimentos destinados a popular as mesmas. 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 do refactoring, 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 o refactoring 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 sobre o histrico. Tais discusses envolveram todos os membros da equipe de desenvolvimento. Depois de dois dias de debates intensos e modelagens em conjunto

43 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 rpida de ser implementada. Neste caso, nota-se que a proximidade fsica entre os membros da equipe e o uso intenso do dilogo foi til mais uma vez no projeto para simplificar as solues e acelerar a implementao das funcionalidades.

44

7CONCLUSO

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 que a adoo das prticas e valores do XP como uma alternativa vivel para a resoluo destes problemas em diversos projetos de software. Procurou-se mostrar que o conjunto formado pelas prticas e valores do XP possui uma sinergia elevada que gera contribuies significativas para os projetos. Neste sentido, foi feita uma reviso detalhada da literatura na busca por justificativas para as prticas propostas pelo XP. Alm disso, foi apresentado um estudo de caso onde estas prticas foram adotadas com sucesso e levaram a construo de um sistema com elevada integridade e satisfao dos seus usurios.

45