Scrum crea costi aggiuntivi per i progetti in cui i requisiti non cambiano?

Sto leggendo la Scrum - Una guida tascabile di Gunther Verheyen e dice:

Il rapporto Chaos del 2011 del Gruppo Standish segna una svolta. Sono state condotte ricerche approfondite nel confronto tra progetti tradizionali e progetti che utilizzavano metodi Agile. Il rapporto mostra che un approccio Agile allo sviluppo del software produce un rendimento molto più elevato, anche contro le vecchie aspettative che il software deve essere consegnato in tempo, budget e con tutti gli scopi promessi. Il rapporto mostra che i progetti Agile hanno avuto un successo tre volte superiore e tre volte meno progetti Agile falliti rispetto ai progetti tradizionali.

Quindi ho una discussione con uno dei miei colleghi che afferma che per alcuni progetti (come medicina / militari in cui i requisiti non cambiano), Agile (e, in particolare, Scrum) è sovraccarico di tutte le riunioni ecc. Ed è più logico per usare la cascata, per esempio.

Il mio punto di vista è che Scrum dovrebbe essere adottato in tali progetti perché renderà il processo più trasparente e aumenterà la produttività di una squadra. Penso anche che gli eventi Scrum non impiegheranno molto tempo se non è necessario perché non abbiamo bisogno di rimanere per 8 ore intere in Sprint Planning per uno sprint di 1 mese. Possiamo risparmiare 5 minuti solo per essere sicuri di essere tutti sulla stessa pagina e iniziare a lavorare.

Quindi, Scrum creerà un sovraccarico aggiuntivo per un progetto in cui i requisiti non cambiano?

Credo che sia un presupposto errato affermare che ci sono progetti in cui i requisiti non cambiano. Avendo lavorato sia nell'industria della difesa che nell'industria farmaceutica nella creazione di software, posso dirti che una volta che il software finisce nelle mani di esperti in materia (interni o esterni), c'è un feedback. A volte, questo feedback è sul modo in cui il requisito è stato soddisfatto e in altri casi è effettivamente sul fatto che i requisiti stessi siano errati o incompleti.

L'agilità consiste nel ridurre quel ciclo di feedback e ottenere il software di lavoro nelle mani di qualcuno più velocemente, ottenere quel feedback e decidere quale dovrebbe essere il passo successivo per assicurarsi che ciò che viene consegnato aggiunga valore quando il cliente decide di accettare il software. Anche in regni come i sistemi embedded con hardware personalizzato (come è possibile trovare in domini come dispositivi aerospaziali, automobilistici o medici), fornire rapidamente sottili sezioni di funzionalità da integrare e prototipare può aiutare a garantire che il software e il sistema hardware stiano per lavorare come previsto e in modo tale da aiutare l'utente finale.

La riduzione della durata del ciclo di feedback è un fattore determinante nella riduzione del rischio. Dal punto di vista della gestione del progetto, se si finanzia un progetto per 2-4 settimane e si ottiene una visibilità regolare sullo stato di avanzamento, ciò garantisce che si è sulla buona strada. Potendo fornire sottili sezioni di funzionalità, lavori in modo incrementale verso lo stato target e puoi iniziare a prevedere quando ci arriverai. Se il tempo diventa un vincolo, è possibile declassare le funzioni di valore inferiore poiché il lavoro svolto per primo dovrebbe essere una funzione di alto valore o un attivatore per una funzione di alto valore. In qualsiasi momento, puoi decidere se vale la pena continuare a finanziare lo sforzo o andare in una direzione diversa e interrompere un progetto prima che sia troppo tardi.

La risposta molto breve è che sì, Scrum è un approccio più costoso dal punto di vista della progettazione, ma se lo chiami un progetto, quasi sicuramente non ha importanza e alla fine si tradurrà quasi sempre in un ROI migliore.

La risposta più completa è questa:

In generale, esistono tre forme di controllo di processo: controllo di processo definito, controllo di processo statistico e controllo di processo imperiale. Il controllo di processo definito è di gran lunga il più economico. Ciò è possibile grazie al lavoro ripetibile di frequente che è stato perfezionato nel tempo per trovare il modo "migliore" di eseguire il lavoro. CI / CD nello sviluppo del software rientra in questa categoria. Non vuoi variazioni nel tuo processo di compilazione, quindi standardizzi il processo, adattalo finché non sei soddisfatto, quindi automatizzalo. Tale processo automatizzato è ovviamente molto meno costoso da eseguire rispetto al combattimento manuale attraverso una distribuzione.

