Perché ho bisogno di SCRUM rispetto a un processo meno formale e più leggero per il mio team?

Vorrei iniziare la mia domanda dicendo che ho capito che SCRUM o qualche suo derivato è probabilmente un buon modo per gestire lo sviluppo del software. Sembra che tutte le grandi aziende e i miei manager lo usino o lo abbiano usato, e non posso davvero discutere con tutta quell'esperienza. Tuttavia sto lottando per capire i "perché" e tutta la lettura e persino la mia formazione ufficiale SCRUM sul lavoro non mi sta facendo il lavoro. È solo tutta retorica. Quindi vengo qui in cerca di risposte.

Fino ad ora, ho sviluppato in team di 4-5 membri in modo molto efficace, completamente auto-organizzato e senza la necessità di formazione, metodologia o software speciale. Solo discussioni in cubi, riunioni ad hoc e revisioni individuali del codice. Ora sono in una posizione di lavoro in cui ci viene detto che SCRUM è la strada da percorrere e tutto ciò che ne consegue. Quando mi descrivono SCRUM, leggo cose come questa:

• Individui e interazioni su processi e strumenti
• Software funzionante su documentazione completa
• Collaborazione con i clienti sulla negoziazione del contratto
• Rispondere al cambiamento seguendo un piano

È grandioso, ma tutto mi sembra buon senso. Perché questo ha bisogno di essere codificato? Quindi mi è stato detto che la metodologia ci aiuta a rispondere al cambiamento. Quale specificoaspetti di SCRUM mi stanno permettendo di essere così flessibile che in precedenza non stavo raggiungendo con le mie riunioni ad hoc, le discussioni sul cubo e le riunioni di pianificazione degli sviluppatori? Spiegano la necessità di avere un prodotto funzionante ogni due settimane o di uno sprint. Nel mio particolare progetto, non esiste un "client", il software non sarà completato per un anno o più, e nel frattempo probabilmente proverò solo all'alta direzione ogni mese o meno. Allora perché l'esplicita necessità di un prodotto a giorni alterni? Sottolineano l'importanza dell'incontro di pianificazione dello sprint in cui l'intero team espone le storie e i compiti per lo sprint successivo. Questo non è diverso dalle improvvisate riunioni di pianificazione che ho avuto in passato. Perché deve accadere a giorni alterni, e perché l'intero team deve essere coinvolto? Capisco il concetto che ogni membro "possiede" il prodotto, ma il fatto è che solo poche persone possono davvero contribuire a spezzare ogni storia in compiti, mentre gli altri guardano pigramente.

Ancora una volta, capisco che la maggior parte delle persone è alla base di questo processo, e quindi deve funzionare, e devo entrare. Vorrei solo capire il perché. Il mio problema è che pratico già queste cose e non mi piace codificarle inutilmente? O forse devo ancora vedere i vantaggi di queste tecniche perché sono state eseguite in modo improprio? Qualsiasi informazione reale o personale su questo, a differenza dello spiel che sono abituato a ricevere, sarebbe estremamente apprezzato.

Penso che ci siano due aspetti per rispondere alla tua domanda, ma vorrei iniziare congratulandomi con te per aver collaborato con persone che sembrano essere abbastanza intelligenti e competenti da essere in grado di lavorare praticamente senza un processo fortemente definito e consegnare comunque un prodotto. Purtroppo questo non è un caso in tutti i team di software, quindi forse uno dei tuoi problemi con Scrum potrebbe essere che tu e i tuoi colleghi in realtà non avete bisogno di un processo scaricato su di voi per rendervi più efficaci. Potresti già essere efficace.

