Fabricação vs Desenvolvimento de software [fechado]

Costuma-se dizer que a indústria de software é imatura em comparação à manufatura. Especificamente no que diz respeito à condução do processo.

Pergunta : Como desenvolvedores, podemos aprender com os processos da indústria de transformação? A adoção de seus processos pode aumentar a taxa de sucesso do desenvolvimento de software?

Minha opinião : na fabricação, a criação de um produto é fortemente orientada por processos. Você pode ter uma fábrica onde cada pessoa tem um conjunto específico de tarefas que segue. Um trabalhador (ou robô) pode apertar um parafuso o dia todo. Em seguida, a próxima tarefa do processo é executada pelo próximo especialista. Os trabalhadores (e robôs) não se intimidam com o processo ou inventam algo "on the fly". As peças agitam durante o processo e a saída é um produto acabado. Funciona bem e as empresas alcançam 99,99966% de produtos sem defeitos. As empresas resolvem ineficiências ao longo do tempo. Isso é impressionante e muito bem pode ser o sinal de uma indústria madura.

Na fabricação, um processo definido pode literalmente criar o produto final. Eu não acho que esse seja o caso em software. Podemos ter processos para controle de origem, revisão de código, folhas de check-in, coleta de requisitos, SDLC, etc. Mas a execução desses processos não cria, por si só, um produto acabado. Esses processos podem ser benéficos, mas são ortogonais à criação real.

Suponha que sua empresa seja contratada para criar um software que procurará milhões de imagens para encontrar o rosto de um criminoso. Apesar do ambiente pesado do processo, o desenvolvedor deve se engajar na criação de coisas "on the fly". Fazer as coisas rapidamente é contra o espírito da manufatura. Um bom processo de fabricação pode ser executado sem pensar por um robô.

Para a criação de algoritmos complexos que ainda precisam ser compreendidos na mente de um humano, é necessário criar coisas em tempo real. O desenvolvimento de software não é o seguinte de um processo, mas a criação de um processo a ser exucuído por um computador. Essa é uma diferença fundamental. Não importa quantos processos ortogonais montamos em torno do desenvolvimento, sempre recorreremos a fazê-lo "on the fly" quando se trata de criação.

Todos com quem falo parecem concordar com a mentalidade de fabricação. Estou sozinho em meus pensamentos?

A diferença fundamental entre desenvolvimento e fabricação de software é que, para o software, a fase de design é praticamente a coisa toda. A produção real (parte da linha de montagem na fabricação tradicional) é uma questão de copiar alguns arquivos. No software, o design do produto é o produto.

Portanto, sim, podemos aprender com os processos de manufatura, mas somente se tivermos em mente que precisamos observar a fase de design, não a fase de produção, e que muitos processos de manufatura são criados para lidar com as limitações específicas de uma cadeia de produção cara , que simplesmente não se aplica ao software.

Um exemplo de modelo de processo que funciona muito bem em software, mas geralmente falha de maneira terrível no design de produtos, é o design iterativo - você começa com um protótipo mínimo e adiciona recursos a cada iteração. Construir um carro protótipo para ver como é o novo design do botão da janela traseira é ridículo, mas no software faz sentido (basta pressionar F5 e esperar alguns segundos - pronto, pronto para testar).

Se olharmos para os processos de design do produto, os melhores setores para se olhar se enquadram em duas categorias:

• aqueles onde a produção pode ser realizada a taxas de commodities; por exemplo, a indústria fonográfica (1% ou menos do preço de um CD é de panificação e impressão), mídia gráfica etc.
• aqueles em que as quantidades são tão baixas que a fase de design é o fator de custo mais importante (artigos de luxo, produtos altamente personalizados, nichos de mercado ...)

É um erro fundamental tentar aplicar processos da fabricação física ao desenvolvimento de software: o desenvolvimento de software não é repetitivo (se você estiver no seu trabalho, procure outro emprego), é apenas parcialmente previsível, existem apenas poucas limitações físicas ( velocidade de hardware sendo uma) e a abordagem adotada e os resultados podem ser altamente pessoais. A aplicação das filosofias da linha de montagem ao que é basicamente uma questão de pensamento analítico e criativo pode (e costuma ter) ter efeitos devastadores.

Se você quiser escrever o mesmo software exato repetidamente (em vez de simplesmente copiá-lo), poderá fazê-lo com muita eficiência por meio de uma linha de montagem.

