O Cl√°ssico, o Tradicional e o Certo 

Jan/11
23

Como muitos já sabem eu sou formado em engenharia física e não em um curso relacionado a computação. Quando decidi que queria entrar de cabeça no desenvolvimento de software senti falta de alguma formação acadêmica mais teórica. Para minha surpresa fora algumas coisas de algoritmia não perdi tanto assim. O meu curso sobriu até que bastantes coisas, claro que em muito menor detalhe. Mas mesmo assim, eu senti-a falta de alguma lógica/mecanismo/receita para a organização do trabalho de fazer um software. Sim, é claro que precisamos de requisitos e queremos ter o software pronto, mas como se vai de um ao outro ?

Aproveitei o embalo dos cursos que fiz na Sun para programador certificado (1.4, bons tempos) e fiz um curso l√° chamado OO226 que trata de Analise Orientada a Objecos. Foi muito bom porque permitiu que se forma-se em mim o conceito de como analisar com objetos √© diferente de programar com objetos. Muitos dos objetos de neg√≥cio nem sempre chegam a ser objetos de c√≥digo, alguns s√£o apenas campos, propriedades ou alguns s√£o at√© a√ß√Ķes que acontecem. O curso n√£o era baseado em nenhuma metodologia de mercado e isso foi excelente porque n√£o me viciou a pensar em certo mecanismo como a muitos que s√£o formados nisto e saem da faculdade com RUP na cabe√ßa ou algo que lhe valha.

Um coisa ficou bem clara: eu estava em desavantagem nenhuma porque nem quem era da área tinha informação real e fidedigna de qual processo/metodologia seguir. Na época já se ouvia falar de XP, mas não muito se Scrum e já estavamos em 2004.

De lá para cá, tenho dedicado muito tempo a tentar aprender sobre processo de desenvolvimento. A meu ver as coisas se separam em : Levantamento de Requisitos e Desenvolvimento. Levantamento de Requisitos é essencial que seja feito e muito bem feito. Requisitos mal levantados causam verdadeiros desastres. Todos os autores advertem sobre isto. O Chaos Report mostra os numeros do que acontece e mesmo o Cone de Incerteza leva isto em consideração. Não ha desculpa para não fazer um levantamento cuidadoso.

Claro que levantamento de requisitos n√£o √© simples. Requer¬†t√©cnica. Por isso, um livro que acho excelente √© Software Requirements Patterns em que nos √© ensinado o valor do requisito bem levanto e nos √© dito que uns requisitos levam a outros num padr√£o. Requirement Patterns s√£o os Design Patterns do levantamento de requisitos.¬†¬†Um outro √© Software Requirements que nos leva a entender como se faz um levantamento de requisitos e que ferramentas existem para nos ajudar. Uma interessante √© o processo Wideband Delphi que √© o antepassado do Planning Poker ( e voc√™ que pensava que os agilistas tinham inventado isto… )

Tudo isto porque eu fiquei obcecado em entender porque em todos os lugares que trabalhei as pessoas teimavam em estimar horas e cobrar por hora. Um modelo que para mim nunca fez sentido até hoje. Consultando a vasta referencia bibliografica no mundo do desenvolvimento rapidamente entendi  que em lugar algum de fala ou ensina sobre este modelo. Então porque o usam ?

Os ensinamentos cl√°ssicos dos livros de muitos autores de todo o mundo √© largamente conflitante com a forma como se implementa o processo de cobran√ßa e estimativa. Mas por costume e tradi√ß√£o as pessoas continuam fazendo o que sempre fizeram mesmo depois de terem v√°rios problemas com o modelo. Este n√£o abandono irracional de costumes e tradi√ß√Ķes que n√£o t√™m nada que ver com os ensinamentos cl√°ssicos nos leva a um tempo quase que de era medieval do desenvolvimento de software onde ha muito mito e pouca¬†ci√™ncia.

Por exemplo, uma mec√Ęnica tradicional que n√£o faz sentido algum para mim: O programador cobra por hora para desenvolver o software. Ele estima quantas horas ser√£o necess√°rias e fecha um pre√ßo por hora. Se mais horas forem necess√°rias para completar o projeto, ou porque o escopo aumentou ou porque o prazo √© fixo, √© cobrado um extra. Mas se o software tem bugs e √© necess√°rio corrigi-los o programador cobra extra. Extrapole isto para empresas e entenda que as empresas sobram dos clientes a sua falta de qualidade. Porque n√£o simplesmente cobrar mais caro para come√ßo de conversa e n√£o cobrar por bugs ? ¬†A resposta a isso √©, para muitos, o velho “o mercados n√£o est√° bom” … hummm… algun dia esteve bom ? algum dia vai ficar bom ? ¬†O fato √© que a empresa deve ter uma imagem e um nome a zelar, mas isso √© desnecess√°rios quandos os clientes que utilizam os seus servi√ßos s√£o enganados todos os dias sem perceber. Se o cliente comprasse uma casa ou autom√≥vel com defeito ele reclamaria o seu dinheiro de volta, mas com software tudo est√° bem, quando acaba bem ( com um software utiliz√°vel mesmo que com bugs).