Altri team non lo sono e hanno bisogno di un processo più rigorosamente definito e di alcune linee guida per ottenere risultati. Questo non significa che queste squadre siano più stupide o meno capaci, significa solo che forse hanno problemi di auto-organizzazione o di lavoro con la disciplina come squadra. Questa può anche essere una semplice esperienza di apprendimento quando proviene da un luogo in cui le persone lavorano principalmente da sole per lavorare insieme come una squadra. Scrum può aiutarti ad arrivarci, perché offre alcune linee guida che sono entrambe abbastanza facili da capire e seguire, ma abbastanza efficaci da mettere un po 'di pressione sulla squadra per iniziare a metterle insieme.

Dal momento che Scrum non dice nulla sul modo in cui lo sviluppo del software dovrebbe essere fatto, lascia anche al team la libertà di decidere da soli (ad esempio puoi ancora fare uno sprint applicando un metodo a cascata piuttosto conservativo fintanto che hai finito al fine dello sprint).

Quindi il team è un problema. L'altro problema è la gestione e la fiducia della direzione. Qui, Scrum potrebbe essere buono perché è trasparente e consente a tutte le parti interessate di vedere i progressi del team in cicli definiti. Quindi non è "stiamo facendo progressi, sfortunatamente non possiamo mostrarti nulla in questo momento, ma credici, avremo finito in tempo". Questo può anche essere vero, ma può essere rassicurante per tutti i manager avere effettivamente una demo regolare in cui possono vedere che i progressi sono effettivamente avvenuti.

Scrum non è un proiettile d'argento. Potrebbe non funzionare per alcuni team per una serie di motivi, forse per alcuni team l'auto-organizzazione non funziona. Forse per te è il contrario e sembra un processo scaricato su un team già produttivo e organizzato.

In caso di dubbi, ti suggerirei di provarlo e vedere. Se non funziona e la maggior parte della squadra non ama lavorare in quel modo, non farlo. Tuttavia, dai un'occhiata per un paio di mesi (dico un paio di mesi, perché i primi sprint saranno comunque scomodi e avrai bisogno di tempo per modificare i dettagli) e quindi rivalutare.

Potrebbe essere controverso, ma Scrum è meglio ridurre le paure gestionali di Agile o usarlo con un team già poco performante. Se la tua squadra sta andando alla grande, raggiungendo obiettivi, facendo soldi e felice, Scrum non ti comprerà nulla perché tutto ciò che farà sarà sconvolgere il buon equilibrio delle attività che fai (e rendere la tua squadra di successo). Scrum non è un proiettile d'argento. Nella mia esperienza, aiuta solo i team che avevano una stima e una comunicazione scarse per cominciare. Un team che lavora con stime realistiche in un ambiente di comunicazione efficace è ostacolato solo dal sovraccarico del processo di Scrum.

Che ci crediate o no, esistevano buoni team di software prima che Scrum arrivasse. Scrum aiuta i cattivi a stare meglio.

La maggior parte delle risposte qui ha già elencato il motivo, anche se un po 'indiretto. La risposta di Anne è particolarmente illuminante quando tocca la trasparenza. Cioè, permettendo ai manager di vedere cosa sta succedendo. E la risposta di Schultz tocca anche questo quando parla di persone che non sono in grado di nascondere il fatto che si stanno rilassando.

Quindi vorrei dire quello che gli altri stanno già dicendo, ma in un linguaggio più diretto: l'obiettivo principale di SCRUM non è gestire lo sviluppo del software, l'obiettivo principale di SCRUM è misurare lo sviluppo del software.

Altri sistemi hanno provato prima e la gente ha proposto innumerevoli metriche per provare a misurare lo sviluppo del software ma ha fallito. SCRUM risolve il problema e sposta l'onere della misurazione lontano dai manager e dagli stessi sviluppatori. La logica è semplice: chi meglio stimare quanto tempo ci vuole per fare qualcosa di quelli che fanno il lavoro da soli?

Ora, il problema è che i programmatori sono ben noti per essere troppo ottimisti. Chiedi a un programmatore quanto tempo ci vuole per fare qualcosa e in genere sottostimerà quanto sia effettivamente difficile il compito. SCRUM fornisce gli strumenti per controllare questo:

