Metodologias geis X Metodologias tradicionais

Publicado em abril 18, 2009 | 6 Comentrios

Existem infinitas formas de se construir sistemas de software, e todo mundo que
trabalha com isso procura pela galinha dos ovos de ouro, a metodologia perfeita para se
construir software perfeito, no menor prazo possvel, e que no final clientes e
desenvolvedores so felizes para sempre. bvio que isso s existe em contos de fadas.
Mas nos corredores de empresas de software e em alguns botecos estranhos voc deve
ouvir calorosas discusses de defesa sobre a metodologia X ou o processo Y. E nos
ltimos anos (nos ltimos 10 anos mais ou menos) a batalha da vez acontece entre as
metodologias geis contra as metodologias iterativas mais tradicionais.

Usar cascata j era!

As metodologias iterativas mais utilizadas so o RUP e suas variantes (para criar
uma variante, adicione o sufixo UP no final de uma palavra legal). Do muita nfase ao
processo, ao controle do andamento do projeto atravs de delivarables (que
normalmente so diagramas de diversos tipos, como diagramas de classes ou diagramas
de interao). So muito utilizadas em fbricas de software, em projetos que envolvem
muitos desenvolvedores, e no so sinnimos, mas esto sempre de mos dadas com
siglas como CMMi, ePMI. Se os gerentes da empresa gostam dessas duas siglas, tem
pouco cabelo e esto na rea h mais de 20 anos, alta a probabilidade de que utilizem

uma metodologia iterativa tradicional. Surgiram em resposta s metodologias em

cascata, que j foram predominantes.
As metodologias geis so uma tentativa de refinar as metodologias iterativas,
tirando o foco do processo em si e dando mais nfase contribuio das pessoas, dos
integrantes do projeto. Trazem alguns conceitos que as diferenciam radicalmente das
metodologias antecessoras, como deixar o cliente participar mais prximo ao processo,
iteraes extremamente curtas e grande nfase em testes automatizados. Por outro
lado, pesquisadores e mesmo defensores dessas prticas no recomendam times muito
grandes para um projeto (e alguns propem dividir o projeto em subprojetos e trabalhar
com equipes menores). Os mtodos mais conhecidos nesta categoria so Extreme
Programming (mais carinhosamente conhecido como XP) e Scrum.
Mesmo tanto tempo depois da definio de mtodos geis, da publicao
doManifesto gil, e de tanta gente pregando e achando que mtodos geis so legais,
porque que isso no ainda utilizado em larga escala? Entre alguns motivos esto:
Burocracia como requisito: existem clientes que pedem pela burocracia,

pelo processo mais rgido. S contratam empresas que tenham fbrica de

software com CMMi nvel 50, e fazem questo de saber que foram definidos 432
diagramas, mesmo que nunca v parar para dar uma olhada para eles.
Maturidade:

obviamente existe um nmero muito maior de projetos

bem sucedidos utilizando metodologias que existem a mais tempo. No precisa

ser um gnio para perceber isso. Por isso, mais gente que conhece e tem
experincia com esses processos. Processos mais novos so obviamente mais
atrativos

para

algumas

empresas

picaretas

oferecerem

servio

de

desenvolvimento de software.
Nvel

tcnico da equipe: no caso de muitos gerentes, ao mesmo tempo

que mtodos geis so vistos como processos que exigem ninjas-Mcgyverprogramadores, eles acham que suas equipes so formados por macacos
bonobos. Ou para diminuir os custos, realmente tentam contratar macacos
bonobos a preo de banana. Quando voc acredita que tem uma equipe no
muito capacitada, acaba querendo ter mais controle sobre o processo. Quanto
menos a mo de obra precisar pensar, menor o seu risco, voc s bota um monte

de especificaes para eles executarem e d choquinho se eles fizerem errado

(no me apedrejem, essa a viso dos caras de gravata).
Medo:

meio que resume os outros itens. Mas basicamente, as pessoas

preferem no mexer em time que aparentemente est ganhando. Voc sabe que
a metodologia B.A.T.A.T.A. vai te entregar um sistema. Pode demorar, custar caro
e ficar cheio de problemas, mas vai entregar um sistema. Preferem no arriscar.
Se nenhuma dessas razes acima perturba sua rea de desenvolvimento, acho
que posso assumir que a razo para que vocs no tenham considerado Agilizar seus
processos o simplesmente no conhecer muito bem o que so mtodos geis. Vou
tentar entregar o caminho das pedras abaixo.

MITOS E CONCEPES ERRADAS

A primeira coisa que muita gente pensa quando ouve falar de mtodos geis
que no existe documentao para o software sendo desenvolvido, que o processo
um oba-oba em que vale tudo e as pessoas saem fazendo as coisas que querem,
praticamente uma suruba no escuro.

verdade que mtodos geis na verdade no chegam a ser mtodos e nem

processos, mas sim conjuntos de diretrizes para se chegar a um bom resultado final, e
por isso, no existe o passo 32 do processo que exige que voc desenhe um diagrama
UML usando 3 cores diferentes coloridos com crayon. Mas diagramas e documentao
existem, mas so ditados pelo bom senso. Voc gera um documento para comunicar
algo para outros seres humanos, para deixar algo mais claro no design para outros seres
humanos entenderem. Voc no gera um diagrama que ningum vai ler mas que voc
foi obrigado a gerar para no tomar choquinho do seu gerente de projeto. Mas o lado
ruim disso que bom senso um conceito bem pouco formal. Ou seja, se seu time tiver
um bom senso ruim (existe isso? ou seria mau senso?) voc est lascado.