Hoje em dia com o movimento √°gil muitos licenciados tomam conhecimento de¬†mec√Ęnicas¬†e processos mais semelhantes ao que seria de esperar e mais perto dos ensinamentos cl√°ssicos. Por exemplo, quando o programador/empresa estimam o esfor√ßo em horas e tornam o prazo igual ao esfor√ßo eles est√£o cometendo dois erros. Primeiro, n√£o est√£o separando as¬†dimens√Ķes¬†de escopo e tempo e segundo est√£o estabelecendo uma taxa de realiza√ß√£o √† priori.

Se temos 1000 horas de trabalho a realizar e nos comprometemos a realiz√°-las em 1000 horas, estamos estabelecendo uma taxa de 1h de esfor√ßo/ 1h de rel√≥gio. Ou seja, o programador em 1h de rel√≥gio n√£o faz nada mais do que programar. N√£o bebe, n√£o come, n√£o l√™ email, n√£o fala com ningu√©m, ou seja, √© uma m√°quina.¬†Mesmo com os 30% a mais que √©¬†tradicionalmente¬†colocado a mais ( as pessoas nem sabem porqu√™) , nos daria uma taxa de 10/13 (= 0,76). Com o cone de incerteza¬†ir√≠amos¬†para algo como 1/4 (0,25) que seria mais apropriado. O problema, aqui √© que o prazo est√° relacionado ao custo e este ao pre√ßo. E o pre√ßo est√° relacionado √† competividade. Entenda que no mercado brasileiro a competividade ainda acontece apenas no campo dos pre√ßos, ningu√©m olha a qualidade. E isto √© sobretudo verdade em licita√ß√Ķes. Onde ganha quem oferece fazer mais barato ( n√£o quem oferece fazer melhor).

Em ágil esta taxa de realização é a Velocidade e é a razão entre o escopo realizado e o tempo para o realizar.  Mas mesmo aqui, com todas as ajudas, as pessoas ainda cometem erros.

Em agil o prazo √© fixado por um numero fixo de sprint que equivale a dizer por uma data pr√©-acordada. E o esfor√ßo √© estimado em pontos de est√≥ria. Como √°gil √© baseado em inspe√ß√£o, ent√£o √© facil verificar se vai caber ou n√£o. E medidas devem ser tomadas. Contudo, perante os fatos as pessoas tomas as a√ß√Ķes tradicionais : adicionar pessoas, cortar na qualidade, ou tentar negociar aumentar o prazo. Mas porque nunca tentam negociar os escopo ?

Basicamente porque de alguma forma se comprometeram a realizar todo o escopo. Mesmo que não por contrato mas para agradar ao cliente, ou não mostrar que as estimativas foram furadas. Ou seja, por simples medo.

√Č este medo que impede as empresas e as pessoas que s√£o desenvolvedoras a alimentar mitos medievais e manter pr√°ticas tradicionais enquanto esquecem os cl√°ssicos. Hoje ha muita gente tentando pegar o trem do √°gil, mas muitos com a mesma inten√ß√£o que pegaram o do RUP e outros antes dele : porque √© “in”, √© da moda. √Č o mesmo que as empresas quererem ser verdes. √Č bem visto. Mas isso n√£o significa que realmente cumpram com o que dizer e sejam o que publicitam. √Č o mercado, vale tudo. Inclusive dizer que se √© o que n√£o se √©.

Depois de tudo, para mim, o jeito clássico é tem muitos prós. Alguns contras, como ser normalmente burucrático e é aí que o movimento modernos mudou o cenário mostrando que é possível aplicar o que é clássico mas sem a chata burocracia.

Talvez não saibamos, ou possamos saber o que é certo, pois tal como em ciência a verdade está por ai escondida. Contudo é fácil e simples saber o que não é certo e tal como em ciências, vamos excluindo as hipoteses erradas. Os modelos tradicionais são hipoteses erradas. São mitos com roupagens que mudam. O cara diz que fazia RUP e agora faz Scrum, mas no fim ele faz é waterfall mesmo. Mas ai de quem ouse dizer que ele faz waterfall.  O rei vai nu.

Você que ainda não enxergou , que tal passar pelo médico e ver se tem algo errados com o seu pensamento lógico. Afinal as células cinzentas não usam a lógica apenas para criar código. Se você já enxerga que o rei vai nu, o que faz no dia a dia para melhorar a situação ?

Comente

Artigos