• incontri quotidiani per valutare i progressi e ottenere una visione d'insieme del progetto
• le stime vengono eseguite in "punti" anziché in ore / giorni per sottrarre il tempo trascorso
• grafici di burn-down e grafici di tortura / lepre per visualizzare la velocità dei punti
• storie e attività su una lavagna per avere una visione d'insieme del carico di lavoro
• sprint e iterazioni che fungono da scadenze in modo da poter misurare i progressi
• ruoli specifici per scrum master, proprietario e membro del team per evitare la tentazione di imbrogliare

eccetera.

Potresti notare che tutto quanto sopra fa principalmente due cose:

1. Misurano il lavoro. O lavoro da svolgere o lavoro svolto o lavoro completato.
2. Si sforzano molto per evitare il problema del programmatore iperottimista per ottenere una stima migliore e più realistica.

Più a lungo implementi SCRUM, più accurata troverai la tua stima. In effetti, personalmente credo che eseguire gli sprint + un backlog + un grafico burn-down da solo sia sufficiente per curare la maggior parte dei programmatori di fare stime sbagliate su quanto tempo ci vuole per fare qualcosa.

Personalmente penso che lo scopo di SCRUM sia quello di soddisfare le organizzazioni più vecchie in cui i vertici aziendali non possono o non possono sostenere un processo più snello. Lavoro come architetto (pollo) da circa un anno in un dipartimento che utilizza fortemente SCRUM. Il mio precedente background sono le startup della Silicon Valley, la maggior parte delle quali ha utilizzato un processo incentrato sulle funzionalità molto più snello, ad hoc e altamente iterativo (a volte settimanale o addirittura giornaliero). Trovo SCRUM, almeno il modo in cui lo implementiamo per essere eccessivo in termini di processo (e in qualche modo più pesante di cascata (almeno dal punto di vista dello sviluppatore). Per essere fiero, dirò che un aspetto del nostro processo che devia è che i nostri proprietari di prodotti sono in realtà più simili agli analisti dei requisiti nell'organizzazione IT. Di conseguenza, tendono a smorzare le informazioni provenienti dall'azienda e, peggio ancora, lasciano l'azienda non responsabile per il team di sviluppo (che richiede periodiche infusioni successive di user story). Tuttavia, nella mia futura startup, non avrei usato uno SCRUM. Probabilmente lo userei solo nella situazione in cui la gestione richiede l'overhead aggiunto.

Non parlerò dal punto di vista del purista. Sento che sei in grado di eseguirlo in qualche modo simile a quello che dice Scrum. Tuttavia, il punto principale è che è la tua capacità di eseguire lo spettacolo. Cosa succederà se sei in vacanza per un mese?

Vedo la mischia come un meccanismo per semplificare tutto ciò che hai fatto e mettere alcuni aspetti definiti al riguardo. In modo che in tua assenza qualcun altro possa replicarlo e replicarlo anche su altri progetti. Tuttavia la mischia non è un proiettile d'argento. Ho visto molte persone che hanno appena iniziato a usare Scrum (perché è di moda) e sono state picchiate male perché non ne capivano l'essenza.

PS: Scrum non richiede che lo sprint debba durare due settimane. Può durare un mese (il tuo caso).

Si prega di vedere prima i miei commenti alla domanda.

SCRUM è un paradigma di sviluppo software agile. Come tale, è agile stesso. Non presume che tu debba seguire il suo modello classico. E dubito che qualcuno lo faccia davvero. Lavoravo in diverse organizzazioni e ogni team lo adattava alle proprie esigenze. Non è insolito che non ci siano clienti / consumatori quando si tratta di rilasciare alcuni prodotti / librerie / API pubbliche. Non ne ho mai avuto uno. Nel mio caso, il nostro GM ha agito come uno, che IMO era come non averne.

Avere sprint di 2 settimane è difficile. Molto difficile. 3 settimane sono migliori ma sono davvero per esperienza e familiarità con il team di processo. Abbiamo trascorso 4 settimane o un mese. Questo ci ha dato il tempo sufficiente per "sistemarci", per così dire all'inizio e avere più fiducia alla fine, a causa di più durante i test. Mi è piaciuto e mi atterrerei almeno 3 settimane.

L'altra squadra con cui collaboravo non aveva altro che arretrati. Si riunivano, riferivano sullo stato e sulle novità e basta. Una volta fatto tutto, avrebbero escogitato un altro arretrato. Sapevano che non era SCRUM ma ha funzionato per loro ed è quello che conta.

È più leggero? Lo è sicuramente. Ma non è SCRUM. Quello che mi piace di SCRUM è che promuove la disciplina. Le persone sentono la pressione di consegnare qualcosa ogni giorno. Tutti sanno cosa fanno gli altri e lui fallisce, lo sapranno tutti. Anche se si cerca di nasconderlo (leggi la bugia), diventa ovvio molto prima che con altri processi. Quindi, quando divergi e semplifichi come con quella squadra, devi essere sicuro di farlo con le persone giuste. Altrimenti potrebbe semplicemente cadere a pezzi degradando molto rapidamente verso incontri di stato insignificanti in cui tutti rimarrebbero e pensano "cosa devo fare qui? So cosa devo fare, quindi che diavolo?"

Sono i miei due centesimi. Faccio il mio SCRUM come sviluppo: pianifico il lavoro, suddivido i compiti, li stima, osservo i progressi. Mi aiuta davvero ad essere al top. Ho applicato alcune cose di SCRUM ai progetti che ho esternalizzato e ha funzionato alla grande per me.

Solo ... resta agile ;-)

