Qualidade Interna vs Qualidade Externa

Processos de desenvolvimento de software são quase todos iguais em termos de práticas e todos podem assumir práticas novas de outros processos, até cascata pode aplicar qualquer prática de XP e Scrum em seu modelo naturalmente.

O que diferencia esses processos não são as práticas, são os valores. O problema é que entender, compreender e adotar valores é algo subjetivo que varia de pessoa para pessoa por mais que se tenha princípios bem definidos que conectem as práticas a esses valores.

Diante disso, nenhum processo garante que seu projeto será um sucesso por estar o seguindo, mesmo que seja “By The Book”.

Há uma preocupação com o chamado Scrumbut, mas eu já vejo e vi projetos Scrum que não são Scrumbut e mesmo assim o software produzido, por mais ágil que seja, não tem qualidade e no primeiro refactoring você já entra no prejuízo similar a um software desenvolvido em Cascata.

Fato é que esses valores e princípios não garantem software com código coeso, desacoplado, limpo, claro e facilmente lido, ou seja, com qualidade interna.

Hoje minha preocupação em todos os projetos é a qualidade interna do software, não importa que metodologia seja adotada. Qualidade interna garante que o software tem boa saúde e é fácil de ser medida.

Saúde do software é o quão rápido e efetivo ele se recupera de mudanças e o quão limpo ele está de defeitos. Para se recuperar de mudanças o software precisa ser limpo e claro, ser facilmente entendível e lido.

Livre de defeitos é ter uma cobertura de testes que explorem e machuquem o código até descobrir falhas que passam despercebidas.

A grande maioria dos processos se preocupa mais com a qualidade externa do que a interna. Não importa se você faz reuniões em pé, tenha o cliente presente ou faça Scrumban ou até mesmo que você esteja entregando software rápido, nada disso vai garantir qualidade e que não vá ter prejuízo no futuro.

Vender qualidade externa tem um apelo comercial fácil porque você não precisa comprovar a qualidade do software e sim do processo, o discurso é sempre mais elegante do que falar em código, principalmente para alta gerência e burocratas, tanto é que todos os modelos de qualidade reconhecidos avaliam o processo e não o produto.

CMMi, ISO ou seja lá que for, não garantem que o produto será de qualidade e sim que o processo seja e se pararmos para pensar um momento, o processo realmente é de qualidade, temos um conjunto de métodos eficazes para produzir… processo e não produto.

Um exemplo de qualidade interna de um software são os testes automáticos em suas diversas nuances como unitários, aceitação, integração e funcional, mas não apenas isso, métricas de coesão, cobertura, LOC, complexidade e tantas outras.

No Maré de Agilidade eu fiz questão de enfatizar:

“Não importa que processo você siga, se é ágil ou não, se você não faz testes de Software vocês está errado em todos.”

Não existe um software sem bateria de testes automáticos com qualidade, isso é lenda. Em mais de 10 anos de profissão o que tenho notado é que a grande maioria, senão todos, são fortemente acoplados e de baixa coesão como consequência da falta de testes. Aplicar testes nesses softwares é uma tarefa quase impossível e proibitiva em relação a custos, sai mais barato fazer um software novo.

Outra coisa que falei no Maré de Agilidade foi:

“Não seja ágil, seja o melhor possível, porque ao procurar ser o melhor você invariavelmente vai se deparar com práticas que o tornam melhor e aí você se tornará ágil”.

Assim como o lema da Rossi: “Armas não matam pessoas, pessoas matam pessoas” podemos induzir que: Processos não desenvolvem software, pessoas desenvolvem software!

Ao trabalhar com pessoas, precisamos entender que modelos de negócios como software são de terceira onda [Alvin Toffler aqui] e não da segunda onda [industrialismo]. Qualquer analogia com modelos de segunda onda provocará insuficiência no trabalho dessas pessoas [por isso Lean faz tanto sucesso hoje] e elas precisam estarem motivadas para produzir qualidade interna, coisa que o trabalho sobre qualidade externa não produz.

Esse tema sobre pessoas e processos [como homem/hora] será escrito em outro artigo.

Resumo desse artigo é: Pessoas são responsáveis por produzirem qualidade interna ao produto e não processo, invista nelas.

7 thoughts on “Qualidade Interna vs Qualidade Externa

  1. Pingback: Tweets that mention Milfont.org Ultrapassando os limites da WEB -- Topsy.com

  2. Bruno Pereira

    Perfeitamente colocado meu caro Milfont.

    A verdade é que se você tem as pessoas certas para construir o produto, a última coisa que você vai ter que se preocupar é em validar a cartilha de algum processo.

    Discussões sobre processos só ocorrem com tanta freqüência porque são muito raros os times genuinamente auto-gerenciados.

  3. Marcos Sousa

    Grande post Milfont!

    Geralmente, testes automatizados não é uma tarefa muito fácil, exige pensar muito, principalmente quando a estrutura do código não favorece. Aí nestes casos prevalece a lei do menor esforço, validar telinhas. E como você disse não existe prática ágil, processo, certificação que garanta a qualidade.

  4. Carlos Átila

    Ótimo post Milfont.

    O Cliente está mais preocupado com a “Qualidade do Processo” do que a qualidade da codificação, acredito que uma das razões da qualidade do processo vencer a qualidade interna, é que atulamente a qualidade do processo possui uma “PROPAGANDA MUITO MELHOR”, o que faz que muitas empresas só enxergam “CMMI”, “RUP”, não atentando para a qualidade interna que é essencial para o projeto.

  5. Pingback: Palestra Agilidade no Mundo Real - Milfont Consulting

Leave a Reply

Your email address will not be published. Required fields are marked *