Il controllo statistico dei processi è il successivo meno costoso, ma tiene conto delle variazioni di un processo noto. Le procedure mediche che vanno secondo i piani rientrano in questa categoria. Non voglio reinventare un intervento chirurgico di bypass ogni volta. Seguo il processo di base e mi adeguo alle variazioni. Questo ha un carico cognitivo relativamente basso e un tasso di successo abbastanza alto.

Il prossimo è Empirical Process Control, che è di gran lunga il più costoso perché devi scoprire il processo mentre procedi. L'apprendimento è incredibilmente alto, ma al prezzo di produttività ed efficienza. Tuttavia, quasi tutto il lavoro di progetto lo richiede perché in precedenza sono stati realizzati pochi progetti. Ci sono, ovviamente, eccezioni. L'impostazione di un grande ambiente di directory attive è più statistico perché si lavora con alcune istruzioni provate e vere che si discostano leggermente dalle circostanze. Ma a meno che il tuo progetto non sia quello di fare esattamente il lavoro che è stato fatto in precedenza, quasi sicuramente richiede Emperical Process Control.

Per riportarlo su Scrum, Scrum è progettato per risolvere problemi con il controllo del processo imperiale. Pertanto, sì, ha più costi generali di altri approcci. Tuttavia, poiché la maggior parte dei progetti richiede questo approccio, è un argomento controverso.

In contrapposizione alla medicina e ai progetti militari, sembra una logica imperfetta. Se stai eseguendo un ordine per 500 aeroplani, allora sì, stai ricreando qualcosa esattamente e Scrum probabilmente non è vantaggioso. Se stai costruendo un nuovo aereo e le tue esigenze non cambiano mai, non volerei quell'aereo.

Certo, se hai un progetto in cui hai requisiti cristallini in anticipo, allora potresti scaricarli precipitosamente di fronte agli sviluppatori e tornare due anni dopo per incontrare il software dei tuoi sogni.

Ma la stragrande maggioranza dei progetti software non è così.

Di solito, il cliente non sa di cosa ha bisogno. Non sono in grado di fornire requisiti completi e specifici. Gli approcci iterativi aiutano qui: costruisci una piccola cosa, quindi chiedi al cliente un feedback. Sì, questo "spreco" di tempo in demo e pianificazione della prossima iterazione. Ma costruire la cosa sbagliata per uno sprint e quindi correggere rapidamente i requisiti è molto meglio che costruire la cosa sbagliata per l'intero progetto. Vale a dire, mentre i requisiti iniziali possono consentire uno sviluppo più efficiente , gli approcci iterativi saranno più efficaci .

Gli sviluppatori devono comprendere correttamente i requisiti per sviluppare software utile. Qual è un buon modo per scoprire incomprensioni prima che sia troppo tardi? Ancora una volta, gli approcci iterativi possono aiutare. Ma è anche importante che gli sviluppatori stessi collaborino con il cliente invece di ottenere solo informazioni filtrate attraverso un autore del documento dei requisiti.

Alla fine, il mondo non si ferma durante il progetto. I sistemi esterni cambiano, le priorità cambiano, le persone cambiano. Fingere che i requisiti di un progetto software non cambierà è una cattiva idea, tranne che per i progetti brevi.

Tutti questi vantaggi a livello di processo mancano il grande vantaggio quotidiano degli approcci agili: se fatti correttamente, l'agile rende tutti più felici. Il più grande di questi è che le tecniche agili si concentrano sulla fornitura di valore reale in tempi brevi. Ciò porta visibilità nel processo di sviluppo, offre alle parti interessate un ragionevole livello di controllo sul progetto ed è molto più motivante che lavorare per un obiettivo distante. A ciò si collega l'idea che i team agili saranno in gran parte auto-organizzati. Sentirsi in controllo del proprio lavoro quotidiano fa sentire le persone apprezzate e quindi più propensi a dare il meglio.

Il tuo collega non ha torto sul fatto che i progetti in stile cascata possano avere il loro posto. E non sbagli che alcune pratiche agili possono essere rituali che fanno perdere tempo. Ma è completamente sciocco ignorare i benefici di approcci agili e iterativi, in particolare una migliore gestione del rischio e rispetto per gli individui. Queste sono le cose che vuoi in ogni progetto. Se necessario, un team può provare a implementare parte di questo internamente, ma i processi funzionano meglio quando tutti sono a bordo.