Ti consiglio di ignorare la mischia. Tra un paio d'anni arriverà una nuova moda, e sarai meno cinico e sarai ancora in grado di abbracciarlo con tutto il cuore. In effetti potresti diventare rapidamente un esperto. Quindi puoi fare un sacco di soldi scrivendo un libro su di esso e parlando alle conferenze.

Poiché molte cose sono cicliche, molto probabilmente questa nuova moda sarà un processo pesante simile al RUP. Quello che sarà successo è che tutti avranno seguito processi leggeri e agili, e questi saranno accusati dei loro fallimenti nel progetto. Quindi, naturalmente, la soluzione logica è che sono necessarie una pianificazione e una progettazione più avanzate!

Scherzi a parte, non penso che tu abbia bisogno di Scrum. Nella mischia non c'è niente di meglio di altri processi agili concorrenti. Inoltre ha molti nomi stupidi per le cose.

È grandioso, ma mi sembra tutto di buon senso. Perché questo ha bisogno di essere codificato?

La mischia viene generalmente confrontata con metodologie più vecchie e più pesanti. Le metodologie hanno cercato di far funzionare la cascata senza feedback applicando più documenti, più firme e più pianificazione in anticipo. Il manifesto Agile (che stai citando) era un'inversione di quelle idee.

Quindi mi è stato detto che la metodologia ci aiuta a rispondere al cambiamento. Quali aspetti specifici di SCRUM mi stanno permettendo di essere così flessibile che in precedenza non stavo raggiungendo con le mie riunioni ad hoc, le discussioni sul cubo e le riunioni di pianificazione degli sviluppatori?

Sembra che tu abbia già una struttura agile. Se stai già rispondendo al cambiamento bene, ovviamente non hai bisogno di aiuto. Alcuni processi diventano così nascosti dalla procedura che la correzione di un bug richiede un'analisi completa e una fase di progettazione funzionale e non può entrare nel progetto fino al prossimo anno, al più presto.

Spiegano la necessità di avere un prodotto funzionante ogni due settimane o di uno sprint. Nel mio particolare progetto, non esiste un "client", il software non sarà completato per un anno o più, e nel frattempo probabilmente proverò solo all'alta direzione ogni mese o meno. Allora perché l'esplicita necessità di un prodotto a giorni alterni?

