Bene, quindi qualcuno sta scrivendo con entusiasmo un grande codice che deve essere fatto, solo che non è in ordine. Con tutto il dovuto rilievo:

LETLI

Sta causando alcune complicazioni negli sprint di scrum. Ha davvero importanza nel grande schema delle cose? Se sta compiendo ciò che dovrebbe, allora lascialo andare avanti e costruisci grandi cose per te.

Conosco diversi programmatori sorprendenti che hanno lasciato le aziende perché non hanno lasciato i programmatori fuori dai limiti di un sistema artificiale come Scrum (io stesso ho lasciato il mio ultimo lavoro dopo essere stato trattato come niente più che un QA glorificato). 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 permettere a lui (e agli altri) di fare ciò che sanno fare meglio con interferenze minime.

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

Ci sono due cose che dovrei considerare qui:

1. Non ostacolare il flusso creativo di qualcuno.
   • Se uno sviluppatore vuole svolgere il lavoro fuori orario, allora fallo.
2. Non creare lavoro per gli altri.
   • Se uno sviluppatore vuole svolgere il 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 detto, non gli piace il fatto che il codice sia scritto senza l'input dell'intero team. Ciò può essere dovuto al fatto che, in termini di design, finisce per essere inferiore. E il codice con un design inferiore ha un modo di infettare altro codice attorno ad esso.

Quindi, cosa puoi fare?

Lascia che l'ambizioso codice di sviluppo sia contenuto nel suo cuore, ma chiarisci che non c'è motivo di pensare che il suo codice extrascolastico sarà usato .

Dopotutto, fa parte di una squadra, quindi il team deve essere coinvolto nel modo in cui viene sviluppato tutto il codice.

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

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

Riportalo nel team

Dovresti chiederti (o meglio al team, incluso il superquipe):

Perché questo comportamento è un problema?

Poiché etichetti lo sviluppatore come un overachiever, suppongo che il suo lavoro sia di buona qualità, quindi presumo 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 sulla prossima cosa da implementare, non sul PO
• lo sviluppatore non riceve alcun feedback dalle varie parti interessate da incorporare nel suo lavoro.

Il prossimo Perché vorrei così com'è:

Perché lo sviluppatore lo fa?

• Se alla fine dello sprint non è rimasto abbastanza lavoro, ci dovrebbe essere una decisione della squadra (incluso il PO) su cosa affrontare dopo. Perché lo sviluppatore evita questa decisione?

Una volta che hai risposto a queste domande puoi iniziare a rispondere alla tua domanda:

• Se non è un problema, fagli fare le sue cose. Sebbene alcune persone considerino SCRUM una religione, non dovrebbe essere così.
• Più probabile che tu abbia due problemi nel team: uno (i) causato dallo sviluppatore canaglia e uno (i) che innesca il comportamento dello sviluppatore malvagio. Trova un modo per risolvere il dopo e il primo andrà via.

Per quanto mi piaccia l'idea che l'aggiunta di lavoro gratuito nel mix sia una buona cosa, non è un lavoro gratuito - a meno che il singolo sviluppatore non sia anche il tester, il QA e il ragazzo delle build e il designer e tutto altro. Se il suo lavoro può essere inserito nel prossimo sprint senza alcun impatto, allora ... fallo. Ma penso che non sia mai il caso. Tutti gli altri, per lo meno, 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 per un compito solo per scoprire che il tizio ha fatto la scorsa settimana.

Tuttavia 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à extra-curriculare. Ciò significa ottenere l'input e l'accordo di tutti, non puoi farlo senza il loro buy-in. È vitale. Se alla squadra non piace, allora il tizio smette di farlo. Fine di. Non è un ragazzo che fa ciò che gli piace, non importa quanto sia buono il suo lavoro, è un impegno di squadra fino in fondo. Il team viene prima di tutto.

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

Forse otterrai una soluzione in cui tutti lavoreranno sui loro progetti preferiti e li porteranno al tavolo (puoi immaginare il caos della tua consegna che causerebbe :) che mette in evidenza il problema con esso in primo luogo) o puoi mandare un'area in cui ogni sviluppatore dispone di automomi per sviluppare qualsiasi soluzione a loro piaccia è il "contribuito" 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 solo spingendo fuori qualunque cosa possa essere fatta rapidamente? Personalmente non permetterei a nessuno di lavorare al di fuori degli orari definiti in quanto rovinerebbe 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 regolare il processo per includere il tempo extra (ma ancora è 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 in modo diverso. In conclusione, tuttavia, qualsiasi operazione eseguita al di fuori del programma pianificato distruggerà le stime e non permetterei che ciò accada.

abbiamo affrontato anche la stessa cosa, fondamentalmente abbiamo commesso qualcosa come 20 punti ma alla scorsa settimana o anche a metà dello sprint abbiamo esaurito il compito di codifica, tuttavia a causa del test e del resto del processo non abbiamo rischiato di scegliere un altro PBI Quindi, ciò che i programmatori hanno fatto è stato esaminare l'arretrato e iniziare a sviluppare PBI futuri (in silenzio!) E informare il resto del team nel pianificare che PBI sia pronto per la revisione e il test del codice! proprio come hai detto tu.

