Qual é a melhor maneira de fazer uma prova de conceito?

Na preparação para uma nova versão do software que nossa empresa mantém, tenho trabalhado no que acredito ser uma abordagem realmente boa para resolver nossos problemas de escalabilidade. Eu tenho toda a intenção de reunir uma prova de conceito para validar o design no papel que realmente fará o que eu quero. Quando informei à equipe, o chefe tinha uma contraproposta, inspirada em parte pela maneira como descrevi as áreas problemáticas. O chefe também aceitou minha proposta de fazer duas provas de conceito para avaliar as alternativas.

Então, qual é a melhor maneira de resolver a prova de conceito? Temos critérios objetivos e subjetivos que estamos usando para avaliar as soluções. Gostaria de garantir que estamos comparando maçãs com maçãs com essas abordagens bastante diferentes.

• Temos requisitos para taxa de transferência e tamanho. Em resumo, sabemos que precisamos processar um certo número de objetos por segundo e manter essa taxa por uma hora.
• Precisamos avaliar a escalabilidade (adicionando mais núcleos e aumentando o número de objetos)
• Precisamos avaliar a facilidade de desenvolvimento (subjetivo)
• Precisamos avaliar como é fácil entender o algoritmo (subjetivo)

Eu tenho minha teoria sobre como as coisas vão melhorar, mas não quero que isso influencie meus resultados. Qualquer contribuição sobre como manter a objetividade nesse processo, e as coisas que talvez eu precise considerar, serão muito apreciadas.

Geralmente o que fazemos é ...

• defina um prazo como 1 mês
• use os requisitos listados e codifique-os.

• peça a um moderador que não esteja escrevendo um dos programas que controle os requisitos e não os veja pensar em um requisito oculto que deve ser factível em um curto período de tempo.

• Quando o resto da equipe examina os programas para avaliá-los, eles precisam adicionar o requisito a cada sistema, para que sintam os dois. Depois que a equipe pesquisar o código e adicionar os requisitos ausentes, eles deverão ter uma idéia razoável das bases de código e escolher qual delas preferiria desenvolver.

  • então pegue as melhores partes restantes do 'perdedor' e as incorpore à arquitetura vencedora.

Para os itens subjetivos, obtenha uma classificação numérica de algum tempo e tente obter feedback imparcial. Exemplo: para "Entendendo o algoritmo", um programador que não escreveu nem olhou para os dois e se classificou um contra o outro.

Você também pode levar em consideração medidas objetivas no código, como os códigos "Complexidade", existem algumas ferramentas para medir isso com base no número de instruções de controle, etc.

Pegue sua classificação em cada categoria e some-as até uma "Pontuação total" para cada abordagem.

como manter a objetividade nesse processo

Você tem apenas um critério objetivo. A taxa de transferência.

Tudo é subjetivo. Você não pode ser "objetivo". Tudo o que você pode fazer é ser "justo". Mundo da diferença.

A decisão final é sempre política. Desde que todas as informações disponíveis sejam fornecidas; você fez tudo o que pode fazer.

Não se preocupe em tentar fazer o ponto perfeito ("objetivo"). O que você vê como certo ou melhor pode simplesmente ser anulado por alguma desculpa ridícula como "a equipe não possui as habilidades necessárias para a sua solução proposta".

Basta criar as demos. Execute-os. Esteja preparado para tomar decisões aleatórias. O melhor que você pode esperar é informado e justo . Você não pode chegar ao "objetivo" com muita facilidade.