Mas a criação de software não é uma tarefa repetitiva, cada módulo é uniqe. É por isso que a comparação com a fabricação é inválida.

Eu acho que a resposta que você está procurando é aplicável ou realista aqui. O que eu sinto que você quer saber é como podemos configurar nossos processos para se parecerem mais com a indústria de transformação. Em vez disso, penso que a verdadeira questão se torna "Saber o que a manufatura e outras indústrias fazem para criar produtos de qualidade, o que podemos aprender?" ou "O que a indústria de software pode fazer para melhorar a qualidade?"

Infelizmente, a resposta para isso não é clara, porque a própria indústria de software ainda não sabe a resposta. Para poder responder a isso, a indústria de software precisa fazer pesquisas sobre o que funciona e por quê? Por exemplo, houve estudos que mostram que o Test Drive Design (TDD) leva a uma melhoria na qualidade. Embora a questão da produtividade ainda pareça não respondida ou pelo menos ainda não completamente esclarecida. Na medida em que as evidências mostram até agora:

• As análises de código são excelentes e são mostradas para encontrar o maior número de erros, mas a eficácia de uma análise diminui bastante após a primeira hora de análise. Dado que a pessoa comum só pode ler algumas centenas de linhas de código por hora, isso sugere que os desenvolvedores devem dividir as alterações em partes menores.
• Quanto mais tempo demorar para encontrar um bug, mais caro (tempo e dinheiro) será corrigido. Portanto, se um desenvolvedor o encontrar enquanto escreve o código, dizemos que o custo é 1. Se um unittest o encontrar mais tarde, o custo será 10, se a EVT achar que o custo é 100 e assim por diante.
• Há alguma evidência que sugere que, quanto mais complexos são os requisitos, mais complexa é a solução e mais complexa é a solução, maior a probabilidade de haver erros.

Há um homem chamado Greg Wilson que deu uma excelente conversa sobre isso há alguns anos atrás. Aqui está um link para a palestra: Greg Wilson Talk

Além disso, eu diria que lembre-se de seu próprio trabalho e encontre os temas com os tipos de erros que você introduz, bem como com quais partes você luta. Compile esses resultados e crie uma lista de verificação para inserir em seu processo em locais diferentes para ajudá-lo a fazer um trabalho melhor. Pessoalmente, olhei para os últimos anos do meu trabalho e descobri que existem alguns temas comuns para os problemas que apresento. Especificamente, descobri que

• Não me lembro com frequência de criar todas as variantes que me levaram a quebrar a compilação.
• Muitas vezes, não penso no seguinte para cada alteração. O caso bom, o caso ruim e os casos excepcionais.
• Todos os cenários possíveis que podem acontecer. Observe que isso é realmente difícil, porque existem muitos deles.

Desde que encontrei alguns temas para meus erros, criei listas de verificação que eu uso automaticamente, devido à inserção deles nos meus scripts, que me ajudam a solucionar esses problemas. Havia um livro escrito sobre essa chamada, o "Manifesto da lista de verificação", que detalha como eles podem ser utilizados. Pessoalmente, achei muito perspicaz.

Não se trata de adotar "seus" processos. Trata-se de adotar "alguns" processos, que não têm os prejuízos usuais e bem apreciados do uso de processos de linha de montagem para empreendimentos criativos. O mais importante a ser observado aqui é a ideia de que a qualidade dos processos se traduz diretamente na qualidade do produto.

Os melhores processos ou produtos para esse assunto são os que se encaixam no cenário de uso pretendido, como uma mão na luva. O que se deve pensar é que a parte real da escrita de código é a única que, pelo menos em nível macroscópico, não é repetitiva. Todas as outras facetas, como controle de versão, rastreamento de bugs, planejamento, estimativas, medições, etc. são, e o uso de um processo padrão, personalizado e comprovado pode ajudá-lo, pelo menos nessas áreas.

Portanto, não, o processo de desenvolvimento de software não pode ser comparado à produção da linha de montagem e, como tal, "seus processos" não são bons, mas a fase de design de produção / design de produto do produto em uma indústria de fabricação pode ser a única a se inspirar.

Pergunta: Como desenvolvedores, podemos aprender com os processos da indústria de transformação? A adoção de seus processos pode aumentar a taxa de sucesso do desenvolvimento de software?