In realtà ha sollevato qualche preoccupazione dai nostri PO che sembra che siamo più capaci 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 hanno potuto seguire quella velocità quindi c'era il rischio di fallire lo sprint. dopo aver pensato a questo problema, abbiamo scoperto che abbiamo bisogno di cambiare la nostra opinione sulla mischia e il problema principale è che le persone non vogliono correre questo rischio perché noi Impegniamo PBI così il team non si è sentito buono a correre il rischio di scegliere nuovi PBI nel caso in cui avessimo programmatore libero.

Semplicemente abbiamo iniziato a Forecast PBI piuttosto che prendere impegni. Previsioni significa in pratica che selezioniamo 25 punti nella pianificazione e inizio dello sprint, E quando il programmatore si libera a metà dello sprint, perché non c'è più attività di codifica, quindi sceglie uno dei PBI futuri e lo inserisce in Sprint attuale e inizia a lavorare su di esso, se il PBI potesse passare tutto il processo (test, fusione ed ecc.) nello stesso sprint, è un punto bonus per la squadra se NON non falliamo lo sprint a causa di quel PBI e continuando a portare avanti il lavoro rimanente ( testing o meging o ecc.) al prossimo sprint e re poker per il lavoro rimanente. Quindi può essere fatto in due diversi sprint in caso peggiore. So che potrebbe sembrare Scrumbut, ma in realtà ha migliorato il nostro modo di lavorare. Posso solo riassumere i suoi vantaggi come di seguito:

• Sconfigge la fobia dello sprint fallito a causa del rischio di prendere più PBI
• Rende visibile il lavoro extra dei tuoi programmatori e team
• Aumenta la velocità della squadra

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

Alcune delle altre risposte hanno suggerito che lo sviluppatore "overachieving" è "canaglia" o "violato 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 questi tempi supplementari, ma potresti dare suggerimenti e aiutare le idee di incoraggiamento).

Non c'è nulla in Scrum che prescriva il modo in cui le persone lavorano e qualsiasi cosa in più che faceva sarebbe stata naturalmente incorporata nella velocità della squadra.

Il suo lavoro dovrebbe essere portato nel backlog del prodotto e stimato nella prossima riunione di pianificazione. Se non puoi prevedere quale sarà lo sforzo rimanente, dovresti inserire un po 'di tempo nello sprint per capirlo (cioè, un Spike).

Interessante descrivi lo sviluppatore come "overachieving", presumo questo significa che sta aggiungendo molto più valore rispetto agli altri membri del team.

Le difficoltà nel lavoro extra creano implicazioni che c'è qualcosa di sub-ottimale (o forse anche disfunzionale) nella tua squadra.

Se questo è il caso, dovresti chiederti perché sta ottenendo molto di più, con presumibilmente solo un piccolo 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 gestiti in modo microscopico, potenzialmente su storie di utenti con prescrizioni, definizione di fatto, che finisce per essere soffocante per gli sviluppatori. Questo sviluppatore sta facendo il lavoro che lui vuole? Presumo che stia prendendo delle buone decisioni. Lavorare in questo modo nella settimana lavorativa aiuta anche il resto della squadra?

Invitali anche a diventare un insegnante

È fantastico che tu abbia uno sviluppatore stellare con le abilità migliori e più avanzate nel gruppo. Vorrei elogiare e complimentarmi con questo. Spesso queste persone sono la "colla" che tiene insieme le organizzazioni.

Vorrei vedere la sfida come "come far diventare gli sviluppatori meno esperti più vicini alla produttività degli sviluppatori più avanzati".

Un ottimo modo per farlo è concentrarsi sul fatto che lo sviluppatore di stelle impieghi più tempo a insegnare, addestrare e guidare i membri del team meno esperti e lenti. Vorrei prima discuterne in un 1-a-1 con lo sviluppatore principale in modo che sappiano cosa stai facendo e perché. Altrimenti, può essere visto con sospetto come un programma nascosto / scarsa gestione

Quando fai le alzate, una o due volte al giorno, se questa persona ha esaurito il lavoro e altre ancora stanno facendo attività, cerca di abbinarle alla 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 un paio?"

Potresti anche trovare un lavoro "laterale" per i migliori sviluppatori per quando sono senza lavoro, come migliorare il set di strumenti utilizzato da tutti, gestire un gruppo di discussione di club di libri tecnici o essere coinvolti in altri progetti organizzativi.

Ho intenzione di rispondere a una domanda diversa. Penso che come 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 dev faccia ciò che sta facendo. Penso che diversi aspetti giochino un ruolo chiave nella risposta a questa domanda:

1. Il programmatore sta facendo un buon lavoro.
2. Tutti stanno bene con lui a fare il suo lavoro da solo (sia buono che cattivo). Dopo tutto, sta schivando il processo di progettazione!
3. Le ore extra sono pagate o meno.

Tutti questi fattori influenzano se è ragionevole per il tuo prodotto che sta facendo ciò che sta facendo. Ancora una volta, incorporare la tua decisione nel processo di progettazione non è davvero un problema. Sii flessibile.

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

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

Il team (non il PO o lo ScrumMaster) deve affrontare questo problema con il programmatore canaglia.