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.

Typically chemist’s shop can sale to you with discreet treatments for various soundness problems. There are numerous of safe online pharmacies that will deliver medications to your address. There are divers medicines for each afflictions. Learn more about “viagra manufacturer coupon“. Maybe “viagra discount coupons” is a very complicated question. Matters, like “coupons for viagra“, are coupled numerous types of heartiness problems. If you need to take prescription medications, ask your druggist to check your testosterone levels before. Sometimes the treatment options may switch on erectile malfunction remedies or a suction device that helps get an erection. Keep in mind web-site which is ready to sell erectile disfunction drugs like Viagra without a formula is fraudulent. When you purchase from an unknown web-site, you run the risk of getting counterfeit remedies.

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

Comments are closed.