A_Nova_Metodologia

Prévia do material em texto

Este artigo é uma tradução do artigo original, The New Methodology, escrito por Martin 
Fowler. A tradução poderá ter alguns erros e partes que não capturem da melhor forma 
as palavras do autor. No processo de revisão tentarei optimizar a tradução. Agradeço a 
quem encontrar algumas falhas que me avise, de modo a oferecer melhor qualidade. O 
artigo ainda não se encontra totalmente traduzido. Irei actualizando esta mensagem 
também para acrescentar o que falta.
A Nova Metodologia
Martin Fowler
A Nova Metodologia ......................................................................................................... 1 
Martin Fowler ................................................................................................................ 1 
Do Nada, para o Monumental, para o Ágil ........................................................................ 1 
Previsível contra Adaptável ............................................................................................... 3 
Separação de Desenho e Construção ............................................................................. 3 
A Imprevisibilidade dos Requisitos ............................................................................... 4 
A previsibilidade é impossível? ..................................................................................... 5 
Controlando um Processo Imprevisível – Iterações ...................................................... 6 
O Cliente Adaptável ...................................................................................................... 7 
Colocando as Pessoas Primeiro ......................................................................................... 8 
Unidades de Programação Compatíveis e Uníveis ........................................................ 8 
Os programadores são profissionais responsáveis ......................................................... 9 
Gerir um Processo Orientado pelas Pessoas ................................................................ 10 
A Dificuldade da Medição ........................................................................................... 11 
O Papel da Liderança do Negócio ............................................................................... 11 
O Processo Auto-Adaptável ............................................................................................ 12 
As Metodologias .............................................................................................................. 13 
XP (Extreme Programming) ........................................................................................ 13 
Família Crystal do Cockburn ....................................................................................... 14 
Open Source ................................................................................................................ 15 
Desenvolvimento Adaptável de Software do Highsmith ............................................ 16 
Nos últimos anos tem havido um interesse crescente nas metodologias ágeis. 
Alternativamente caracterizadas como um antídoto à burocracia ou uma licença para 
hackar, elas suscitaram o interesse em todo o campo do software. Neste ensaio eu 
exploro os motivos dos métodos ágeis, focando não tanto no seu peso mas na sua 
natureza adaptativa e na sua orientação às pessoas. Dou também um sumário e 
referências aos processos nesta escola e considero os factores que devem influenciar a 
tua escolha sobre se deves percorrer este novo caminho.
Do Nada, para o Monumental, para o Ágil
A maior parte do desenvolvimento de software é uma actividade caótica, 
frequentemente caracterizada pela frase "codifica e corrige". O software é escrito sem 
grande planeamento, e o desenho do sistema é remendado com muitas decisões de curto 
prazo. Isto efectivamente funciona bem quando o sistema é pequeno, mas quando este 
começa a crescer começa a ser cada vez mais difícil acrescentar novas funcionalidades. 
Além disso, os erros começam a ser mais frequentes e mais difíceis de corrigir. Um 
sinal típico de um sistema destes é uma longa fase de testes após a "conclusão de uma 
funcionalidade". Uma longa fase de testes como esta destroi quaisquer calendarizações, 
dado que o teste e o debug são impossíveis de calendarizar.
Vivemos com este estilo de desenvolvimento há bastante tempo, mas também temos 
uma alternativa há bastante tempo: Metodologia. As metodologias impõem um processo 
disciplinado sobre o desenvolvimento de software com o objectivo de tornar o 
desenvolvimento de software mais previsível e mais eficiente. É conseguido isto 
desenvolvendo um processo detalhado com um forte ênfase no planeamento inspirado 
pelas outras disciplinas de engenharia - é por isso que eu tenho tendência a referir-me a 
elas como metodologias de engenharia.
As metodologias de engenharia estão connosco há muito tempo. Elas não se têm 
evidenciado por serem extremamente bem sucedidas. Ainda se notam menos por serem 
populares. A crítica mais frequente a estas metodologias é que são burocráticas. 
Existem tantas tarefas a realizar para seguir a metodologia que todo o ritmo de 
desenvolvimento diminui.
Como reacção a estas metodologias, um novo grupo de metodologias apareceram nos 
últimos anos. Durante algum tempo estas foram conhecidas como metodologias leves, 
mas agora é aceite o termo metodologias ágeis. Para muitas pessoas o interesse nas 
metodologias ágeis é a sua reacção à burocracia das metodologias monumentais. Estes 
novos métodos tentar atingir um compromisso útil entre nenhum processo e demasiado 
processo, oferecendo um processo suficiente para obter um compromisso razoável.
O resultado disto tudo é que os método ágeis têm algumas diferenças significativas na 
ênfase relativamente aos métodos de engenharia. A diferença mais notável é que eles 
são menos orientados à documentação, tipicamente enfatizando uma menor quantidade 
de documentação para uma dada tarefa. Em muitos sentidos são mais orientados ao 
código: seguindo um caminho quediz que a parte chave da documentação é o código 
fonte.
No entanto eu não penso que este é o ponto chave acerca dos métodos ágeis. A falta de 
documentação é um sintoma de duas diferenças ainda mais profundas:
- Os métodos ágeis são adaptáveis em vez de preditivos. Os métodos de 
engenharia tendem a tentar planear uma grande parte do processo de software 
em grande detalhe para um grande intervalo de tempo. Isto funciona bem até que 
as coisas mudam. Assim sendo, a sua natureza é resistir à mudança. Para 
os métodos ágeis, por sua vez, as mudanças são bem-vindas. Eles tentam ser 
processos que se adaptam e prosperam na mudança, chegando ao pondo de se 
mudarem a si próprios.
- Os métodos ágeis são orientados à pessoa em vez de serem orientados ao 
processo. O objectivo dos métodos de engenharia é definir um processo que 
funciona bem independentemente de quem o usar. Os métodos ágeis partem do 
pressuposto que nenhum processo irá alguma vez substituir as capacidades de 
uma equipa de desenvolvimento, logo o papel de um processo é suportar a 
equipa de desenvolvimento no seu trabalho.
Nas secções seguintes eu vou explorar estas diferenças em maior detalhe, para que 
possam entender como é um processo adaptável e centrado nas pessoas, os seus 
benefícios e as suas desvantagens e quando é algo que deves usar: tanto como um 
projectista ou como um cliente de software.
Previsível contra Adaptável
Separação de Desenho e Construção
A inspiração habitual das metodologias são as disciplinas de engenharia como a 
engenharia civil ou mecânica. Estas disciplinas colocam um grande ênfase no 
planeamento antes da construção. Estes engenheiros trabalham num conjunto de 
esquemas que indicam com precisão o que necessita de ser construído e como é que as 
várias partes se irão reunir. Muitas decisões de desenho, como saber como gerir a carga 
numa ponte, são efectuadas à medida que os esquemas são produzidos. Os esquemas 
são então entregues a um grupo diferente, frequentemente de uma empresa diferente, 
para serem construídos. Assume-se que o processo de construção irá seguir os 
esquemas. Na prática, os construtores encontram alguns problemas, mas estes são 
tipicamente pequenos.
Sendo que os esquemas especificam as peças e como é que elas se irão juntar, estes 
funcionam como a base de um plano de construção detalhado. Um plano desses 
consegue determinar quais as tarefas que necessitam de ser realizadas e que 
dependências existem entre elas. Isto permite um planeamento e um orçamento para a 
construção razoavelmente previsíveis. Também se diz em detalhe como é que as 
pessoas que realizam a construção devem realizar o seu trabalho. Permite-se assim que a 
construção tenha menos capacidade intelectual, tendo no entanto com frequência grande 
capacidade manual.
Assim sendo, o que vemos aqui são duas actividades fundamentalmente diferentes. 
Desenho que é difícil de prever e requer pessoas caras e criativas, e construção que é 
mais fácil de prever. Assim que se tem o desenho, podemos planear a construção. Assim 
que tivermos o plano para a construção, podemos então lidar com a construção de uma 
forma muito mais previsível. Na engenharia civil construção é muito maior que o 
desenho e planeamento em termos de custo e de tempo.
Então a abordagem para a metodologias de engenharia em software assemelham-se a 
isto: queremos um planeamento previsível que é capaz de utilizar pessoas com poucas 
capacidades. Para fazer isto temos de separar o desenho e a construção. Assim sendo 
necessitamos de determinar como realizar o desenho para o software de forma a que a 
construção seja linear assim que o planeamento esteja realizado.
Então que forma este planeamento pode tomar? Para muitos, este é o papel de notações 
de desenho como o UML. Se conseguirmos realizar todas as decisões significativas 
utilizando o UML, conseguimos desenvolver um plano de construção e entregar estes 
desenhos a programadores como actividade de construção.
Mas aqui está a questão crucial. Consegues ter um desenho que é capaz de tornar a 
programação numa actividade previsível de construção? E se sim, o custo de realizar 
isto é suficientemente pequeno para justificar esta abordagem?
Todas estas coisas trazem algumas questões. A primeira relaciona-se com a dificuldade 
de ter um desenho ao estilo de UML num estado que possa ser dado aos programadores. 
O problema com um desenho ao estilo de UML é que pode parecer muito bem no papel, 
mas ainda assim com sérias falhas quando se efectivamente tem que se programar. Os 
modelos que os engenheiros civis utilizam baseiam-se em muitos anos de prática que 
estão enraizados nos códigos de engenharia. Além disso os pontos essenciais, como a 
forma (...). A única verificação que podemos realizar em diagramas ao estilo de UML é 
a verificação com os pares. Enquanto isto pode ajudar, leva a erros no desenho que 
frequentemente só são descobertos durante a codificação e teste. Mesmo os desenhoers 
mais capacitados, como eu considero ser, são frequentemente surpreendidos quando se 
torna um dado desenho em software.
Outro problema é o do custo comparativo. Quando se constrói uma ponte, o custo do 
esforço de desenho é cerca de 10% do trabalho, sendo o resto da construção. Em 
software a quantidade de tempo despendida na codificação é muito, muito menor que o 
McConnell sugere para um projecto grande, somente 15% do projecto é código e testes, 
uma razão quase perfeitamente inversa da construção de pontes. Mesmo que se 
considere todos os testes como parte da construção, então o desenho é ainda assim 50% 
de todo o trabalho. Isto levanta uma questão importante sobre a natureza do desenho em 
software comparando com o seu papel nos outros ramos de engenharia.
Estes tipos de questões levaram o Jack Reeves a sugerir que efectivamente o código 
fonte é um documento de desenho e que a fase de construção é a utilização do 
compilador e do linker. Efectivamente tudo o que seja construção pode e deve ser 
automatizado.
Isto leva a algumas conclusões importantes:
- Em software: construção é tão barata que é grátis.
- Em software todo o esforço é em desenho, e assim necessita de pessoas 
talentosas e criativas.
- O processo criativo não pode ser planeado facilmente, e assim a previsibilidade 
pode ser um objectivo impossível.
- Devemos ser bastante atenciosos à metáfora da engenharia tradicional para 
construir software. É um tipo diferente de actividade e requer processos 
diferentes.
A Imprevisibilidade dos Requisitos
Existe uma frase recorrente que oiço em todos os problemas dos projectos em que 
participei. Os projectistas vêm até mim e dizem "o problema com este projecto é que os 
requisitos estão sempre a mudar". O que eu acho surpreendente acerca desta situação é 
que as pessoas se surpreendem com isto. No processo de construção de software as 
mudanças de requisitos são a norma, a questão é o que vamos fazer sobre isso.
Um caminho é tratar as mudanças de requisitos como resultado de uma fraca engenharia 
de requisitos. A ideia por detrás da engenharia de requisitos é obter uma imagem 
completamente compreendida dos requisitos antes de se começar a desenvolver 
software, levar o cliente a aceitar esses requisitos e depois montar os procedimentos que 
limitam as mudanças de requisitos após a aceitação.
Um problema com isto é que simplesmente tentar perceber as opções para os requisitos 
é complicado. É ainda mais complicado porque a organização de desenvolvimento 
tipicamente não oferece informação de custo sobre os requisitos. Acaba-se na situação 
em que podes pretender um tecto de abrir para o carro, mas o responsável pelas vendas 
não consegue dizer se isso vai adicionar $10 ao preço do carroou $10,000. Sem grande 
ideia do custo, como é que se pode decidir se aceitamos o custo do tecto de abrir?
A estimação é complicada por muitos motivos. Parte disso é que o desenvolvimento de 
software é uma actividade de desenho, e consequentemente difícil de planear e custear. 
Parte disso é que os materiais básicos mudam rapidamente. Parte disso é que depende 
muito em cada pessoa que está envolvida e as pessoas são difíceis e prever e quantificar.
A natureza intangível do software também conta. É muito difícil ver qual o valor de 
uma funcionalidade de software antes de esta ser efectivamente utilizada. Somente 
quando se começa a utilizar uma versão inicial de algum software é que se começa 
realmente a perceber quais são as funcionalidades que têm valor e as que não.
Isto leva a um ponto irónico em que as pessoas esperam que os requisitos devam ser 
alteráveis. Afinal de contas o software é suposto ser maleável. Então os requisitos não 
só são maleáveis, como devem ser maleáveis. É necessário um grande esforço para que 
os clientes do software corrijam os requisitos. É ainda pior se eles já tiverem trabalhado 
em desenvolvimento de software porque eles sabem que o software é facilmente 
alterável.
Mas se conseguisses isso tudo e obter um conjunto de requisitos preciso e estável ainda 
assim provavelmente estarias condenado. Na economia de hoje as forças fundamentais 
de negócio estão a mudar o valor das funcionalidades de software muito rapidamente. O 
que pode ser um bom conjunto de funcionalidades agora, não será um bom conjunto 
daqui a seis meses. Mesmo que os clientes consigam corrigir os seus requisitos, o 
mundo do negócio não vai esperar por eles. E muitas das mudanças no mundo do 
negócio são completamente imprevisíveis: quem disser o contrário está a mentir, ou já 
conseguiu um bilião no mercado das acções.
Tudo o resto no desenvolvimento de software depende nos requisitos. Se não 
conseguires requisitos estáveis não conseguirás um bom planeamento.
A previsibilidade é impossível?
Na generalidade, não. Existem alguns desenvolvimentos de software onde a 
previsibilidade é possível. Organizações como o grupo de software do vaivém espacial 
da NASA são um exemplo de onde o desenvolvimento de software pode ser previsível. 
Requer muita cerimónia, bastante tempo, uma equipa grande, e requisitos estáveis. 
Existem por aí projectos que são vaivéns espaciais. No entanto, não acho que muito do 
negócio de software se encontre nesta categoria. Para isto, é necessário um tipo de 
processo diferente.
Um dos grandes perigos é fingir que se consegue seguir um processo previsível quando 
não se consegue. Pessoas que trabalham numa metodologia não são muito boas a 
identificar situações fronteira: os pontos onde a metodologia passa de apropriada a 
inapropriada. Muitos metodologistas querem que as suas metodologias sejam utilizáveis 
por todos, logo não entendem nem publicitam as suas condições de fronteira. Isto leva a 
que as pessoas utilizem uma metodologia nas circunstâncias erradas, como utilizar uma 
metodologia previsível numa situação imprevisível.
Existe uma forte tentação para fazer isso. Previsibilidade é uma propriedade muito 
desejável. No entanto, se se acredita que se pode ser previsível quando não se pode, isso 
leva a situações onde as pessoas constróem um plano cedo e depois não gerem 
apropriadamente a situação quando o plano não resulta. Vê-se o plano e a realidade 
lentamente a afastar-se. Por um grande período pode-se fingir que o plano ainda é 
válido. Mas em algum ponto a distância torna-se bastante elevada e o plano vai abaixo. 
Tipicamente esta queda é dolorosa.
Então se estás numa situação não previsível então não se pode utilizar uma metodologia 
previsível. (...) Significa que muitos dos modelos para controlar projectos, muitos dos 
modelos para toda a relação com o cliente, já não são válidos. Os benefícios da 
previsibilidade são tão grandes, é difícil deixá-los ir. Tal como muitos problemas a parte 
mais difícil é perceber que o problema existe.
No entanto deixar ir a previsibilidade não significa que se tenha de entrar num caos 
incontrolável. Em vez disso é necessário um processo que ofereça controlo sobre a 
imprevisibilidade. É isso que é a adaptividade trata.
Controlando um Processo Imprevisível – Iterações
Então como é que nos podemos controlar num mundo imprevisível? A parte mais 
importante, e também a mais difícil, é perceber exactamente onde nos encontramos. 
Necessitamos de um mecanismo de retorno honesto onde podemos dizer com precisão a 
situação em intervalos frequentes.
A chave para este retorno é um desenvolvimento iterativo. Esta ideia não é nova. O 
desenvolvimento iterativo está por aqui sob muitos nomes: incremental, evolucionário, 
faseado, em espiral... muitos nomes. A chave para o desenvolvimento iterativo é 
produzir frequentes versões funcionais do sistema final onde se possui um subconjunto 
das funcionalidades requeridas. Estes sistemas funcionais são limitados em 
funcionalidade, mas devem ser fieis aos objectivos do sistema final. Devem ser 
totalmente integrados e testados cuidadosamente como uma entrega final.
O objectivo disto é que não existe nada como um sistema integrado e testado para 
oferecer uma dose de realidade ao projecto. Os documentos podem esconder muitos 
tipos de falhas. Código não testado pode esconder muitas falhas. Mas quando as pessoas 
realmente se sentam em frente ao sistema e trabalham com ele, aí as falhas se tornam 
verdadeiramente aparentes: tanto em termos de bugs como em termos de requisitos mal 
entendidos.
Desenvolvimento iterativo faz sentido em processos previsíveis também. Mas é 
essencial em processos adaptáveis porque estes necessitam de lidar com um grande 
número de mudanças nas funcionalidades requeridas. Isto leva a um estilo de 
planeamento onde os planos a longo prazo são muito fluidos, e os únicos planos estáveis 
são os planos a curto prazo que são feitos para uma única iteração. O desenvolvimento 
iterativo oferece uma base firme em cada iteração sobre a qual se podem desenvolver os 
planos futuros.
A questão chave para isto é qual deve ser a duração de uma iteração. Pessoas diferentes 
dão respostas diferentes. XP sugere que as iterações sejam entre uma a três semanas. 
SCRUM sugere uma duração de um mês. Crystal estica um pouco mais. A tendência, no 
entanto, é realizar cada iteração no tempo mais curto possível. Isto oferece um retorno 
frequente, para que se possa saber onde nos encontramos com mais frequência.
O Cliente Adaptável
Este tipo de processo adaptável requer um diferente tipo de relação com o cliente em 
relação ao que os outros frequentemente consideravam, particularmente quando o 
desenvolvimento é realizado por uma firma separada. Quando se contrata uma firma 
separada para realizar desenvolvimento de software, muitos clientes preferem um 
contrato de preço fixo. Dizer aos projectistas o que se pretende, perguntar por um 
orçamento, aceitar o orçamento e depois o ónus está na organização de desenvolvimento 
para construir o software.
Um contrato de preço fixo requer requisitos estáveis e portanto um processo preditivo. 
Processos adaptativos e requisitos estáveis implicam que não se pode trabalhar com a 
usual noção de preço fixo. Tentar encaixar um modelo de preço fixo num processo 
adaptativo acabar por ser uma explosão muito dolorosa. A parte pior desta explosão é 
que o cliente sai tão lesado quando a companhia de desenvolvimento de software. 
Afinal de contas o cliente não pretende um software a não ser que o seu negócio 
necessite dele. Se ele não o conseguir o seu negócio sofre. Então mesmo que não 
paguem nada à companhia de desenvolvimento, perdemna mesma. Na realidade 
perdem mais do que pagariam pelo software (porque pagariam pelo software se o valor 
de negócio do software fosse menor?)
Então existem perigos para ambos os lados em assinar um contrato de preço fixo onde 
um processo previsível não pode ser utilizado. Isto significa que o cliente tem de 
trabalhar de forma diferente.
Isto não significa que não é possível determinar um orçamento para o software no 
início. O que significa é que não se pode fixar o tempo, preço e profundidade. A 
abordagem ágil típica é fixar tempo e preço e permitir que a profundidade varie de 
forma controlada.
Num processo adaptável o cliente tem um controlo mais detalhado sobre o processo de 
desenvolvimento de software. Em cada iteração ele verifica o progresso e altera a 
direcção do desenvolvimento do software. Isto leva a uma relação muito mais próxima 
com os projectistas de software, uma verdadeira parceria de negócio. Este nível de 
compromisso não é para todas as organizações clientes, nem para todos os projectistas 
de software; mas é essencial fazer o processo adaptável funcionar correctamente.
Tudo isto tem um número de vantagens para o cliente. Para começar ele obtém um 
desenvolvimento de software muito mais responsivo. Um utilizável, no entanto 
mínimo, sistema pode ir para produção atempadamente. O cliente pode então alterar as 
suas capacidades de acordo com as mudanças no negócio, e também pela aprendizagem 
de como o sistema é utilizado na realidade.
(...) O problema com os processos preditivos é que a qualidade é medida em 
conformidade com o plano. Isto torna difícil às pessoas para notarem quando a realidade 
e o plano divergem. O resultado comum é um grande deslize no planeamento tarde no 
projecto. Num projecto ágil existe actualização constante do planeamento em cada 
iteração. Se más notícias estão para aparecer, tendem a aparecer mais cedo, quando 
ainda existe tempo para fazer alguma coisa sobre isso. Efectivamente este controlo de 
risco é a vantagem chave do desenvolvimento iterativo. Métodos ágeis levam isto mais 
fundo mantendo as durações das iterações pequenas, mas também vendo estas variações 
como oportunidades.
Isto é um suporte importante que constitui um projecto bem sucedido. Um projecto 
previsível é frequentemente medido pelo quando segue o seu plano. Um projecto que se 
encontra dentro do tempo e custo é considerado ser um sucesso. Esta medida não faz 
sentido num ambiente ágil. Para os ágeis a questão é o valor de negócio - recebeu o 
cliente software que tem mais valor para ele que o dinheiro que investiu. Um bom 
projecto previsível segue o plano, um bom projecto ágil vai construir algo diferente e 
melhor que o plano original previu.
Colocando as Pessoas Primeiro
Executar um processo adaptável não é fácil. Em particular, requer uma equipa de 
projectistas bastante eficiente. A equipa necessita de ser eficiente tanto na qualidade dos 
indivíduos, e na forma como a equipa se junta. Existe também uma sinergia 
interessante: não só a adaptabilidade necessita de uma equipa forte, como a maioria dos 
bons programadores preferem um processo adaptável.
Unidades de Programação Compatíveis e Uníveis
Um dos objectivos das metodologias tradicionais é desenvolver um processo onde as 
pessoas envolvidas são partes substituíveis. Com um processo destes pode-se tratar as 
pessoas como recursos que estão disponíveis em vários tipos. Tem-se um analista, 
alguns programadores, alguns testers, um gestor. Os indivíduos não são tão importantes, 
somente os papeis são importantes. Desta forma se for planeado um projecto não 
interessa qual é um analista e os testers que se tenham, desde que se saiba quantos se 
tem e de que forma o número de recursos afecta o plano.
Mas isso levanta uma questão chave: são as pessoas envolvidas no desenvolvimento de 
software partes substituíveis? Uma das características chave os métodos ágeis é rejeitar 
essa assunção.
Talvez a mais explicita rejeição das pessoas como recursos é Alistair Cockburn. No seu 
artigo, Characterizing People as Non-Linear, First-Order Components in Software 
Development, ele refere que processos preditivos requerem componentes que se 
comportem numa forma previsível. No entanto as pessoas não são componentes 
previsíveis. Para além disso os seus estudos de projectos de software levaram-no a 
concluir que as pessoas são o factor mais importante no desenvolvimento de software.
No título, [deste artigo] eu refiro as pessoas como "componentes". É assim que as pessoas 
são tratadas na literatura de desenho de processos/metodologia. O erro desta abordagem é 
que as "pessoas" são altamente variáveis e não lineares, com modos de sucesso e falha 
únicos. Estes factores são de primeira ordem, factores não negligenciáveis. A falha dos 
desenhoers de processo e metodologia em considerarem isto contribui com todos os tipos de 
trajectórias de projecto não planeadas que frequentemente vemos.
-- [Cockburn non-linear]
Questionam-se se a natureza do desenvolvimento de software trabalha contra nós aqui. 
Quando nos encontramos a programar um computador, controlamos um dispositivo 
previsível. Já que estamos neste negócio porque somos bons em fazer isso, estamos 
idealmente destinados a falhar quando nos deparamos com seres humanos.
Mesmo sendo o Cockburn o mais explicito na sua visão centrada nas pessoas do 
desenvolvimento de software, a noção de pessoas primeiro é um tema comum com 
muitos pensadores em software. O problema, muito frequentemente, é que a 
metodologia se tem oposto à noção de pessoas como um factor de primeira ordem no 
sucesso de um projecto.
Isto cria um forte efeito de retorno positivo. Se se esperar que todos os projectistas 
sejam unidades de programação compatíveis e uníveis, não se tenta tratá-los como 
indivíduos. Isto reduz a moral (e produtividade). As melhores pessoas procurarão um 
melhor lugar para estar, e acabarás com o que pretendias: unidades de programação 
compatíveis e uníveis.
Decidir que as pessoas vêm primeiro é uma grande decisão, que requer uma grande 
determinação para levar para a frente. A noção de pessoas como recursos está 
fortemente enraizada no pensamento de negócio, as suas raízes vêm do impacto da 
abordagem de gestão cientifica de Frederick Taylor. Na gestão de uma fábrica, esta 
abordagem Tayloristica pode fazer sentido. Mas para o trabalho altamente profissional e 
criativo, como eu acredito que o desenvolvimento de software seja, isto não serve. (E 
efectivamente a industria moderna está também a afastar-se do modelo Taylorista.)
Os programadores são profissionais responsáveis
Um ponto chave na noção Taylorista é que as pessoas que realizam o trabalho não são 
pessoas que conseguem perceber a melhor forma de o fazer. Numa fábrica isto pode ser 
verdade por várias razões. Parte disto é que muitos trabalhadores fabris não são as 
pessoas mais inteligentes ou criativas, e em parte isto é devido à tensão existente entre a 
gestão e os trabalhadores no sentido em que a gestão obtém mais dinheiro quando os 
trabalhadores obtêm menos.
A história recente mostra-nos o quando isto não é verdade para o desenvolvimento de 
software. Pessoas cada vez mais brilhantes e capazes são atraídas pelo desenvolvimento 
de software, atraídas tanto pela sua popularidade como por prémios potencialmente 
elevados. (Ambos me afastaram da engenharia electrónica.) Esquemas como (??) 
alinham os interesses dos programadores com os da companhia.
(Pode existir um efeito geracional aqui. Algumas provas anedóticas fazem-me pensar se 
mais pessoas brilhantes se aventuraram na engenharia de software nos últimos dez anos 
ou assim. Se sim esta seria uma razão do porquê da existência de um culto dajuventude 
no negócio dos computadores, como todos os cultos necessita de ter um ponto de 
verdade nele.)
Quando se pretende contratar e reter boas pessoas, necessita-se de reconhecer que eles 
são profissionais competentes. Assim sendo eles são as melhores pessoas para decidir 
como conduzir o seu trabalho técnico. A noção Taylorista de um departamento de 
planeamento separado que decide como fazer as coisas funciona apenas se os 
planeadores perceberem como fazer o trabalho melhor que aqueles que estão a fazer. Se 
tens pessoas brilhantes e motivadas a realizar o trabalho então isto não serve.
Gerir um Processo Orientado pelas Pessoas
A orientação por pessoas manifesta-se de diversas formas nos processos ágeis. Isto leva 
a efeitos diferentes, não sendo todos eles consistentes.
Um dos elementos chave é a aceitação do processo em vez da imposição do processo. 
Frequentemente os processos de software são impostos por figuras de gestão. Desta 
forma eles são frequentemente resistidos, particularmente quando as figuras de gestão 
estiveram muito tempo afastadas de desenvolvimento activo. Aceitar um processo 
requer dedicação, e assim sendo necessita do envolvimento activo de toda a equipa.
Isto resulta num resultado interessante em que apenas os projectistas podem decidir por 
seguir um processo adaptável. Isto é particularmente verdade para XP, que requer muita 
disciplina para executar. É aqui que Crystal é um complemento efectivo pois foca a 
mínima disciplina.
Outro ponto é que os projectistas têm de ser capazes de efectuar todas as decisões 
técnicas. XP vai ao centro desta questão onde, no seu processo de planeamento, diz que 
apenas os projectistas podem estimar quanto tempo demorará a realizar uma tarefa.
Esta liderança técnica é uma grande mudança para muitas pessoas em posições de 
gestão. Uma abordagem destas requer partilha de responsabilidade onde os projectistas 
e a gestão têm um lugar igual na liderança do projecto. De notar que eu disse igual. A 
gestão ainda tem o seu papel, mas reconhece a experiência dos projectistas.
Uma razão importante para isto é a taxa de mudança de tecnologia na nossa industria. 
Após alguns anos o conhecimento técnico torna-se obsoleto. Esta meia vida de 
capacidades técnicas não tem paralelo em qualquer outra industria. Até pessoas técnicas 
têm de reconhecer que entrar na gestão significa que as suas capacidades técnicas são 
desaparecer depressa. Ex-projectistas necessitam de reconhecer que as suas capacidades 
técnicas vão desaparecer depressa e que necessitam de confiar e depender dos 
projectistas actuais.
A Dificuldade da Medição
Se tens um processo onde as pessoas que dizem como é que o trabalho deve ser 
realizado são diferentes das pessoas que efectivamente o realizam, os chefes necessitam 
de alguma forma de medição sobre o quão efectivos os trabalhadores são. Na gestão 
cientifica houve um grande esforço para desenvolver abordagens objectivas para medir 
o resultado das pessoas.
Isto é particularmente relevante para o software devido à dificuldade de aplicar 
medições ao software. Apesar dos nossos melhores esforços não formos capazes de 
medir as coisas mais simples acerca do software, como a produtividade. Sem boas 
medições para estas coisas, qualquer tipo de controlo externo está acabado.
A introdução de gestão medida sem boas medições leva aos seus próprios problemas. 
Robert Austin efectuou uma excelente discussão sobre isto. Ele refere que quando se 
mede a performance tem que se ter todos os factores importantes sob medição. 
Qualquer coisa que esteja em falta tem o resultado inevitável que os trabalhadores vão 
alterar o que estão a fazer para produzir as melhores medições, mesmo que isso reduza 
claramente a verdadeira eficácia do que fazem. Esta disfunção de medição é o calcanhar 
de aquiles da gestão baseada em medição.
A conclusão do Austin é que se tem que escolher entre gestão baseada em medição e 
gestão delegatória (em que os trabalhadores decidem como trabalhar). Gestão baseada 
em medição é a melhor para trabalho simples e repetitivo, com poucos requisitos de 
conhecimento e resultados facilmente mensuráveis - exactamente o oposto do 
desenvolvimento de software.
O resultado disto tudo é que os métodos tradicionais têm operado sob a assunção que a 
gestão baseada em medição é a forma mais eficiente de gerir. A comunidade ágil 
reconhece que as características do desenvolvimento de software são tais que a gestão 
baseada em medição leva a níveis elevados de disfunção na medição. É realmente mais 
eficiente utilizar um estilo delegatório de gestão, que é o tipo de abordagem que é o 
centro do ponto de vista agilista.
O Papel da Liderança do Negócio
Mas os técnicos não podem realizar todo o processo por si próprios. Eles necessitam de 
indicações nas necessidades do negócio. Isto leva a outro aspecto importante dos 
processos adaptativos: eles necessitam de estar em contacto próximo com a experiência 
de negócio.
Isto vai para além do envolvimento de muitos projectos no papel de negócio. Equipas 
ágeis não podem existir sem comunicação ocasional. Eles necessitam de acesso 
continuo à experiência de negócio. Para além disso este acesso não pode ser algo que é 
realizado ao nível da gestão, é algo que está presente para qualquer projectista. Já que os 
projectistas são profissionais capazes na sua própria disciplina, eles necessitam de poder 
trabalhar ao mesmo nível com outros profissionais noutras disciplinas.
Uma grande parte disto, obviamente, é devida à natureza do desenvolvimento 
adaptativo. Já que toda a premissa do desenvolvimento adaptativo é que as coisas 
mudam rapidamente, necessita-se de contacto constante para avisar toda a gente das 
mudanças.
Não há nada mais frustrante para um projectista que ver o seu trabalho a ir para o lixo. 
Então é importante assegurar que existe experiência de negócio de qualidade e que esta 
está disponível para o projectista e que tem qualidade suficiente para que o projectista 
possa confiar nela.
O Processo Auto-Adaptável
Até agora falámos acerca da adaptabilidade no contexto de um projecto a adaptar o seu 
software frequentemente para atingir os requisitos mutáveis dos seus clientes. No 
entanto existe outro ângulo para a adaptabilidade: o do processo a alterar ao longo do 
tempo. Um projecto que começa utilizando um processo adaptável não vai ter o mesmo 
processo um ano depois. Ao longo do tempo, a equipa vai descobrir o que funciona para 
ela, e altera o processo.
A primeira parte da auto-adaptabilidade é a revisão regular do processo. Tipicamente 
faz-se isso com cada iteração. No final de cada iteração, tem-se uma curta reunião e 
colocam-se as seguintes questões
- O que é que fizemos bem?
- O que aprendemos?
- O que podemos fazer melhor?
- Que dúvidas temos?
Estas questões levam a ideias para alterar o processo para a próxima iteração. Deste 
modo o processo que começa com problemas pode melhorar à medida que o projecto 
avança, adaptando-se melhor à equipa que o usa.
Se a auto-adaptabilidade ocorre dentro de um projecto, é ainda mais marcante numa 
organização. Para enraizar o processo da auto-adaptabilidade eu sugiro que as equipas 
realizem uma revisão mais formal e que (???). Estas retrospectivas envolvem um 
encontro e 2-3 dias e um facilitador treinado. Não só se oferece aprendizagem para a 
equipa, também se oferece aprendizagem para toda a organização.
Uma consequência da auto-adaptabilidade é que nunca se deve esperar encontrar uma 
única metodologia de corporação. Em vez disso cada equipa não deve somente escolher 
o seu próprio processo, mas deve também activamente afinar o seu processo à medida 
que avança no projecto. Enquanto tanto os processos publicados e a experiência de 
outros projectos possa servir como inspiraçãoe base, a responsabilidade profissional 
dos projectistas é adaptar o processo à tarefa em mãos.
Esta auto-adaptividade está mais marcada em ASD e Crystal. As regras rígidas do XP 
parecem não permitir isso, mas é apenas uma impressão superficial já que o XP 
encoraja as pessoas a afinar o processo. A diferença principal com o XP é que os seus 
advogados sugerem seguir o XP pelas regras algumas iterações antes de o adaptar. 
Além disso as revisões nunca são enfatizadas, nem parte do processo, mesmo existindo 
sugestões para que as revisões façam mais uma prática do XP.
As Metodologias
Várias metodologias encaixam sob este cartaz ágil. Enquanto todas partilham as 
mesmas características, existem também algumas diferenças significativas. Não posso 
apresentar todos os pontos neste breve sumário, mas pelo menos posso apontar alguns 
locais para ver. Também não posso falar com experiência significativa acerca da 
maioria deles. Realizei muito trabalho baseado em XP, e vi RUP por alguns (???), mas 
com a maioria dos outros o meu conhecimento é o menos adequado conhecimento 
literário.
XP (Extreme Programming)
De todas as metodologias ágeis, esta é a que tem atraído a maior atenção. Em parte isto 
acontece devido à habilidade dos líderes do XP, em particular Kent Beck, para atrair a 
atenção. É também devido à habilidade do Kent Beck para atrair as pessoas para a 
abordagem, e tomar um papel de liderança nele. Nalguns sentidos, no entanto, a 
popularidade do XP tornou-se um problema, pois tirou público às outras metodologias e 
às suas ideias com valor.
As raízes do XP encontram-se na comunidade de Smalltalk, e em particular na 
colaboração próxima do Kent Beck e Ward Cunningham nos finais dos anos 80. Ambos 
refinaram as duas práticas em numerosos projectos durante os inícios dos anos 90, 
estendendo as duas ideias de uma abordagem de desenvolvimento de software que era 
adaptável e orientada às pessoas.
O passo crucial de prática informal para metodologia ocorreu na primavera de 1996. 
Kent foi contratado para rever o progresso do projecto de pagamento C3 para a 
Chrysler. O projecto estava a ser levado em Smalltalk por uma empresa contratada, e 
estava com problemas. Devido à baixa qualidade da base de código, o Kent recomendou 
deixar fora todo o código e começar do inicio. O projecto recomeçou sob a sua 
liderança e tornou-se num campo de treino para o XP.
A primeira fase do C3 foi bastante bem sucedida e ficou activa no inicio de 1997. O 
projecto continuou e começou com dificuldades mais tarde, o que resultou no 
cancelamento de mais desenvolvimento em 1999. (o que prova que o XP não é garantia 
de sucesso.)
O XP começa com quatro valores: Comunicação, Retorno, Simplicidade, e Coragem. 
Depois constrói-se sob meia dúzia de práticas que os projectos de XP devem seguir. 
Muitas destas práticas são velhas, técnicas tentadas e testadas, no entanto muitas vezes 
esquecidas por muitos, incluindo os processos mais planeados. Para além de ressuscitar 
estas técnicas, o XP leva-as para um todo sinergético onde cada uma é reforçada pelas 
outras.
Uma das mais difíceis, mas também mais interessantes para mim, é o seu forte ênfase 
nos testes. Enquanto os outros processos referem os testes, a maioria fá-lo com pouco 
ênfase. No entanto o XP coloca o teste nas fundações do desenvolvimento, com todos 
os programadores a escrever testes à medida que escrevem o seu código de produção. 
Os testes são integrados num processo de integração e construção contínua o que resulta 
numa plataforma altamente estável para desenvolvimento futuro.
Nesta plataforma o XP constroi um processo evolucionário de desenho que se suporta 
na refactorização de um sistema base simples com cada iteração.Todo o desenho é 
centrado à volta da iteração corrente com nenhum código de desenho realizado para 
necessidades futuras antecipadas. O resultado é um processo de desenho que é 
disciplinado, no entanto (???), combinando disciplina com adaptabilidade num sentido 
que a torna na metodologia adaptável mais bem desenvolvida.
O XP desenvolveu uma grande liderança, muitos deles do projecto C3. Como resultado 
existem muitas fontes para mais informação. O Kent Beck escreveu o Extreme 
Programming Explained o manifesto chave do XP, que explica os motivos por detrás da 
metodologia e uma explicação suficiente dela para dizer às pessoas se estão ou não 
interessadas em segui-la. Nos últimos anos houve uma epidemia de livros XP, muitos 
deles sendo bastante semelhantes no sentido em que descrevem todo o processo a partir 
do ponto de vista dos primeiros seguidores.
Além dos livros, existe um grande conjunto de recursos na web. Para encontrar uma 
abordagem mais estruturada ao XP, é melhor começar por dois sites de pessoas do C3: o 
xprogramming.com do Ron Jeffries e o extremeprogramming.org do Don Wells. Muito 
da advocacia e desenvolvimento inicial das ideias do XP ocorreram no ambiente de 
escrita colaborativa do Ward Cunningham. A wiki continua um local fascinante para 
descobrir, no entanto a sua natureza (???) leva a que seja sugado. Existe um activo e 
frequentemente interessante egrupo de discussão xp. Uma das mais interessantes vistas 
de fora do XP é a do Mark Paulk, que é um dos líderes da comunidade CMM – o seu 
documento vê o XP numa perspectiva CMM.
Família Crystal do Cockburn
O Alistair Cockburn tem vindo a trabalhar sobre metodologia deste que teve a tarefa de 
escrever sobre metodologia na IBM nos inícios dos anos 90. A sua abordagem não é 
igual à maioria dos metodologistas, no entanto. Em vez de construir somente na 
experiência pessoal para construir uma teoria de como as coisas devem ser feitas, ele 
suplementa a sua experiência directa com a procura activa de entrevistar os projectos 
para ver como eles funcionam. Além disso ele não tem receio de alterar os seus pontos 
de vista baseado nas suas descobertas: por todo isto faz com que seja o meu 
metodologista favorito.
O seu livro, Surviving Object-Oriented Projects, foi a primeira peça de aviso aos 
projectos em execução, e continua a ser a minha primeira recomendação para projectos 
iterativos em execução. Mais recentemente o Alistair escreveu um livro no 
desenvolvimento ágil de software que olha para os princípios por debaixo destes tipos 
de metodologias.
Desde essse livro ele explorou ainda mais os métodos ágeis, chegando à família de 
metodologias Crystal. É uma família porque ele acredita que tipos diferentes de 
projectos necessitam de tipos diferentes de metodologias. Ele vê esta variação em dois 
eixos: o número de pessoas no projecto, e as consequências dos erros. Cada 
metodologia encaixa numa parte diferente da grelha, logo um projecto de 40 pessoas 
que pode perder algum dinheiro tem uma metodologia diferente de um projecto crítico 
de 6 pessoas.
Os Crystals partilham uma orientação humana com o XP, mas esta centralidade nas 
pessoas é realizada de forma diferente. O Alistair considera que as pessoas acham difícil 
seguir um processo disciplinado, e portanto em vez de seguir a difícil alta disciplina do 
XP, o Alistar explora a metodologia menos disciplinada que ainda assim pode ter 
sucesso, conscientemente trocando produtividade pela facilidade de execução. Assim 
mesmo sendo Crystal menos produtiva que o XP, mais pessoas poderão segui-la.
O Alistair também coloca bastante peso nas revisões de cada iteração, encorajando 
assim as pessoas a auto melhorarem-se. O seu pressuposto é que o desenvolvimento 
iterativo está lá para encontrar os problemas mais cedo, e permitir então às pessoas de o 
corrigir. Isto coloca mais ênfase nas pessoas a monitorarem o seu processo e a afinarem-
no à medida que desenvolvem.
Open Source
Podes estar surpreendido por este título. Afinal de contas o open sourceé um estilo de 
software, não propriamente um processo. No entanto existe uma forma definida de fazer 
as coisas na comunidade open source, e muita da sua abordagem é tão aplicável aos 
projectos closed source como aos de open source. Em particular o seu processo está 
afinado para equipas fisicamente distribuídas, o que é importante porque a maioria dos 
processos referem equipas co-localizadas.
A maioria dos projectos open source têm um ou mais gestores. Um gestor é a única 
pessoa que pode colocar uma actualização no repositório de código fonte. No entanto 
outras pessoas para além do gestor pode realizar alterações à base de código. A 
diferença chave é que as outras pessoas têm que enviar a sua alteração para o gestor, 
que depois revê a alteração e aplica-a à base de código. Tipicamente estas alterações são 
efectuadas na forma de (???) que torna este processo mais simples. O gestor é então 
responsável pela coordenação das (???) e manutenção da coesão de desenho do 
software.
Projectos diferentes gerem o papel do gestor de formas diferentes. Alguns têm um 
gestor para todo o projecto, outros dividem-no em módulos e têm um gestor por 
módulo, outros rodam o gestor, outros têm múltiplos gestores para o mesmo código, 
outros têm uma combinação destas ideias. A maioria das pessoas do open source são-no 
em part-time, logo existe um problema do quanto uma equipa se coordena um projecto a 
tempo inteiro.
Uma característica particular do desenvolvimento open source é que o debugging é 
altamente paralelizado. Muitas pessoas podem estar envolvidas no debugging. Quando 
elas encontram um bug elas podem enviar uma actualização para o gestor. Isto é um 
bom papel para os não-gestores já que a maior parte do tempo se ocupa a procurar o 
bug. Também é bom para pessoas sem grandes capacidades de desenho.
O processo para o open source ainda não está bem escrito. O paper mais famoso é o The 
Cathedral and the Bazar do Eric Raymond que, enquanto é uma boa descrição, é um 
pouco breve. O livro do Karl Fogel sobre o repositório de código CVS também contém 
alguns bons capítulos sobre o processo de open source que podem ser interessantes 
mesmo que nunca queiras fazer cvs update.
Desenvolvimento Adaptável de Software do Highsmith
O Jim Highsmith ocupou muitos anos a trabalhar em metodologias preditivas. Ele 
desenvolveu-as, instalou-as, ensinou-as, e concluiu que elas tinham falhas profundas: 
particularmente para o negócio moderno.
O seu livro recente foca a natureza adaptável das novas metodologias, com particular 
ênfase na aplicação das ideias que originam no mundo dos sistemas adaptáveis 
complexos (comummente referidos como teoria do caos.) Não oferece o tipo de práticas 
detalhadas como o trabalho do XP faz, mas oferece uma base de trabalho fundamental 
para o porquê da importância do desenvolvimento adaptável e as consequências nos 
níveis mais profundos de organização e gestão.
No coração do ASD existem três fases não lineares e sobrepostas: especulação, 
colaboração e aprendizagem.
O Highsmith vê o planeamento como um paradoxo no ambiente adaptável, já que os 
resultados são naturalmente imprevisíveis. No planeamento tradicional, desvios dos 
planos eram erros que deviam ser corrigidos. Num ambiente adaptável, no entanto, 
desvios guiam-nos para a solução correcta.
Neste ambiente imprevisível necessita-se que as pessoas colaborem de uma forma rica 
para lidar com a incerteza. A atenção da gestão é menos sobre dizer às pessoas o que 
dizer, e mais sobre encorajar a comunicação para que as pessoas surjam elas próprias 
com respostas criativas.
Nos ambientes preditivos, a aprendizagem é frequentemente desencorajada. As coisas 
são dispostas no inicio e depois segue-se esse desenho.
Num ambiente adaptável, a aprendizagem desafia todos – projectistas e os seus clientes 
– a examinar as suas assunções e a utilizar os resultados de cada ciclo de 
desenvolvimento para adaptar o próximo.
– Highsmith
Como a aprendizagem é uma característica importante e contínua, assume-se que os 
planos e desenhos devem alterar à medida que o desenvolvimento progride.
	A Nova Metodologia
	Martin Fowler
	Do Nada, para o Monumental, para o Ágil
	Previsível contra Adaptável
	Separação de Desenho e Construção
	A Imprevisibilidade dos Requisitos
	A previsibilidade é impossível?
	Controlando um Processo Imprevisível – Iterações
	O Cliente Adaptável
	Colocando as Pessoas Primeiro
	Unidades de Programação Compatíveis e Uníveis
	Os programadores são profissionais responsáveis
	Gerir um Processo Orientado pelas Pessoas
	A Dificuldade da Medição
	O Papel da Liderança do Negócio
	O Processo Auto-Adaptável
	As Metodologias
	XP (Extreme Programming)
	Família Crystal do Cockburn
	Open Source
	Desenvolvimento Adaptável de Software do Highsmith