Quando il mio Manager disse al team che "da quel momento in poi le storie degli utenti di successo verranno prese in considerazione per la valutazione! "
Ci siamo seduti lì per un po 'scioccati e quello è stato uno dei tanti momenti strabilianti che ci ha regalato :-)
Abbiamo ritenuto che fosse un'idea stupida, poiché ciò rovinerebbe tutto il concetto e l'obiettivo della metodologia di sviluppo agile.
Fammi sapere cosa ne pensi? e come possiamo convincerlo?
Risposte:
Sandy, purtroppo la dichiarazione del tuo manager è un classico fraintendimento della mischia in particolare e agile in generale.
L'approccio proposto uccide la collaborazione e contrappone il principio della proprietà del codice collettivo . Le storie degli utenti in agile (se è una vera agile) raramente vengono completate prima di essere toccate da più persone. Inoltre, di volta in volta avrai storie utente che necessitano di sciamare per essere completate all'interno dell'iterazione. Come riuscirai a ottenerlo quando gli incentivi individuali sono allineati di 180 gradi nella direzione opposta?
L'istinto del tuo team è corretto. Quali fonti ti consiglierei di leggere a breve termine mentre fai il brainstorming della risposta al tuo manager? Guarda i blog di rinomati esperti agili come Mike Cohn , Martin Fowler , Elizabeth Hendrickson , Jurgen Appelo , Esther Derby e molti altri e cerca articoli sull'organizzazione agile del team.
La mia principale obiezione a questo metodo di valutazione è che può essere un ostacolo alla cooperazione tra sviluppatori. Penso che una parte importante della produttività di un team di sviluppo sia la volontà dei membri del team di aiutarsi a vicenda. Quando capisco lo schema suggerito, potrebbe portare gli sviluppatori a rimanere fedeli ai propri compiti assegnati e ignorare gli altri membri del team che sono bloccati e potrebbero essere facilmente sbloccati da una piccola assistenza.
Siamo sempre alla ricerca del contributo che il programmatore sta dando al team e al business.
Questo è alla pari della misurazione di righe di codice o del numero di bug, ma leggermente più sofisticato.
A prima vista non c'è nulla di sbagliato nella misurazione, ma quando ci pensi inizi a sollevare obiezioni:
è il più ovvio che mi viene in mente: sono sicuro che ce ne sono altri.
Il tuo manager ovviamente pensa che sia una buona idea, quindi devi stare attento che quando sollevi obiezioni puoi anche presentare soluzioni. Questa soluzione potrebbe dover essere una modifica al suo schema piuttosto che un nuovo schema.
Quindi, ad esempio, potresti voler sottolineare che qualcuno che lavora solo su storie "facili" completerà più di qualcuno che lavora su storie più "difficili" e questo potrebbe portare a una concentrazione sugli aspetti meno importanti dello sviluppo. Quindi una soluzione potrebbe essere quella di considerare il numero di punti della storia piuttosto che solo il numero di storie.
Concordo con ChrisF sul fatto che questo ritorni allo stesso problema con qualsiasi misurazione. Ciò che lodi è ciò che ottieni. Ci saranno sempre persone che giocheranno al sistema, qualunque esso sia.
L'unico vero metodo efficace che ho trovato per premiare i programmatori prevede tre passaggi.
L'intera chiave è che i programmatori non sono ingranaggi in una macchina che può essere "sintonizzata" guardando le statistiche. Le persone reali devono essere esaminate e migliorate nel loro insieme e il team deve poter contare l'uno sull'altro in modo cooperativo e non competitivo.
I poveri attori della squadra hanno tutte le possibilità di miglioramento e arricchimento prima di essere considerati lasciati andare. Alla fine, buoni programmatori prospereranno in questo ambiente e i poveri programmatori, che si rifiutano di essere migliorati, saranno lasciati andare.
Il più delle volte, le User Story sono completate in uno sforzo collettivo. Ciò rende praticamente impossibile basare la valutazione individuale su questa metrica.
La metrica stessa può essere facilmente manipolata poiché anche il processo di pianificazione è uno sforzo di squadra e, anche prima, l'intero sistema viene truccato. Questo è sicuramente ciò che non vuoi in un processo incentrato sulle persone.
Penso che le buone prestazioni debbano essere riconosciute da una sorta di sistema di bonus basato sul successo del team, ma le User Story non sono un buon indicatore di successo.