¿Cuál es la mejor manera de hacer un tiroteo de Prueba de concepto?

En preparación para una nueva versión de software que mantiene nuestra compañía, he estado trabajando en lo que creo que es un enfoque realmente bueno para resolver nuestros problemas de escalabilidad. Tengo toda la intención de reunir una prueba de concepto para validar el diseño en papel que realmente hará lo que quiero. Cuando se lo informé al equipo, el jefe tenía una contrapropuesta, inspirada en parte por la forma en que describí las áreas problemáticas. El jefe también aceptó mi propuesta de hacer dos pruebas de concepto para evaluar las alternativas.

Entonces, ¿cuál es la mejor manera de superar la prueba de concepto? Tenemos criterios objetivos y subjetivos que estamos utilizando para evaluar las soluciones. Me gustaría asegurarme de que estamos comparando manzanas con manzanas con estos enfoques bastante diferentes.

• Tenemos requisitos de rendimiento y tamaño. En resumen, sabemos que necesitamos procesar una cierta cantidad de objetos por segundo y mantener esa velocidad durante una hora.
• Necesitamos evaluar la escalabilidad (agregando más núcleos y aumentando el número de objetos)
• Necesitamos evaluar la facilidad de desarrollo (subjetivo)
• Necesitamos evaluar qué tan fácil es entender el algoritmo (subjetivo)

Tengo mi teoría sobre cómo se inclinarán las cosas, pero no quiero que eso influya en mis resultados. Cualquier aportación sobre cómo mantener la objetividad en este proceso y las cosas que podría tener que considerar serían muy apreciadas.

Generalmente lo que hacemos es ...

• establecer un plazo como 1 mes
• use los requisitos que enumeró y codifíquelos.

• tener un moderador que no esté escribiendo ninguno de los programas controla los requisitos y no los ve pensar en un requisito oculto que debería ser factible en un corto período de tiempo.

• Cuando el resto del equipo revisa los programas para evaluarlos, TIENEN que agregar el requisito a cada sistema para que tengan una idea de ambos. Después de que el equipo profundice en el código y agregue el requisito que falta, deberían tener una idea razonable de las bases de código y elegir cuál preferirían desarrollar.

  • luego tome las mejores piezas restantes del "perdedor" e incorpórelas a la arquitectura ganadora.

Para los ítems subjetivos, obtenga una calificación numérica de algún tiempo e intente obtener retroalimentación imparcial. Ejemplo: para "Comprender el algoritmo", haga que un programador que no escribió ni mire a ambos y los clasifique uno contra el otro.

También puede tener en cuenta medidas objetivas en el código como los códigos "Complejidad", hay algunas herramientas para medir eso en función del número de declaraciones de control, etc.

Tome su clasificación en cada categoría y sume un "puntaje total" para cada enfoque.

Cómo mantener la objetividad en este proceso

Solo tienes un criterio objetivo. El rendimiento

Todo es subjetivo. No puedes ser "objetivo". Todo lo que puedes hacer es ser "justo". Mundo de diferencia

La decisión final es siempre política. Siempre y cuando se haya proporcionado toda la información disponible; Has hecho todo lo que puedes hacer.

No te estreses por tratar de hacer el punto perfecto ("objetivo"). Lo que ves como correcto o mejor simplemente puede ser revocado por una excusa ridícula como "el equipo no tiene las habilidades necesarias para su solución propuesta".

Solo construye las demos. Ejecútalos. Esté preparado para la toma de decisiones al azar. Lo mejor que puede esperar es informado y justo . No se puede llegar a "objetivo" muy fácilmente.