introducao-desenvolvimento-sw-Dissertação Vinicius Telles

Prévia do material em texto

12
2 A CRISE DO SOFTWARE 
O termo crise do software vem sendo usado na ind stria de software desde 
1968, quando houve a primeira admiss o aberta da exist ncia de uma crise latente na 
rea (DIJKSTRA, 1972, tradu o nossa). Naquele ano, ocorreu a Confer ncia da OTAN 
sobre Engenharia de Software (NATO Software Engineering Conference) em Garmisch, 
Alemanha, que considerado atualmente o momento hist rico do nascimento da 
disciplina de Engenharia de Software (BRYANT, 2000; EISCHEN, 2002). 
Diversos autores utilizam o termo crise do software , embora alguns o fa am 
com alguma ressalva, como o caso de Pressman (1997, p.16, tradu o nossa) que 
considera que temos uma crise que vem nos acompanhando h 30 anos e essa uma 
contradi o de termos. (...) O que n s temos de fato uma calamidade cr nica. 
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 informa o. Atualmente, seus 
dados est o entre os mais utilizados para quantificar a crise do software . 
O CHAOS Report do ano 2000 (THE STANDISH GROUP INTERNATIONAL, 
2001) apresenta uma colet nea de dados envolvendo 280 mil projetos de software nos 
Estados Unidos, os quais revelaram que: 
 Em m dia, os atrasos representaram 63% mais tempo do que o estimado; 
 Os projetos que n o cumpriram o or amento custaram em m dia 45% 
mais e 
 No geral, apenas 67% das funcionalidades prometidas foram 
efetivamente entregues. 
 13
O Standish Group classifica o resultado final de um projeto nas seguintes 
categorias: 
 Mal sucedido; 
 Comprometido e 
 Bem sucedido. 
Em 2000, o resultado final da pesquisa mostrou a seguinte distribui o entre os 
projetos: 
Figura 2.1: estat stica sobre o resultado final de projetos de software. 
 
Tais n meros, embora desastrosos, mostram um avan o em rela o aos 
resultados do primeiro levantamento realizado em 1994: 
 
 14
 
Figura 2.2: evolu o do resultado final de projetos de software ao longo dos 
anos. 
 
Na terceira Confer ncia Internacional sobre Extreme Programming, que ocorreu 
na It lia em 2002, Jim Johnson, presidente do Standish Group, apresentou um estudo 
revelador sobre a utiliza o 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 t pico jamais s o usadas e 19 por cento 
raramente s o usadas: 
 15
 
Figura 2.3: estat stica sobre a utiliza o de funcionalidades. 
 
Al m de as estat sticas mostrarem, em n meros, o significado do que vem sendo 
chamado h quase quarenta anos de crise do software , a an lise de casos isolados 
demonstra a exist ncia de grandes varia es nos resultados dos projetos. o caso, por 
exemplo, de dois sistemas desenvolvidos na rea governamental dos EUA. 
H alguns anos, os estados americanos da Fl rida e Minnesota se lan aram no 
desafio de criar um Sistema de Informa es para o Bem Estar das Crian as (Statewide 
Automated Child Welfare Information System SAC IS). Cada estado adotou uma 
abordagem distinta e a diferen a de resultados significativa. Na Florida, o 
desenvolvimento do sistema teve in cio em 1990 e foi estimado em oito anos a um custo 
de US 32 milh es. Em 2002, a Florida j havia gasto US 170 milh es e o sistema foi 
re-estimado para ser finalizado em 2005 a um custo de US 230 milh es. Por sua vez, 
Minnesota come ou a desenvolver essencialmente o mesmo sistema em 1999 e o 
finalizou no in cio de 2000 ao custo de US 1,1 milh o. A diferen a de produtividade 
de 200:1(POPPENDIECK & POPPENDIECK, 2003). 
 16
Ao analisar os fatores que levam tantos projetos de software a fracassarem e 
outros (poucos) a serem bem sucedidos, relevante avaliar o que significa desenvolver 
um software. Quais s o os fatores que caracterizam o desenvolvimento de software e 
diferenciam os projetos desta rea 
 17
3 A NATUREZA DO SOFTWARE 
A compreens o dos fatores que levam crise do software passa primeiramente 
pela compreens o da natureza do software e como ele vem sendo tratado ao longo dos 
anos. Essa an lise envolve duas partes: os aspectos b sicos que caracterizam o software 
e as met foras que s o utilizadas no desenvolvimento do mesmo. 
O estudo detalhado do software aponta para as seguintes caracter sticas 
(BROOKS, 1995; BRYANT, 2000; BUHRER, 2000; KRUTCHTEN, 2001): 
 Complexidade; 
 Conformidade; 
 Maleabilidade; 
 Invisibilidade; 
 Aus ncia de leis b sicas; 
 Imaturidade e 
 Baixo custo de manufatura. 
3.1 Complexidade 
Frederick Brooks, apresenta no artigo No silver bullet: essences and accidents 
of Software Engineering (1987) o que considera como sendo as propriedades 
essenciais do software e come a 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 constru o 
humana. 
Quando as partes de um software s o semelhantes, as mesmas costumam ser 
agrupadas em m todos, classes e outros elementos. Assim, medida que um sistema 
 18
cresce em tamanho, cresce tamb m a quantidade de partes distintas. Esse 
comportamento difere profundamente de outras constru es, tais como computadores, 
pr dios ou autom veis, nos quais se encontram elementos repetidos em abund ncia. 
Isso leva os programas a terem um n mero extremamente elevado de estados. 
Computadores, por exemplo, s o produtos bastante complexos que cont m uma elevada 
quantidade de estados. Softwares, por sua vez, costumam ter uma quantidade bem maior 
de estados. 
Outro problema est ligado necessidade de escalar. Fazer um software escalar 
n o significa apenas repetir os mesmos elementos em tamanho maior. Normalmente 
necess rio o aumento no n mero de elementos distintos, elevando ainda mais a 
quantidade de estados de um sistema, e o que pior, de forma n o linear. 
Brooks acredita que grande parte dos problemas cl ssicos relacionados ao 
desenvolvimento de sistemas deriva diretamente da complexidade que est na ess ncia 
de qualquer software e sua correspondente eleva o n o linear com o aumento de 
tamanho. A complexidade dificulta a comunica o entre os membros da equipe de 
desenvolvimento e torna dif cil enumerar e compreender todos os poss veis estados do 
programa, resultando em falta de confiabilidade. Por sua vez, a complexidade das 
fun es gera dificuldades para invoc -las, tornando os sistemas dif ceis de serem 
utilizados. 
A complexidade estrutural tamb m torna dif cil estender os programas para que 
incorporem novas funcionalidades sem criar efeitos colaterais. Al m disso, dif cil ter 
uma vis o geral do software, o que impede que se alcance integridade conceitual no 
mesmo. Finalmente, o esfor o de aprendizado e transmiss o de conhecimento se torna 
 19
bastante elevado, raz o pela qual trocas de pessoal costumam acarretar preju zos 
significativos. 
 A complexidade do software colabora e explica, em parte, os resultados 
apresentados no cap tulo anterior. E importante compreender que, segundo Brooks, 
trata-se de um problema que est na ess ncia do software. Isso significa que n o 
existem ferramentas ou t cnicas que possam evit -lo. Elas naturalmente podem ajudar a 
tratar a complexidade, mas a alta complexidade sempre estar presente nos projetos de 
software. Segundo einberg (1971, p.15, tradu o nossa), (...) programar n o apenas 
um comportamento humano; comportamento humano complexo. 
3.2 Conformidade 
A complexidade um problema que tamb m afeta outras reas de 
conhecimento, como por exemplo a f sica. Esta, al m de lidar com objetos 
extremamente complexos, eventualmente chega ao ponto de lidar com elementos no 
n vel fundamental das part culas. Apesar disso, o f sico se baseia na convic o de que 
existam princ pios unificadores,os quais, uma vez descobertos, facilitam a compreens o 
e o tratamento dos problemas. Al m disso, princ pios f sicos tendem a ser est veis. 
Infelizmente, sistemas de software n o costumam existir em conformidade com 
princ pios fundamentais e est veis. Grande parte da complexidade com a qual o 
desenvolvedor deve lidar arbitr ria. Ela imposta sobre ele por institui es e sistemas 
humanos, com os quais o software precisa estar em conformidade. Tal conformidade 
din mica, visto que os sistemas humanos mudam com o tempo, as pessoas mudam e o 
software passa a ter que se adequar a novas realidades (BROOKS, 1987). 
 20
