Può essere riassunto in sette principi base:

  1. Eliminare gli scarti
  2. Miglioramento continuo
  3. Decidere il più tardi possibile
  4. Consegnare il più velocemente possibile
  5. Dare il potere al team
  6. La qualità prima di tutto
  7. Avere una visione globale

Eliminare gli scarti

Tutto quello che non aggiunge valore al prodotto lo dobbiamo definire come uno scarto e questo può includere

  • Burocrazia inutile
  • Comunicazione poco efficiente
  • Requisiti poco chiari
  • Codice che non è strettamente indispensabile
  • Tutto quello che può rallentare lo sviluppo software
  • Goals non specifici

Definire cosa è uno scarto e cosa non lo è può essere complicato, però come linee guida possiamo basarci su cosa è strettamente necessario per il nostro obiettivo e cosa non lo è.

Se vediamo che ci sono attività che non apportano valore o che non ci servono per concludere il nostro task allora le dobbiamo bollare come scarto NON farle.

Tutto quello che non è un’attività produttiva è uno scarto, bugs in produzione dovuti a una bassa qualità del codice è considerato una grande perdita di tempo e qualsiasi attività manageriale che non apporti al team e al progetto è anche da considerati uno scarto.

I passi per ridurre o eliminare gli scarti sono:

  1.              Identificare i processi che si eseguono per completare un task
  2.              Determinare quali producono valore
  3.              Eliminare quelli che non producono valore aggiunto

Questi tre passi bisognerebbe riprodurli per tutti i task che sono assegnati al nostro team per far si che la nostra maniera di lavorare rispetti i principi del “lean software development”.

Miglioramento Continuo (Kaizen)

Lo sviluppo software è in continua evoluzione e bisogna stare aggiornati per migliorare la qualità del codice e dell’architettura. Il cosiddetto “learning on demand” deve essere alla base di ogni team, però perché sia efficace dovrebbe essere condiviso con tutto il team con una metodologia agile di documentazione.

Per esempio, se un membro del team impara qualcosa di interessante per il progetto, allora dovrebbe creare una breve documentazione su come il team può usufruire di questo.

Le cose da migliorare sono molte, in particolare come far si che il team sia in grado di passare dai requisiti software al prodotto finale senza impedimenti e consegnando un risultato che sia in linea con quello che vuole il cliente.

Per fare questo occorre un miglioramento costante in tutti i processi interni e esterni.

Decidere il più tardi possibile

Le decisioni cruciali in progetti grandi dovrebbero essere prese il più tardi possibile, solo quando il cliente è completamente sicuro  di quello che vuole e dia personalmente l’ok.

Questo fa si che il team sia più flessibile al cambiamento di rotta che sarà più facile e meno costoso se si adotta questo sistema.

Bisogna anche partire dal fatto che il cliente può cambiare spesso e volentieri idea e il codice dovrebbe essere abbastanza flessibile per gestire questi cambi di rotta.

Quindi le decisioni che possiamo chiamare irreversibili, più tardi si prendono meglio è, e sarebbe meglio consultare tutto il team prima di avventurarsi per un cammino.

Consegnare il più velocemente possibile

l’obiettivo è ricevere il feedback il più velocemente possibile, perché siamo in un mondo in continua evoluzione e il feedback deve essere la base della pianificazione delle seguenti iterazioni.

Le iterazioni devo essere corte di modo da integrare il responso del cliente, pubblico etc… e per far si che i bug o difetti funzionali vengano a galla il più presto possibile.

Si potrebbe anche adottare il “just in time development” che si basa su un semplice processo:

  1. Il cliente da le specifiche della funzionalità
  2. Il team divide la funzionalità in singoli task
  3. il team fa una stima del tempo necessario per ogni task
  4. Ogni giorno il team e fa un review di quello che è successo ieri
  5. I componenti del gruppo si dividono i task per la giornata

Questo ciclo si ripete ogni giorno fino a che la funzionalità non è consegnata al cliente.

Il team è quello che ha il controllo della situazione ed è responsabile di far si che si consegni in tempo la funzionalità richiesta.

Dare il potere al team

Il modo di lavorare è sostanzialmente ribaltato, la filosofia che ci sta dietro è quella di trovare gente competente e lasciarla lavorare, eliminando tutti i possibili impedimenti, favorendo un ambiente produttivo e dinamico dove sia facile imparare e condividere problemi e soluzioni.

I manager sostanzialmente devono ascoltare gli sviluppatori facilitandogli il lavoro, revisando la qualità e trovando potenziali errori il prima possibile.

Gli sviluppatori dovrebbero avere visibilità sui clienti per capire i loro bisogni e aspettative.

La qualità prima di tutto

I clienti hanno bisogno di avere una esperienza positiva e trasparente di come funziona il software per cui hanno pagato la licenza, si deve trasmettere una integrità globale nella maniera di usarlo, di come si risolvono i problemi degli utenti, nella maniera in cui viene pubblicizzato e venduto.

La cosa più importante è che la comunicazione tra sviluppatori e clienti non sia mai interrotta per un lungo periodo di tempo, per evitare che si accumulino troppi sviluppi senza un feedback, questi cicli corti garantiscono la qualità del prodotto finale.

La riorganizzazione del codice ha una importanza chiave specialmente quando il progetto cresce e si aggiungono nuove funzionalità, nasce la necessità di fare un refactoring del codice per garantire che la integrazione dei nuovi moduli non comprometta la scalabilità e flessibilità del codice.

La parte di test e pubblicazione ha un ruolo importante, i test servono per trovare gli errori il prima possibile, quindi dovrebbero essere automatici e eseguiti ogni volta che si cerca di creare una nuova versione. Se i test che non aggiungono valore al prodotto finale si dovrebbero eliminare perché prenderebbero del tempo a altre fasi di sviluppo.

Avere una visione globale

“Pensa in grande, attua nel piccolo, fallisci veloce e impara velocemente” questo è il motto del lean software development e ogni membro della propria organizzazione dovrebbe farlo proprio.

Il software ha la tendenza a crescere e a diventare più complesso quando si aggiungono più caratteristiche e si coinvolgono più persone nello sviluppo, quindi è importante riuscire a dividere in piccole stadi il processo di creazione del software per riuscire a isolare i comportamenti che sono fonti di errori e evitare che si propaghino e che poi siano un costo notevole per il team.