Come dimostrate le prestazioni in ambienti con programmazione accoppiata?

include il valore aggiunto alla programmazione della coppia nella revisione delle prestazioni - hai aiutato l'altro programmatore a imparare cose utili? (e viceversa, hai ascoltato i suoi saggi consigli e hai collaborato bene?)

una revisione delle prestazioni non deve essere una competizione, dovrebbe essere una valutazione di coaching relativa ai tuoi obiettivi personali (che sono presumibilmente in linea con gli obiettivi aziendali e concordati di comune accordo all'inizio dell'anno, altrimenti è arbitraria)

Sarebbe difficile dimostrare in modo definitivo un vantaggio prestazionale rispetto all'altro scientificamente.

La tua ipotesi è che la programmazione della coppia aumenti le prestazioni dello sviluppatore e migliori la qualità. Il tuo test implicherà di dare a una coppia una serie di requisiti vincolati a uno specifico architecturen e di averli implementati.

Il tuo controllo in questo caso è che tu dai gli stessi requisiti a un singolo sviluppatore di pari statura, abilità ed esperienza (giudicato oggettivamente dai suoi colleghi) e anche vincolato all'interno della stessa architettura.

Per verificare la tua ipotesi di prestazioni temporali, i programmatori di coppia devono completare il loro lavoro in meno della metà del tempo del controllo. Per verificare la tua ipotesi sulla qualità devi avere la coppia di esperimenti e il codice di controllo rivisto da una terza parte obiettiva, e fare in modo che un gruppo QA obiettivo verifichi i risultati di entrambi i gruppi senza dire quale squadra ha prodotto cosa. Il gruppo di programmazione della coppia deve avere un codice migliore e meno bug.

Non è un esperimento perfetto, ma sarei affascinato dal sentire se qualcuno ha tentato qualcosa di simile.

Oltre a questo, tuttavia, non riesco a vedere come si possa dimostrare in realtà che Pair Programming è superiore a un singolo programmatore su una determinata funzione.

Nelle tue metriche sul rendimento, chiama separatamente 1) crescita e sviluppo individuali e 2) tutoraggio e supporto tra pari. Consentire a ciascun dipendente di autovalutare e incorporare il feedback del proprio lead. Se ha senso nella cultura aziendale, prendi in considerazione le revisioni tra pari o le testimonianze.

Se fatto correttamente, il dipendente che ottiene il valore più educativo di un accoppiamento viene ricompensato per la sua capacità a lungo termine di contribuire al team, e il dipendente che sta aiutandolo a portarlo a termine viene ricompensato per il trasferimento di conoscenza e Esperienza. Le persone che si trovano da qualche parte nel mezzo (imparando nuovi domini invece di spostarsi da un livello minore ad un altro) vengono riconosciute per entrambi i fini dell'equazione.

In pratica, valutare le prestazioni individuali è complicato nel migliore dei casi. È piuttosto difficile farlo senza creare sentimenti di risentimento o competizione. Ma se valuti il contributo individuale al team e apprezzi sia l'apprendimento che l'insegnamento, ci sono alcune possibilità di farlo funzionare con un po 'meno attrito.

Le coppie cambiano spesso? Se è così, è possibile utilizzare recensioni anonime per ottenere un indicatore. Per esempio, se la persona A ha detto che B ha fatto il 60% del lavoro, la persona C ha detto che la persona B ha fatto il 30% del lavoro, e la persona D ha detto che la persona B ha fatto il 90% del lavoro. Il 60% del lavoro. Se il lavoro che la persona B ha compiuto nelle sue coppie ha un fattore relativo di 100 punti, allora la persona B ha fatto 60 punti di lavoro!

Tuttavia, questo non è (da nessuna parte vicino) perfetto. È probabile che le persone si concedano più credito di quello che danno all'altra persona, quindi potrebbe essere necessario tenerne conto nel calcolo. Ciò potrebbe anche portare a un ambiente in cui le coppie sono sospettose l'una dell'altra. Il calcolo può anche essere spostato da qualcuno che non ama la persona con cui sta lavorando, ecc.

Dico che due di noi hanno lavorato insieme per creare X, quindi entrambi abbiamo ottenuto il merito di averlo finito e di averlo distribuito. Dove potresti avere un problema è quando una parte di una coppia non ha funzionato affatto. In questo caso, il gestore avrebbe dovuto essere informato di tutto questo e quindi dovrebbe usare quel feedback quando compila il suo commento alla recensione delle prestazioni.

Sei nella esatta situazione in cui il mio insegnante ci mette a parte gli studenti nel nostro programma di sviluppo di giochi. Siamo accoppiati (2, 3 o 4 persone a seconda delle dimensioni della classe e delle dimensioni del progetto) e alla fine ci viene detto di valutare ogni singolo membro del team e noi stessi in relazione al progetto e a quale lavoro è stato fatto, oltre che i progetti delle altre squadre nel loro complesso. Un voto è formulato sulla base di queste valutazioni.

Durante la formulazione della squadra, l'insegnante posizionava deliberatamente un programmatore strong e un programmatore debole sperando che si lavorassero a vicenda e / o aiutassero, ma il 99% delle volte il programmatore debole pattugliava e faceva pochissimo lavoro a nessuno a tutti o non hanno idea di cosa stanno facendo (essendo questo i corsi avanzati, è molto frustrante).

Le valutazioni dovrebbero essere private, ma lascia solo dire, ci sono alcune persone con cui tutti rifiutano di lavorare più.

Associare la programmazione significa che una persona pensa cosa e come qualcosa dovrebbe essere fatto, e l'altra interpreta una scimmia codificante. Poi a un certo punto cambiano (si annoia, si annoia, ecc.). È buono, perché entrambi non sono interrotti nelle loro attività.

Alcune persone lo considerano anche come "la revisione del codice sugli steroidi". Ottieni il codice revisionato, che dovrebbe significare una qualità più elevata.

Bella domanda. Ciò che è importante non è solo ciò che contribuisci, ma come i tuoi colleghi vedono il tuo contributo. Chiedi loro il loro feedback personale perché è questo feedback che ti aiuta a essere un migliore "qualunque" . Seriamente, è importante che il tuo pari capisca il tuo contributo e lo capisca solo quando ha un discreto livello di apprendimento durante l'accoppiamento con te. Felice codifica, condivisione e apprendimento che si traducono in un buon guadagno.

Lo svantaggio della programmazione della coppia è che la produttività del programmatore più esperto è limitata alla produttività del programmatore meno esperto, nel breve, medio termine. A lungo termine, l'esperienza e la produttività sono aumentate nello sviluppatore junior.