Sono uno sviluppatore che lavora su una nuova app mobile per Android e iOS con un grande componente back-end. Abbiamo partecipato a tre sprint di questo progetto e usiamo Scrum con tutte le sue cerimonie (raffinatezza, pianificazione, quotidiani, retrospettive, ecc.).

In due degli sprint il team ha dovuto lavorare (non retribuito) negli straordinari e nei fine settimana, poiché i dirigenti erano molto allarmati e non avremmo completato l'impegno dello sprint in tempo. Tutti hanno lavorato duramente, ma alcune dipendenze esterne e stime ottimistiche ci hanno fatto lottare per realizzare tutte le storie di sprint.

Nella mia esperienza avere una piccola percentuale di storie non completate durante alcuni sprint è in qualche modo normale e possono essere affrontati nel prossimo. Ma il nostro project manager afferma che è colpa nostra se abbiamo fatto noi stessi la stima, quindi dovremmo completare tutti gli elementi nello sprint.

1. È una variazione accettabile / comune di Scrum di cui non sono a conoscenza?

2. Come suggerisci che dovrei agire su questo?

Alcune cose si distinguono per me.

L'idea che il management abbia il team impegnato in una serie di lavori non è coerente con le ultime versioni della Scrum Guide. La parola "impegno" o "impegno" viene utilizzata solo due volte nella versione più recente (novembre 2017) della Guida Scrum - una volta quando si elencano i valori Scrum e una volta per indicare che "le persone si impegnano personalmente a raggiungere gli obiettivi dello Scrum Team ".

L'idea degli obiettivi è importante per Scrum. Non solo le organizzazioni e i team hanno obiettivi generali, ma in Scrum ogni Sprint ha un obiettivo Sprint che viene definito in Sprint Planning come una collaborazione tra il Product Owner e il Team di sviluppo. L'obiettivo Sprint viene raggiunto implementando gli articoli dal Product Backlog, ma non è semplicemente "termina questo lavoro" e spesso non rappresenta il Backlog Sprint completo. In altre parole, dovresti essere in grado di raggiungere l'obiettivo Sprint senza completare ogni singolo articolo arretrato prodotto selezionato per lo sprint o ogni singolo articolo nell'arretrato Sprint. Il mio pensiero attuale è che il lavoro necessario per raggiungere l'obiettivo di Sprint dovrebbe essere da qualche parte circa il 60-70% della capacità della tua squadra, comunque tu tenga conto della capacità. Diverse organizzazioni saranno diverse, tuttavia, ma "

Il lavoro straordinario e il fine settimana è anche una pratica di sviluppo software anti-agile. Uno dei principi di base è che tutte le parti interessate di uno sforzo sono in grado di lavorare a un ritmo sostenibile. Lunghi giorni e fine settimana, anche se pagati, non sono sostenibili per una squadra.

A questo punto, ci sono alcuni passaggi successivi. Lo Scrum Master del team dovrebbe educare il management sui valori e sui principi dello Scrum e dello sviluppo software agile (come "impegno" e "ritmo sostenibile"). Il team dovrebbe lavorare sulla sua capacità di prevedere il lavoro e negoziare l'ambito con il Product Owner. Il team dovrebbe anche identificare e lavorare per risolvere o prevenire gli impedimenti che hanno portato a questa situazione (eliminando o riducendo l'impatto delle dipendenze esterne).

La situazione che descrivi, in cui la direzione richiede che il team lavori straordinariamente per completare tutte le storie pianificate, è uno dei motivi per cui la letteratura Scrum ha smesso di usare il termine "impegno". Un vero impegno può essere dato solo quando viene eliminata tutta l'incertezza, inclusa l'incertezza sulle dipendenze di terze parti, quanto lavoro è ogni elemento, quanto tempo saranno disponibili tutti tenendo conto della malattia, ecc.

Una delle idee di base di Scrum è che il team lavora a un ritmo sostenibile, il che significa essenzialmente lavorare in orario normale senza lavoro straordinario (retribuito o non retribuito). Questo vuol dire direttamente che si sta non verifica una variazione accettabile di Scrum.

Quello che puoi fare al riguardo dipende dal tuo ruolo.

Se sei uno sviluppatore, il meglio che puoi fare è

