Rielaborazione su progetti software

Spiegazione della rilavorazione del software

La rilavorazione del software è il lavoro consequenziale che deriva dalla modifica di requisiti, progetti, codice e test dopo che il lavoro è già stato avviato. Nella maggior parte delle aziende software ciò rappresenta 30-50% di tutta l'attività. Generalmente escludiamo la correzione di bug dalla categoria delle rielaborazioni del software. La rilavorazione generalmente descrive il lavoro extra che è una conseguenza del “cambiamento dei requisiti”.

Rilavorazione del software: buona o cattiva

Alcune rielaborazioni possono essere viste come un indicatore positivo del fatto che il feedback degli utenti sta guidando il cambiamento verso ciò che è necessario. Ciò sarebbe giusto se i cambiamenti fossero imprevedibili. Tuttavia, i livelli tipici di rilavorazione sui progetti software sono ostinati e si aggirano intorno ai 30-50% di tutto lo sforzo. Per la maggior parte delle organizzazioni, fornire software costa molto di più di quanto dovrebbe.

Come la rilavorazione del software fa lievitare i costi

Un problema particolare con la rielaborazione del software è che è più lenta o meno produttiva rispetto allo sviluppo iniziale. In altre parole, scrivere il codice la prima volta è più veloce che alterarlo per fare qualcos'altro. Utilizzando un approccio standard alla misurazione e alla produttività del software, possiamo monitorare la produttività dei team software durante la creazione iniziale e durante la rielaborazione. Le velocità di creazione tipiche degli sviluppatori sono circa 1 Punto funzione COSMIC (CFP) al giorno (intervallo tipico: 0,7-2 CFP/giorno), mentre la produttività in caso di rilavorazione è inferiore, pari a 0,75 CFP al giorno.

Quando è necessaria una rilavorazione, sei costretto a svolgere il lavoro la prima volta (1 giorno per 1 CFP) e poi (altri 1,5 giorni per CFP) per modificarlo. Pertanto il costo totale diventa 2,5 giorni anziché 1 giorno.

Questa semplice spiegazione mostra come progetti IT modesti possano trasformarsi in disastri in termini di budget. Monitorando tempestivamente la qualità dei requisiti, la probabilità del disastro diventa prevedibile. Inoltre, prestando maggiore attenzione alla qualità dei requisiti, è possibile ridurre sostanzialmente le rilavorazioni precedenti.

Le cause profonde della rilavorazione

Quando ci rendiamo conto che qualche caratteristica che stiamo costruendo, o che abbiamo costruito, non è corretta, dobbiamo decidere se lasciarla sbagliata o correggerla. Più avanti nel ciclo di vita dello sviluppo in cui viene effettuata questa scoperta, maggiori saranno le rielaborazioni, le interruzioni e i ritardi causati. Non importa se il requisito è il risultato di una conversazione, di una user story scritta o di un documento scritto più dettagliato. L'errata o la cattiva comunicazione è la probabile causa principale della rielaborazione. Forse il requisito originale è stato frainteso, interpretato male o comunicato male, il tutto si riduce a una scarsa comunicazione. La scarsa comunicazione a volte viene liquidata o travisata come “requisiti in cambiamento” quando in realtà non lo è.

La maggior parte del cambiamento non è autentico

Molto occasionalmente assistiamo a un vero e proprio cambiamento inaspettato nelle circostanze aziendali durante un progetto che porta a requisiti modificati. Tuttavia la maggior parte dei requisiti sono noti o conoscibili in anticipo. Allo stesso modo la maggior parte delle decisioni architetturali necessarie per soddisfare tali requisiti sono conoscibili (in anticipo). A volte l'utente dice "non sappiamo di cosa abbiamo bisogno finché non lo vediamo". Per scoprire questi requisiti, è necessario utilizzare tecniche di elicitazione aggiuntive come la prototipazione.

La stragrande maggioranza delle “modifiche ai requisiti”, e quindi delle rilavorazioni, sono causate da un lavoro sui requisiti scadente o incompleto.

Alcune cause principali di rilavorazione legate ai requisiti (un elenco incompleto):

