domingo, 9 de agosto de 2009

Forma vs Conteúdo

O Pio num twit interessante sobre metodologias ágeis me fez lembrar de um assunto interessante. Hoje em dia, uma empresa de software valoriza mais a forma do que o conteúdo. Não importa se o sistema for simplesmente uma agenda para a produção de pão em uma padaria, o mercado valoriza tanto a reusabilidade de código, a documentação, o plano de testes, a infra-estrutura utilizada e 2000 páginas de documentação que, no final, a funcionalidade única do sistema fica em segundo plano.

Longe de defender uma metodologia anárquica, porém organização por si só não garante boas coisas, afinal, ela deve ter um objetivo maior. E é aí que eu vejo alunos entrando de cabeça em todo esse aparato sem se preocupar que isso é acessório para realizar uma tarefa bastante concreta e que existe no mundo real. Não adianta dezenas de boas práticas se no fundo não se conhece bem o negócio que se quer modelar. Dificilmente o cliente reclama que o sistema trava, mas sim que ele não faz o esperado. E não tem boa prática de projeto ou infra-estrutura de servidor que resolva isso.

Acho difícil sair dessa espiral descendente em que se mede qualidade de software com métricas que são dissociadas do objetivo do software em si. Afinal, uma empresa de software é tocada por administradores que não sabem diferenciar um documento Word de um programa Hello world!, mas é preciso pelo menos colocar na cabeça do pessoal que sai da universidade de que software é negócio, mas não nosso, é negócio do cliente e que nenhuma metodologia vai conseguir sozinha traduzir isso para um sistema. Por mais simples que ele seja.

11 comentários:

Piovezan disse...

Buscar a satisfação do cliente (e isso inclui tentar enxergar o problema com os olhos do cliente, e ele quer ver a aplicação dele funcionando e tocando o negócio, simples assim) deveria ser a primeira diretiva de qualquer metodologia ou processo. :) E na verdade ela é, nos processos mais maduros e aceitos pelo mercado, seguida de perto pelas outras qualidades "acessórias".

Muitas vezes porém o cliente também não sabe direito o que quer, tanto nos requisitos funcionais quanto não-funcionais, e cabe à empresa de software ajudá-lo a descobrir, nisso acabam entrando as dezenas de boas práticas e valores agregados, incluindo aí alguns dispensáveis.

A meu ver o problema maior é quando se escolhe a metodologia errada ou quando existem entraves do lado do cliente (no caso das metodologias ágeis, por exemplo, tem cliente que adora o conceito e os resultados, e tem muitos que ficam com medo de usar porque não tem ênfase em gerar documentação). Por isso é importante reavaliar esses conceitos constantemente.

Agora, plano de testes não tem como ficar de fora. :)

Piovezan disse...

Tem também o problema do processo não estar sendo implementado corretamente, mas aí a culpa não é do processo, a menos que a gente comece a avaliar os processos pela facilidade com que são mal implementados. :) Até porque uma das coisas mais fáceis quando se foca muito em processo é segui-lo à risca sem se perguntar se tudo aquilo faz sentido. :)

Piovezan disse...

Como qualidade está embutida no preço (cliente está mais preocupado que ela exista para economizar em manutenção depois, porque fazer o que se propõe já está no contrato), é claro que se ele descobrisse uma empresa que cobrasse barato, entregasse no prazo e fizesse tudo isso usando programação cowboy, nem pensaria duas vezes em fechar com ela. :P

PV disse...

Não é bem cliente não saber o que ele quer. O problema maior é o cliente dialogar nos termos do processo do seu dia-a-dia e o analista querer replicar nos termos de projeto/recursos computacionais. Experimenta chegar com esse papo de requisito funcional/não funcional pro cliente :). Os melhores analistas não são necessariamente os que melhor programam, mas os que melhor dialogam com o cliente para colocar em termos se sistema o processo do cliente.

Também não leve tão pejorativamente a metodologia ser um acessório, é simplesmente uma constatação humilde de que o computador/sistema/metodologia é apenas uma parte da solução do problema, que é o que deveria ser o foco do desenvolvimento de qualquer sistema. Infelizmente, mesmo nas metodologias mais maduras, no fundo o foco é vender o peixe de um produto que é a própria metodologia, seu ferramental e sua evangelização (vai RUP aí??), engessando qualquer sistema num modelo único e supostamente infalível (até aparecer algo melhor).

