Sinais de Aviso: um Questionário Sobre Qualidade

Toda a gente é a favor da qualidade de software, mas nem todos produzem software de qualidade. Como é que podemos afirmar se um grupo de software se desviou do caminho certo? Pode ser o nosso departamento de desenvolvimento de produto, o nosso fabricante de computadores, ou mesmo o nosso fornecedor de software. O grupo de software ideal utiliza o feedback e ciclos de desenvolvimento repetidos para identificar aquilo que os utilizadores realmente precisam. Além disso, também utiliza uma engenharia de software rigorosa.

Quando se desenvolve software, dizer que se responde aos utilizadores é sempre uma expressão sonante que fica bem. No entanto, também se vêm muitos sistemas em que os programadores introduzem alterações constantes e patches para dar aos utilizadores aquilo que pedem. A maior parte desses sistemas transformam-se numa confusão impossível de gerir e cheios de bugs. No outro extremo temos grupos de desenvolvimento que não satisfazem as necessidades dos utilizadores. Estes são normalmente grupos com fracas capacidades que reagem aos pedidos/queixas dos utilizadores com contra-argumentos.

O grupo de software ideal utiliza o feedback e ciclos de desenvolvimento repetidos para identificar aquilo que os utilizadores realmente precisam. Além disso, utiliza uma engenharia de software rigorosa. Apesar das alterações constantes, o grupo de software ideal assegura que as funcionalidades existentes continuam a funcionar e que são possíveis alterações futuras. Neste artigo, as ideias estão organizadas numa espécie de questionário com frases que provavelmente reconhecerá. São frases que lançam avisos sobre projectos de software com problemas - por exemplo "esse trabalho não é da minha responsabilidade", ou "é contra a nossa política".

As 18 frases/questões que se seguem ao longo do texto são expressões que constituem avisos relativamente a projectos de software com problemas. Veja quantas destas frases já ouviu e atribua uma pontuação de cinco pontos por cada uma que ouça regularmente. Anote os pontos numa folha ao lado para obter a soma global e confira o resultado no fim do artigo.

O nosso primeiro sinal de aviso é uma desculpa clássica dos programadores:

1. É uma característica, não um bug.

Se os utilizadores provarem que têm razão na sua queixa com base na documentação, costuma surgir uma segunda desculpa:

2. É um erro do manual.

Com estas duas respostas, os programadores podem fugir a qualquer relatório de bugs.

Outra expressão que se ouve com frequência tem a ver com as evasivas em sinal de ataque quando os utilizadores solicitam algo. Quando um utilizador entra em contacto com o serviço de suporte do fornecedor de software, ouve-se frequentemente a contra-pergunta:

3. Porque quer fazer isso?

Esta questão sugere uma atitude superior por parte dos programadores. No entanto, esta atitude nem sempre é confirmada pela realidade. Os clientes têm que encontrar formas inesperadas e incríveis de utilizar os programas para resolverem os seus problemas. Um sinal de que um programa é realmente bom tem a ver com o facto de poder ser utilizado por qualquer pessoa (leigo) e funcionar. A utilidade de um programa é um juízo que cabe ao cliente e não ao fornecedor.

4. Se não existem questões, é porque toda a gente está satisfeita.

Numa reunião em que os utilizadores colocaram apenas 18 questões, o moderador afirmou a brincar que "isto prova que os clientes estão satisfeitos". Nada mais errado. Os clientes que não dão voz às suas reclamações, quando lhe é dada essa possibilidade, é porque já desistiram (em grande parte dos casos) e ficam à espera de respostas. A atitude inconsciente por parte dos clientes que está associada a este sinal de aviso é considerarem que as suas queixas serão encaradas como algo irritante que tem de ser tolerado.

As queixas/sugestões dos utilizadores reais são boas e não más. As pessoas que utilizam e gostam de um software estão constantemente a pensar em mais problemas que o produto poderia resolver. Isto só acontece quando as reclamações aumentam (e não o contrário). Neste contexto, sempre que se resolve um problema, as queixas/sugestões tenderão a aumentar. Se um fornecedor de software lançar uma resolução de um problema (patch) e ninguém se pronunciar, a conclusão é simples: ninguém a experimentou.

5. Perdemos o código fonte.