3.3 Maleabilidade 
O software, por ser digital, possui uma maleabilidade extremamente elevada e 
infinitamente superior quela encontrada em outros tipos de produtos, como aqueles 
compostos por elementos f sicos. Isso gera press es permanentes por mudan as nos 
sistemas. 
Fazendo um comparativo, observa-se que constru es tais como pr dios, carros 
e computadores tamb m sofrem press es por mudan as. Entretanto, por serem formadas 
de elementos f sicos, os custos das mudan as s o melhores compreendidos e 
observados, o que reduz os caprichos daqueles que as desejam. Software, por sua vez, 
 apenas pensamento, o que o torna infinitamente male vel. Isso notado pelas pessoas 
de um modo geral, que naturalmente pressionam por mais mudan as, por considerarem 
que as mesmas ter o um custo reduzido (BROOKS, 1987). 
A maleabilidade do software difere, portanto, daquela encontrada na engenharia 
civil. Se voc constr i uma ponte, voc n o tem este tipo de flexibilidade. Voc n o 
pode dizer Hum, agora que eu j vejo os pilares, eu gostaria que essa ponte fosse 
colocada duas milhas rio acima (KRUTCHTEN, 2001, tradu o nossa). 
Na situa o ilustrada acima, qualquer pessoa seria capaz de avaliar o enorme 
custo de mover a ponte de uma posi o para a outra, o que tenderia a reduzir ou 
eliminar completamente a mudan a. Mas, no caso do software, a sua maleabilidade 
torna as mudan as muito mais f ceis e menos custosas. Seus usu rios t m a exata 
percep o de que infinitamente mais f cil alterar um software que a posi o de uma 
ponte, o que os leva a solicitar mudan as com mais freq ncia e mais intensidade. 
 21
3.4 Invisibilidade 
Ao elaborar um projeto, diversos profissionais t m a oportunidade de utilizar 
uma importante ferramenta: abstra es geom tricas. Um arquiteto, por exemplo, tem a 
possibilidade de utilizar uma planta baixa que o ajuda, bem como ajuda seu cliente a 
avaliar espa os, fluxos de tr nsito, disposi o de elementos, entre outros. Com ela, 
torna-se simples identificar contradi es e omiss es. Ao capturar a realidade 
geom trica, em uma abstra o geom trica correspondente, o arquiteto tem a sua 
disposi o uma ferramenta que facilita e melhora o seu trabalho. 
J o software, invis vel e imposs vel de ser visualizado, visto que sua realidade 
n o se encontra inserida de modo intr nseco no espa o. Assim, n o possui uma 
representa o geom trica disposi o, da mesma forma que terras possuem mapas, por 
exemplo. Ao se tentar diagramar a estrutura de um software, notamos que ela 
constitu da n o por um, mas por v rios grafos direcionados de forma gen rica, 
superpostos uns sobre os outros. Os v rios grafos podem representar o fluxo de 
controle, o fluxo de dados, padr es de depend ncia (...) (BROOKS, 1987, tradu o 
nossa). 
Brooks acredita que, embora tenha havido avan os no sentido de simplificar as 
estruturas de software, elas continuam sendo praticamente imposs veis de serem 
visualizadas. Isso gera uma defici ncia para o desenvolvedor que acaba n o podendo 
contar com uma importante ferramenta. Esta falta n o apenas retarda o processo de 
design dentro de uma mente, como tamb m prejudica severamente a comunica o entre 
mentes diferentes (BROOKS, 1987, tradu o nossa). 
 22
3.5 Inexist ncia de princ pios b sicos 
Como j vimos, o software n o possui leis fundamentais como a f sica, tornando 
dif cil pensar sobre ele sem efetivamente constru -lo. Al m disso, os poucos padr es de 
engenharia de software que conhecemos se baseiam apenas em boas pr ticas, enquanto 
c digos de constru o em outras disciplinas se originam em s lidos princ pios f sicos 
(KRUTCHTEN, 2001, tradu o nossa). 
3.6 R pida evolu o tecnol gica 
As t cnicas de desenvolvimento de software, ferramentas e o pr prio ambiente 
de software mudam em um ritmo profundamente acelerado. Isso torna dif cil 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-
come o, pois aquilo que aprenderam h pouco tempo, perde a utilidade com enorme 
rapidez. Al m disso, a engenharia de software, ao contr rio de outras disciplinas, n o 
se beneficia de centenas ou at mesmo milhares de anos de experi ncia (KRUTCHTEN, 
2001, tradu o nossa). 
3.7 Baixo custo de manufatura 
Quando os desenvolvedores de software tratam do design de um aplicativo, 
normalmente est o se referindo a uma descri o de alto n vel das estruturas do sistema. 
Freq entemente acreditam que elaborar este design a parte complexa, enquanto a 
codifica o uma parte mec nica. Comparando com uma f brica de autom veis, 
como se elaborar o design se assemelhasse ao trabalho do engenheiro que projeta um 
novo modelo, enquanto a codifica o o trabalho mec nico de produzir tal modelo no 
ch o de f brica. 
 23
Segundo Krutchten (2001), isso n o corresponde realidade. Praticamente todo 
o trabalho do desenvolvedor, incluindo a codifica o, representa um esfor o de design. 
Usando a compara o anterior, praticamente todo o trabalho de desenvolvimento de 
software pode ser comparado ao trabalho do engenheiro que projeta um novo 
autom vel. 
A manufatura de um autom vel, ou seja, o trabalho realizado no ch o de f brica 
para reproduzir o mesmo modelo in meras vezes, buscando eliminar varia es, 
corresponde em software ao trabalho de compilar, empacotar e gerar um CD, por 
exemplo. Este o trabalho que pode, automatizado, e essencialmente o trabalho que 
se assemelha ao que feito na linha de produ o de uma ind stria, com uma importante 
diferen a: o custo. 
Manufaturar um software tem um custo extremamente baixo. Comparando-se 
com uma ind stria automobil stica, por exemplo, quase como se n o existisse custo de 
manufatura. Quase todo o investimento est associado ao design. Uma vez projetado, o 
software pode ser replicado infinitas vezes, fazendo-se uma c pia de arquivos, gerando-
se um CD ou transferindo-se o aplicativo pela Internet (KRUTCHTEN, 2001). 
Projetar um novo modelo de autom vel um trabalho essencialmente dif cil, 
pouco previs vel, demorado e com potencial limitado de ser acelerado. S o necess rias 
v rias idas e vindas durante o projeto (POPPENDIECK & POPPENDIECK, 2003). A 
automa o n o exerce um efeito t o dr stico na velocidade de elabora o do projeto, 
quanto exerce na manufatura do autom vel. 
A partir das caracter sticas que analisamos, podemos compreender que sempre 
haver uma crise do software , pois a causa de muitos dos problemas est na pr pria 
natureza do software (BRYANT, 2000, tradu o nossa). O que certamente podemos 
 24
fazer reconhecer estas caracter sticas e buscar solu es que as levem em 
considera o, de modo a atenuar os problemas que as equipes de desenvolvimento 
costumam vivenciar. 
 
 25
4 MET FORAS E O DESENVO VIMENTO DE SOFTWARE 
H d cadas, a crise do software vem inspirando estudiosos e profissionais a 
criarem propostas para solucion -la. De um modo geral, tais solu es carregam 
met foras que procuram lan ar luz sobre a natureza do software e poss veis abordagens 
para trat -la. 
Como mostra Bryant (2000), a pr tica de desenvolvimento de software 
inevitavelmente fundada sobre met foras. A pr pria palavra software uma 
met fora. A compreens o das met foras, que v m sendousadas 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 solu es, atrav s 
do uso de novas met foras. A tens o entre sua invisibilidade e intangibilidade por um 
lado e sua complexidade por outro, praticamente exige mecanismos e alus es 
metaf ricas (BRYANT, 2000, tradu o nossa). 
Ao longo dos anos, a met fora que mais vem influenciando o processo de 
desenvolvimento de software a da engenharia. Software vem sendo visto como um 
processo de constru o e de fabrica o. Em tal met fora, utilizam-se termos tais como 
constru o, desenvolvimento, manuten o, prototipagem, entre outros (BRYANT, 
2000). 
Um dos efeitos mais marcantes da crise do software , a busca permanente por 
solu es que possam tornar os projetos: 
 Mais produtivos; 
 Mais previs veis e 
 Com resultados de melhor qualidade. 
 26