Finalmente, claro que a etapa de testes é importante, mas ela é tão crítica hoje porque não se planeja o sistema do ponto de vista matemático (banco de dados também é completamente matemático). Isso é ignorado pelas metodologias atuais, que pregam boas práticas, menos a de que o sistema deve ser matematicamente funcional no papel. Se isso acontecesse, a etapa de testes seria uma mera validação, não o inferno de se caçar eisen bugs que é hoje.

PV disse...

Programação cowboy encaixa-se em método anárquico, então não é o caso. A nossa área sofreu muito por conta de picaretas que se diziam "analistas de sistemas", coisa que você não deve ter pego por ser mais novo.

Porém eu não nego que gostaria de ver surgir um método mais enxuto e ver o mundo livre dessa parafernália toda de arquitetura que transforma um texto "hello world" em um mega-objeto XH-alguma coisa de 2MB que é enviado pela rede em uma cascata de 5 serviços que se encaixam que só estão lá porque ninguém sabe mais como é que faz comunicação via TCP/IP sem recorrer a este tipo de artifício :).

Piovezan disse...

Ninguém vai planejar o sistema do ponto de vista matemático mesmo, num mercado onde às vezes o pessoal te pressiona para reduzir a cobertura dos casos de teste pra dar tempo de entregar, seria muito utópico. :P

Não me referi ao vocabulário, que tem que ser alinhado com a realidade do cliente, é que tem cliente que não sabe o que quer mesmo. :P Lógico que se vc propor documentação ele vai achar bom ter, mas não sabe até que ponto ele realmente precisa dependendo do orçamento. Sem falar nos clientes que não têm certeza dos requisitos funcionais. E tem os clientes que já chegam com tudo definidinho, varia muito.

Agora, acho que foi no "Applying UML and Patterns" do Craig Larman que aprendi que processo bala de prata, para todos os casos, é coisa que não existe, e o próprio RUP estava em foco (que na verdade é bem customizável, mais um guarda-chuva que outra coisa, mas mesmo assim não faz sentido em projetos pequenos, por exemplo).

Piovezan disse...

propor não, propuser :P

Bruno Sanches disse...

A questão de apertar os testes depende muito da empresa. No meu ultimo projeto onde lidavamos com medicamentos quando o prazo apertava eles jogavam o processo no lixo (e olha que são CMMI 3), a ponto de gerente chegar e perguntar o que esta faltando e ele sair passando por cima de todo mundo para conseguir o que faltava (de aprovações a outros sistemas)

A unica coisa que eles não aceitavam deixar passar por cima era os testes, o pessoal de QA tinha que cumprir os testes, poderiam atrasar os releases, mas nunca deixavam os testes de lado.

A diferença ali era que a empresa desenvolvia para ela mesma, e sabia que um sistema falho iria custar muito caro, ainda mais no ambiente 24x7 que eles tinham.

PV disse...

Não acredito que o problema do modelo matemático seja utopia ou o custo, afinal, o pessoal ficar patinando três meses em cima de um problema titica custa o mesmo preço que fazer uma modelagem matemática o problema. O grande problema é que o pessoal do mercado hoje não seria capaz de fazer tal tipo análise. Hoje ensina-se análise de sistemas como ensina-se administração, o que é adequado para gerentes, mas não para arquiteto de sistema.

Um engenheiro que constrói um prédio tem toda uma base matemática para fazer o que durante muitos anos foi feito na base do "acho que tá bom". Hoje software na média é feito na base do "acho que tá bom", apoiado por uma metodologia. Daí pra coisa ferrar e estourar prazo são dois toques.

Pega mesmo um curso como Ciência da Computação, que é de todos o mais matemático. Mesmo ali o aluno não sai com uma base matemática boa da coisa. Daí fica fácil dizer que modelagem do ponto de vista matemático é utópico, claro, ninguém ia saber fazer! Joga um livro do Knuth na mão de qualquer gerente de desenvolvimento hoje só pra ver a cara de susto dele :).

Piovezan disse...

*suspiro* Uma hora a modelagem matemática vai ser tendência, só falta o povo ver as vantagens, aí todos vão descobrir e adotar, aguarde :)

PV disse...

Faço minhas suas palavras. Aí eu vou poder ensinar o problema de parada da máquina de Turing sem o pessoal ficar de cabelos em pé :P.