• (collettivamente come team di sviluppo) si rifiutano di "impegnarsi" in più lavori di quanti ne sia assolutamente certo di poter consegnare entro uno sprint. Questo sarà probabilmente molto meno di quello che la direzione vuole che tu faccia.
• concentrarsi sul completamento del lavoro, piuttosto che iniziare nuove attività. Se vedi che alcuni lavori non possono essere completati, indicalo il prima possibile in modo che i piani possano essere adattati.

Se sei un maestro Scrum, allora puoi davvero dimostrare il tuo valore educando il management su Scrum. Alcuni punti che mi contraddistinguono:

• Come indicato nel primo paragrafo, il team non si impegna durante la pianificazione dello sprint, ma fornisce una previsione del lavoro che prevede di aver terminato.
• Sebbene il team dovrebbe evitare di avere un lavoro incompiuto alla fine di uno sprint, questa situazione è quasi inevitabile all'inizio di un progetto (o dopo un cambiamento nella composizione del team). La quantità di lavoro che la squadra può realizzare realisticamente in uno sprint può essere determinata solo sulla base delle figure storiche degli ultimi sprint della squadra in questa composizione. All'inizio del progetto, tali figure storiche non esistono, quindi una squadra che realizza nei primi 3 sprint esattamente ciò che il previsto per ogni sprint è più un incidente che una buona pianificazione. Dopo circa 5 sprint a un ritmo sostenibile, ci sono dati sufficienti per avere un'idea ragionevole di quanto lavoro il team può realisticamente terminare in uno sprint.

Il tuo PM non è coinvolto nella tua mischia.

Il tuo PM non ha affari che ti chiedano straordinari non retribuiti.

La cosa ovvia da fare è stimare tutte le attività in modo tale da garantire che saranno completate in tempo. Quindi dovresti essere in grado di andare al pub nel secondo modo, poiché chiaramente se sottovalutare un'attività significa finirla gratis, quindi sopravvalutare significa che hai tempo senza lavoro.

Ci sono una serie di aspetti in questo, ma ad un livello elevato, sì - il PM vorrà assolutamente capire chiaramente perché il lavoro pianificato non è stato completato. Tuttavia, questo dovrebbe essere sollevato (e risolto) nella retrospettiva. Dal punto di vista dello sviluppo, ci sono molti fattori che possono contribuire ai fallimenti dello sprint.

Alcune cose che potresti voler considerare:

Troppo nello sprint

Se ti impegni regolarmente a lavorare troppo, gli sprint falliranno. La velocità dello sprint deve essere tracciata nel tempo per scoprire qual è il numero ottimale di punti (o giorni).

Assegnazione delle risorse

Garantire che la pianificazione dello sprint tenga adeguatamente conto delle attività di non sviluppo come cerimonie, festività, formazione, amministrazione, supporto e altri progetti ecc. Supponendo automaticamente che tutti si stiano sviluppando ogni minuto di ogni ora in cui si trovano fisicamente in ufficio, non è pratico e immediatamente metterti sul piede posteriore fin dall'inizio.

Stima la variazione

Stai facendo raffinatezza, ma ci sono alcuni tipi di compiti che hanno sempre la meglio? Comunemente si tratta di requisiti mancanti o vaghi. Se i requisiti sono lanosi, la storia non dovrebbe nemmeno arrivare allo sprint a meno che non sia stata adeguatamente raffinata o non sia stato pianificato un picco.

Velocità

Se la velocità viene tracciata correttamente, il numero reale di storie dovrebbe diventare chiaro. Questo non vuol dire che saranno sempre fatti in tempo, ma dovrebbe rendere le cose molto più facili.

Buona volontà

Su qualsiasi progetto, la buona volontà è limitata. Se ti alleni costantemente per ore, il morale ne soffrirà e gli sviluppatori si esauriranno - questo è un fallimento della gestione del progetto . Come ho già delineato, assicurati che la pianificazione dello sprint pianifichi solo un numero realistico di storie usando velocità e punte per aiutarti lungo la strada.

spikes