Felizmente, outras disciplinas se depararam com esta mesma busca no passado. 
Algumas foram extremamente bem sucedidas, tendo alcan ado os tr s objetivos 
descritos acima. Em particular, vale a pena analisar a ind stria de produ o em massa, 
que vem melhorando continuamente nestes quesitos h alguns s culos (DRUCKER, 
1999; TOFFLER, 2001). 
4.1 A ind stria de produ o em massa 
Alvin Toffler (2001) avalia a hist ria da humanidade como uma sucess o de 
ondas de mudan a em marcha, as quais focalizam a nossa aten o n o apenas para as 
continuidades hist ricas (por mais importantes que sejam), mas tamb m as 
descontinuidades, ou seja, as inova es e interrup es. 
Come ando com a simpl ssima id ia de que o aparecimento da 
agricultura foi o primeiro ponto decisivo do desenvolvimento social 
humano, e de que a revolu o industrial foi a segunda grande ruptura, 
olha cada um destes acontecimentos n o como um discreto evento no 
tempo, mas como uma onda de mudan a avan ando a uma certa 
velocidade (TOFFLER, 2001, p.27). 
 
A Revolu o Industrial, que nos lan ou na Segunda Onda de mudan as, trouxe 
consigo uma s rie de regras, consistindo em seis princ pios inter-relacionados (...). 
Nascendo naturalmente da desuni o da produ o e do consumo, estes princ pios 
afetavam todos os aspectos da vida (...) (TOFFLER, 2001, p.59). 
Os seis princ pios b sicos apontados por Toffler (2001) s o: 
 Padroniza o; 
 Especializa o; 
 Sincroniza o; 
 Concentra o; 
 Maximiza o e 
 27
 Centraliza o. 
4.1.1 Padroniza o 
A padroniza o foi um princ pio inventado por um construtor de m veis 
chamado Thonet que (...) descobriu que, em vez de fabricar cem cadeiras, cada uma 
diferente da outra, muito mais lucrativo faz -las todas iguais: o desperd cio menor, a 
produ o mais r pida e a menor custo (MASI, 2000, p.59). 
Pelos seus m ritos, tal princ pio foi levado s ltimas conseq ncias por 
Frederick inslow Taylor no in cio do s culo . Ele prop s que o trabalho podia ser 
cient fico, caso fosse poss vel padronizar os passos executados pelos trabalhadores para 
executarem suas atividades. Sobretudo, Taylor acreditava que havia uma maneira 
melhor (padr o) de realizar cada tarefa, uma ferramenta melhor (padr o) para execut -
la com ela e um tempo estipulado (padr o) no qual podia ser completada (TOFFLER, 
2001, p.61). 
4.1.2 Especializa o 
Em 1776, no auge da Revolu o Industrial, Adam Smith publicou um dos mais 
famosos e importantes livros de economia: A riqueza das na es. No in cio da obra, ele 
aborda o princ pio da especializa o, declarando que o maior aprimoramento das 
for as 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 divis o do trabalho (SMITH, 1996, p.65). 
A divis o do trabalho uma das caracter sticas mais importantes do processo 
de industrializa o devido ao enorme aumento de produtividade que acabou 
 28
proporcionando. Como exemplo, Toffler faz refer ncia Smith, que ao visitar uma 
f brica de alfinetes ofereceu o seguinte relato: 
Um trabalhador nico de velho estilo, efetuando todas as opera es 
necess rias sozinho, escreveu, podia produzir apenas um punhado de 
alfinetes por dia n o mais de 20 e talvez nem um. Em contraste, 
Smith descrevia uma manufatura que ele tinha visitado, na qual se 
exigiam 18 opera es diferentes efetuadas por dez trabalhadores 
especializados, cada um efetuando apenas uma ou algumas fases. 
Juntos, conseguiam produzir mais de 48 mil alfinetes por dia mais 
de quatro mil e oitocentos por trabalhador (TOFFLER, 2001, p.62). 
4.1.3 Sincroniza o 
O princ pio da sincroniza o est associado necessidade de reunir os 
trabalhadores em um local no qual se encontram os meios de produ o, ou seja, na 
f brica. Isso causa a necessidade de que as pessoas estejam juntas ao mesmo tempo e, 
portanto, tenham os mesmos hor rios. 
Se f ssemos artes os numa oficina de vasos, cada um fabricaria um 
vaso inteiro. Se, ao contr rio, trabalh ssemos numa linha de 
montagem, voc enroscaria um parafuso e, cinco segundos depois, eu 
deveria apertar outro: logo, dever amos ambos estar presentes no 
instante em que a cadeia se inicia (MASI, 2000, p.61). 
 
Al m da interdepend ncia intensificada, m quinas caras n o podem ficar 
ociosas e operam ao seu ritmo pr prio (TOFFLER, 2001, p.64). Por essa raz o, a 
pontualidade se torna essencial e toda a f brica precisa operar em sincronia, de acordo 
com o ritmo estabelecido pelas m quinas. 
4.1.4 Concentra o 
A concentra o (ou economia de escala) se baseia na id ia de que (...) se eu 
concentro dez empresas de mil pessoas numa nica megaempresa sic de dez mil 
pessoas, ser necess rio um n mero menor de dirigentes, de empregados, de fiscais e o 
lucro ser maior (MASI, 2000, p.66). Naturalmente, as fontes de economia podem 
 29
englobar tamb m outros fatores, tais como a reutiliza o de equipamentos, o maior 
poder de barganha com fornecedores e maior capacidade de impor pre os vantajosos no 
mercado. 
4.1.5 Maximiza o 
A maximiza o 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 f rmula E P/H, que quer dizer que a efici ncia (E) igual a P, de 
produ o, 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 eleva o da 
produtividade ao longo do s culo foi a respons vel pela atual exist ncia de pa ses 
desenvolvidos. 
Menos de uma d cada depois que Taylor examinou o trabalho e 
analisou-o, a produtividade do trabalhador manual iniciou sua 
ascens o sem precedentes. Desde ent o, ela tem subido regularmente 
taxa de 3,5% ao ano, o que significa que aumentou 50 vezes desde 
Taylor. Nesta realiza o baseiam-se todos os ganhos econ micos e 
sociais do s culo . A produtividade do trabalhador manual criou 
aquelas que hoje chamamos de economias desenvolvidas . Antes de 
Taylor, isso n o havia todas as economias eram igualmente 
subdesenvolvidas . Hoje, uma economia subdesenvolvida, ou mesmo 
emergente , aquela que ainda n o tornou produtivo o trabalhador 
manual (DRUCKER, 1999, p.112). 
 
Analisando a cita o de Drucker, fundamental notar o uso da express o 
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 
pr ximas se es, quando come aremos a analisar a produtividade do trabalho de 
desenvolvimento de software. 
 30
4.1.6 Centraliza o 
Da mesma forma que a Segunda Onda trouxe consigo a forte divis o entre 
produ o e consumo (TOFFLER, 2001), criou tamb m a divis o entre planejamento e 
execu o, isto , deixou claro que existem aqueles que pensam (e conseq entemente 
mandam) e aqueles que fazem (e, portanto, obedecem). Utiliza-se a premissa de que 
(...) a organizao deve ter a forma de uma pir mide: o v rtice sabe tudo e pode tudo. 
Entre quem pensa e quem executa, a divis o cristalina (MASI, 2000, p.66). 
4.2 O desenvolvimento de software como trabalho do conhecimento 
No in cio deste cap tulo, apontamos a busca por solu es que possam tornar os 
projetos de desenvolvimento de software mais produtivos, mais previs veis e com 
resultados de melhor qualidade. Esses objetivos, entre outros, foram alcan ados com 
sucesso pela ind stria de produ o em massa utilizando os princ pios explicados nas 
se es anteriores, que est o presentes no cotidiano. Desde 1776, quando Adam Smith 
defendeu a divis o do trabalho em A riqueza das na es , racionalizar a produ o vem 
servindo como um m todo provado para elevar a qualidade, reduzir custos e aumentar a 
efici ncia (EISCHEN, 2002). 
Uma quest o relevante que se poderia levantar se n o seria poss vel utilizar 
estes mesmos princ pios no desenvolvimento de software e obter os mesmos resultados 
positivos. Esse questionamento n o novo. Ele acompanha a ind stria de software h 
bastante tempo. Muitos acreditam que poss vel mapear estes princ pios no 
desenvolvimento de software e cada vez mais encontramos met foras que procuram 
aproxim -lo do processo de produ o de uma f brica, culminado inclusive na atual id ia 
de f brica de software t o extensamente divulgada no mercado. 
 31
