Há alguns meses, surgiu uma questão a respeito da qualidade. Enquanto pensava na afirmação, "Com certeza a qualidade interessa a todos, sempre", e fazendo um paralelo com o nosso dia a dia, percebi que esta frase não é verdadeira. Nem sempre queremos qualidade, ou estamos com possibilidades de pagar por ela.
Ontem, bebendo um chopp com um amigo do trabalho, ele me disse: "Cara, a única coisa que não é passível de discussão é qualidade". E eu respondi: "Não é bem assim". Dada a minha fama de desenvolvedor psicopata, obviamente, a minha afirmação gerou um certo espanto, que ficou clara na expressão dele.
Este assunto é delicado e gera controvérsias. Trazendo para o mundo real, vou citar um exemplo, que acredito ser pertinente.
No nosso dia-a-dia, na verdade, nem sempre estamos atrás da qualidade. Pretendo, neste ano, comprar um autorama de Natal para meu filho de 4 anos de idade. Entretanto, não sei qual seria a reação dele ao brinquedo e nem sabia se ele seria capaz de brincar. Então, na semana passada comprei um mais barato para ver se no Natal poderia comprar um "de verdade".
Este foi apenas um pequeno exemplo, com um caso onde a qualidade foi postergada. Existem outros no cotidiano, como a compra de um carro, de roupa, relógio e por aí vai.
Voltando ao desenvolvimento de software, acredito que o problema central seja a visão superficial de alguns clientes no que diz respeito à qualidade de software. Para estes clientes, qualidade significa correctness e uma boa interface (beleza e usabilidade).
Na minha visão, esta definição de qualidade está incompleta, pois é superficial. Como o Yoshima falou no Maré de Agilidade e eu já venho dizendo desde o início deste blog, a maior fase do tempo de vida de um software, normalmente, é a manutenção. Assim, a qualidade de código é importante, pois está intimamente ligada a esta fase. Mas o cliente não tem visibilidade direta disso, o que pode sugerir pouca importância do código bem desenvolvido.
Por não ter esta visibilidade, não fica claro para o cliente que, pagando menos, ele pode obter correctness e um boa interface, mas um péssimo código, o que vai dificultar muito a fase de manutenção.
Uma possível analogia no mundo fora do desenvolvimento de software, seria comprar uma Ferrari com um motor de Fusca. Neste caso. o desempenho do carro deixará claro o motivo daquela Ferrari ter sido tão barata. Da mesma forma, o baixo desempenho na fase de manutenção (dificuldade de alterar, incluir e excluir requisitos) pode indicar o motivo daquele software ter sido tão barato.
E você? Quais são as suas reflexões sobre a qualidade de software?
Olá Celso!
ResponderExcluir"Cara, a única coisa que não é passível de discussão é qualidade"
Na minha opinião, qualidade é uma das coisas mais passíveis de discussão, simplesmente, pelo fato de que a qualidade é muito influenciada pela visão da pessoa e por sua situação.
Exemplo:
Quando estou com pressa para chegar em casa do trabalho, eu pego o trem uma estação (Brás) depois da de partida (Luz).
E o resultado disso é uma viajem com menos qualidade, uma vez que é bem provável que eu fique de pé durante toda viagem, pois todos os lugares do vagão já estão ocupados.
Ou seja, eu abdiquei da qualidade, por causa da velocidade.
Isso também ocorre no desenvolvimento de software. E se todos estão de acordo com isso, não há problema em entregar um software com menos qualidade, em prol da velocidade, pois a perda representada pela baixa qualidade, pode ser menor do que a perda que ocorreria com o atraso na entrega.
Parabéns pelo post, gostei das reflexões! ;)
Primeiramente, parabéns pelo post. Muito bem organizado.
ResponderExcluirSobre a qualidade de software, é passível de muita discussão sim, dependendo da visão de cada um (começou a complicação). Citarei alguns exemplos, somente para contextualizar. Para o testador: é um software sem erros. Para o Gerente de projetos: é um software dentro dos requisitos de prazo e custo. Para o designer: software usual. Para o cliente, conforme você falou: software correto e fácil. Para o desenvolvedor: de fácil manutenção.
Agora como juntar tantas visões diferentes em um mesmo conceito? Dentro do escopo, prazo e custo. Bem complicado! Afinal, muitos clientes acreditam que a Qualidade nem precisa ser mencionada, pois já deve estar dentro do processo.
Bem, essas foram apenas algumas reflexões sobre o tema.
Forte Abraço!
@Fabricio,
ResponderExcluirObrigado pela participação e pelo elogio.
Acho que o problema principal é exigir um "nascimento" rápido, atropelado e achar que este software terá um ótimo desempenho na fase de manutenção, que na verdade, começa depois de escrever as primeiras linhas. Não tem mágica! Tem que se dedicar naqueles 20% que representa o nascimento de uma aplicação.
Abs
@Renato
Também agradeço sua participação e o elogio.
Acredito que a chave seja unir tudo isso no projeto. Os principios da qualidade estão interligados.
E o mais interessante: É possível ter tudo que agrada todo mundo. É só organizar. Organizar os processos, prazos e se auto-organizar. TDD é produtivo, pair-programming é produtivo. É possível criar mais (requisitos), melhor(qualidade) e em menos tempo.
Abs