Resposta: Sim, claro. Há muitas lições que os desenvolvedores de software podem aprender com a fabricação, apesar de o desenvolvimento de software ser um processo criativo. O desenvolvimento de software é, por si só, um processo e inclui muitos outros processos. Quanto melhor você definir e controlar esses processos, melhor poderá controlar o processo de desenvolvimento de software em geral. Isso não significa que você deve prescrever todas as teclas digitadas por um desenvolvedor; significa apenas que, como desenvolvedor, você naturalmente executa tarefas em uma determinada ordem, e essas tarefas geralmente podem ser gerenciadas. aqui estão alguns exemplos:

• rastreamento de defeitos: quando um erro é observado ou relatado, o que acontece com ele? Você o escreve em um pedaço de papel e o cola em uma ponta de 'investigação'? Mais tarde, você remove esses restos, um de cada vez, os investiga e, eventualmente, os move para o pico "resolvido"? Se você fizer isso sem falhas toda vez que receber um relatório de bug, terá um processo mensurado e bem definido, e provavelmente estará muito melhor do que alguém que tenha um sofisticado sistema de rastreamento de defeitos de alta tecnologia que é tão oneroso que alguns membros da equipe rastreiam os erros de outras maneiras, ou de modo algum.

• controle de versão: existe uma boa chance de você usar o controle de versão onde trabalha e, obviamente, o controle de versão é muito mais útil quando todos usam da mesma maneira.

• design do produto: você decide quais recursos implementar lançando dardos em uma parede coberta com post-its? Nesse caso, você tem um processo. Eu não acho que alguém argumentaria que é um ótimo processo, mas pelo menos é um ponto de partida. Se você mudar o processo, como pode ter certeza de que sua mudança foi realmente uma melhoria, a menos que você avalie antes e depois? Você não pode.

• revisões de código: uma revisão de código seria útil se o processo de revisão e os critérios de codificação fossem alterados para cada revisão? Claro que não.

• ciclo de vida de desenvolvimento de software: Toda a análise -> design -> implementação -> teste -> ciclo de manutenção é um processo que deve ser definido claramente.

Em cada um desses casos, a implantação de um processo permite medir entradas e saídas e determinar se as alterações efetuadas têm o efeito pretendido. Não ter processos no lugar significa que você está apenas tentando adivinhar quando tenta melhorar a maneira como trabalha. É realmente disso que se trata a manufatura, e só faz sentido emprestar as sucessivas ferramentas de refinamento da manufatura, quando apropriadas.

Existe um campo inteiro dedicado à definição e melhoria de processos usados ​​para criar e manter software; isso se chama engenharia de software . Não é surpresa que você tenha dúvidas sobre o processo de desenvolvimento enquanto lê sobre o CMMI - o CMMI é um produto do Software Engineering Institute .

O desenvolvimento de software já adotou muitos conceitos de fabricação:

• É difícil não ver a influência das partes intercambiáveis ​​de Eli Whitney no desenvolvimento da OOP e no componente .

• As técnicas de gerenciamento de projetos usadas no desenvolvimento de software não são muito diferentes daquelas desenvolvidas para a fabricação. Como apenas dois exemplos, o mundo do software adotou apenas recentemente o conceito Kanban, desenvolvido décadas atrás na Toyota, e os gráficos de Gantt foram utilizados na fabricação muito antes da construção do primeiro computador eletrônico.

• Metodologias de gerenciamento da qualidade, como o Six Sigma, desenvolvido para fabricação, foram adaptadas ao desenvolvimento de software.

Apesar do ambiente pesado do processo, o desenvolvedor deve se engajar na criação de coisas "on the fly".

Você está me dizendo que alguém decidirá por si próprio adicionar um patch ao pacote de reconhecimento facial e o incluirá na criação de produção sem antes criar um problema no sistema de rastreamento, revisar o design, verificar o código no controle de versão ou fazer com que o pessoal do teste o analise primeiro? Nosso processo exige essas coisas por algumas boas razões. Se "on the fly" você quer dizer "fora do processo", isso é inaceitável.

Fazer as coisas rapidamente é contra o espírito da manufatura.

Novamente, se "on the fly" significa "fora do processo", você está certo. Mas se você acha que a fabricação não requer pensamento rápido e desenvolvimento de soluções criativas para os problemas, você está errado. Todos os tipos de problemas surgem no processo de fabricação - os cupcakes não têm enchimento suficiente de creme, as superfícies pintadas de repente param de passar no teste de controle de qualidade, 20% das peças acabadas não possuem um anel de retenção importante, o sistema de mistura de massa quebrou parte crítica...