Abbiamo un team "tipico" di SCRUM e ci impegniamo a lavorare per uno sprint, mantenendo anche un backlog. Di recente ci siamo imbattuti in un problema nel tentativo di integrare / gestire il lavoro di uno sviluppatore esagerato facendo un lavoro fuori banda (scegliendo di lavorare al di fuori del normale orario di lavoro / sprint).

Per fare un esempio, se il team prende 50 punti di lavoro, diciamo che completeranno tutto quel lavoro all'interno del framework SCRUM entro la fine dello sprint e loro e l'azienda sono felici. Uno dei membri del team decide di lavorare da solo, su un articolo arretrato, nel proprio tempo libero. Non controllano questo lavoro, ma lo salvano (usiamo TFS ed è in uno scaffale).

Come gestirlo? Alcuni dei problemi ..

• Durante il prossimo sprint questo membro del team afferma che il lavoro di programmazione è stato eseguito al 99% e necessita solo di revisione e test del codice. Come gestirli con SCRUM e la metodologia agile?
• Altri sviluppatori si lamentano di non essere coinvolti nelle decisioni di progettazione legate a queste storie, dal momento che il lavoro è stato fatto fuori banda.
• Il nostro product owner è tentato di dedicarsi a questo lavoro "gratuito" e probabilmente i membri esagerati lo fanno apposta al fine di ottenere nel prodotto più funzionalità che il team non sarebbe in grado di realizzare negli sprint. Si ritiene che ciò stia interrompendo il "processo". Ovviamente il lavoro di controllo qualità, interfaccia utente e documentazione deve ancora essere svolto su questo lavoro.

Vedo molte discussioni sul non forzare un team SCRUM a fare gli straordinari, ma che dire di un membro del team che lavora al di sopra e al di là delle aspettative avanzate durante la pianificazione e l'esecuzione degli sprint? Esiterei a regnare su questa persona e direi che non puoi lavorare di più (avvertendo di bruciare ovviamente), ma allo stesso tempo sembra causare alcuni problemi con alcuni membri del team (ma non tutti).

Come integrare il lavoro svolto da un membro che ha raggiunto un livello eccessivo nello SCRUM e un processo agile per lo sviluppo del software?

Bene, quindi qualcuno sta scrivendo con entusiasmo un ottimo codice che deve essere fatto, ma non in ordine. Con tutta la dovuta enfasi:

LASCIARLI

Sta causando alcune complicazioni nei tuoi sprint di mischia. Importa davvero nel grande schema delle cose? Se sta realizzando ciò che dovrebbe, allora lascialo andare e costruire grandi cose per te.