Em janeiro de 2005, uma busca pela express o f brica de software no Google1 
gerou como resultado 333 mil refer ncias, dentre as quais era poss vel identificar uma 
grande quantidade de empresas brasileiras que atuam no desenvolvimento de software, 
desde pequenas a grandes. Utilizando-se o equivalente em ingl s, ou seja, a express o 
software factory, o Google retornou 10.2 milh es de refer ncias. Tais n meros d o uma 
id ia da extens o desta met fora e da import ncia que lhe dedicada atualmente. 
Seu uso facilmente compreens vel quando observamos os resultados da 
produ o industrial e o tremendo impacto gerado pelos princ pios descritos 
anteriormente sobre o trabalho manual (DRUCKER, 1999). A express o trabalho 
manual nos chama a aten o para a possibilidade de exist ncia de outros tipos de 
trabalho, os quais podem ou n o ser beneficiados pelos princ pios da industrializa o 
em massa, ou Segunda Onda, para usar as palavras de Toffler (2001). 
Outro tipo de trabalho que est cada vez mais presente na sociedade 
contempor nea o trabalho do conhecimento. Compreender a diferen a entre trabalho 
manual e trabalho do conhecimento relevante tendo em vista o fato de que (...) 
grande parte da discuss o atual (...) parece assumir que programar similar produ o 
industrial, o programador sendo visto como (...) um componente que precisa ser 
controlado (...) e que pode ser substitu do facilmente (COCKBURN, 2002, p.237, 
tradu o 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; 
 
1 Ferramenta de busca na Internet. 
 32
1987), De Masi (2000), Drucker (1999), Poppendieck e Poppendieck (2003) e Toffler 
(2001). 
Os trabalhadores do conhecimento existem h bastante tempo, mas ao longo da 
Segunda Onda, isto , da Era Industrial, o n mero de trabalhadores manuais era maior e 
mais significativo do ponto de vista de resultados para a sociedade. Entretanto, medida 
em que avan amos pela Terceira Onda, conforme a nomenclatura de Toffler (2001), ou 
a Sociedade P s-industrial, segundo De Masi (2000) ou a Revolu o da Informa o, 
segundo Drucker (1999), os trabalhadores do conhecimento est o se tornando 
rapidamente o maior grupo isolado da for a de trabalho de todos os pa ses 
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, n o s o, necessariamente, os mesmos que regem o 
trabalho manual . De fato, como veremos adiante, tais fatores, embora ainda n o sejam 
t o 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. S o eles: 
1. Definir qual a tarefa a ser feita; 
2. Permitir que os pr prios trabalhadores se auto-gerenciem. Ou seja, 
assegurar que eles tenham autonomia e responsabilidade sobre o que 
produzem; 
 33
3. Assegurar que os trabalhadores tenham a oportunidade de inovar; 
4. Aprendizado e ensino cont nuo; 
5. Qualidade um fator t o o mais importante que a quantidade produzida e 
6. Os trabalhadores do conhecimento precisam ser tratados como ativos e 
n o como custo . Al m disso, precisam querer trabalhar para a 
organiza o. 
Portanto os princ pios apresentados anteriormente, sobre a produtividade do 
trabalhador manual , n o se aplicam ao trabalho do conhecimento , podendo 
inclusive prejudic -lo. 
O que os empregadores da Terceira Onda precisam cada vez mais, por 
conseguinte, s o 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 circunst ncias modificadas e que estejam sensivelmente 
afinados com as pessoas em volta deles. (...) 
A firma da Terceira Onda exige pessoas que sejam menos pr -
programadas e mais criativas. (...) 
Tais pessoas s o 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 iener erkst tte como exemplo de uma organiza o 
que sabia alcan ar 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, cart es postais, papel de parede, 
talheres, m veis e at mesmo bairros inteiros. Nela, o processo de cria o e produ o 
era completamente diferente daqueles de Taylor: escassa divis o do trabalho, pouca 
padroniza o, pouca especializa o, pouca sincroniza o, pouca centraliza o, pouca 
maximiza o. Com resultados (...) extraordin rios (MASI, 2000, p.69). 
 34
4.2.1 Definir a tarefa 
Os trabalhadores manuais s o programados pela tarefa que executam e 
normalmente executam um conjunto reduzido de tarefas repetidas vezes. As tarefas 
realizadas por um trabalhador do conhecimento, entretanto, costumam ser maiores, mais 
complexas e pouco estruturadas. Al m disso, no dia-a-dia, um trabalhador do 
conhecimento solicitado a fazer in meras tarefas distintas. Os engenheiros est o 
constantemente sendo afastados de sua tarefa por terem de redigir um relat rio ou 
reescrev -lo, serem solicitados para uma reuni o 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 m xima produtividade, necess rio que 
eles saibam priorizar e concentrar o m ximo de esfor os naquilo que mais pode fazer 
diferen a para a organiza o ou seu projeto a cada dia de trabalho. 
4.2.2 Qualidade 
A produtividade do trabalho manual est fortemente atrelada ao volume 
produzido,desde que se respeitem os padr es m nimos de qualidade. O mesmo n o 
acontece com o trabalho do conhecimento, pois neste caso, a qualidade a ess ncia da 
produ o. Por exemplo, ao julgar o desempenho de um professor, n o questionamos 
quantos alunos pode haver em uma classe, mas quantos deles aprendem algo e esta 
uma pergunta de qualidade (...) (DRUCKER, 1999, p.117). 
 35
O trabalhador do conhecimento deve executar suas atividades de modo a atingir 
n o apenas a qualidade m nima, mas sim a m xima qualidade poss vel. A quest o da 
quantidade s come a a fazer sentido depois de se alcan ar o maior n vel de qualidade. 
No caso do desenvolvimento de software, por exemplo, onde t cnicas, 
ferramentas e ambientes de software evoluem em ritmo extremamente acelerado, atingir 
alta qualidade est diretamente associado a um processo de aprimoramento cont nuo. 
Portanto, a produtividade do desenvolvedor de software est profundamente associada a 
sua capacidade de executar suas atividades com qualidade elevada e continuar 
aprendendo tanto quanto poss vel medida que as executa. 
4.2.3 O trabalhador do conhecimento como ativo 
Na l gica do trabalho manual, acredita-se comumente que o trabalhador um 
custo e, ao mesmo tempo uma pe a da engrenagem que constitui os sistemas de neg cio 
de uma organiza o. Com exce o do custo de turnover2, o gerenciamento de 
trabalhadores, baseado em mil nios 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 recontrata o, re-treinamento 
etc, bem como a possibilidade de se perder a experi ncia dessa pessoa. Apesar disso, o 
trabalhador manual ainda visto como um custo e basicamente como uma pe a 
intercambi vel. 
No caso do trabalhador do conhecimento a situa o bem mais grave. O 
trabalhador manual n o possui os meios de produ o. Portanto, sua experi ncia s 
valiosa no local em que trabalha, ela n o port vel. Por sua vez, os trabalhadores do 
 
2 Custo de substitui o de um trabalhador. 
 36
conhecimento possuem os meios de produ o. O conhecimento que est entre suas 
orelhas um ativo enorme e totalmente port til. Pelo fato de possu rem seus meios de 
produ o, eles s o m veis (DRUCKER, 1999, p.121). 
Hoje, se sou um publicit rio e estou tentando criar um slogan, quando 
saio do escrit rio e volto para casa, levo o trabalho comigo: na minha 
cabe a. A minha cabe a n o p ra de pensar e s vezes acontece que 
posso achar a solu o para o slogan em plena noite, ou debaixo do 
chuveiro, ou ainda naquele estado intermedi rio entre o sono e o 
despertar (MASI, 2000, p.205). 
 
