segunda-feira, 3 de janeiro de 2011

Variabilidade X Anormalidade

Muito tem sido dito sobre diminuição da variação no processo de desenvolvimento de software.

Infelizmente existe uma confusão de terminologia que não deve ser aceitar/mantider, sob pena de estarmos nos direcionando novamente no paradigma Fordista e ainda atual da Engenharia de Software.

Quando Ford produzia seus carros em 1904, a demanda era muito superior a sua produção, os mercados eram ávidos por seus produtos, portanto, segundo Ford: Henry Ford: "O carro é disponível em qualquer cor, contanto que seja preto..".

Isso se chama variabilidade na indústria.

Outro fenômeno paralelo é que, desde a manufatura artesanal, ocorria que as peças apresentavam imprecisões, por baixa padronização ou por erro de produção, que são consideradas anormalidades da produção.

Tais anormalidades são medidas, e em controle estatístico de processos, são identificadas como variações de medida dentro do processo.

Diz-se, matematicamente, que o desvio entre o esperado e o obtido é uma variação.
Existe ainda a propriedade estatística que define que a soma dos desvios será sempre zero.
Portanto para descobrirmos um desvio médio (erro médio) não se pode tirar a média dos desvios (erros), faz-se a média dos desvios quadrados, a que chamamos variância.

O desvio padrão, ou média dos desvios, é a raiz quadrada da variância.

Busca-se matematicamente diminuir esta variação com o objetivo de eliminar as anormalidades ou erros do processo.

Entretanto, não se busca diminuir a variação, porque a variação é inerente a demanda.
Variação significa evolução, de conceitos, de valores, da sociedade e da indústria.

Busca-se eliminar os erros e seu desvio do objetivo inicial.

Vários autores em desenvolvimento de software pregam eliminar a variação, o que é incorreto.

Devemos sim trazer o processo para a eliminação de erros, e para uma estabilidade tal que possamos conhecer e estimar o desempenho, qualidade e capacidade do processo.

É interessante dizer que existem técnicas de controle estatístico de processos que existem com esta finalidade, entretanto existem outras técnicas como o Six Sigma, que buscam otimizar processos sob a ótica do controle estatístico.

Entretanto, existe um perigo intrínseco e antigo em otimizações.

Ford, na década de 20, atingiu através da padronização das peças que utilizava o auge da velocidade de produção, quando tem início de fato a era da "Produção em Massa". O sistema então chamado Fordista, consegue diminuir drasticamente os erros e tempos de produção.

Ford atingiu o que na Toyota se chama de fluxo de produção, com a diferença que Ford levava as máquinas e pessoas ao estresse extremo, tirando a última gota de sua capacidade de produção.

A velocidade que a Toyota propõe é na verdade baseada na eliminação de desperdícios, esperas, operações ineficientes e desnecessárias. Entretanto, mesmo as paradas totais da fábrica são apoiadas e necessárias, com vistas ao trabalho consciente e a melhoria da qualidade do trabalho.

Outra dúvida/erro muito comum é achar que na Toyota tudo tem que ser feito rápido, isso é uma afirmativa errada. Não pode haver demoras e esperas, isso sim. Mas os funcionários devem poder realizar o trabalho em um rítmo sustentável e calmo para poder observar e pensar sobre o que estão fazendo, e sobre como podem mudar para atingir a resultados melhores.

Entretanto, na Ford a otimização unicamente do desempenho estava direcionada para a produção de estoques. Com este objetivo, unicamente velocidade, pode-se monitorar as estatísticas e produzir mais rápido, gerando estoques cada vez maiores e mais cheios.

De forma semelhante, o desenvolvimento de software pode ser acelerado usando técnicas estatísticas, mas será este um caminho para o processo ideal?

Por este mesmo motivo, atualmente é difícil encontrar casos de processos otimizados unicamente por SixSigma. Na verdade utiliza-se mais de uma forma de otimização associadas, como por exemplo Lean + SixSigma, ou Lean + TOC.

O Lean ( ou Pensamento Enxuto) possibilita mudar qualitativamente o processo, dando rítimo sustentável para o processo de trabalho, o que significa LEVE ou LIVRE de esperas, demoras, e outras formas de desperdício, e somente por isso mais rápido, como consequência.

A Engenharia de Software, na busca de um processo Otimizado, no CMMI em seu nível mais alto, já ouviu falar do SixSigma, e recentemente começou a ouvir falar de Lean.

Talvez, daqui a pouco tempo estejamos percebendo a Engenharia de Software se livrar dos paradígmas de processo Fordistas e da Produção em Massa.

Um comentário:

  1. A raíz de maior parte dos problemas do Desenvolvimento de Softwares talvez seja, esse medo eterno de mudanças. Os processos são construídos para serem moldados e imediatamente após serem considerados "finalizados", todo seu conteúdo gerado é engessado, estocado, e só após uma lacuna de tempo que esse conteúdo engessado será recuperado.
    Dessa forma eles tentam evitar a variação, mas só acabam aumentando a variância. Se faz preciso aprender que os erros são filhos da variância e não da variação.
    E outra grande causa de erros é a pressa. Já diz o ditado "a pressa é inimiga da perfeição". No Desenvolvimento de Softwares, é pior ainda. Apressamentos não ajudam a obter qualidade de produção, pelo contrário. O que pode ajudar na qualidade é quando a comunicação entre os processos flui sem problemas, com agilidade, mas sem gerar gargalos em certos pontos.
    É importante não apenas observar os processos matematicamente, mas sim saber o que se fazer com os números obtidos. Talvez por isso o SixSigma não seja usado sozinho em projetos de Desenvolvimento. Porque Desenvolvimento de Software não é produção de materiais fisicos, e sim de conhecimento

    ResponderExcluir