Conosco diversi programmatori fantastici che hanno lasciato le aziende perché non hanno lasciato i programmatori al di fuori dei vincoli di un sistema artificiale come Scrum (io stesso ho lasciato il mio ultimo lavoro dopo essere stato trattato come nient'altro che un glorificato QA). Se ci sono lamentele da parte di altri sviluppatori sull'input (reclami perfettamente validi, posso aggiungere), potrebbe essere meglio introdurre un programma "20% di tempo" per consentire a lui (e ad altri) di fare ciò che fanno meglio con interferenze minime.

Invece di storie future (che potrebbero richiedere input da altri), lascia che lo sviluppatore sperimenti nuove tecnologie o funzionalità. Potresti trovare una nuova grande opportunità che altrimenti non sarebbe mai stata esplorata. Sono sicuro che questo sviluppatore ha alcune cose che vorrebbero provare se glielo permettessi.

Ci sono due cose che penso che dovresti considerare qui:

1. Non ostacolare il flusso creativo di qualcuno.
   • Se uno sviluppatore vuole lavorare fuori orario, allora lascialo fare.
2. Non creare lavoro per gli altri.
   • Se uno sviluppatore vuole fare un lavoro fuori orario, è sicuramente meglio non creare più lavoro per gli altri .

Il punto 2 è probabilmente ciò di cui gli altri sviluppatori sono preoccupati.

Come hai menzionato, a loro non piace il fatto che il codice sia scritto senza l'input dell'intero team. Questo può essere perché, in termini di design, finisce per essere inferiore. E il codice con un design inferiore ha un modo per infettare altro codice attorno ad esso.

Che cosa si può fare?

Lascia che l'ambizioso codice di sviluppo contenga il contenuto del suo cuore, ma chiarisci che non c'è motivo di ritenere che verrà utilizzato il suo codice extracurricolare .

Dopotutto, fa parte di un team e quindi il team dovrebbe essere coinvolto nel modo in cui tutto il codice viene sviluppato.

Se, tuttavia, il suo lavoro è solido e si adatta al design concordato dal team, sarà in grado di utilizzare gran parte di ciò che ha già scritto (bonus!). In caso contrario, lo costringerà a pensare di più al suo design la prossima volta che decide di ottenere un vantaggio.

In questo modo, a nessuno viene detto NO , e nessuno ha creato lavoro extra per loro.

Riportalo nella squadra

Dovresti chiedere a te stesso (o meglio alla squadra, incluso l'overachiever):

Perché questo comportamento è un problema?

Dato che etichetti lo sviluppatore come overachiever, immagino che il suo lavoro sia di buona qualità, quindi suppongo che questo non sia un problema.

Ma sembrano esserci altri problemi:

• Il lavoro extra non è stato testato correttamente
• non è documentato
• il resto della squadra non lo sa
• lo sviluppatore decide la prossima cosa da implementare, non l'OP
• lo sviluppatore non riceve alcun feedback dai vari stakeholder da incorporare nel suo lavoro.

Il prossimo Perché vorrei come è:

Perché lo sviluppatore lo fa?

• Se alla fine dello sprint non è rimasto abbastanza lavoro, dovrebbe esserci una decisione della squadra (incluso l'OP) su cosa affrontare in seguito. Perché lo sviluppatore evita questa decisione?

Dopo aver risposto a queste domande, puoi iniziare a rispondere alla tua domanda:

• se non è un problema, lasciagli fare le sue cose. Sebbene alcune persone trattino SCRUM come una religione, non dovrebbe essere così.
• È più probabile che tu abbia due problemi nel team: quello / i causato dallo sviluppatore canaglia e quello / i che innescano il comportamento dello sviluppatore canaglia. Trova un modo per risolvere il successivo e il primo sparirà.

Per quanto mi piaccia l'idea che l'aggiunta di lavoro gratuito nel mix sia una buona cosa, questo non è un lavoro gratuito - non a meno che quel singolo sviluppatore sia anche il tester, il QA e il ragazzo della build e il designer e tutto il resto. Se il suo lavoro può essere inserito nello sprint successivo senza alcun impatto, allora ... provaci. Ma penso che non sia mai così. Almeno tutti gli altri devono capire cosa ha fatto e quale impatto ha su di loro. Devono capire che i suoi cambiamenti sono in atto e quindi non duplicare i suoi sforzi - è difficile dire a qualcuno che hanno lavorato duramente su un compito solo per scoprire che il ragazzo canaglia lo ha fatto la scorsa settimana.

Stai lavorando in un ambiente agile, e una cosa che so di agile è che è progettato per funzionare per te, non contro di te. Quindi è necessario cambiare il modo di lavorare per consentire questo tipo di attività extracurricolare. Ciò significa ottenere il contributo e l'accordo di tutti, non è possibile farlo senza il loro buy-in. È vitale. Se alla squadra non piace, allora il ladro smette di farlo. Fine di. Non è un ragazzo che fa quello che gli piace, non importa quanto sia bello il suo lavoro, è uno sforzo di squadra fino in fondo. La squadra viene prima di tutto.

Quindi è necessario sedersi tutti alla prossima riunione di pianificazione e discuterne, tutti i membri del team devono decidere di autorizzarlo o modificare il processo per gestire meglio questo tipo di attività.

Forse otterrai una soluzione in cui tutti lavorano sui loro progetti preferiti e li portano al tavolo (puoi immaginare il caos alla tua consegna che causerebbe :) che evidenzia il problema con esso in primo luogo) o puoi mandare un mandato area in cui ogni sviluppatore ha l'automia per sviluppare qualsiasi soluzione che gli piace sia il 'contributo' in modo simile a quanti progetti open source funzionano, oppure puoi dare a tutti un po 'di tempo libero per sperimentare (il vecchio tempo del 20%).

Questo sviluppatore scrive test e codice pulito / solido o sta semplicemente spingendo fuori tutto ciò che può fare rapidamente? Personalmente, non permetterei a nessuno di lavorare al di fuori degli orari definiti, poiché confonderà le tue stime e, come hai sottolineato, si verificano altri problemi.

Tuttavia, non dovresti mai essere rigido nel tuo processo. Scrum è solo un framework in modo da poter sempre adattare il processo per includere il tempo extra (ma ancora una volta è difficile pianificare ciò che qualcuno potrebbe fare).

Potresti anche chiedergli di lavorare su cose diverse dal progetto. Guardare nuove tecnologie o creare formazione su cose che fa diversamente. La conclusione è che qualsiasi cosa fatta al di fuori del programma pianificato ti distruggerà le stime e non permetterei che ciò accada.

ci siamo trovati di fronte anche con la stessa cosa, fondamentalmente abbiamo commesso qualcosa come 20 punti ma alla scorsa settimana o anche a metà dello sprint abbiamo finito l'attività di codifica, tuttavia a causa dei test e del resto del processo non abbiamo rischiato di scegliere un altro PBI, quindi cosa i programmatori lo hanno fatto per esaminare il backlog e iniziare a sviluppare i PBI futuri (in silenzio!) e informare il resto del team nella pianificazione che PBI è pronto per la revisione e il test del codice! proprio come hai detto.

In realtà ha sollevato alcune preoccupazioni dai nostri PO che sembra che siamo in grado di fare di più ma non sfruttiamo appieno il potenziale del nostro team, il che era in parte vero, ma sì, forse i nostri programmatori potrebbero fare di più, ma i nostri tester non sono riusciti a seguire quella velocità così c'era il rischio di fallire lo sprint. Dopo aver riflettuto su questo problema abbiamo scoperto che abbiamo bisogno di cambiare la nostra visione sulla mischia e il problema principale è che le persone non vogliono correre il rischio è perché noi commettiamo PBI così squadra non si sentiva bene a correre il rischio di raccolta nuovi PBI nel caso in cui abbiamo programmatore gratuito.

Semplicemente abbiamo iniziato a Previsione PBI piuttosto che fare l'impegno. La previsione in pratica significa che raccogliamo 25 punti alla pianificazione e all'inizio dello sprint, e quando il programmatore si libera nel mezzo dello sprint, perché non c'è più attività di codifica, quindi sceglie uno dei futuri PBI e lo mette in Current Sprint e inizia a lavorare su di esso, se il PBI può passare tutto il processo (test, fusione ed ecc.) all'interno dello stesso sprint, è un punto bonus per il team se NON falliamo lo sprint a causa di quel PBI e stiamo semplicemente portando avanti il ​​lavoro rimanente ( test o meging o ecc.) allo sprint successivo e ri-poker per il lavoro rimanente. Quindi può essere fatto in due diversi sprint nello scenario peggiore. So che potrebbe sembrare Scrumbut ma in realtà ha migliorato il modo in cui lavoriamo. Posso solo riassumere i suoi benefici come di seguito:

• Sconfigge la fobia del fallimento dello sprint a causa del rischio di assumere più PBI
• Rende visibile il lavoro extra di programmatori e team
• Aumenta la velocità della tua squadra

Tuttavia, forse per una squadra con meno esperienza, forse riduce la spinta che l'impegno dà alla squadra per finire i PBI

Alcune delle altre risposte hanno suggerito che lo sviluppatore "esagerato" è "canaglia" o "violare i principi di Scrum". Questo non è corretto e questo sviluppatore dovrebbe essere incoraggiato (anche se non dovresti chiedere alle persone di lavorare su qualcosa di specifico in questo tempo extra, ma potresti dare suggerimenti e aiutare a promuovere idee).

In Scrum non c'è nulla che possa prescrivere il modo in cui le persone lavorano e qualsiasi cosa in più facesse sarebbe naturalmente incorporata nella velocità della squadra.

Il suo lavoro dovrebbe essere inserito nel portafoglio ordini del prodotto e stimato nella prossima riunione di pianificazione. Se non riesci a prevedere quale sia lo sforzo rimanente immediatamente, dovresti passare un po 'di tempo allo sprint per capirlo (cioè uno Spike).

Interessante che descrivi lo sviluppatore come "esagerato", presumo che ciò significhi che sta aggiungendo molto più valore degli altri membri del team.

Le difficoltà nel fare un lavoro extra implicano che nella tua squadra c'è qualcosa di non ottimale (o forse anche disfunzionale).

Se questo è il caso, dovresti chiederti perché sta ottenendo molto di più, presumibilmente con solo un po 'di sforzo in più?

È possibile per te consentire al resto del team di ottenere di più?

Ho visto la situazione in cui i team sono stati micro-gestiti, potenzialmente su user story prescrittive, la definizione del fatto, che finisce per essere soffocante per gli sviluppatori. È questo sviluppatore fare il lavoro che egli vuole? Suppongo che stia prendendo buone decisioni. Lavorare in questo modo durante la settimana lavorativa aiuterebbe anche il resto della squadra?

Li hanno anche essere un insegnante

È fantastico che tu abbia uno sviluppatore stellare con le migliori e più avanzate competenze del gruppo. Loderei e complimento questo. Spesso queste persone sono la "colla" che tiene insieme le organizzazioni.

Considererei la sfida come "come avvicinare gli sviluppatori meno esperti alla produttività dello sviluppatore più avanzato".

Un ottimo modo per farlo è quello di far sì che lo sviluppatore principale trascorra più tempo a insegnare, addestrare e guidare i membri del team meno esperti e più lenti. Vorrei prima discuterne in 1 a 1 con lo sviluppatore principale in modo che sappiano cosa stai facendo e perché. Altre cose sagge possono essere viste con sospetto come un'agenda nascosta / cattiva gestione

Quando fai stand-up, una o due volte al giorno, se questa persona rimane senza lavoro e gli altri continuano a svolgere compiti, cerca di accoppiare la programmazione in modo che possa accoppiarsi con i membri junior e impartire la sua grande conoscenza ed esperienza. Assicurati di porre la domanda "qualcuno ha bisogno di aiuto? Qualcuno sta cercando una coppia?"

Potresti anche trovare un po 'di lavoro "laterale" per il miglior sviluppatore quando non ha un lavoro, come migliorare il set di strumenti utilizzato da tutti, gestire un gruppo di discussione di club di libri tecnici o essere coinvolto in altri progetti organizzativi.

Ho intenzione di rispondere a una domanda diversa. Penso che affrontare questa situazione in Scrum non sia davvero importante. Scrum è più come una linea guida comunque. Se vuoi che ciò accada, trova un modo semplice per adattare il tuo processo come semplicemente supponendo che il lavoro sia già stato fatto.

La vera domanda è se vuoi che questo sviluppatore faccia quello che sta facendo. Penso che diversi aspetti abbiano un ruolo chiave nella risposta a questa domanda:

1. Il programmatore sta facendo un buon lavoro.
2. Stanno tutti bene che faccia il suo lavoro da solo (sia esso buono o cattivo). Dopotutto sta schivando il processo di progettazione!
3. Le ore extra vengono pagate o meno.

Tutto ciò influenza se ha senso per il tuo prodotto che stia facendo quello che sta facendo. Ancora una volta, integrare la tua decisione nel processo di progettazione non è davvero un problema. Sii flessibile.

Questo viola un inquilino di Scrum perché la squadra non sta decidendo il lavoro nello sprint. Questa è una squadra di mischia . Il team deve disciplinare questo programmatore se deve essere impartita la disciplina.

Un altro problema che questo crea è che si avvita con la velocità della squadra. Il lavoro fuori banda non conta per la velocità e il burn down. Quindi, questo lavoro fuori banda viene svolto, la squadra sta facendo una media di 50 punti in velocità, ma vengono fatti più di 50 punti. Il proprietario del prodotto lo vedrà e richiederà una maggiore velocità nel prossimo sprint. Velocità che potrebbe non essere possibile.

Il team (non l'OP o lo ScrumMaster) deve occuparsene con il programmatore canaglia.