Vantaggi di Scrum per gli sviluppatori stessi? [chiuso]

Essendo Scrum una metodologia di project management, come la venderesti agli sviluppatori in un team ragionevolmente soddisfatto della sua situazione attuale?

Mi sembra facile spiegare al nostro Product Manager come Scrum gli permetterà di ottenere rilasci regolari, di modificare i requisiti e di far concentrare prima il team sulle storie ad alta priorità. Ho trovato facile spiegare ciò che TDD o l'integrazione continua portano nella vita quotidiana di uno sviluppatore.

Ma come possono gli sviluppatori essere convinti ad abbracciare Scrum? In che modo Scrum semplificherebbe la loro vita?

Scrum fornirà molta più visibilità su ciò che sta succedendo . Cattiva gestione, cambiamenti dell'ultimo minuto, pressioni e ogni genere di cose che uno sviluppatore deve affrontare di solito.

Tuttavia, porterà anche molta visibilità su procrastinatori, sviluppatori di malafede, individualisti pazzi, ... in altre parole, sviluppatori malvagi.

Scrum è un'arma a doppio taglio

Scrum ti offrirà l'opportunità di risolvere questi problemi. Ecco perché è così potente.

Rompere il grande obiettivo ("fare il software") in pezzi più piccoli - storie - e decidere quale di loro fare allo sprint corrente migliora la produttività e riduce lo stress. Quando sai esattamente cosa dovresti fare ora , c'è poco di cui preoccuparti e puoi concentrarti sul fare il piccolo pezzo invece di sentirti sopraffatto dal grande insieme.

Stack Ranks / Backlog evita che le pietre miliari siano marce a morte

Come sviluppatore, il "modello distruttivo" che vedo maggiormente nello sviluppo del software è quando un "controller esterno" (ad es. Gestione di progetti, gestione esecutiva) si entusiasma molto per il fatto che la "caratteristica preferita" non ce la farà " data del calendario "e ordina una marcia della morte.

Scrum, perché classifica le "caratteristiche importanti" in alto in un elenco di arretrati aiuta gli sviluppatori a gestire proattivamente questa tensione in due modi. In primo luogo, è possibile classificare la "funzione preferita" in alto nel backlog in modo che sia più probabile che sia felice. In secondo luogo, fornisce una risposta molto visiva e concreta a "dal momento che abbiamo spostato i" widget lampeggianti "al rango 1, è molto probabile che non riusciremo a" rimbalzare i coniglietti "in questo sprint poiché ora è al rango 7. Sono ti senti a tuo agio con questo compromesso? "

Ho anche scoperto che con brevi sprint, i "controller esterni" sono meno turbati dal rimandare il lavoro. Se i "widget lampeggianti" non si trasformano in "milestone 1" e "milestone 2" non si esaurisce entro 9 mesi da allora, lo sponsor di "widget lampeggianti" si arrabbia molto. Ma se "widget lampeggianti" è classificato nello stack 7 anziché 1 perché ci sono davvero 6 cose più importanti che devono essere fatte prima, ciò significa che probabilmente ci arriveremo nello sprint + 1 o nel peggiore sprint + 2 che significa mostrerà tra 12 o 18 settimane (usando gli sprint di 6 settimane). Nella mia esperienza, aspettare 3 mesi è "accettabile" per gli impazienti. Inoltre, nel modello "a cascata" delle pietre miliari di 3+ ​​mesi,

Alla fine, se stiamo raggiungendo la fine dello sprint e le cose hanno impiegato più tempo del previsto, è molto bello poter spingere gli elementi di backlog 5-6-7 allo sprint successivo e assicurarsi di aver completato 1-2-3 -4 con alta qualità e senza 70 ore settimane. Dopotutto, saremo sicuri di arrivare al 5-6-7 sprint successivo. Ancora una volta, visti i tempi più brevi coinvolti nel rinvio, i "controller esterni" sono generalmente più a loro agio con questo e non insistono sul fatto che superiamo il traguardo due settimane e ordiniamo cene ogni sera "solo per superarlo".

Le persone in un team di Scrum possono decidere molte cose da sole: cosa verrà fatto durante il prossimo sprint, come spezzeremo questa storia in compiti, chi lavora su cosa, ecc. Ciò li autorizza ed è quasi esattamente il contrario di micro -gestione.

Il fatto che i requisiti cambieranno viene preso in considerazione fin dall'inizio. Gli sviluppatori non devono creare specifiche dettagliate con stime precise e quindi passare settimane a sviluppare una funzionalità solo per rendersi conto che il cliente cambia idea non appena vede il risultato ...

Per me, puoi auto-assegnare le attività dal backlog è il più grande punto di forza dal punto di vista degli sviluppatori. Inoltre, l'intimità con il cliente / proprietario del prodotto aiuta a comprendere lo schema più ampio delle cose.

Un paio di cose:

• Basandosi sul punto di Xavier sui requisiti che cambiano fin dall'inizio - un'atmosfera meno politica si sviluppa quando tutti accettano fin dall'inizio che alcune cose non saranno come previsto dal cliente. La consegna e la revisione rapide significheranno che il costo delle comunicazioni errate è basso e, invece di giocare al gioco della colpa, gli sviluppatori possono semplicemente cambiare le cose in modo che funzionino come previsto dal cliente.

• Punti della storia! A quale sviluppatore non piace ottenere punti per fare cose !!?! Scherzi a parte, è meglio che ottenere badge in SC2 o Stack Overflow.

Ci sono diverse cose che mi piacciono come sviluppatore della mischia.

Gli sviluppatori tendono a ricevere maggiori informazioni in anticipo. Il proprietario del prodotto deve spiegare tutto il lavoro che verrà svolto durante lo sprint successivo in modo sufficientemente dettagliato da consentire buone stime.

La stima just in time significa che tali stime sono ragionevolmente accurate. Di solito tutti hanno una buona idea di cosa sarà finito in uno sprint. Ciò offre a programmatori e project manager gli strumenti per respingere richieste irragionevoli.

È bello fare un passo indietro ogni tre o quattro settimane e prendere un respiro e almeno cambiare ritmo.

I team auto-organizzati sembrano dare un po 'più di varietà al lavoro.

Almeno in teoria, durante lo sprint ci sono meno interruzioni ed "emergenze".

La riunione quotidiana in piedi costringe i programmatori a pronunciare più parole ogni giorno.

È più facile vedere i progressi mentre le storie vengono esplicitamente finite e riviste alla fine di ogni sprint.

I grafici di burn down sono un mezzo leggero piuttosto efficace per monitorare i progressi.

Il vantaggio per lo sviluppatore è il feedback tempestivo (da client, tester, proprietario del prodotto ecc.).

Anche come sviluppatore, sono sempre interessato a fare le cose passo dopo passo senza distrazioni. Scrum lo fornisce.

PS: scrum non è una metodologia, è un framework.