Os programas são activos valiosos que dependem de uma infra-estrutura para a sua preservação. Se adoptarmos atalhos no desenvolvimento, perdemos o controlo desses activos. Aquilo que é necessário, é simples, mas exige disciplina. Para qualquer programa existe uma job stream que recompila a versão actual. Essa job stream mostra os ficheiros fonte do programa e a forma como os combinar. O ambiente de teste é mantido separado do ambiente de produção. Outro trabalho standard passa uma nova versão do ambiente de teste para o ambiente de produção.

6. Estamos demasiado ocupados para documentar isso.

Se quisermos que cada programador reinvente a roda, estamos a promover a ineficiência. As técnicas de software utilizadas por um grupo de trabalho poderão tornar-se um activo valioso se forem documentadas. Existe uma forma ainda melhor de reter o conhecimento: utilizar bibliotecas de código. O código reutilizável rentabiliza o investimento. Se um programador tem trabalho a resolver um problema, os outros não precisam de ter trabalho idêntico para resolver o mesmo problema.

Os bons programadores escrevem software que pode ser reutilizado, mesmo que não vejam uma reutilização imediatamente no horizonte. O desenvolvimento para ser reutilizável também obriga a definir interfaces limpas.

Quando um programador não consegue encontrar a razão para um bug complicado e particularmente bizarro, existe certamente uma desculpa que pode ser utilizada:

7. Tem que ser um problema de hardware.

De todos os bugs que investigámos em cerca de 20 anos nas empresas, apenas num caso se provou ser um verdadeiro problema de hardware. A grande verdade é que o hardware é espantosamente fiável, enquanto que o software não.

8. Seria demasiado caro actualizar a documentação.

Num famoso estudo sobre o desastre do Challenger, chegou-se à conclusão que um grupo de funcionários de produção tinha identificado uma forma simples de melhorar a calibragem dos motores do foguetão, mas a mesma nunca foi implementada. Foi escrito um memorando com essa sugestão para o superior hierárquico dois anos antes, mas não teve qualquer seguimento. Quando foi questionado sobre a razão porque não lhe deu seguimento, o superior disse que a sugestão era demasiado cara.

Não era a implementação da sugestão pura e simples que era cara, mas antes a revisão e actualização de todos os manuais. Os trabalhadores tinham outras observações e sugestões, mas não eram muito encorajados nesse sentido. Ninguém dava muita atenção.

Quando as pessoas não querem preocupar-se com alguns aspectos, costumam-se ouvir frases como a seguinte:

9. Ninguém irá aperceber-se disso.

O que isto quer dizer é que os utilizadores são demasiado estúpidos para reconhecer a qualidade quando são confrontados com ela. Podemos ir buscar um exemplo deste espírito à Ford Motor Company, que em tempos implementou algo a que chamou PIP (Profit Improvement Program). O objectivo dos PIP era reduzir os custos de construção dos carros equipando-os com materiais mais baratos. Alguns tradicionalistas estavam convencidos de que os PIP reduziam a qualidade, mas que os clientes nunca se aperceberiam das diferenças. Curiosamente, os PIP rapidamente entraram no vernáculo para designar cortes em algo.

Nunca sabemos quais são as funcionalidades que são importantes para os nossos utilizadores. O sucesso exige atenção a todos os detalhes. No caso do software, os utilizadores prestam atenção às pequenas coisas. E parecem mais sensíveis aos detalhes do que ao mais importante - talvez porque vêm o mais importante como garantido, enquanto que os detalhes os enfurecem no dia a dia.

10. Mais um Go To não faz mal nenhum.

Os bons programadores não utilizam o Go To para resolver problemas de lógica. Estruturam o seu código tão facilmente como respiram. Mantêm os seus programas dentro da sua dimensão intelectual utilizando estruturas de controlo limitadas: While, Do-Until, If-Then_Else, e Case. Manter as coisas simples faz com que sejam mais fáceis de compreender. O problema com o Go To reside no facto de podermos criar estruturas complexas com ele.

11. Só iremos reutilizar este item de dados.

Os programadores disciplinados não dão dois nomes a uma coisa, nem atribuem duas coisas a um nome. Os nomes têm significado e são específicos. Além disso, a sua dimensão é proporcional à sua abrangência. Os programadores disciplinados aderem aos standards do seu grupo de trabalho, mesmo quando esses standards parecem arbitrários. Um programa é escrito uma vez, mas lido muitas vezes. Como tal, deve-se facilitar a leitura às outras pessoas que vão ler o código.

12. Isso nunca poderá falhar - não se preocupe em testá-lo.