A perda de um trabalhador do conhecimento tem conseq ncias mais s rias, 
porque significa tamb m a perda do meio de produ o e de todo o aprendizado obtido 
ao longo do tempo. Portanto, o trabalhador do conhecimento precisa ser encarado como 
um ativo que deve ser mantido na organiza o. Se os custos de substitui o s o 
elevados para o trabalhador manual, eles s o significativamente maiores para os 
trabalhadores do conhecimento. 
4.2.4 Motiva o 
No trabalho do conhecimento (tamb m chamado de trabalho intelectual por De 
Masi) o trabalho pouco estruturado e n o existe uma linha de produ o que imponha o 
ritmo de trabalho. Portanto, preciso que cada trabalhador decida produzir com a 
m xima qualidade no ritmo mais gil poss vel. Por esta raz o, no trabalho intelectual a 
motiva o tudo (MASI, 2000, p.223). 
Segundo Cockburn (2002, p.63, tradu o nossa), existem tr s tipos de 
recompensa que podem manter a motiva o intr nseca de uma pessoa: orgulho no 
trabalho, orgulho de realizar e orgulho da contribui o. Brooks (1995), por sua vez, 
acredita que o trabalho de desenvolvimento de software proporciona 5 tipos de 
satisfa es: 
 37
 A satisfa o de montar coisas; 
 A satisfa o de montar coisas que s o teis para outras 
pessoas; 
 O fasc nio de montar objetos que se assemelham a quebra-
cabe as; 
 A satisfa o de estar sempre aprendendo coisas n o 
repetitivas e 
 O prazer de trabalhar em um meio t o male vel pensamento 
puro que, apesar de male vel, existe, se move e trabalha de 
uma forma diferente dos objetos do mundo f sico (BROOKS, 
1995, p.230, tradu o nossa). 
 
Se motiva o 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, n o f cil motivar algu m, pois necess rio que a 
pr pria pessoa seja capaz de se motivar. Entretanto, relativamente f cil reduzir ou 
eliminar a motiva o de um trabalhador do conhecimento. 
O trabalhador do conhecimento precisa compreender o prop sito daquilo que 
faz. Voc n o pode lhe dizer para fazer alguma coisa porque voc o chefe e voc diz 
que precisa ser feito. (...) Voc n o pode lhe impor objetivos que n o lhe fa am sentido 
(DEMARCO, 2001, p.28, tradu o nossa). 
Al m disso, n o se pode estruturar as atividades de um trabalhador do 
conhecimento. Ele tem que ser o pr prio respons vel pela forma como o trabalho 
conduzido. Alem disso, tem que saber o que deve ser feito e porque. 
A ess ncia da Administra o Cient fica 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. N o se pode estruturar a 
atividade e, sobretudo, n o se pode estrutur -la de uma forma que n o d ao trabalhador 
a chance de crescer. Crescimento essencial para ele, t o essencial quanto o contra-
 38
cheque. Voc n o pode mais esperar que ele trabalhe sem desafios significativos (...) 
(DEMARCO, 2001, p.28, tradu o nossa). 
A preocupa o em padronizar a forma de execu o das atividades de um 
trabalhador do conhecimento tamb m se mostra ineficaz porque acabamos nos 
concentrando na mec nica da atividade que uma parte pouco significativa em rela o 
ao trabalho como um todo. A forma como o trabalho executado dentro dos n s do 
organograma n o nem de perto t o importante quanto estabelecer qu o ampla e rica 
s o as conex es entre os trabalhadores (DEMARCO, 2001, p.108, tradu o nossa). 
Ao lidar com atividades mais complexas, os trabalhadores do conhecimento 
normalmente necessitam da ajuda de diversos colegas para atingir seus objetivos. Por 
essa raz o, a riqueza da comunica o, do relacionamento e da colabora o entre os 
trabalhadores do conhecimento mais relevante que a forma como as atividades s o 
estruturadas. Por isso a preocupa o em padronizar o modo de trabalho pouco eficaz 
e, eventualmente, prejudicial. Especialmente quando os padr es adotados prejudicam o 
fluxo de comunica o ou reduzem as chances de se executar um trabalho de alta 
qualidade do qual se possa ter orgulho. 
4.3 A produ o enxuta 
A mesma ind stria automobil stica que levou a industrializa o em massa s 
ltimas conseq ncias atrav s do Taylorismo criou, algumas d cadas depois, um 
processo de produ o diferente, que aborda de maneira diferente o trabalho do 
conhecimento. Desta vez, ao inv s da Ford, os conceitos vieram da Toyota, no Jap o. 
Na d cada de 1940, a Toyota buscou formas de produzir autom veis com maior 
agilidade e qualidade, mas com custos mais reduzidos. Al m disso, precisava viabilizar 
um modelo de produ o que n o fosse em massa, visto que naquele momento n o havia 
 39
demanda no Jap o para absorver uma oferta baseada na produ o em massa. Assim a 
Toyota criou a produ o enxuta (lean production, em ingl s) que foi se aperfei oando 
ao longo de d cadas e atualmente mais conhecida pelo termo just-in-time 
(POPPENDIECK & POPPENDIECK, 2003). 
Atualmente, a Toyota uma das montadoras de autom veis mais lucrativas do 
mundo. Ela fabrica produtos excelentes, cresce rapidamente, tem altas margens de 
lucratividade e fatura muito dinheiro (BECK & ANDRES, 2005, p.135, tradu onossa). Entretanto, utiliza um conjunto de pr ticas completamente diferente daquelas 
sugeridas por Taylor. Ela procura eliminar esfor os desnecess rios em cada passo de 
fabrica o de seus autom veis, na cren a de que eliminando desperd cios se consegue 
avan ar mais rapidamente. 
A produ o enxuta mencionada nesta obra por conter princ pios que est o na 
base dos processos geis de desenvolvimento de software como o Extreme 
Programming. Ela caracterizada por um conjunto de sete princ pios b sicos 
(POPPENDIECK & POPPENDIECK, 2003): 
1. Eliminar desperd cios; 
2. Amplificar o aprendizado; 
3. Adiar decis es ao m ximo; 
4. Entregar o mais rapidamente poss vel; 
5. Delegar poder equipe; 
6. Incorporar integridade e 
7. Ver o todo. 
Estes princ pios incorporam os fatores citados anteriormente sobre a 
produtividade do trabalhador do conhecimento. Por esta raz o, existe uma chance de 
 40
que processos de desenvolvimento de software baseado nos mesmos possam 
efetivamente elevar a produtividade e a qualidade dos projetos de desenvolvimento. 
4.3.1 Eliminar desperd cios 
Ao analisar a produtividade do trabalhador manual, Taylor buscou formas de 
eliminar desperd cios e, portanto, obter maior produtividade. A forma utilizada por ele 
foi avaliar o modo de trabalho dos oper rios 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 fal ncia todas as f bricas artesanais de 
autom veis que existiam na poca (em torno de quinhentas) (POPPENDIECK & 
POPPENDIECK, 2003). 
O Sistema de Produ o da Toyota, por sua vez, tamb m priorizou a redu o de 
desperd cios, por m adotou estrat gias diferentes. Ela procurou colocar o cliente final 
no centro do problema e analisar toda a cadeia produtiva desde o momento em que o 
autom vel come ava a ser produzido at o momento de ser entregue ao cliente. 
Observando a cadeia, procurou identificar tudo aquilo que era feito e que n o 
gerava resultados percept veis para o cliente final. Se alguma coisa assim fosse 
identificada, seria considerada um desperd cio e, portanto, eliminada. A nfase foi em 
tentar reduzir, tanto quanto poss vel, a quantidade de trabalho executada e os 
subprodutos envolvidos, de modo a concentrar esfor os exclusivamente naquilo que 
pudesse gerar um resultado objetivo e percept vel para o cliente final. 
Desperd cio tudo aquilo que n o adiciona valor ao produto, valor tal 
como percebido pelo cliente. (...) Se um componente est colocado em 
uma estante pegando poeira, isso desperd cio. Se um ciclo de 
desenvolvimento coletou requisitos em um livro que est pegando 
poeira, isso desperd cio. Se uma planta industrial produz mais coisas 
do que imediatamente necess rio, isso desperd cio. Se os 
desenvolvedores codificam mais funcionalidades que o imediatamente 
necess rio, isso desperd cio, transferir o desenvolvimento de um 
 41
grupo para outro desperd cio. O ideal descobrir o que o cliente 
deseja e ent o fazer ou desenvolver isso e entregar exatamente o que 
ele quer, virtualmente de imediato. O que quer que atrapalhe a r pida 
satisfa o da necessidade do cliente um desperd cio 
(POPPENDIECK & POPPENDIECK, 2003, p.xxv, tradu o nossa). 
 
