Come misurare i contributi a un progetto? [duplicare]

5

Qualcuno ha mai incontrato questo problema? Quando hai un team di sviluppatori che lavorano su un progetto, come puoi misurare i loro contributi a detto progetto? Esiste un modo "formale" di farlo? Numero di commit? Numero di correzioni di bug? Linee impegnate? O forse in base al biglietto?

Sto provando a pensare a un flusso di lavoro in cui un gruppo di sviluppatori può lavorare senza problemi scambiando le attività e alla fine del mese, ricevendo il pagamento per i contributi (o il merito se lo si desidera).

Spero che questa domanda non sia del tutto fuori luogo qui, se lo è, sentiti libero di chiuderla.

    
posta Deleteman 10.04.2013 - 19:10
fonte

2 risposte

10

Non c'è modo di farlo in modo accurato. Ad esempio, chi contribuisce di più: qualcuno che commette 1000 righe di codice in un mese, o qualcuno che ha speso la maggior parte del suo tempo a pensare davvero duramente, e quindi a impegnare 100 righe di codice che sostituiscono le 1000 righe di codice? O che ne dici di qualcuno che ha perso la testa per gran parte del mese, poi ha trovato quelle stesse 100 righe di codice in un blog?

Chi contribuisce di più: qualcuno che ha generato 100 risorse immagine o qualcuno che ha trascorso settimane a pensare all'usabilità e alla fine ha controllato solo una mezza dozzina di wireframe per un'applicazione altamente utilizzabile?

In altre parole, come si misura la quantità di lavoro immateriale che la maggior parte degli artisti di alto livello esegue su base regolare?

    
risposta data 10.04.2013 - 19:18
fonte
1

Non penso che tu possa farlo, almeno nel senso che suggerisci. La risposta di Bryan e diverse risposte nella domanda collegata da gnat parlano di diversi intangibili (forse dovremmo chiamarli "incommensurabili") in questo contesto) attività produttive.

In particolare, questo:

I'm trying to think of a workflow where a group of developers can work seamlessly interchanging tasks

sembra che creerà un incentivo perverso per gli sviluppatori a non concentrare i loro sforzi laddove sono più produttivi, ma invece a far finta di essere unità di risorse intercambiabili per adattarsi al tuo schema di misurazione.

Un approccio potrebbe essere semplicemente chiedere a tutti di stimare il lavoro di tutti gli altri e fare in modo che si traduca in un qualche tipo di consenso approssimativo sulla produttività. Questo potrebbe solo portare a (alcune) persone che parlano della complessità dei loro bug o delle funzionalità attorno al refrigeratore d'acqua.

Un modo più gestibile sarebbe utilizzare le recensioni tra pari una o due volte l'anno, in cui i membri del team danno voti per la produttività relativa reciproca.

  • perché questo non viene fatto ogni settimana o per un numero fisso di storie, è più difficile per il gioco
  • perché tutti i membri del team sono già dotati di un ampio computer che viene calibrato con cura per valutare le relazioni di gruppo, è possibile utilizzarli come proxy
    • tutti conoscono il valore dei favori fatti o ricevuti, anche se sono difficili da quantificare
    • se i membri del team si rivedono il codice degli altri, avranno la sensazione di chi stia accumulando il debito più tecnico per il futuro
    • questo permette agli sviluppatori di giocare ai loro punti di forza (ignorando lo sviluppo personale e la costruzione di team in questo contesto, questo dovrebbe essere il più produttivo)
risposta data 10.04.2013 - 20:46
fonte

Leggi altre domande sui tag