Se un articolo è mal rifinito o semplicemente lanoso, non aver paura di inserire un picco per fornire una stima migliore per gli sprint successivi. Sì, alcune persone sono pessime nella stima, ma la maggior parte delle volte, i fatti completi non sono noti al momento. Idealmente, questo avrebbe dovuto essere coperto nell'affinamento o raccolto in anticipo dall'OP, ma a volte possono scivolare in uno sprint. Gli sviluppatori dovrebbero respingere questi duri in quanto questi possono facilmente silurare uno sprint che altrimenti sta andando bene.

No, questa non è una forma riconosciuta di Agile , per una ragione molto importante: se ti impegni a consegnare tutto , non stai facendo Agile, stai facendo Waterfall - e se pensi invece che stai facendo Agile , probabilmente stai facendo Waterfall male , a questo. Sono sicuro che hai sentito la vecchia sega "buona, veloce, economica, scegli due", giusto? Con lo sviluppo del software, è più simile a "tutte le funzionalità fornite, puntuali, economiche, scegli la prima o le altre due". Waterfall sceglie il primo e Agile sceglie i secondi due.

Se vuoi diventare Agile, hai bisogno della flessibilità necessaria per eliminare Storie dallo Sprint che non riesci a completare in tempo. Un modo possibile per farlo è chiedere al proprietario del prodotto di valutare le storie usando la definizione delle priorità MoSCoW. Ciò implicherebbe la selezione non più del 60% delle storie (in totale dei punti storia) come Must Haves che saranno completate, il 20% come Should Haves che dovresti completare con il progetto si conclude e il Prodotto minimo vitale viene rilasciato, il 20% come Potrebbero essere completati se si ha il tempo e qualcosa al di fuori dell'ambito della versione corrente come Won't Haves. È anche importante notare che, una volta combinati, i Must Haves dovrebbero avere abbastanza carne per le loro ossa per creare il Prodotto minimo vitale senza la necessità di includere alcun articolo delle altre categorie.

Determinare se eliminare gli articoli dallo Sprint Backlog è responsabilità del Product Owner, dopo che è stato richiesto dal Team, e tutti gli articoli che vengono rilasciati dallo Sprint Backlog vengono valutati dal Product Owner, e quindi vengono abbandonato completamente dal progetto o inserito nel Portafoglio progetti in una posizione opportunamente classificata.

In questo caso, suppongo che il Product Owner sia il Project Manager, giusto? Sarebbe suo compito determinare quali compiti abbandonare, quindi certamente non dovrebbe biasimarti per il tuo impegno eccessivo, dal momento che sarebbe suo compito abbandonare i compiti per compensare quello, e sembra che non lo stia facendo.

Ha ragione, non dovrebbe esserci alcun riporto tra gli sprint. I team Scrum che hanno un riporto tra gli sprint sono un modello anti-pattern e non qualcosa che lo Scrum canonico accetta come risultato valido.

Ma il suo approccio non è buono.

Durante uno sprint, il team dovrebbe monitorare costantemente il lavoro svolto e se può mantenere il proprio impegno nella pianificazione dello sprint sul completamento delle storie selezionate. Se la squadra identifica che non può finire tutte le storie, dovrebbe incontrarsi con PO e selezionare una storia da rimuovere dallo sprint. In questo modo, tutti smettono di lavorare sulla storia e si concentrano sul portare a termine le storie rimanenti. Ricorda: è sempre meglio finire una storia completamente piuttosto che averne due a metà.

I problemi delle dipendenze esterne e della stima imprecisa sono esattamente i motivi per cui esistono Retrospettive. Durante Retro, il team dovrebbe riflettere e identificare questi problemi. E il team dovrebbe quindi trovare e implementare soluzioni a questi problemi. Le stime possono essere rese più precise conoscendo meglio il sistema e la semplice esperienza. Le dipendenze esterne sono più difficili, ma non impossibili da risolvere.

Il tuo PM ( cosa sta facendo anche PM in un team Scrum ?? ) non dovrebbe essere autorizzato da Scrum Master a costringerti a finire tutte le storie. Invece, se ha lamentele, dovrebbe conservarle per Retrospective. E ancora meglio, dovrebbe far parte della risoluzione dei problemi che hanno impedito il completamento puntuale delle storie.

È una variazione accettabile / comune di Scrum di cui non sono a conoscenza?