O Sistema de Produ o da Toyota tamb m busca eliminar desperd cios fazendo 
com que o estoque seja m nimo, ou simplesmente inexistente, e as entregas sejam 
efetuadas com a maior velocidade poss vel. 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 existir o para aprimorar o 
produto e o processo de produ o. Al m disso, eventuais falhas poder o ser descobertas 
cedo, facilitando a corre o e tornando-as menos custosas. Portanto, toda a produ o 
organizada em torno da id ia de aprendizado, melhoria cont nua e detec o r pida de 
falhas. 
4.3.2 Amplificar o aprendizado 
Ao contr rio da abordagem adotada por Taylor, a Toyota partiu da premissa de 
que a melhor forma de se executar um trabalho n o est tica, mas sim din mica. Sendo 
assim, busca fazer com que os oper rios 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 experi ncia e conhecimento. Al m 
disso, acredita que ningu m tem mais informa es para aprimorar o trabalho do ch o de 
f brica quanto as pessoas que est o l executando o trabalho. 
Ao fazer isso, a Toyota se afasta da id ia da separa o entre planejamento e 
execu o que faz parte do modelo Taylorista. Na Toyota, o oper rio respons vel por 
planejar, executar e aprimorar continuamente a forma de fazer ambas as coisas. O 
supervisor deixa de ser respons vel pelo planejamento centralizado e assume o papel de 
 42
treinador. Ele busca assegurar que a equipe tenha o aprendizado mais rico poss vel ao 
longo do trabalho (POPPENDIECK & POPPENDIECK, 2003). 
Desenvolver como criar uma receita, enquanto produzir como 
preparar o prato. Receitas s o criadas por chefs experientes que 
desenvolveram o instinto para o que funciona e a capacidade de 
adaptar os ingredientes dispon veis conforme a ocasi o. Ainda assim, 
at mesmo os grandes chefs produzem in meras varia es de um novo 
prato medida que iteram na dire o da receita que ter um excelente 
sabor e ser f cil de reproduzir. N o se espera que os chefs atinjam a 
receita perfeita na primeira tentativa; espera-se que eles produzam 
diversas varia es sobre o mesmo tema como parte natural do 
processo de aprendizagem (POPPENDIECK & POPPENDIECK, 
2003, p.xxv, tradu o nossa). 
 
Visto que o desenvolvimento de software envolve experimenta o e 
aprimoramento, a id ia 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. Al m disso, a r pida evolu o 
tecnol gica torna ainda mais essencial a ado o de formas de se amplificar o 
conhecimento em um projeto de software. 
4.3.3 Adiar decis es ao m ximo 
Ao se projetar um novo produto, tal como um software, existem decis es que 
podem ser afetadas por mudan as que venham a ocorrer ao longo do projeto. Por 
exemplo, mudan as ocorridas na economia ou de regras legislativas podem resultar na 
necessidade de mudan as em um projeto de software que vinha sendo conduzido dentro 
de uma institui o banc ria. O desenvolvimento de software tradicionalmente afetado 
por diversas mudan as ao longo dos projetos. 
O Sistema de Produ o da Toyota trabalha com o princ pio de adiar decis es at 
o ltimo momento respons vel, ou seja, aquele a partir do qual a n o tomada da decis o 
traria preju zos diretos ao projeto. O objetivo aguardar at que informa es mais 
 43
concretas estejam dispon veis para a equipe. Desta forma, procura-se reduzir a 
necessidade de re-trabalho em fun o de decis es tomadas cedo demais e que mais 
tarde possam ser for adas a mudar em fun o de mudan as nas circunst ncias 
(POPPENDIECK & POPPENDIECK, 2003). 
Pr ticas de desenvolvimento que permitam adiar a tomada de decis es 
s o eficazes em dom nios que envolvem incerteza, porque elas 
prov m uma abordagem baseada em op es. Diante de incertezas, a 
maioria dos mercados econ micos desenvolve op es para prover 
uma forma de o investidor evitar se trancar em decis es at que o 
futuro esteja mais perto e mais f cil de prever. Adiar decis es 
valioso porque poss vel tomar melhores decis es quando elas s o 
baseadas em fatos e n o especula es. Em um mercado em evolu o, 
manter decis es de design em aberto mais valioso que se 
comprometer cedo demais. Uma estrat gia chave para adiar 
compromissos durante o desenvolvimento de um sistema complexo 
incorporar a capacidade de mudan a no pr prio sistema 
(POPPENDIECK & POPPENDIECK, 2003, p.xxvi, tradu o nossa) 
 
O ExtremeProgramming trabalha com este conceito evitando a implementa o 
de funcionalidades baseadas em especula es. Al m disso, usa o desenvolvimento 
iterativo para assegurar que a equipe se concentre apenas em um conjunto reduzido de 
funcionalidades a cada itera o, deixando que o tempo traga maiores informa es sobre 
as funcionalidades futuras. 
4.3.4 Entregar o mais rapidamente poss vel 
Feedback um conceito chave na filosofia just-in-time, porque quanto mais rico 
e mais r pido for o feedback, maior ser o aprendizado. Quando uma equipe capaz de 
fazer entregas r pidas, mesmo que cada uma se refira apenas a um conjunto reduzido de 
funcionalidades, poss vel aprender e aprimorar o que est sendo produzido, bem como 
a forma de produ o. 
No desenvolvimento, o ciclo de descoberta cr tico para o 
aprendizado: fa a o design, implemente, obtenha feedback, melhore. 
Quanto mais curtos s o estes ciclos, mais se pode aprender. A 
velocidade assegura que os clientes obtenham o que desejam agora e 
 44
n o aquilo que eles precisavam ontem. Isso tamb m permite que eles 
adiem a tomada de decis es sobre o que eles realmente querem at 
que eles saibam mais (POPPENDIECK & POPPENDIECK, 2003, 
p.xxvi, tradu o nossa). 
 
 dif cil adiar decis es 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 per odo de seis meses de trabalho, o cliente pode vir a ter 
que aguardar no m nimo seis meses antes de ver qualquer mudan a de id ia ser 
colocada em pr tica. Por outro lado, se a equipe faz entregas a cada duas semanas, 
mudan as de rumo podem ser incorporadas mais rapidamente, o que permite adiar 
decis es sem que isso gere conseq ncias indesej veis (POPPENDIECK & 
POPPENDIECK, 2003). 
4.3.5 Delegar poder e uipe 
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 dom nio 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 poss vel. 
Executar atividades com a m xima qualidade depende de obter os 
detalhes corretamente e ningu m entende melhor dos detalhes que as 
pessoas que efetivamente executam o trabalho. Envolver 
desenvolvedores nos detalhes das decis es t cnicas fundamental 
para alcan ar a excel ncia. As pessoas na linha de frente combinam o 
conhecimento do detalhe do ltimo minuto com o poder de muitas 
mentes. Quando equipados com a qualifica o t cnica necess ria e 
guiados por um l der, eles tomar o melhores decis es t cnicas e 
melhores decis es de processo que qualquer um possa tomar por eles. 
Pelo fato de as decis es serem adiadas e a execu o ser r pida, n o 
poss vel para uma autoridade central orquestrar as atividades dos 
trabalhadores (POPPENDIECK & POPPENDIECK, 2003, p.xxvi, 
tradu o nossa). 
 
 45
Este mais um princ pio no qual a produ o enxuta se afasta da id ia de divis o 
entre planejamento e execu o. Ao inv s disso, procura-se assegurar que o 
conhecimento gerado no ch o de f brica circule da melhor maneira poss vel, se 
enrique a e retorne para o ch o de f brica rapidamente na forma de melhorias no 
processo. 
4.3.6 Incorporar integridade 
Outra forma de reduzir desperd cios assegurar que o produto tenha elevada 
integridade percept vel e conceitual. A integridade percept vel alcan ada quando um 
usu rio pensa Isso exatamente o que eu quero. Algu m entrou na minha cabe a 
(POPPENDIECK & POPPENDIECK, 2003, p.xxvii, tradu o nossa). Ou seja, quando 
o software possui uma interface intuitiva e f cil de utilizar, cujos conceitos se 
relacionam de maneira harm nica. 
Tal n vel de integridade importante para reduzir desperd cios na medida em 
que reduz ou elimina poss veis chamados dos usu rios contendo d vidas ou 
reclama es. Al m disso, eleva a satisfa o do usu rio final. 
A integridade conceitual, por sua vez, significa que os conceitos centrais do 
sistema trabalham em conjunto como um todo harm nico e coeso; e um fator cr tico 
para a cria o da percep o de integridade (POPPENDIECK & POPPENDIECK, 2003, 
p.xxvii, tradu o nossa). Em outras palavras, a partes se encaixam de maneira 
coerente, tornando f cil re-conectar os componentes e reduzindo as chances de defeitos. 
Ambos s o fatores que geram redu o de desperd cios. 
. 
Software ntegro possui uma arquitetura coerente, alcan a uma 
pontua o elevada em usabilidade e adequa o ao prop sito e 
manuten vel, adapt vel e extens vel. Pesquisas revelam que a 
integridade deriva de lideran a s bia, qualifica o significativa, 
comunica o eficaz e disciplina sadia; processos, procedimentos e 
 46
