Qual è il modo migliore per fare una sparatoria a Proof of Concept?

8

In preparazione di una nuova versione del software che la nostra azienda sostiene, ho lavorato su quello che ritengo sia un approccio davvero valido per risolvere i nostri problemi di scalabilità. Ho tutte le intenzioni di mettere insieme una bozza di concetto per convalidare il disegno su carta e farò effettivamente quello che voglio. Quando l'ho informato sulla squadra, il capo ha avuto una controproposta, ispirata in parte dal modo in cui ho descritto le aree problematiche. Il capo ha anche accettato la mia proposta di fare due prove di concetto per valutare le alternative.

Quindi, qual è il modo migliore per superare la prova del concetto? Abbiamo criteri oggettivi e soggettivi che stiamo usando per valutare le soluzioni. Mi piacerebbe assicurarmi di confrontare le mele con le mele con questi approcci abbastanza diversi.

  • Abbiamo requisiti per throughput e dimensioni. In breve, sappiamo che dobbiamo elaborare un certo numero di oggetti al secondo e mantenere tale velocità per un'ora.
  • Dobbiamo valutare la scalabilità (aggiungendo più core e aumentando il numero di oggetti)
  • Dobbiamo valutare la facilità di sviluppo (soggettiva)
  • Abbiamo bisogno di valutare quanto sia facile capire l'algoritmo (soggettivo)

Ho la mia teoria su quale modo le cose si sposteranno, ma non voglio che ciò influisca sui miei risultati. Qualsiasi input su come mantenere l'obiettività in questo processo e le cose che potrei dover considerare sarebbe molto apprezzato.

    
posta Berin Loritsch 25.01.2011 - 14:39
fonte

3 risposte

9

Generalmente ciò che facciamo è ...

  • imposta una scadenza come 1 mese
  • usa i tuoi requisiti che hai elencato e codificalo.
  • un moderatore che non sta scrivendo il programma controlla i requisiti e non li vede pensare a un requisito nascosto che dovrebbe essere possibile farlo in un breve lasso di tempo.

  • Quando il resto del team controlla i programmi per valutarli, questi devono aggiungere il requisito a ciascun sistema in modo da avere un'idea di entrambi. Dopo che la squadra ha scavato nel codice e aggiunto il requisito mancante, dovrebbe avere una ragionevole sensazione per le codebase e scegliere quale preferirebbe sviluppare.

    • quindi prendi i migliori pezzi rimanenti del "perdente" e incorportali nell'architettura vincente.
risposta data 25.01.2011 - 14:47
fonte
1

Per gli elementi soggettivi si ottiene una valutazione numerica di un certo tempo e si tenta di ottenere un feedback imparziale. Esempio: per "Capire l'algoritmo", un programmatore che non ha scritto né guarda né classifica l'una contro l'altra.

Puoi anche prendere in considerazione misure oggettive sul codice come i codici "Complessità", ci sono alcuni strumenti per misurare quello basato sul numero di dichiarazioni di controllo ecc.

Assumi il tuo ranking in ogni categoria e sommi fino a un "Punteggio totale" per ciascun approccio.

    
risposta data 25.01.2011 - 14:49
fonte
1

how to maintain objectivity in this process

Hai solo un criterio obiettivo. Il throughput.

Tutto è soggettivo. Non puoi essere "obiettivo". Tutto quello che puoi fare è essere "equo". Mondo di differenza.

La decisione finale è sempre politica. Finché sono state fornite tutte le informazioni disponibili; hai fatto tutto quello che puoi fare.

Non stressarti cercando di fare il punto perfetto ("oggettivo"). Quello che vedi come giusto o meglio può semplicemente essere rovesciato da qualche scusa ridicola come "la squadra non ha le competenze richieste per la tua soluzione proposta".

Costruisci i demo. Eseguili. Preparati a prendere decisioni casuali. Il meglio che puoi sperare è informed e fair . Non puoi raggiungere "obiettivo" molto facilmente.

    
risposta data 25.01.2011 - 14:45
fonte

Leggi altre domande sui tag