No . È completamente sbagliato. Potrei forse simpatizzare con gli straordinari retribuiti , se l'OP commettesse l'errore di fornire le stime come fatti prima della fine dello sprint, ma gli straordinari non retribuiti sono completamente ridicoli e mi farebbero cercare un altro lavoro al più presto.

Come suggerisci che dovrei agire al riguardo?

Nella mia esperienza, le persone che sono così tanto della ferrovia non ascolteranno argomenti logici. L'unico modo per loro di vedere quanto è rotto è mostrare , non dire. Quindi la prossima volta quando stimerai e ti impegnerai, impegnati nella quantità più piccola possibile . Impegnati a finire un piccolo biglietto entro la fine dello sprint. Uno che potresti fare in un giorno. Guarda come reagisce il tuo PM. Quindi avviare una discussione da lì su ciò che viene utilizzato per il sistema e per cosa dovrebbe essere utilizzato il sistema .

Generalmente, all'inizio del progetto, quando decidiamo la velocità della squadra, prendiamo un numero conservativo (inferiore al solito) considerando il fatto che si tratta di una nuova squadra, ci vorrebbe un po 'di tempo prima che la squadra si stabilizzi , capirsi, capire i requisiti funzionali e NFR, ecc. Fondamentalmente, dopo i primi sprint ottimizziamo la velocità della squadra e ovviamente la velocità migliorerà solo da quel punto.

Non ha senso commettere una velocità maggiore all'inizio e allungare la squadra per raggiungerla.

Un'altra cosa è che, in uno scenario unico, in cui vi è un impegno di consegna da non perdere, i project manager potrebbero fare pressione sul team per lo stretching, lavorare fino a tardi e lavorare durante i fine settimana. Ma allora deve essere considerata un'eccezione e non la norma del lavoro. Lavorare in questo modo potrebbe aumentare la velocità a breve termine, ma a lungo termine sarebbe controproducente, in quanto potrebbe causare problemi di qualità del codice, problemi di esaurimento della squadra, squadra infelice con bassa motivazione, ecc.

Domande frequenti sull'impegno

Questo comportamento è normale?

Non ne sono sicuro.

È sorprendente?

No. Alcune persone capiranno sempre "impegno" nel senso che tutto nell'impegno deve essere completato.

È una buona idea?

No. Lo sviluppo agile ha come tema centrale la sostenibilità : lavora solo tanto / a lungo / duramente quanto puoi fare a tempo indeterminato. Questa è un'idea sensata nella maggior parte dei casi. (Se la tua direzione non lo accetta, non dovrebbe chiamare la sua organizzazione agile.)

Cosa dovremmo fare?

• Spiega che il contenuto dello sprint si basa su una stima . "Stima" significa che a volte sarà corretto - e di solito è sbagliato. Quando è sbagliato, a volte è troppo basso e talvolta troppo alto.
• Spiegare che è molto più semplice modificare il comportamento di stima rispetto alla velocità di lavoro.
• Spiega che quando il team viene punito per una stima troppo alta, stimerà solo un calo e la gestione perderà molti più progressi in quel modo che spingendo un po 'del contenuto da uno sprint al successivo di tanto in tanto.

La cosa bella è: il project manager saprà già tutte queste cose e le riconoscerà come giuste. È solo che a breve termine si può preferire di ignorarli.

Non sono d'accordo con il tuo team di gestione. Non avrebbero dovuto farti fare gli straordinari per finire lo sprint.

Tuttavia, l'idea che gli impegni non siano possibili deriva da un malinteso sullo sviluppo del software. Ho visto molti team provare a prevedere le storie che possono completare in uno sprint in base al numero di punti storia che hanno completato negli sprint precedenti. Se ciò fosse possibile, direbbe che lo sviluppo del software è lineare, vale a dire se lavoro due ore ottengo il doppio rispetto a un'ora.

Lo sviluppo del software è creativo e quindi non lineare. È una prassi migliore per il team raccontare al management cosa possono fare in uno sprint e quindi fornire tali storie. Se manchi costantemente i tuoi impegni, o non avevi idea dell'ambito della storia o se sei stato spinto dal proprietario del tuo prodotto ad assumerne di più.

Nel primo caso, è necessario assicurarsi di aver compreso l'ambito della storia prima di accettare di accettarla. Se è quest'ultimo, hai un problema di cultura e c'è poco da fare.