Penso che questo possa parafrasare quello che sta dicendo @Cort Ammon, ma ecco la mia opinione:

I requisiti esterni (che descrivono i "risultati finali") non sono gli unici requisiti in un progetto. Anche se i requisiti esterni non cambiano, i requisiti "interni" cambieranno o dovranno essere autorizzati a cambiare mentre lavori. Gli sviluppatori scopriranno ostacoli o problemi con un approccio e questo influenzerà il lavoro delle altre persone nel team. Uno stand-up quotidiano terrà tutti aggiornati con questi cambiamenti interni.

Considera che:

• Anche con requisiti funzionali fissi è necessario tradurli in requisiti tecnici. E questo può essere fatto meglio dalle iterazioni. Potresti scoprire modi migliori per risolvere il problema nel mezzo del progetto.

• Alcuni requisiti possono essere troppo generici o ambigui: "essere facile da usare", "essere sicuro". È difficile analizzare la sicurezza o l'usabilità di un sistema che non è finito. Alcuni possono avere implicazioni nascoste o potrebbero non essere ben compresi.

• Alcuni requisiti potrebbero essere migliorati. Rispondere in 200ms potrebbe essere buono ma 100 potrebbe essere migliore. Puoi scegliere come target il miglior risultato possibile ma sacrificarlo se necessario durante il progetto.

• Potresti scoprire alcuni requisiti nascosti che non saranno scritti sul contratto ma potrebbero cambiare il progetto da fallimento a successo. Anche se consegnate il progetto, il cliente potrebbe non essere felice. Potrebbe anche essere necessario modificare il contratto per aggiungere (e addebitare) nuove funzionalità che è possibile progettare nel progetto in modo più economico nelle prime fasi.

• Potresti scoprire che non puoi soddisfare i tuoi requisiti in un determinato momento. Non è come se i progetti software non arrivassero mai in ritardo. Pertanto, fornire il miglior valore ti consentirà di rinegoziare le funzionalità da eliminare.

• Fornire qualcosa in anticipo aiuterà l'integrazione e mostrerà che questo progetto può fornire risultati.

Si può sostenere che, se tutti i requisiti sono definiti perfettamente, esiste un approccio dall'alto verso il basso che raggiunge tali requisiti il ​​più rapidamente possibile. Tuttavia, se questi sono buoni requisiti, ti dicono cosa fare, non come farlo. Se ti dicessero come farlo, sceglierei di chiamarlo "istruzioni di lavoro" anziché "requisiti" e discuteremo di un diverso tipo di problema.

Di conseguenza, esiste sempre un processo di sviluppo del "come" che è interno all'azienda o al team che implementa i requisiti. Dal punto di vista empirico, ci affidiamo fortemente a un approccio gerarchico in cui un team di progettisti progetta il sistema di alto livello per soddisfare tali requisiti e quindi utilizza le specifiche di quel sistema di alto livello per fornire "requisiti" ai team più piccoli che perfezionano i nostri dettagli.

Nel processo a cascata, questo può essere visto nella freccia unidirezionale tra progettazione e realizzazione. Tuttavia, questi requisiti non sono fissati nella pietra, come quelli forniti dal cliente. Questi sono definiti internamente e hanno spazio per il processo iterativo. In pratica, scopriamo che i progettisti mettono un margine considerevole nel processo per spiegare questa mancanza di iterazione o cercano un processo iterativo.

SCRUM e molti altri metodi agili correlati forniscono semplicemente un quadro rigoroso all'interno del quale eseguire questo processo iterativo. Un marchio di fabbrica degli approcci agili è che considerano l'ottimizzazione di questo modello iterativo come il cuore del processo, piuttosto che concentrarsi sullo strato esterno di requisiti difficili. Come altri hanno già detto, i requisiti fissi effettivi sono rari, ma anche in loro presenza, SCRUM utilizza l'approccio iterativo come metodologia per controllare l'approccio contrattuale al suo interno.

Se riesca a farlo è una questione di dibattito aperto. Altri hanno fornito molte metriche a tal fine. Noterò semplicemente che spetta alla forza della leadership assicurarsi che le iterazioni che si verificano al di sotto di esse si inseriscano correttamente nel sistema contrattuale di cui sopra. Questo è vero con qualsiasi approccio allo sviluppo, ma è più visibile negli approcci agili perché siamo stati sollevati per assumere che l'approccio più dall'alto verso il basso sia "normale" e leader addestrati in quanto tali.