Scrum originale prescrive sprint di un mese. C'è una brutta tendenza verso il machismo Agile nell'accorciare gli sprint. ("Sì, beh, i nostri sprint durano solo un giorno ...") Il cliente / cliente è chiunque abbia l'autorità di dire che il progetto è buono o che ha bisogno di più lavoro. Se stai dimostrando all'alta direzione ogni mese, sono probabilmente i tuoi clienti e probabilmente sei già molto vicino a Scrum.

Sulla base della descrizione di ciò che sta facendo la tua squadra, Scrum probabilmente non è molto diverso. Potresti ottenere un valore dalla standardizzazione, perché sarà più facile spiegare agli estranei cosa succede se usi i termini Scrum. Inoltre, Scrum può essere usato come scudo; ad esempio, Scrum prescrive che le decisioni tecniche dovrebbero essere prese dal team - sottolineando questo principio può essere un buon modo per ottenere un valore tecnico che altrimenti sarebbe difficile da vendere (Associare la programmazione, per esempio.)

Scrum è sostanzialmente un'interfaccia che il tuo team può implementare. Se lo fai, allora hai una buona idea su come comunicare con quelli esterni al team e hanno una buona idea su come comunicare con te. Solo tu puoi sapere se la tua squadra ha bisogno di questo.

Non usiamo Scrum al lavoro. Usiamo una metodologia fondata su Agile e Lean che è simile per molti aspetti. Ho usato questo processo in team di dimensioni variabili tra 3-5 persone incluso il lead. Sebbene ci siano differenze, penso che potresti essere in grado di aiutarti a capire se Scrum è utile per la tua situazione.

Rendere esplicita la metodologia

Rendiamo esplicito il nostro processo perché rivediamo il nostro processo ad ogni riepilogo / revisione dello sprint. Parte della conclusione / revisione è identificare le pratiche che non funzionano per noi. Discutiamo anche delle pratiche che pensiamo possano funzionare per noi e se c'è abbastanza accordo lo proveremo. Non saremmo in grado di farlo senza codificare la nostra metodologia.

Cancella la sottoscrizione

Questo è il cavallo di battaglia per il nostro processo. Questo garantisce ciò che scriviamo è ciò che è necessario. Quando riceviamo una caratteristica particolare andiamo al nostro cliente. Il cliente è chiunque userà ciò che scrivi. In alcuni casi devi delegare il cliente con qualcuno che rappresenti il ​​cliente (come la gestione del prodotto). Questi sono i nostri passaggi e fino al completamento dell'ultimo passaggio la funzione non viene eseguita.

• Ottieni la funzionalità dalla scheda, dal tracker, ecc.
• Parla con il cliente e capisci cosa sta cercando prima di scrivere qualcosa.
• Implementa la funzione.
• Mostra al cliente la funzionalità funzionante nella sua forma finale Far completare la firma del cliente sulla funzionalità.

Fette verticali

Facciamo tutto il nostro sviluppo in sezioni verticali. Ciò supporta la possibilità di firmare con una funzionalità completata, nonché questi altri motivi.

• Ammortizza i problemi di integrazioni inserendoli in ciascuna funzione. Aiuta a eliminare i tempi di crunch alla fine di un progetto.
• Ci permette di tagliare facilmente le funzionalità perché eliminiamo molte dipendenze incrociate.
• Ci consente di interrompere lo sviluppo se dobbiamo cambiare direzione.
• Siamo in grado di realizzare rilasci iterativi , fornendo tempestivamente funzionalità al cliente.

Accettazione TDD

Sfruttiamo i framework di test unitari per l'accettazione tdd. Questo ci dà molti vantaggi.

• La ristrutturazione di grandi dimensioni non costa molto tempo di rielaborazione dei test.
• Assicuriamo la funzionalità del cliente.
• Copriamo l'integrazione del codice.
• Supportare la pratica di sviluppo di Vertical Slice.

La build è sempre disponibile

