Existe uma correlação entre algumas práticas de engenharia de software e histórias de sucesso de engenharia de software?

Eu tenho lido o livro " A caminhada dos bêbados: como a aleatoriedade governa nossas vidas ", de Leonard Mlodinow, e é uma leitura verdadeiramente esclarecedora. O livro lida com probabilidades e raciocínio humano. E digamos, apenas para constar, que enquanto algumas coisas às vezes funcionam, há uma chance de que as coisas que você pensou que fizeram funcionar não estejam relacionadas ao que realmente fez funcionar.

As probabilidades não são intuitivas.

No entanto, isso me deu uma ideia. Já deveria haver estudos sobre isso, que tentaram quantificar os resultados dos esforços de engenharia de software (o que, é claro, é um problema difícil por si só). E esses estudos devem apontar para que tipo de práticas de engenharia de software são realmente importantes em termos de sucesso quantificável.

ie

• Uma equipe que emprega TDD tem thismuito menos probabilidade de ter thisalgum tipo de problema.
• Uma equipe que emprega os princípios do SOLID tem thismuito menos probabilidade de ter um thistipo de problema.
• etc etc.

O que estou procurando aqui são práticas de engenharia de software que mostram forte correlação entre implementação e sucesso. Estou confiante de que essas coisas existem, mas são difíceis de encontrar e é por isso que faço essa pergunta.

Quais estudos ou práticas que você conhece têm forte correlação entre implementação e sucesso (onde o sucesso é um tanto arbitrário, mas acho que você entendeu)?

Se vamos vender a ideia de que a engenharia de software é melhor do que a codificação de cowboys, acho que precisamos de provas.

O problema com esse tipo de quantificação é que é quase impossível obter dados suficientes sobre a eficácia das práticas de engenharia de software para tirar qualquer conclusão significativa.

Mais importante, a correlação não implica causalidade - por exemplo, pode ser que bons programadores sejam rápidos em adotar novas idéias, para que você veja uma correlação geral entre o sucesso do projeto e a adoção de novas técnicas de engenharia de software. Mas isso não prova nada sobre a eficácia das próprias técnicas, pois todo o efeito pode ser explicado pelo maior nível de talento dos programadores que as adotam.

E então é difícil controlar as variáveis ​​independentes . Como você garante uma experiência justa, a menos que seja capaz de controlar os seguintes itens?

• Nível de experiência / habilidade / motivação da equipe
• Extensão real da adoção da metodologia reivindicada (eles estão realmente fazendo o TDD corretamente?)
• Presença / ausência de grandes erros de design não relacionados à metodologia de engenharia de software (por exemplo, aqueles que exigem uma grande re-arquitetura durante o projeto)
• Nível de dificuldade dos projetos comparados
• Impacto de problemas impostos externamente (por exemplo, grandes mudanças nos requisitos)
• Viés de seleção (por exemplo, as pessoas tendem a compartilhar dados com mais frequência sobre projetos bem-sucedidos?)
• Viés de confirmação (por exemplo, as pessoas exageraram no sucesso de projetos que usam sua metodologia favorita?)

Mesmo se você decidir resolver o problema acima, dando a várias equipes cuidadosamente selecionadas o mesmo problema sob as mesmas condições cuidadosamente controladas, é provável que sua experiência seja proibitivamente cara se você quiser criar dados suficientes para ser estatisticamente significativo.

E, finalmente, é quase impossível medir o sucesso :

• Uma métrica de quantidade como linhas de código de origem (SLOC) é terrivelmente ruim. O incentivo para os desenvolvedores é criar monstruosidades de milhões de linhas com codificação de copiar / colar para parecer mais "produtivo"
• Uma métrica dentro do prazo / dentro do orçamento depende principalmente do nível de ambição nas estimativas usadas para criar o plano / orçamento
• Uma métrica do tipo ROI depende tanto da situação do mercado e do gerenciamento comercial do produto quanto da qualidade da produção de engenharia (veja o histórico do Microsoft Windows!)
• Os Story Points são úteis para ter uma sensação de velocidade em uma equipe ágil, mas não são realmente comparáveis ​​entre as equipes
• Métricas baseadas em funcionalidade, como pontos de função ou pontos de caso de uso, talvez sejam as melhores, mas são burocráticas para coletar e não refletem a diferença no esforço de engenharia necessário para criar cada unidade de funcionalidade.
• Métricas de qualidade, como bugs na disponibilidade de produção / aplicativo, são notoriamente difíceis de calcular e comparar em bases iguais - depende significativamente de coisas como plataforma escolhida, tamanho da base de usuários e vários fatores operacionais / de implantação.

Concluindo: tentar quantificar o impacto das tarefas de desenvolvimento de software é uma tarefa extremamente difícil e, apesar de muitos anos após o tópico, ninguém ainda apresentou uma abordagem realmente eficaz. Como resultado, a avaliação das metodologias de desenvolvimento de software continua sendo mais uma arte do que uma ciência e provavelmente permanecerá assim por muitos anos.

Curiosamente, há uma abordagem que acho promissora: aplicação de princípios enxutos . Isso não é uma panacéia e não resolverá diretamente o problema de avaliar as metodologias de desenvolvimento de software, mas possui um insight importante: um processo com um elemento específico de desperdício é inequivocamente menos eficiente que o mesmo processo sem esse elemento de desperdício, todas as outras coisas são iguais . Portanto, se você se concentrar na eliminação de desperdícios no processo de desenvolvimento de software, pode ter certeza de que está seguindo na direção certa. Além disso, o desperdício é frequentemente quantificável, portanto, você também deve ter uma idéia de quanto mais eficiente está obtendo, pelo menos em termos percentuais aproximados.