medi es n o s o substitutos adequados (POPPENDIECK & 
POPPENDIECK, 2003, p.xxvii, tradu o nossa). 
 
Os demais princ pios s o essenciais para se alcan ar integridade, na medida em 
que ajudam a reduzir os ciclos de feedback e, portanto, procuram amplificar o 
aprendizado. 
4.3.7 Ver o todo 
Para que um software alcance integridade percept vel e conceitual, importante 
que o todo seja harm nico. Portanto, n o desej vel que um determinado aspecto do 
projeto seja extremamente otimizado, enquanto outros tenham comportamentos 
deficientes. Para atingir integridade, o equil brio mais importante que o 
comportamento individual das partes envolvidas. necess rio que a equipe de 
desenvolvimento seja capaz de ter a vis o do todo permanentemente. 
Integridade em sistemas complexos requer profunda qualifica o em 
muitas reas diferentes. Um dos problemas mais intrat veis no 
desenvolvimento de produtos que especialistas em qualquer rea 
(banco de dados ou interface gr fica, por exemplo) t m a tend ncia de 
maximizar o desempenho de uma parte do produto representando a 
sua pr pria especialidade ao inv s de focar no desempenho geral do 
sistema. Com bastante freq ncia, o bem comum acaba sofrendo se as 
pessoas se comprometem primariamente com seus pr prios interesses 
especializados. Quando indiv duos ou organiza es s o medidos de 
acordo com suas contribui es especializadas, ao inv s do 
desempenho geral, prov vel que ocorra sub-otimiza o 
(POPPENDIECK & POPPENDIECK, 2003, p.xxvii, tradu o nossa). 
 
Para solucionar os problemas de sub-otimiza o equipes just-in-time procuram 
elevar o n vel das medi es. Procura-se medir o resultado final e n o as partes 
individuais, ou seja a aten o voltada para o equil brio do conjunto. Al m disso, 
utilizam-se os demais princ pios para estabelecer um fluxo de comunica o rico que 
ajude a equipe a ter a vis o do todo (POPPENDIECK & POPPENDIECK, 2003). 
 47
4.4 Processos de desenvolvimento de software 
Como vimos no segundo cap tulo, o termo crise do software acompanha a 
ind stria de software desde 1968, quando ocorreu a confer ncia da OTAN que cunhou o 
nome Engenharia de Software. O termo Engenharia de Software, deu origem a uma 
disciplina dentro da rea de computa o, embora originalmente tivesse sido criado 
apenas como uma provoca o, conforme os relatos de Peter Naur e Brian Randell. 
O termo engenharia de software foi escolhido deliberadamente para 
ser provocativo, cuja implica o era a necessidade de que a 
manufatura de software fosse baseada nos tipos de fundamentos 
te ricos e disciplinas pr ticas que s o tradicionais em ramos 
estabelecidos da engenharia (MCBREEN, 2002, p.xv, tradu o nossa). 
 
A Engenharia de Software surgiu com o objetivo de atender s necessidades da 
OTAN para o desenvolvimento de grandes sistemas de defesa. Em princ pio, seu escopo 
n o envolvia projetos de aplica es comerciais que, de um modo geral, s o bem 
menores e precisam entrar em produ o em pouco tempo. Nestes casos, s o raros os 
projetos desenvolvidos por equipes de mais de 20 pessoas e a maioria dos 
desenvolvedores trabalha em equipes com menos de 10 membros (MCBREEN, 2002, 
p.xvi, tradu o nossa). 
Segundoo IEEE Standard Computer Dictionary, a engenharia de software a 
aplica o de uma abordagem sistem tica, disciplinada e mensur vel para 
desenvolvimento, opera o e manuten o de software; isto , a aplica o da engenharia 
ao software (MCBREEN, 2002, p.7, tradu o nossa). O objetivo desta abordagem 
alcan ar na rea de software o mesmo n vel de previsibilidade, determinismo e acerto 
presente em outros ramos da engenharia. 
A Engenharia de Software deu origem a diversos processos de desenvolvimento. 
O mais conhecido e antigo deles o processo linear e seq encial de desenvolvimento, 
 48
tamb m conhecido como cascata. Ele organiza os projetos de software em quatro 
grandes etapas realizadas seq encialmente: an lise, design, codifica o e testes. Ainda 
hoje, este o modelo de desenvolvimento mais conhecido e amplamente utilizado 
(PRESSMAN, 1997). 
Ele pode ser relacionado facilmente aos princ pios da produ o em massa 
utilizados por Taylor. A evolu o seq encial do projeto se assemelha a uma f brica 
onde requisitos s o tratados como mat rias primas que s o transformadas medida que 
avan am pela linha de produ o. Cada transforma o gera um conjunto de artefatos a 
serem utilizados em etapas posteriores da fabrica o. Procura-se assegurar que cada 
artefato seja produzido corretamente para que o resultado final possa ser alcan ado com 
a mesma previsibilidade e determinismo de uma f brica. Portanto, evitar varia es 
fundamental. 
Dentro do projeto, grande parte dos artefatos representada por documentos 
criados para direcionar o trabalho que ser executado mais adiante na cadeia de 
produ o, os quais s o produzidos por profissionais especializados. Normalmente o 
processo de planejamento feito no in cio da cadeia, enquanto espera-se que os 
artefatos produzidos ao longo do projeto permitam que as ltimas etapas da cadeia 
sejam produzidas de forma cada vez mais mec nica e determin stica. Portanto, 
observam-se dois princ pios fundamentais da racionaliza o do trabalho manual: a 
especializa o e a centraliza o. 
Durante um projeto, tr s habilidades diferentes s o necess rias: 
 Analistas para documentar os requisitos; 
 Projetistas para criar a especifica o do design e 
 Programadores para escrever o c digo. 
A cada etapa, os autores de cada documento t m que adicionar 
detalhes extras porque n o sabem quem ir ler o documento mais 
adiante. Sem saber que tipo de conhecimento em comum pode ser 
assumido, a nica coisa segura a fazer adicionar o m ximo de 
detalhes e refer ncias cruzadas que o autor conhe a. Os revisores 
 49
precisam, ent o, analisar o documento para confirmar que ele esteja 
completo e sem ambig idades. Documenta o completa gera outro 
desafio: os membros da equipe precisam assegurar que os 
documentos permane am consistentes quando ocorrem mudan as nos 
requisitos ou mudan as de design feitas durante a codifica o. (...) 
Como as mudan as se tornam muito caras devido necessidade de 
atualiza o dos documentos, acabam sendo controladas e evitadas 
(MCBREEN, 2002, p.6, tradu o nossa). 
 
A utiliza o de um processo seq encial, baseado na cria o de artefatos, uma 
tentativa de disciplinar o desenvolvimento e buscar os n veis de previsibilidade 
desejados. Entretanto, freq entemente o resultado obtido apenas formalismo e n o 
disciplina. Em parte isso ocorre porque como j vimos, mudan as s o constantes em 
projetos de software e o modelo seq encial de desenvolvimento gera uma necessidade 
de control -las, o que, por sua vez, leva a um conflito de interesses entre clientes e 
equipes de desenvolvimento. Al m disso, esse modelo revela poucas chances para a 
aquisi o e utiliza o de feedback ao longo do desenvolvimento, elevando os riscos de 
que o projeto entregue algo que n o resolva as necessidades dos usu rios, mesmo 
seguindo um planejamento e controlando o processo. 
DeMarco (DEMARCO & BOEHM, 2002) acredita que o foco na gera o de 
artefatos, ao inv s de ajudar, acabou se tornando uma forma de agravar os problemas da 
crise do software . Segundo ele, Depois de quase 20 anos de obsess o por processos 
(...), o processo que encontro tipicamente em empresas clientes se tornou 
excessivamente baseado em documenta es, gerando a enxurrada de documentos que se 
tornou end mica (...). 
Ao longo do tempo, a ind stria de software criou alternativas para o processo de 
desenvolvimento em cascata. Algumas mantiveram parte das caracter sticas do modelo 
seq encial, enquanto outras se baseiam em formas completamente diferentes de se tratar 
os projetos de software. 
 50
