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 ?