Dopo ogni spinta il codice dovrebbe essere rilasciabile. Anche se la funzione è incompleta, nulla dovrebbe essere rotto. Dovrebbero essere eseguiti tutti i test e dovrebbero essere presenti tutte le funzionalità precedenti. Questa è davvero un'estensione del nostro sviluppo di sezioni verticali. Come tale, condivide molti degli stessi vantaggi.

• Ci permette di tagliare facilmente le funzionalità perché eliminiamo molte dipendenze incrociate.
• Ci consente di interrompere lo sviluppo se dobbiamo cambiare direzione.
• Siamo in grado di realizzare rilasci iterativi , fornendo tempestivamente funzionalità al cliente.

Integrazione continua

Ogni push genera una build tramite il nostro server di build CI. Il server di build verifica il codice, esegue l'intera suite di test, contrassegna il codice e lo impacchetta per la distribuzione. Rafforza la nostra politica secondo cui la build è sempre rilasciabile.

Stima puntuale per le carte

Ogni bug, funzione e attività diventa "carta". Una carta è la più piccola unità logica di lavoro che presenta alcuni vantaggi per il cliente. Li segnaliamo secondo la nostra scala. Qualsiasi valore che superi il nostro valore massimo in punti o sia ulteriormente suddiviso. Abbiamo trovato maggiore è il valore in punti, maggiore è la deviazione che può esserci nel tempo per il completamento, quindi rompendo ulteriormente le carte di grandi dimensioni. Se la carta ha abbastanza ambiguità, viene arrotondata per eccesso al valore del punto successivo nella scala. Ogni carta deve essere firmata prima di poter essere considerata completa. La stima corretta supporta la nostra capacità di calcolare la velocità.

Velocità

Abbiamo sprint settimanali. Ogni venerdì pianifichiamo il lavoro e diamo priorità al lavoro per la prossima settimana. In base alla nostra velocità, abbiamo una buona idea di quanto "lavoro" possiamo realizzare entro la settimana. La nostra velocità è la media e la mediana dei punti totali completati entro la settimana. Gli aumenti della deviazione standard vengono analizzati per stime errate (che cercano sempre di migliorare) o per maggiori interruzioni (di cui parlo con il manager). La velocità può anche essere utilizzata per stimare una data di completamento accurata per un progetto, ma solo se si tratta dell'unico progetto su cui si sta lavorando.

Miglioramento e design incrementali

Abbiamo anche una politica per lasciare il codice in uno stato almeno un po 'migliore rispetto a come lo hai trovato. Rifattorizza / riprogetta il codice all'inizio di una carta. L'obiettivo è quello di rendere conto della crescita organica che può essere prevalente con uno sviluppo incrementale. Rifattorizziamo anche alla fine come al solito.

Per la maggior parte queste sono le regole che seguiamo e perché le seguiamo.

Mi sembra che tu faccia parte di un team molto esperto e altamente funzionante. Congratulazioni, Scrum / Agile sta sostanzialmente formalizzando ciò che la tua squadra ha intuito per tutto questo tempo.

Penso che ciò che potrebbe essere a vantaggio della tua (intera) azienda è l'adozione di Scrum come "terreno comune", non tra i membri del tuo team di sviluppo, ma tra il tuo team di sviluppo e il dipartimento aziendale in generale .

Mentre Scrum Sprint è in timebox, i team possono scegliere tra le raccomandazioni che vanno da due settimane a 1 mese. Meno e ci sarebbero troppe recensioni e retrospettive, e più potrebbero ostacolare la capacità dell'azienda di cambiare direzione entro un anno. Sembra che tu abbia trovato il tuo punto debole di 1 mese, quindi spingi per quello.

C'è un sacco di margine per modificare i parametri Scrum e sono sicuro che puoi spiegare alla tua attività che stai ancora facendo Scrum nel modo giusto. Un aspetto positivo è che se si incontra l'attività a metà strada, il loro coinvolgimento può fornire supporto positivo.