Gli sprechi dei progetti software hanno un costo $1miliardo al giorno nelle aziende e nei governi di tutto il mondo che svolgono un lavoro completamente inutile.
Ogni giorno i team software di tutto il mondo sprecano 30-60% del loro tempo (e tempo e denaro del datore di lavoro) a causa di pratiche inefficienti. La maggior parte di questi sprechi è evitabile. In qualsiasi momento, ogni membro del team può svolgere un lavoro utile ma, il lavoro che stanno svolgendo avrebbe potuto essere evitato. Nella maggior parte dei casi i manager non sono consapevoli di ciò che sta accadendo.
Questo articolo esamina alcune delle principali cause di spreco nel lavoro del software. Cominciamo esaminando le attività dispendiose dei team software. Chiunque abbia lavorato su un progetto software ne avrà sperimentati diversi.
Sforzo e tempo sono spesso sprecati dai team software:
- rivisitare funzionalità mal progettate degli sprint precedenti,
- comprendere e rielaborare il codice scarsamente strutturato di altri sviluppatori negli sprint precedenti,
- affrontare i malintesi perché l'autore del requisito non ha garantito che i requisiti fossero chiari in modo tale che tutti i lettori (utenti, architetti, sviluppatori, tester) raggiungessero una comprensione comune,
- fare rielaborazioni perché l'autore del requisito non ha capito cosa fosse effettivamente necessario,
- scrivere test manuali o automatizzati rispetto a requisiti che successivamente si rivelano errati,
- modificare o eliminare il codice errato perché i requisiti erano scadenti,
- rielaborazione o lavoro extra perché è stata scelta una struttura dati inadeguata, forse perché i requisiti erano incoerenti,
- implementare requisiti a bassa priorità perché non veniva preso in considerazione o non era disponibile un quadro più completo dell’intero insieme di requisiti.
- rielaborazione del codice a causa dell'uso del linguaggio incoerente e non strutturato nei requisiti,
- correggere e testare nuovamente bug che sarebbero stati evitabili se i requisiti e i progetti fossero stati più chiari,
- scrivere criteri di accettazione dettagliati inappropriati dei requisiti privi di una descrizione di base,
- cambio di attività causato da rilavorazioni dovute a requisiti o progetti inadeguati. (il contrario di “fallo bene e fallo una volta”)
- partecipare a riunioni di valutazione (story point) che sono principalmente dedicate alla scoperta del significato dei requisiti, perché i requisiti non sono chiari,
- lavorare su progetti che vengono successivamente annullati perché il progetto ha superato il budget e la tempistica, perché la conoscenza dell'ambito generale era scarsa o incompleta all'inizio
Si parla molto di pratiche snelle da parte dei team software, che riguardano l'eliminazione degli sprechi. Eppure è raro trovare team che esaminino attentamente la fonte effettiva e l’entità degli sprechi, ne determinino l’impatto sul progresso e stabiliscano come potrebbero essere evitati in futuro. La maggior parte dei team è impegnata in alcune o molte delle attività dispendiose di cui sopra. L'impatto accumulato è in media di circa 40-50% di tutto il lavoro svolto dai team software. E la maggior parte di questo è evitabile.
Sforzo sprecato nel lavoro sulla conoscenza
Lo sforzo sprecato nella conoscenza è comune ed è sostanziale. Ad esempio, modificare il codice che è già stabile è molto costoso perché esso, e tutte le funzionalità che lo circondano, devono essere riconsiderati e testati nuovamente. Il nuovo test è necessario per garantire che il cambiamento non abbia introdotto effetti negativi. Una modifica del codice di una riga può richiedere il nuovo test di migliaia di righe di codice correlato. Il Test Driven Development (TDD) è una tecnica che aiuta ad alleviare questo problema, ma non lo previene, né individua tutti i possibili difetti.
Nei progetti con team più grandi, il lavoro di una persona dipende dal lavoro precedente di qualcun altro. Prima di apportare modifiche al codice, uno sviluppatore deve capire cosa ha scritto il suo predecessore, quindi capire dove altro è stato utilizzato, quindi finalmente può iniziare ad apportare le modifiche desiderate. Lo stesso vale per requisiti, progetti e test. IL pre-modifica apprendimento possono volerci ore o addirittura giorni. Quella che sembra una modifica minore può diventare sproporzionatamente molto costosa.
Saltare da un pezzo di codice a quello successivo implica il cambio di contesto. Per far sì che la conoscenza funzioni bene, dobbiamo concentrarci ed evitare cambiamenti di contesto. La correzione dei bug implica un cambio di contesto maggiore rispetto alla scrittura del codice in primo luogo. Il cambio di contesto è completamente dispendioso. La combinazione di riapprendimento e cambio di contesto spiega in qualche modo come una piccola modifica al codice possa essere straordinariamente costosa. Idealmente vogliamo modificare un metodo il minor numero di volte possibile oltre lo sprint in cui è stato creato.
I team misurano i veri sprechi?
In generale no, non lo fanno. Esatto, $1Bn al giorno vengono sprecati da aziende e governi di tutto il mondo e pochissimi lo misurano. Questi rifiuti non si ridurranno o scompariranno magicamente da soli, è necessario un lavoro proattivo.
L’analisi delle cause profonde può essere utile per identificare dove, perché e quanti sprechi vengono generati. Prima di considerare un lavoro software imminente che richiede una modifica o una correzione del codice esistente, dovremmo porci alcune domande importanti, ecco un elenco non esaustivo:
- Questo requisito o cambiamento avrebbe potuto essere previsto o ragionevolmente anticipato?
- Come avremmo potuto saperlo prima in modo da evitare di dover modificare il codice esistente? Si poteva evitare del tutto questo cambiamento?
- Quanto impegno aggiuntivo e durata estesa sono causati dall'esecuzione di questa modifica ora rispetto a se l'avessimo affrontata quando il codice è stato scritto per la prima volta.
- Quanto tempo e impegno extra verranno dedicati ai test di regressione come risultato di questo cambiamento?
- Qual è l'effetto a catena di apportare questo cambiamento ora rispetto a se lo avessimo fatto prima?
- Questa modifica introduce nuove prestazioni o rischi per la sicurezza sul codice precedentemente distribuito (introduce una correzione errata)?
- Questo cambiamento è espresso in termini inequivocabili in modo tale che qualsiasi lettore possa capirlo.
La causa principale più comune
La causa principale della maggior parte di questi sprechi è lo scarso lavoro svolto nelle prime fasi del ciclo di vita del software. Requisiti scadenti funzionano, decisioni affrettate sull'architettura, opzioni di soluzione sciatte funzionano o lavoro di progettazione.
La maggior parte dei team software raramente considera l'effettivo impatto dei difetti dei requisiti sulla produttività e sugli sprechi da essi causati. Inoltre, potrebbero trascurare il costo di decisioni di progettazione inadeguate fino a molto tempo dopo l'implementazione del progetto. Questo viene etichettato come debito tecnico.
Requisiti poco chiari implementati con una progettazione scadente e poco flessibile possono portare a costi di rilavorazione straordinari. Questo costo di rilavorazione può quindi essere reso ancora più elevato se provoca un ritardo in altri lavori correlati e non correlati. In alcuni casi, e molto spesso nei progetti più grandi, requisiti scadenti e decisioni di progettazione inadeguate possono portare alla demolizione di un intero progetto.
I difetti dei requisiti scoperti tardi sono solitamente il tipo di difetto più costoso da correggere.
A livello globale vengono spesi circa $720 miliardi all'anno in attività software aziendali. Circa la metà di queste sono rilavorazioni evitabili e causate da requisiti inadeguati, decisioni di progettazione inadeguate e dalle conseguenze di entrambi. A livello globale si tratta di circa $360 miliardi all’anno o circa $1 miliardi al giorno.
Che dire dell'Agile?
Agile non cura gli sprechi che abbiamo descritto qui. Il vantaggio principale delle metodologie di sviluppo software Agile è un rapido ciclo di feedback tra utenti e sviluppatori. Vediamo che in molti casi l’adozione di Agile porta con sé un calo della qualità e della diligenza dei requisiti e di altro lavoro di precodifica. Le organizzazioni hanno fretta di offrire nuove funzionalità basate su software. Coloro che sono coinvolti nello svolgimento del lavoro presentano un approccio “adattarsi man mano che procediamo”, che sembra attraente. Se eseguite bene, le pratiche Agile aiutano a garantire che il cliente ottenga qualcosa che desidera, ma se accompagnate da un lavoro di precodifica sciatto, i risultati sono livelli significativi di rielaborazione durante il progetto e un aumento degli sforzi sprecati.
I dati provenienti da migliaia di progetti mostrano che ci sono tanti difetti introdotti prima della codifica quanti durante la codifica.[io] Questo è noto come potenziale di difetto. 16% – 35% tutti i difetti di produzione sono causati da requisiti scarsi o incompleti.[ii]
Pochi team software considerano attentamente che i requisiti e i difetti di progettazione sono la causa principale di così tanti sforzi sprecati. Non è possibile svilupparsi finché non si ha un'idea dei requisiti. In altre parole, lo sviluppo segue i requisiti. Un requisito scarsamente studiato o mal espresso può portare un intero team a svolgere giorni o settimane di lavoro sprecato. Spesso questo tipo di spreco viene liquidato come “apprendimento” o “evoluzione dei requisiti degli utenti” quando in realtà non è né l’uno né l’altro, si tratta di un lavoro con requisiti inferiori agli standard. Esistono diversi motivi per cui i requisiti potrebbero essere scadenti. Uno dei motivi è che molte organizzazioni non riescono a garantire che il personale che scrive i requisiti sia adeguatamente formato ed esperto per svolgere un lavoro con requisiti di alta qualità. Un altro motivo è che c’è poco accordo e coerenza nel settore su ciò che costituisce un buon requisito.
Altre cause comuni di spreco di progetti software
Abbiamo menzionato lo scarso lavoro precedente e il cambio di contesto come principali cause di spreco, alcune altre cause comuni includono:
- sprechi causati da una scarsa leadership,
- sprechi causati da bassi livelli di abilità, che portano a maggiori rielaborazioni e bug
- sprechi derivanti dal seguire processi che sembrano aggiungere valore ma non lo fanno,
- non seguire buoni processi che aggiungono valore ma forse non sono alla moda,
- spreco di comunicazione a causa delle dimensioni eccessive del team,
I requisiti software sono spesso di scarsa qualità
I requisiti software e le storie degli utenti sono spesso di scarsa qualità. Forse l'autore non è sufficientemente qualificato o esperto. Forse non hanno accesso alle informazioni di cui hanno bisogno. Il problema con quasi tutti i requisiti è che sono scritti in un linguaggio naturale non vincolato. Di solito gli autori non hanno una formazione formale sui requisiti di qualità della scrittura. Il linguaggio naturale non vincolato non è il mezzo ideale per comunicare i requisiti software, ma è quello che utilizziamo maggiormente. La maggior parte delle organizzazioni non gestisce la qualità dei requisiti.
Noi di Scopemaster abbiamo analizzato oltre 300.000 requisiti provenienti da centinaia di progetti software in diversi paesi e settori. Ciò che abbiamo scoperto è che:
- In media un requisito (o user story) è composto da 12 parole (esclusi i criteri di accettazione). E in media ogni parola corrisponderà a 125 parole di codifica, o token scritti. Pertanto possiamo dire che un errore con una singola parola di un requisito potrebbe portare alla necessità di riscrivere 125 parole di codifica. Questi numeri non devono essere utilizzati come base per la stima, ma indicano quanto è importante ciascuna parola di un requisito.
- In media vediamo 4-8 problemi per ogni requisito. Questi problemi variano in gravità ma, a meno che non vengano risolti in anticipo, ciascuno causerà, o è probabile che causi, un bug del software.
I difetti dei requisiti comuni includono:
- Non orientato all'utente
- Incoerente
- Non chiaro
- Non testabile
- Indimensionabile
- Contenuto tecnico eccessivo
- Duplicato
- Mancante
- Non prezioso
- Troppo prolisso
La maggior parte dei lettori interpreterà diversamente un requisito scritto. Se la differenza di interpretazione non è banale, è probabile che porti a un bug del software. Se il bug non viene identificato se non in un secondo momento, è stato fatto molto lavoro che dovrà essere rifatto per risolverlo. Fare le cose bene la prima volta, o trovare i difetti in anticipo, è davvero importante.
Attributi di qualità di buoni requisiti software
Esistono varie fonti e opinioni su ciò che costituisce un requisito di buona qualità. C'è un ottimo lavoro da parte di IEEE e rivisitano regolarmente questo argomento. Esiste un elenco di attributi comunemente adottato, anche se a nostro avviso carente, spesso promosso da vari allenatori agili, incapsulato nell’INVEST pneumonic.
Ecco il nostro elenco di attributi di qualità dei requisiti.
Il controllo di ciascun requisito affronta bene tutti gli aspetti di cui sopra, è un lavoro piuttosto noioso, ma necessario se si desidera ridurre al minimo gli sprechi. Per fortuna, strumenti come ScopeMaster ora possono fare la parte del leone nel garantire la qualità di questi requisiti per te.
Altre forme di rifiuti di progetti software
Grazie a Todd Sedano per la sua immagine molto utile all'inizio di questo articolo che mostra le forme più comuni di spreco di progetti software. Abbiamo trattato i primi tre in dettaglio ora poiché sono le principali cause profonde degli sprechi dei progetti. Vediamo gli altri:
Soluzioni inutilmente complesse
Debito tecnico, integrazioni complesse, mescolanza di linguaggi, regole aziendali complesse e architetture software inadeguate portano tutti a soluzioni eccessivamente complesse, che comportano una perdita di tempo nella rielaborazione, nella scoperta di come funzionano i sistemi e nel garantire che l'introduzione di modifiche non causi risultati indesiderati. ovvero una buona architettura porta ad una flessibilità efficiente.
Carico cognitivo estraneo
Gli sprechi dei progetti software sono talvolta causati dall'offerta a sviluppatori e progettisti di distrazioni e vincoli aggiuntivi. I progetti di successo proteggeranno sviluppatori, tester e progettisti da tutto ciò di cui non devono preoccuparsi.
Disagio psicologico
Questa causa di spreco tende ad essere meno comune o causata da pressioni esterne o, in alcuni rari casi, da una gestione molto inadeguata.
Perdita di conoscenza
In ambienti di sistemi grandi o complessi, la continuità del personale aiuta a conservare la conoscenza. Se gli esperti se ne vanno, potrebbero essere necessarie settimane o mesi di apprendimento per raggiungere il livello del personale in partenza.
Multitasking/attesa
I progetti software sprecano tempo e fatica nel cambiare attività (un risultato del multitasking). Spesso possono essere necessari 20-50 minuti affinché uno sviluppatore torni al punto in cui si trovava prima che una distrazione interrompesse il corso dei suoi pensieri.
Comunicazione inefficace
Abbiamo ampiamente coperto questo aspetto con scarsi requisiti. Ma a volte la comunicazione su altri progetti viene gestita in modo inadeguato, ad esempio se i dirigenti non riescono a fornire indicazioni chiare su ciò che è importante per l'azienda.
Evitare gli sprechi
Per evitare questo spreco abbiamo solo bisogno di un migliore lavoro sui requisiti e di una migliore progettazione. È così semplice? SÌ.
Se si scrivono requisiti migliori che comunichino in modo chiaro e coerente a tutti i lettori, e poi si dedica tempo adeguato per garantire che le opzioni di progettazione siano attentamente considerate, i progetti siano rivisti e ottimizzati prima della codifica, accadranno cose buone e gli sprechi saranno minimi.
Raramente viene posta un'adeguata attenzione alla qualità dei requisiti. Inoltre, molti approcci, framework e tendenze Agile stanno minando metodi comprovati ed efficienti per fornire software di alta qualità al primo tentativo. Requisiti di qualità e qualità del design Potere essere misurati, monitorati e migliorati, ma raramente lo sono.
I team hanno bisogno di aiuto per risolvere questo problema
Scrivere buoni requisiti non è facile, richiede formazione ed esperienza. Molti team hanno un proprietario del prodotto che è un esperto in materia o un laureato esperto, potrebbe conoscere l'attività ma non come scrivere requisiti di buona qualità. Ecco alcuni motivi per cui questo problema rimane in gran parte irrisolto:
1. C’è poca ricompensa lavorativa per aver messo in discussione la qualità dei requisiti
2. Se i requisiti sono scarsi e devi costruirlo due volte, vieni pagato di più
3. Gli autori dei requisiti raramente hanno una conoscenza approfondita delle esigenze degli utenti, dei sistemi esistenti e di come scrivere buoni requisiti.
4. Spesso gli autori dei requisiti sono gli sviluppatori che scrivono attività di sviluppo ricche di termini tecnici, requisiti utente non facilmente comprensibili che possono essere compresi da tutti.
5. I team raramente limitano il linguaggio dei requisiti a quello che consente di ottenere intese comuni costantemente chiare.
6. Il team fa affidamento sulla discussione come mezzo per chiarire i malintesi. Le discussioni spesso non sono documentate.
7. Esiste un'ampia variabilità nelle opinioni su ciò che costituisce una buona qualità dei requisiti.
2022 e l'automazione/intelligenza artificiale vengono in soccorso
Stanno emergendo strumenti che possono aiutare con la garanzia della qualità dei requisiti (QA). I fornitori di strumenti di gestione dei requisiti stanno lavorando su nuove funzionalità per aiutare con alcuni aspetti del QA dei requisiti. IBM Doors, Jama Connect, Visulutions e ScopeMaster ne sono esempi. Il nostro strumento ScopeMaster è lo strumento più avanzato disponibile che risolve i problemi descritti in questo documento. Automatizza il QA dei requisiti nelle prime fasi del ciclo di vita del software. È come un analizzatore statico dei requisiti; lo fa per i requisiti cosa SonarQube fa per il codice.
ScopeMaster e alcuni altri strumenti utilizzano l'elaborazione del linguaggio naturale e altre tecniche analitiche per interpretare e testare i requisiti. ScopeMaster guida l'autore dei requisiti a migliorare la qualità dei requisiti a velocità e completezza finora impossibili. (ScopeMaster eseguirà in media 100.000 test su una serie di 100 storie utente in 4 minuti). ScopeMaster in genere trova 2-4 difetti per requisito in pochi secondi.
ScopeMaster troverà circa la metà di tutti i difetti latenti in una serie di requisiti. I tipi di difetto che coprono 9 dei 10 attributi di qualità sopra indicati. Ciò può aiutare i team a innalzare molto rapidamente la qualità di una serie di requisiti a uno standard molto più elevato, contribuendo ad alleviare questo problema di $360Bn pa.
Conclusione
Se sei coinvolto in progetti software in un settore aziendale o governativo, potresti sprecare fino a 50% del tuo budget in lavori evitabili. La causa principale di gran parte di questi sprechi è la scarsa qualità dei requisiti e del lavoro di progettazione del sistema. Riconoscere che esiste un problema e che questa è la probabile causa principale è il primo passo per poterlo risolvere. Il passo successivo è introdurre un'iniziativa di miglioramento della qualità che affronti l'inizio del ciclo di vita dello sviluppo: obiettivi, requisiti, architettura e progettazione. Inizia a misurare i difetti nei requisiti e l'impatto che stanno avendo sui tuoi progressi. Riconoscere i potenziali difetti e introdurre iniziative per individuare e correggere tali difetti il prima possibile. Strumenti come ScopeMaster rappresentano un punto di svolta per la certezza del software.
Scritto da Colin Hammond, veterano IT da 37 anni e fondatore di ScopeMaster.
[io] Origini dei difetti Difetti per punto funzione Difetti dei requisiti 0,75 Difetti dell'architettura 0,15 Difetti di progettazione 1,00 Difetti del codice 1,25 Difetti del documento 0,20 Difetti di correzioni errate 0,15 Potenziale difetto totale 3,65
https://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirty-years-of-IFPUG.-Software-Economics-and-Function-Point-Metrics-Capers-Jones.pdf
[ii] Capers Jones e Accenture, gennaio 2021
Economia della qualità del software, di C Jones e Olivier Bonsignour.