Por causa dessa percepo que as pessoas tem de que as coisas podem meio que
ser feitas de qualquer jeito com mtodos geis, existem muitos casos reportados de
projetos fracassados utilizando essas metodologias, o que acabou espantando ainda
mais as empresas grandes em relao a sua adoo. Mas tambm existem casos

conhecidos de muito sucesso como a Primavera Systems e oSalesforce.com, que

utilizavam anteriormente processos iterativos tradicionais.
Conhea as histrias de sucesso e de fracasso. Provavelmente se algum olhar
para a porcentagem de projetos tradicionais que fracassam e olhar para a mesma
estatstica no caso de metodologias geis, vai chegar a concluso de que a competncia
do time mais importante que o processo utilizado.

MAIORES VANTAGENS
Iteraes

curtas. Voc entrega verses funcionais do sistema com mais

frequncia, em espaos mais curtos de tempo (que podem ser poucas semanas,
ou um ms). Assim seu cliente corre menos risco, porque sabe sempre como est
o andamento do projeto, e pode te dar muito mais feedback. Todo mundo fica
feliz.
Diminuio dos custos de comunicao. o tipo de custo que as pessoas

dificilmente colocam no papel. Mas olhe para mtodos mais dirigidos por
especificaes e diagramas. Todos esses artefatos so feitos com o objetivo de
comunicar alguma coisa (pelo menos deveria ser esse o principal objetivo de um
diagrama). O problema que ao mesmo tempo, as pessoas utilizam exatamente
os mesmos diagramas como documentao de longo prazo. O resultado disso
que durante o processo so gerados muitos documentos e diagramas que no so
utilizados para comunicar nada, apenas para registrar como as coisas deveriam
ser. E no final de tudo, tente descobrir se seu software realmente est seguindo
toda aquela documentao gerada. mais fcil construir outro sistema.
Levar

em considerao que as coisas vo mudar ao longo do caminho.

Enquanto voc est especificando o sistema, as coisas esto mudando, e quem

sabe aquilo que voc bolou s vai servir para forrar galinheiro. Ento voc faz
iteraes curtas, para que essas mudanas tenham o mnimo de impacto no
projeto. Voc controi testes para garantir que mudanas futuras sejam mais
seguras de fazer atravs de refatorao do cdigo. E voc tenta sempre resolver
o problema que voc tem na mo, no fica tentando criar a super soluo genrica
para casos que voc nem sabe se vo aparecer. O ltimo ponto algo
extremamente til quando voc tem na equipe pessoas que gostam muito de

modelagem de arquitetura de sistemas, e que gostam de bolar coisas

extremamente complicadas. O cliente no vai pagar mais pelo software que tiver
a arquitetura mais bonita. Mas vai ficar mais feliz pelo software entregue mais
cedo.
ALGUMAS PRTICAS SO BOAS DE QUALQUER JEITO
Mesmo que voc no v adotar um processo gil, existem prticas bem
difundidas pela comunidade que DEVERIAM ser adotadas independente do processo
utilizado. Repare que coloquei DEVERIAM em maisculas e negrito de propsito.
Deveria ser lei, obrigao, sujeito a 30 aoitadas em praa pblica para quem no
seguisse essas prticas.
Testes automatizados. Automatize o mximo de testes que puder. Sim, vai dar
mais trabalho. No, no vai acabar com todos os bugs. Mas mais tarde, quando voc
precisar fazer uma refatorao mais radical, ou resolver algum bug ou alterao que
surgiu, voc no precisa mais ter medo e suar frio. Com um clique em um boto voc
sabe se quebrou alguma coisa (dependendo de quanto os seus testes so bons, claro).
infinitamente mais til voc ter um negcio que te d essa informao sobre seu
software do que pilhas e pilhas de qualquer tipo de documentao e especificao.
Tente usar um UML para descobrir se voc pode fazer uma alterao nas suas classes de
objetos. Incontveis vezes pude resolver problemas muito rapidamente simplesmente
porque gastei algumas horas a mais escrevendo testes. Lembre-se, testes so como
remdio ruim. Na hora que voc est tomando vai reclamar, mas vai agradecer pelos
benefcios no futuro.
Integrao contnua. Pode ser visto como uma extenso dos testes
automatizados. Automatize a integrao e o build do seu software. No deixe para
descobrir no dia da entrega que o negcio no funciona (ou s funciona se o seu cdigo
e o do Juca estiverem separados).
Iteraes curtas. Entregue verses do seus sistema com mais frequncia e
descubra mais cedo se voc est indo na direo certa. muito melhor quando isso
acontece depois de duas semanas do que trs meses depois. E se quer realmente saber
se possvel cumprir seu prazo, voc precisa deixar que os desenvolvedores, as pessoas
que botam a mo na massa, estimem o tempo. Eles tem mais noo que voc (que quer
o prazo para ontem) e seu cliente (que quer o prazo para duas semanas atrs).