Quando il mio manager ha detto al team che " ora in poi le user story di successo saranno considerate per la valutazione! "
Ci siamo seduti lì mentre eravamo scioccati e quello fu uno dei tanti momenti che ci lasciò a bocca aperta: -)
Abbiamo ritenuto che fosse un'idea stupida, poiché ciò rovinerebbe tutto il concetto e l'obiettivo della metodologia di sviluppo agile.
Fammi sapere cosa pensi tu? e come possiamo convincerlo?
Sandy, sfortunatamente la dichiarazione del tuo manager è un classico fraintendimento della mischia in particolare e agile in generale.
L'approccio proposto uccide la collaborazione e neutralizza il principio di 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 a disposizione storie degli utenti che hanno bisogno di sciami per poter essere terminate entro l'iterazione. Come farai a ottenerlo quando i singoli incentivi sono allineati di 180 gradi nella direzione opposta?
I tuoi istinti di squadra sono corretti. Quali fonti ti suggerirei a breve termine affinché tu legga le tue idee mentre rispondi al tuo manager? Guarda blog di noti esperti agili come Mike Cohn , Martin Fowler , Elizabeth Hendrickson , Jurgen Appelo , Esther Derby e molti altri e cerchi articoli sull'agile organizzazione 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. Come ho capito lo schema suggerito, potrebbe portare gli sviluppatori ad attenersi ai compiti assegnati e ignorare gli altri membri del team che sono bloccati e potrebbero facilmente essere scollati da un piccolo aiuto.
Siamo sempre alla ricerca del contributo che il programmatore sta apportando al team e al business.
Questo è paragonabile alla misurazione di linee di codice o numero di bug, ma leggermente più sofisticati.
A prima vista non c'è niente 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 delle soluzioni. Questa soluzione potrebbe dover essere una modifica al suo schema piuttosto che un nuovo schema.
Quindi per esempio potresti voler sottolineare che qualcuno che lavora solo su storie "facili" completerà più di qualcuno che lavora su uno "più difficile" 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 storia piuttosto che il numero di storie.
Sono d'accordo con ChrisF sul fatto che questo si ripresenta allo stesso problema con qualsiasi misurazione. Ciò che elogi è ciò che ottieni. Ci saranno sempre persone che giocano al sistema, qualunque sia quel sistema.
L'unico metodo veramente efficace che ho trovato per i programmatori gratificanti arriva con tre passaggi.
L'intera chiave è che i programmatori non sono ruote dentate in una macchina che possono essere "sintonizzate" guardando le statistiche. Le persone reali devono essere esaminate e migliorate nel loro complesso e il team deve poter contare l'uno sull'altro in una cooperativa e non in un modo competitivo.
I poveri esecutori della squadra hanno tutte le opportunità di miglioramento e arricchimento prima di essere considerati lasciati andare. In definitiva, i buoni programmatori prospereranno in questo ambiente e i programmatori poveri, che si rifiutano di essere migliorati, saranno lasciati andare.
La maggior parte 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é il processo di pianificazione è anche un lavoro di squadra e anche prima, l'intero sistema viene truccato. Questo è sicuramente ciò che non vuoi in un processo focalizzato sulla gente.
Penso che le buone prestazioni debbano essere riconosciute da una sorta di sistema bonus basato sul successo del team, ma le User Story non sono un buon indicatore del successo.
Leggi altre domande sui tag productivity agile scrum user-story