Apesar de toda a confiança e certezas dos programadores, será necessário testar exaustivamente para evitar falhas. Isto também é válido para os procedimentos manuais, como a instalação de uma nova versão. Nunca se deve embarcar em afirmações como "já fiz isto tantas vezes, que poderia fazê-lo de olhos fechados", o que quer dizer "é impossível enganar-me".

Infelizmente, é nas tarefas mais corriqueiras que é mais provável cometermos erros, uma vez que é mais difícil manter a concentração. Desta forma, sempre que instalamos um novo software, temos que seguir uma lista de tópicos escritos que inclua todos os passos para criar uma nova versão do produto, mais os passos para verificar se a instalação foi realizada de forma adequada.

13. É um projecto fascinante - foi pena ter falhado.

O fascínio por esquemas e negócios grandiosos conduz a elefantes brancos. Os sintomas são objectivos pretensiosos, custos elevados, afirmações fantásticas, abandono de outros projectos, negação fanática do fracasso, e um cancelamento repentino e total. Tudo isto é desnecessário. No caso do software, os grandes resultados podem ter origem em pequenos investimentos, enquanto que os fracos resultados podem ser consequência de grandes investimentos.

14. Já realizámos testes manuais - não é suficiente?

Não podemos testar até à completa ausência de bugs, uma vez que não podemos testar todo o código. No entanto, podemos testar os casos típicos e os casos fronteira: valor mínimo, valor máximo e sem valor. Nos ambientes de teste mais rigorosos, é prática corrente procurar uma cobertura de 100 por cento.

A resposta reside nos testes automatizados. Os computadores podem realizar mais testes do que nós manualmente, e realizá-los de modo mais fiável. Quando se está a trabalhar na resolução de um bug, uma boa prática é acrescentar um teste que reproduza o problema. A reprodução de um bug da solução de testes também nos avisa se o mesmo bug volta a afectar o código.

15. Está resolvido, mas está à espera do próximo ciclo de release.

A instalação de novo software em ambiente de produção é um processo propício a erros. Tudo tem que ser testado (código fonte, ficheiro de ajuda, manual). Quanto mais o processos de instalação for à prova de erros, mais caro será e mais tempo exigirá. Esta realidade desencoraja as actualizações de software frequentes, demorando muito tempo a disponibilizar resoluções de bugs, mesmo as mais simples. A forma de acelerar os ciclos de desenvolvimento é automatizar todos os passos.

16. Isso não pode ser alterado - há demasiado código a referenciá-lo.

As variáveis globais são o pior inimigo do bom software.

17. Isso significaria alterar todos os programas.

O ano 2000 preocupou todos aqueles que reservaram apenas dois dígitos para o ano, em vez de quatro. As facturas ficam com a data de 1 de Janeiro de 1900 com a viragem do século? E como vamos ordenar por data quando 01 é menor que 99?

18. Demos aos utilizadores aquilo que pediram.

Um especialista em desenvolvimento disse um dia que "quanto mais rígidas foram as especificações, maiores as probabilidades de errarmos". É natural planear apenas uma release de um novo programa. No entanto, infelizmente, o desenho do software original raramente é aquilo que os utilizadores realmente precisam. Quanto mais pressionarmos os utilizadores a dizerem-nos aquilo que querem, mais frustradas ficam ambas as partes. Os utilizadores nem sempre conseguem dizer aquilo que precisam, mas reconhecem aquilo que não querem quando o vêem.

A chave para escrever software de qualidade é fazê-lo em várias releases. Depois dos utilizadores terem a primeira release, os programadores podem incorporar o feedback (reclamações/sugestões) na release seguinte.

Veja quantos pontos obteve

Some os pontos obtidos com as respostas às afirmações/questões anteriores. Lembre-se de que cada afirmação ouvida frequentemente na sua empresa/grupo de trabalho vale cinco pontos. Quanto menor for a soma final, melhor.

• 0 pontos. Demasiado bom. De certeza que fez batota.
• 20 pontos. Excelente. Parabéns.
• 40 pontos. Respeitável. Bom trabalho.
• 60 pontos. Preocupante.
• 80 pontos ou mais. Um desastre.
  

Adaptado de um documento intitulado "The Warning Signs, A Pop Quiz on Quality", da autoria de Robert Green e David Greer e publicado pela Robelle Solutions Technology Inc.

Produzido em 2005