È agile riguardo allo sviluppo o alla gestione?

In un dibattito su cosa sia Scrum, ho scoperto che forse ho completamente frainteso la cosa agile. Mi sembra che Scrum (che è certamente considerato un processo Agile) si occupa della gestione di funzionalità e sprint e ruoli e cose senza nulla a che fare con TDD, programmazione di coppie, CI, refactoring e altre tecniche e pratiche incentrate sullo sviluppatore che ho pensato fino ad ora) sono il cuore dell'agile. Ora sto affrontando una difficoltà!

1) Scrum è agnostico sul fatto che gli sviluppatori facciano pratiche agili?

2) Puoi implementare Scrum in un team che non utilizza test automatici? non esegue refactoring o non aderisce alle pratiche di programmazione agile?

È un errore comune pensare che Scrum sia uguale ad Agile.

Essere Agili sta seguendo i quattro principi del Manifesto Agile . Scrum è un processo di gestione del progetto coerente con tali principi, ma non è di per sé Agile. XP (TDD, programmazione in coppia) è un processo di sviluppo, anch'esso coerente con questi principi e coerente con Scrum, ma non è Agile. Integrazione continua, consegna continua, DevOps, tutti coerenti con i principi Agile.

Segui i principi, prima di tutto. Tutte queste frasi d'ordine sono solo metodologie che le persone hanno trovato con successo per aiutarle a seguire i principi. Ma la parte principale di "essere Agili" è essere in grado di adattare i tuoi processi a piacimento dove non seguono i principi di Agile.

Scrum è agnostico sul fatto che gli sviluppatori facciano pratiche agili?

Scrum è un insieme di linee guida che incoraggiano una squadra ad essere agile.

Puoi implementare Scrum in un team che non utilizza test automatici? non esegue refactoring o non aderisce alle pratiche di programmazione agile?

Molto difficile, perché alla fine di ogni sprint devi avere un prodotto funzionante. Se è necessario eseguire un test di regressione manuale completo per dimostrare che funziona, è probabile che ciò sia irrealizzabile.

Alistair Cockburn (uno dei creatori del movimento Agile) dice questo su Crystal Clear (un aspetto della sua metodologia Agile):

Crystal Clear può essere descritto a un ascoltatore di livello 3 con le seguenti parole:

“Metti 4-6 persone in una stanza con postazioni di lavoro e lavagne e accesso agli utenti. Invitali a consegnare agli utenti software in esecuzione e testati ogni uno o due mesi, altrimenti lasciali soli. "

Questa è una definizione di agile, certamente per il personale di sviluppo con esperienza che sa cosa sta facendo e di cui ci si può fidare per andare avanti e farlo. Quindi significa che si deve usare CI e TDD e coppia di programmazione e tutte le altre cose alla moda? In parole povere ... No.

Agile non si tratta di seguire una serie di processi, ma di essere efficace. Cosa significa per te dipende dal tuo team e da come funziona, cosa ritieni utile. Se TDD non ti aiuta a produrre codice funzionante, smetti di ascoltare le luci minori che lo gridano sul web e non usarlo! Se la programmazione in coppia aiuta davvero la tua squadra a concentrarsi e a fare cose, allora ignora chiunque dica che è una perdita di tempo e organizza la tua squadra come una gara a 3 zampe durante la giornata sportiva della scuola.

Sono stato agile molti anni fa, così tanti che non ci siamo nemmeno resi conto che stessimo agendo: abbiamo consegnato iterazioni del prodotto ogni mese, e abbiamo corretto ciclicamente i bug correndo e aggiungendo nuove funzionalità regolarmente. Abbiamo fatto assolutamente zero unit test in quanto tali cose non erano state inventate e il libro di refactoring non era stato scritto. Quindi sì, puoi assolutamente fare agile senza nessuna delle cosiddette pratiche agili.

Alistair dice anche questo di Kent Beck:

Alla domanda su XP e sui cinque livelli del "Capability Maturity Model" del Software Engineering Institute, ha risposto con i tre livelli di maturità di XP:

1. Fai tutto come scritto.

2. Dopo averlo fatto, sperimenta le variazioni delle regole.

3. Alla fine, non importa se stai facendo XP o no.

Alla fine, non importa se stai facendo XP o no ... parole sagge che dovrebbero ricordare di non cadere in questa trappola .

Scrum è un sapore agile che segue uno schema specifico per raggiungere gli obiettivi della metodologia di sviluppo agile. Non puoi seguire Scrum e non essere agile, ma puoi essere agile e non seguire Scrum.

Scrum non ha alcun rapporto con l'uso di test automatizzati, l'agile tende a favorirli ma non lo sono affatto. Il refactoring dovrebbe essere un obiettivo in Agile e Scrum, ma spesso viene ignorato. non avere alcuna intenzione di refactoring non è davvero agile.

È agile riguardo allo sviluppo o alla gestione?

Agile è un insieme di pratiche di sviluppo software per soddisfare la flessibilità e le esigenze del mercato che cambiano rapidamente fase o la cosiddetta consegna accelerata . Quindi, in una visione d'insieme, si tratta di un approccio flessibile per soddisfare le mutevoli esigenze complesse del cliente suddividendo il lavoro in piccole parti e offrendo funzionalità in iterazioni rapide di 2-4 settimane.

Tuttavia, per soddisfare questa flessibilità, il team di sviluppo deve praticare pratiche di programmazione Agile .

Descrizione da Wiki in merito allo sviluppo di software Agile :

Lo sviluppo software agile è un gruppo di metodi di sviluppo software basati sullo sviluppo iterativo e incrementale, in cui i requisiti e le soluzioni evolvono attraverso la collaborazione tra team auto-organizzanti e interfunzionali. Promuove la pianificazione adattiva, lo sviluppo e la consegna evolutivi, un approccio iterativo prestabilito e incoraggia una risposta rapida e flessibile ai cambiamenti. È un quadro concettuale che promuove le interazioni previste durante il ciclo di sviluppo.

Infatti, puoi usare la mischia in progetti che non hanno nulla a che fare con lo sviluppo del software. È un metodo di gestione del progetto / team management.

1) NO !!!! Scrum è Agile, il che significa che le pratiche di sviluppo agile (TDD, programmazione di coppie, CI, refactoring, ecc.) Sono molto importanti per tutti gli aspetti di un progetto Scrum. Sarà molto più difficile capire la frequenza dei tuoi team, stimare il lavoro, impostare le dimensioni appropriate dello sprint, ecc. Se non stai usando queste pratiche.

2) Sì, puoi implementare Scrum in una squadra che non aderisce a pratiche agili, ma sento che limita davvero il potenziale della squadra. Una grande parte del motivo per cui Scrum / Agile ha così tanto successo sono le prestazioni e i guadagni di qualità che si ottengono dalle pratiche di sviluppo Agile, che sono fondamentali per offrire funzionalità complete fronte-retro ad ogni scatto.

Se qualcun altro nel tuo gruppo sta cercando di convincerti che le pratiche di sviluppo Agile sono una perdita di tempo, penso che dovresti dedicare un po 'di tempo per sottolineare perché queste pratiche sono sempre stressate con Scrum e Agile nel suo insieme. Fanno davvero la differenza.