O Rational Unified Process (RUP), por exemplo, traz avan os em rela o ao 
desenvolvimento em cascata, embora mantenha conceitos herdados do taylorismo. Ele 
um framework de processo bastante abrangente que, como tal, pode ser instanciado para 
atender s necessidades dos mais diversos tipos de projetos de software (JACOBSON, 
BOOCH et al., 1999). 
O RUP organizado em torno do conceito de melhores pr ticas . Ele prov 
um vasto arcabou o de pr ticas que procuram indicar a melhor forma de se realizar 
diversos tipos de atividades nos projetos de software. Neste sentido, ele se aproxima da 
abordagem taylorista que tamb m buscava identificar as melhores formas de estruturar 
o trabalho dentro de uma f brica. 
A proposta que, ao iniciar um projeto que utilizar o RUP, a equipe de 
desenvolvimento selecione dentre as melhores pr ticas dispon veis no arcabou o, 
aquelas que fazem sentido para o projeto em quest o. Embora seja uma proposta 
intuitivamente justific vel e louv vel, existem alguns problemas pr ticos que foram 
levantados por Boehm e Turner ((2003). 
Em seu arcabou o, o RUP engloba tamb m um vasto conjunto de artefatos, al m 
de melhores pr ticas . Determinar que pr ticas e artefatos devem ser adotados em um 
projeto uma atividade que pode ser bem feita por pessoas com treinamento, 
conhecimento e experi ncia no RUP. Entretanto, raro encontrar pessoas com essas 
caracter sticas nos projetos de software. Na falta delas, os membros das equipes de 
projeto tendem a adotar um conjunto desnecessariamente abrangente de pr ticas e 
artefatos temendo retirar elementos que possam fazer falta mais tarde, o que 
freq entemente leva burocratiza o dos projetos. 
 51
N o objetivo do RUP tornar os projetos pesados e enfadonhos , entretanto, 
o que Boehm e Turner observam que abordagens baseadas em boas pr ticas como o 
RUP (entre outras), freq entemente levam os projetos a se burocratizarem devido 
forma como os membros da equipe adotam os conceitos. O desconhecimento e a 
inexperi ncia normalmente se tornam um convite para o excesso, embora este n o seja o 
objetivo destes tipos de processos. 
Outra quest o contradit ria na id ia de melhores pr ticas est no fato de que 
n o existem melhores pr ticas em absoluto. A avalia o do que vem a ser uma melhor 
pr tica normalmente precisa levar em conta o contexto em que a pr tica utilizada. 
Pois, enquanto em determinados casos a pr tica pode se mostrar perfeita, em outros, 
pode se revelar desastrosa devido a caracter sticas do projeto. 
Al m de se basear em um conjunto de boas pr ticas, o RUP orientado a casos 
de uso, centrado na arquitetura, iterativo e incremental (JACOBSON, BOOCH et al., 
1999). Os casos de uso s o utilizados pelas equipes para capturar os requisitos 
funcionais e indicar que atores utilizar o as funcionalidades implementadas. 
Muitas equipes encaram os casos de uso como o mecanismo essencial para o 
levantamento dos requisitos, o que problem tico, porque significa que freq entemente 
os casos de uso ser o interpretados como elementos completos e suficientes para a 
implementa o das funcionalidades. Basear a compreens o dos requisitos em canais de 
comunica o escritos problem tico, conforme veremos no pr ximo cap tulo. 
Ao ser centrado na arquitetura, o RUP tamb m incentiva (direta ou 
indiretamente) as equipes a estabelecerem a arquitetura dosoftware antes de come ar a 
implementa o do mesmo. Portanto, a utiliza o de casos de uso para os requisitos e a 
elabora o de documentos que descrevem a arquitetura antes da implementa o 
 52
freq entemente levam equipes a adotarem um modelo de desenvolvimento bastante 
semelhando ao cascata, embora exista uma diferen a fundamental na proposta do RUP: 
o desenvolvimento iterativo e incremental. 
Em princ pio, o RUP estabelece o desenvolvimento iterativo e incremental como 
forma de incorporar feedback e aprendizado ao processo de desenvolvimento. 
Entretanto, comum equipes adotarem o RUP com itera es muito longas ou 
simplesmente executarem o projeto inteiro em uma nica itera o. Nestes casos, o que 
se observa a equipe executando um projeto de acordo com o processo em cascata, mas 
basicamente usando os artefatos do RUP para organizar a documenta o. 
Uma das maiores falhas do processo de desenvolvimento em cascata e de outras 
propostas de desenvolvimento baseadas em princ pios tayloristas a incapacidade de 
levar em conta o fator humano de forma apropriada. Como vimos anteriormente, Taylor 
tornou produtivo o trabalho manual, mas seus princ pios n o s o aplic veis para o 
trabalho do conhecimento, em especial o desenvolvimento de software. 
Um bom software n o se origina de ferramentas CASE, programa o 
visual, prototipagem r pida ou tecnologia de objetos. Um bom 
software resultado de pessoas. Assim como o caso de softwares 
ruins. (...) j que software criado por pessoas e usado por pessoas, 
uma melhor compreens o das pessoas como executam o trabalho e 
como trabalham em conjunto a base para um melhor 
desenvolvimento de software e para criarmos softwares melhores 
(CONSTANTINE, 2001, p.xvii, tradu o nossa). 
 
Na d cada de 1990, alguns profissionais da ind stria de software come aram a 
propor novos processos de desenvolvimento que fossem mais adequados para lidar com 
os aspectos humanos dos projetos de software. Em fevereiro de 2001, 17 profissionais 
experientes se reuniram em Utah (EUA) para discutir suas pr ticas de desenvolvimento 
e suas propostas alternativas para evitar os processos de desenvolvimento 
excessivamente baseados em documenta es e formalismos. Naquele momento, 
 53
decidiram organizar suas propostas sob um nome comum: desenvolvimento gil de 
software. Isto foi feito pelo lan amento do Manifesto pelo Desenvolvimento gil de 
Software3. 
O manifesto estabelece um conjunto de valores que s o adotados nos projetos 
geis: 
 Indiv duos e intera es ao inv s de processos e ferramentas; 
 Software funcionando ao inv s de documenta o abrangente; 
 Colabora o com o cliente ao inv s de negocia o de contratos e 
 Responder a mudan as ao inv s de seguir um plano. 
A proposta que, embora exista valor nos itens direita, os processos geis 
valorizam mais os itens que est o esquerda. Atualmente, estes s o os principais 
processos geis conhecidos: Scrum, Dynamic Systems Development Method (DSDM), 
Crystal Methods, Feature-Driven Development (FDD), Lean Development (LD), 
Extreme Programming e Adaptative Software Development (HIGHSMITH, 2002). 
Uma das principais diferen as dos processos geis em rela o aos seus 
antecessores o conceito chamado de barely sufficient, ou seja, m nimo necess rio. 
Enquanto abordagens como o RUP (entre outras) procuram estabelecer um arcabou o 
de melhores pr ticas , os processos geis sugerem o uso de um conjunto bastante 
reduzido de pr ticas. Tal conjunto pode se revelar suficiente em muitos projetos 
comerciais que envolvam equipes reduzidas, tais como os que foram mencionados no 
in cio desta se o. 
O objetivo come ar os projetos de software de forma simples, com poucas 
pr ticas e avaliar os resultados. Caso pr ticas ou artefatos faltem ao projeto, deve-se 
 
3 http://www.agilemanifesto.org. 
 54
busc -los em outras propostas metodol gicas. Com isso, procura-se evitar as chances de 
que um projeto seja iniciado com um conjunto desnecessariamente elevado de pr ticas e 
artefatos que possam torn -lo burocr tico. A nfase passa a ser de s trazer elementos 
novos para o projeto quanto os mesmos realmente se mostram necess rios (BOEHM & 
TURNER, 2003; COCKBURN, 2002; HIGHSMITH, 2002). O pr ximo cap tulo 
apresentar o Extreme Programming que representa um dos processos geis mais 
conhecidos e utilizados.