• Requisiti poco articolati
• Requisiti noti ma non dichiarati (omissioni)
• Incoerenze tra una serie di requisiti.
• Requisiti non dichiarati che potrebbero essere stati scoperti tramite la prototipazione (ovvero l'utente deve prima vedere qualcosa)
• Requisiti non dichiarati che avrebbero potuto essere scoperti attraverso l'analisi
• Confusione tra obiettivi aziendali, requisiti funzionali e criteri di accettazione. (scarsa articolazione).
• Confusione tra vincoli funzionali e non funzionali e compiti.
• E forse l'unico motivo legittimo per la rielaborazione: requisiti sconosciuti e inconoscibili

La rilavorazione rimane prevalente ad alti livelli – Motivazione

La maggior parte degli studi mostrerà che il 30-50% di tutti gli sforzi sui progetti software viene speso in rilavorazioni. Esistono diversi motivi per cui i livelli di rilavorazione rimangono elevati. Alcuni dei motivi vengono discussi raramente poiché potrebbero essere verità scomode.

Requisiti incoerenti Standard di qualità

L’industria non riesce a mettersi d’accordo su cosa renda validi i requisiti. Un'organizzazione che cerca di promuovere la qualità dei requisiti è l'IIBA. Per la maggior parte delle persone non esistono standard formali per i requisiti di scrittura e la qualità è generalmente bassa.

Evitare comunicazioni importanti

Alla maggior parte degli sviluppatori piace scrivere codice, spesso sono introversi e non grandi comunicatori. L'interazione umana potrebbe non essere così facile per loro e sono più contenti di rielaborare che di avere in anticipo quelle impegnative conversazioni sui requisiti.

Spesso i team di sviluppatori descrivono la rielaborazione come “codice di refactoring”. Potrebbero soddisfare requisiti scadenti e usare la scusa di: “siamo agili, impariamo mentre procediamo”. Oppure potrebbero dire che gli utenti non sapevano cosa volevano finché non glielo mostravamo. La prima è una scusa per “non imparare prima di partire”; quest'ultimo è un problema più economicamente superabile con la prototipazione.

Nessuna responsabilità per le storie utente valide

Le user story sono il pilastro della comunicazione di un team agile su ciò che si vuole costruire. Ma chi è responsabile delle user story? Chi è responsabile di garantire che essi descrivano correttamente un insieme olistico di bisogni che forniscono capacità preziose? Team diversi danno risposte diverse, alcuni dicono il proprietario del prodotto, altri dicono l'intero team. La mancanza di una chiara responsabilità può portare a storie degli utenti di qualità inferiore, che a loro volta portano a incomprensioni e rielaborazioni. Chi è responsabile della qualità delle storie degli utenti? Ancora una volta, otteniamo risposte incoerenti a queste domande. Rivisitare la chiarezza di una user story è un lavoro noioso che coinvolge almeno tre membri del team (i tre amigos). È un lavoro dispendioso in termini di tempo e piuttosto noioso che spesso avviene in modo ad hoc, se non altro. Idealmente, la necessità di queste sessioni viene ridotta co-localizzando il team. Con il lavoro a distanza la co-locazione è sostanzialmente impossibile. In alcuni casi il proprietario del prodotto è un rappresentante per procura dell'utente reale e un vero esperto in materia. Tutti portano a requisiti di qualità inferiori.

Contratti che aumentano i livelli di rilavorazione

Quando lo sviluppo del software è esternalizzato. La società a cui viene affidato il lavoro viene generalmente pagata su base giornaliera. Per loro più giorni lavoravano, più giorni venivano fatturati. Potrebbero esserci alcuni indicatori contrattuali che incoraggiano superficialmente il lavoro efficiente, ma questi di solito mancano di efficacia. In definitiva, di solito è nell'interesse dell'organizzazione appaltatrice sostenere elevati livelli di rilavorazione. E così spesso vediamo i peggiori requisiti sugli incarichi contrattuali. Nella mia esperienza c'è una farsa sul lavoro efficiente, in realtà, la maggior parte dei lead degli appaltatori sono incentivati ad allungare il progetto e vendere più giorni-uomo. Con scarsi requisiti, le rilavorazioni sono elevate e sono inevitabili più ore fatturabili. Se stai acquistando uno sviluppo software a contratto, fai attenzione.

Cause culturali di rielaborazione

Se un requisito non è chiaro, il team deve verificarne la comprensione prima di svolgere il lavoro. Eventuali malintesi potrebbero causare rielaborazioni. In alcune culture, mettere in discussione le esigenze del cliente è una conversazione scomoda che preferirebbero evitare. Invece il team può lavorare su ipotesi e svilupparsi in base a tali ipotesi. Ciò è particolarmente comune nei contratti di outsourcing. Laddove i requisiti siano scritti in una lingua che non è la lingua madre di tutti i membri del team, sono molto probabili malintesi (e quindi rielaborazioni).

Ridurre la rilavorazione

Osservare e quantificare il problema

Alla fine di ogni sprint, chiedetevi quanto lavoro abbiamo fatto in termini di rielaborazione rispetto a nuovo lavoro. Quindi poniti la domanda: come avremmo potuto evitarlo? Infine, registra lo sforzo aggiuntivo (ovvero il costo) dovuto al fatto di dover svolgere il lavoro più di una volta.

Abbraccia gli standard per scrivere buoni requisiti

Il nostro elenco consigliato di attributi di qualità è:

1. Chiaro
2. Conciso
3. Orientato all'utente
4. Testabile
5. Misurabile
6. Coerente
7. Completare
8. Unico
9. Prezioso
10. Senza design

Ad eccezione di #9 in questo elenco, ScopeMaster controlla automaticamente i tuoi requisiti per il rispetto di questi attributi di qualità, quindi non è necessario controllarli manualmente. (Non consigliamo l'elenco INVEST poiché non copre tutte le caratteristiche di cui sopra che abbiamo ritenuto importanti.)

Utilizzare strumenti che migliorano i requisiti

OK, quindi abbiamo creato ScopeMaster esattamente per questo scopo. Usando ScopeMaster esporrai e risolverai 9/10 dei tipi di qualità comuni elencati sopra e ad una velocità di circa 10 volte più veloce rispetto a farlo manualmente. In breve, potete aspettarvi di ridurre drasticamente le rilavorazioni utilizzando ScopeMaster per aiutarvi a valutare e perfezionare i vostri requisiti. Esistono altri strumenti di QVScribe e persino IBM Doors, ma questi sono solo la superficie di ciò che fa ScopeMaster.

Scrivere contratti che incentivano una bassa rilavorazione

Esistono diversi modi per affrontare questo problema. Innanzitutto, bisogna essere profondamente consapevoli che si tratta di una preoccupazione. Ricordare che la maggior parte delle rilavorazioni è evitabile. Disponiamo di un pacchetto di raccomandazioni contrattuali che possono aiutarti a definire i tuoi contratti di sviluppo in outsourcing per ridurre al minimo la probabilità di rilavorazioni.

Quantificazione della rilavorazione

Abbiamo visto che la rilavorazione causata da requisiti scadenti provoca un aumento dello sforzo da 1x a 2,5x. Si tratta in realtà di una stima modesta, perché quando si cambia direzione l'interruzione di un blocco di codice può avere un impatto negativo su altre parti della base di codice, causando ulteriori rielaborazioni.

Previsione dei difetti: utilizzo dei numeri per ridurre le rilavorazioni

Gli studi hanno raccolto dati sulla creazione e sulla rimozione dei difetti. Questi hanno dimostrato che i potenziali difetti si verificano in ciascuno degli artefatti chiave dello sviluppo software: requisiti, progettazione, codice, test. La conseguenza è che conosciamo i potenziali difetti di ciascuno e quindi quanti difetti dobbiamo rimuovere per raggiungere una qualità soddisfacente. Ancora una volta, utilizzando il dimensionamento standard sappiamo che i potenziali difetti tipici sono circa 5 difetti per CFP, di cui 1 probabilmente rientra nei requisiti. Sappiamo anche che la dimensione media di una user story è 5,5 CFP, quindi abbiamo un potenziale di difetto dei requisiti di 5,5 per user story. Ciò significa che, a meno che non siamo proattivi, quei 5,5 difetti rimarranno e diventeranno rilavorazioni in seguito. Strumenti come ScopeMaster possono trovare circa 50% difetti nei requisiti, ovvero 2-3 per user story. Ciò dimezza la probabile causa di rilavorazione.

Scritto da Colin Hammond, 35 anni di esperienza IT e fondatore di ScopeMaster.