Lean development can be summarized by seven principles, very close in concept to lean manufacturing principles:
- Eliminate waste
- Amplify learning
- Decide as late as possible
- Deliver as fast as possible
- Empower the team
- Build integrity in
- Optimize the whole
Eliminate wasteEdit
Lean philosophy regards everything not adding value to the customer as waste (muda). Such waste may include:
- Partially done work
- Extra features
- Relearning
- Task switching
- Waiting
- Handoffs
- Defects
- Management activities
In order to eliminate waste, one should be able to recognize it. If some activity could be bypassed or the result could be achieved without it, it is waste. Partially done coding eventually abandoned during the development process is waste. Le caratteristiche extra come le scartoffie e le caratteristiche non usate spesso dai clienti sono sprechi. Passare le persone da un compito all’altro è uno spreco. Aspettare altre attività, team, processi è spreco. Il riapprendimento richiesto per completare il lavoro è spreco. Difetti e qualità inferiore sono sprechi. Le spese generali del management che non producono valore reale sono sprechi.
Una tecnica di mappatura del flusso di valore è usata per identificare gli sprechi. Il secondo passo è quello di evidenziare le fonti di spreco e di eliminarle. L’eliminazione degli sprechi dovrebbe avvenire iterativamente fino a quando anche i processi e le procedure apparentemente essenziali sono liquidati.
Amplificare l’apprendimentoModifica
Lo sviluppo del software è un processo di apprendimento continuo basato su iterazioni durante la scrittura del codice. La progettazione del software è un processo di risoluzione dei problemi che coinvolge gli sviluppatori che scrivono il codice e ciò che hanno imparato. Il valore del software si misura in idoneità all’uso e non in conformità ai requisiti.
Invece di aggiungere più documentazione o una pianificazione dettagliata, si potrebbero provare diverse idee scrivendo codice e costruendo. Il processo di raccolta dei requisiti utente potrebbe essere semplificato presentando schermate agli utenti finali e ottenendo il loro input. L’accumulo di difetti dovrebbe essere prevenuto eseguendo i test non appena il codice è scritto.
Il processo di apprendimento è accelerato dall’uso di brevi cicli di iterazione – ognuno accoppiato con refactoring e test di integrazione. Aumentare il feedback attraverso brevi sessioni di feedback con i clienti aiuta a determinare l’attuale fase di sviluppo e a regolare gli sforzi per i miglioramenti futuri. Durante queste brevi sessioni, sia i rappresentanti del cliente che il team di sviluppo imparano di più sul problema del dominio e capiscono le possibili soluzioni per un ulteriore sviluppo. Così i clienti capiscono meglio i loro bisogni, basati sul risultato esistente degli sforzi di sviluppo, e gli sviluppatori imparano come soddisfare meglio quei bisogni. Un’altra idea nel processo di comunicazione e apprendimento con un cliente è lo sviluppo basato su set – questo si concentra sulla comunicazione dei vincoli della soluzione futura e non delle possibili soluzioni, promuovendo così la nascita della soluzione attraverso il dialogo con il cliente.
Decidere il più tardi possibileModifica
Come lo sviluppo del software è sempre associato a qualche incertezza, si dovrebbero ottenere risultati migliori con un approccio basato su set o su opzioni, ritardando il più possibile le decisioni fino a quando possono essere prese sulla base di fatti e non su ipotesi e previsioni incerte. Più un sistema è complesso, più la capacità di cambiamento dovrebbe essere incorporata in esso, permettendo così il ritardo di impegni importanti e cruciali. L’approccio iterativo promuove questo principio – la capacità di adattarsi ai cambiamenti e correggere gli errori, che potrebbero essere molto costosi se scoperti dopo il rilascio del sistema.
Con lo sviluppo basato su set: Se è necessario un nuovo sistema frenante per un’automobile, per esempio, tre team possono progettare soluzioni allo stesso problema. Ogni team impara a conoscere lo spazio del problema e progetta una potenziale soluzione. Se una soluzione è ritenuta irragionevole, viene tagliata. Alla fine di un periodo, i progetti sopravvissuti sono confrontati e uno viene scelto, forse con alcune modifiche basate sull’apprendimento degli altri – un grande esempio di rinvio dell’impegno fino all’ultimo momento possibile. Anche le decisioni sul software potrebbero beneficiare di questa pratica per minimizzare il rischio portato da una grande progettazione iniziale. Inoltre, ci sarebbero più implementazioni che funzionano correttamente, ma sono diverse (internamente, dal punto di vista dell’implementazione). Queste potrebbero essere usate per implementare sistemi fault-tolerant che controllano tutti gli input e gli output per la correttezza, attraverso le implementazioni multiple, simultaneamente.
Un approccio agile allo sviluppo del software può anticipare la costruzione di opzioni per i clienti, ritardando così alcune decisioni cruciali fino a che i clienti non abbiano realizzato meglio le loro necessità. Questo permette anche un adattamento successivo ai cambiamenti e la prevenzione di costose decisioni precedenti legate alla tecnologia. Questo non significa che non ci debba essere alcuna pianificazione – al contrario, le attività di pianificazione dovrebbero essere concentrate sulle diverse opzioni e sull’adattamento alla situazione attuale, oltre a chiarire le situazioni confuse stabilendo modelli per un’azione rapida. Valutare le diverse opzioni è efficace non appena ci si rende conto che non sono gratuite, ma forniscono la flessibilità necessaria per una decisione tardiva.
Consegnare il più velocemente possibileModifica
Nell’era della rapida evoluzione tecnologica, non è il più grande che sopravvive, ma il più veloce. Prima il prodotto finale viene consegnato senza grossi difetti, prima il feedback può essere ricevuto e incorporato nell’iterazione successiva. Più brevi sono le iterazioni, migliore è l’apprendimento e la comunicazione all’interno del team. Con la velocità, le decisioni possono essere ritardate. La velocità assicura il soddisfacimento dei bisogni attuali del cliente e non quello che ha richiesto ieri. Questo dà loro l’opportunità di ritardare la decisione su ciò di cui hanno veramente bisogno fino a quando non acquisiscono una migliore conoscenza. I clienti apprezzano la consegna rapida di un prodotto di qualità.
L’ideologia della produzione just-in-time potrebbe essere applicata allo sviluppo del software, riconoscendo i suoi requisiti specifici e l’ambiente. Questo si ottiene presentando il risultato necessario e lasciando che il team si organizzi e divida i compiti per realizzare il risultato necessario per una specifica iterazione. All’inizio, il cliente fornisce l’input necessario. Questo potrebbe essere semplicemente presentato in piccole schede o storie – gli sviluppatori stimano il tempo necessario per l’implementazione di ogni scheda. Così l’organizzazione del lavoro si trasforma in un sistema di auto-pulling – ogni mattina durante una riunione di stand-up, ogni membro del team esamina ciò che è stato fatto ieri, ciò che deve essere fatto oggi e domani, e chiede qualsiasi input necessario ai colleghi o al cliente. Questo richiede la trasparenza del processo, che è anche vantaggioso per la comunicazione del team.
Il mito sottostante a questo principio è che la fretta fa sprecare. Tuttavia, l’implementazione lean ha fornito che è una buona pratica per consegnare velocemente al fine di vedere e analizzare l’output al più presto.
Empower the teamEdit
C’è stata una credenza tradizionale nella maggior parte delle aziende circa il processo decisionale nell’organizzazione – i manager dicono ai lavoratori come fare il loro lavoro. In una tecnica lean, i ruoli sono invertiti – ai manager viene insegnato come ascoltare gli sviluppatori, in modo che possano spiegare meglio quali azioni potrebbero essere intraprese, così come fornire suggerimenti per i miglioramenti. L’approccio lean segue il principio agile “costruire progetti intorno a individui motivati e fidarsi di loro per portare a termine il lavoro”, incoraggiando il progresso, catturando gli errori e rimuovendo gli impedimenti, ma senza microgestire.
Un’altra convinzione sbagliata è stata la considerazione delle persone come risorse. Le persone potrebbero essere risorse dal punto di vista di un foglio di dati statistici, ma nello sviluppo del software, così come in qualsiasi attività organizzativa, le persone hanno bisogno di qualcosa di più di una semplice lista di compiti e la garanzia che non saranno disturbate durante il completamento dei compiti. Le persone hanno bisogno di motivazione e di uno scopo superiore per cui lavorare – scopo all’interno della realtà raggiungibile, con la garanzia che il team possa scegliere i propri impegni. Gli sviluppatori dovrebbero avere accesso al cliente; il team leader dovrebbe fornire supporto e aiuto nelle situazioni difficili, così come assicurare che lo scetticismo non rovini lo spirito del team. Rispettare le persone e riconoscere il loro lavoro è un modo per responsabilizzare il team.
Costruire l’integrità inEdit
Il cliente deve avere un’esperienza complessiva del sistema. Questa è la cosiddetta integrità percepita: come viene pubblicizzato, consegnato, distribuito, accessibile, quanto è intuitivo il suo uso, il suo prezzo e quanto bene risolve i problemi.
Integrità concettuale significa che i componenti separati del sistema lavorano bene insieme come un tutto con equilibrio tra flessibilità, manutenibilità, efficienza e reattività. Questo può essere ottenuto comprendendo il dominio del problema e risolvendolo allo stesso tempo, non in modo sequenziale. Le informazioni necessarie sono ricevute in piccoli lotti – non in un unico grande blocco – preferibilmente tramite comunicazione faccia a faccia e non tramite documentazione scritta. Il flusso di informazioni dovrebbe essere costante in entrambe le direzioni – dal cliente agli sviluppatori e viceversa, evitando così la grande quantità stressante di informazioni dopo un lungo sviluppo in isolamento.
Una delle vie salutari verso l’architettura integrale è il refactoring. Più caratteristiche vengono aggiunte alla base di codice originale, più difficile diventa aggiungere ulteriori miglioramenti. Il refactoring consiste nel mantenere la semplicità, la chiarezza, il numero minimo di caratteristiche nel codice. Le ripetizioni nel codice sono segni di cattiva progettazione del codice e dovrebbero essere evitate. Il processo di costruzione completo e automatizzato dovrebbe essere accompagnato da una suite completa e automatizzata di test dello sviluppatore e del cliente, con la stessa versione, sincronizzazione e semantica dello stato attuale del sistema. Alla fine l’integrità dovrebbe essere verificata con test approfonditi, assicurando così che il sistema faccia ciò che il cliente si aspetta. Anche i test automatizzati sono considerati parte del processo di produzione, e quindi se non aggiungono valore dovrebbero essere considerati uno spreco. I test automatici non dovrebbero essere un obiettivo, ma piuttosto un mezzo per raggiungere un fine, in particolare la riduzione dei difetti.
Ottimizzare l’InteroEdit
I moderni sistemi software non sono semplicemente la somma delle loro parti, ma anche il prodotto delle loro interazioni. I difetti nel software tendono ad accumularsi durante il processo di sviluppo – decomponendo i grandi compiti in compiti più piccoli, e standardizzando le diverse fasi di sviluppo, le cause alla radice dei difetti dovrebbero essere trovate ed eliminate. Più grande è il sistema, più organizzazioni sono coinvolte nel suo sviluppo e più parti sono sviluppate da diversi team, maggiore è l’importanza di avere relazioni ben definite tra i diversi fornitori, al fine di produrre un sistema con componenti che interagiscono senza problemi. Durante un periodo di sviluppo più lungo, una rete di subappaltatori più forte è molto più vantaggiosa dell’ottimizzazione del profitto a breve termine, che non permette relazioni win-win.
Il pensiero snello deve essere compreso bene da tutti i membri di un progetto, prima di essere implementato in una situazione concreta, di vita reale. “Think big, act small, fail fast; learn rapidly” – questi slogan riassumono l’importanza della comprensione del campo e l’opportunità di implementare i principi lean lungo tutto il processo di sviluppo del software. Solo quando tutti i principi lean sono implementati insieme, combinati con un forte “buon senso” rispetto all’ambiente di lavoro, c’è una base per il successo nello sviluppo del software.