Sviluppo del software essenziale

Da David J.Anderson.David J.Anderson è l'autore dei tre valori possibili, Lezioni in gestione Agile: La strada a Kanban, che è stato pubblicato nel 2012, Kanban: La modifica scalabile per la società di tecnologia, [1] che è stata pubblicata nel 2010 e, Gestione Agile per il software engineering: Applicando la stringa dei vincoli dei risultati aziendali, [2] che è stata pubblicata nel 2003.È stato membro del team che ha creato il metodo di sviluppo software Agile, sviluppo basato su funzionalità, a Singapore tra il 1997 e il 1999.Ha creato MSF for CMMI Process Improvement e congiuntamente ha creato la nota tecnica del software engineering institute, "CMMI e Agile: Poiché non abbraccio entrambi!" È un fondatore della società magra di sistema (http://www.leansystemssociety.org).È CEO di Magra - Kanban University Inc., la formazione accreditata e l'organizzazione di standard di qualità che offre la formazione di Kanban tramite una rete dei partner il mondo intero e di cui esegue una prova alla gestione e un'azienda di consulenza internazionali, David J.Anderson & Associates Inc.(http://www.agilemanagement.net) che consente alle aziende di migliorare le prestazioni tramite una migliore gestione dei criteri e del processo decisionale.

Novembre 2011, novembre 2012 aggiornato.

Anderson descrive il Lean Software Development.

Si applica a

Lean, sviluppo del software, gestione dei progetti, Team Foundation Server

• Introduction

• Lean e Agile

• Lean oltre Agile

• Definizione di Lean Software Development

• Valori

• Principi

• Procedure

Il termine Lean Software Development è stato coniato per la prima volta come titolo di una conferenza organizzata dall'iniziativa ESPRIT dell'Unione Europea, a Stoccarda in Germania, nell'ottobre 1992.In maniera indipendente, l'anno seguente Robert "Bob" Charette nel 1993 suggerì il concetto di "“Lean Software Development" come parte del suo lavoro di ricerca di modi migliori per gestire il rischio nei progetti software.Il termine "Lean" risale al 1991 ed è stato suggerito da James Womack, Daniel Jones e Daniel Roos nel loro libro The Machine That Changed the World: The Story of Lean Production[3] come termine della lingua inglese per descrivere l'approccio alla gestione utilizzato in Toyota.L'idea che la lean manufacturing potesse essere applicabile allo sviluppo di software è nata molto presto, solo 1 o 2 anni dopo che questo termine fu associato alle tendenze nei processi di produzione e nella progettazione industriale.

Nel secondo libro pubblicato nel 1995, Womack e Jones[4] definirono cinque colonne principali del pensiero Lean.Questi sono:

• Valore

• Flusso di valore

• Flusso

• Pull

• Perfezione

Questi elementi sono diventati la definizione predefinita del Lean nell'arco della maggior parte del decennio successivo.La perfezione, è stato consigliato, è stata raggiunta eliminando lo spreco.Sebbene vi fossero 5 colonne, era la quinta, il perseguimento della perfezione attraverso l'identificazione sistematica delle attività dispendiose e della relativa eliminazione, che ha effettivamente risuonato in un ampio pubblico.Lean è stata quasi esclusivamente associata alla pratica dell'eliminazione di sprechi dalla fine degli anni '90 agli inizi del ventunesimo secolo.

La definizione attribuita da Jones e Womack al concetto di Lean non è condivisa universalmente.I principi alla base della gestione di Toyota sono molto più complessi.La parola "spreco" in italiano viene espressa in giapponese con tre termini più precisi:

• Muda: letteralmente significa "spreco", ma implicando un'attività non a valore aggiunto

• Mura: significa "irregolarità" e viene interpretata come "variabilità nel flusso"

• Muri: significa "sovraccarico" o "irragionevolezza"

La perfezione è perseguita con la riduzione di attività non a valore aggiunto ma anche con l'agevolazione del flusso e l'eliminazione del sovraccarico.Inoltre, l'approccio di Toyota si è basato sul fondamentale rispetto per le persone ed è stato ampiamente influenzato da insegnamenti di esperti del controllo di qualità e del controllo statistico dei processi del ventesimo secolo, come W.Edwards Deming.

Sfortunatamente, le definizioni di Lean sono tante quanti sono gli autori sull'argomento.

Lean e Agile

Bob Charette è stato invitato ma non riesce a partecipare alla riunione del 2001 a Snowbird, in Utah, in cui è stato creato il Manifesto for Agile Software Development[5].Nonostante la mancanza della riunione storica, Lean Software Development è stato considerato come uno dei diversi approcci Agile allo sviluppo software.JIM Highsmith ha dedicato un capitolo del suo libro[6] del 2002 a un'intervista con Bob sull'argomento.In seguito, Mary & Tom Poppendieck hanno proseguito nella stesura di una serie di 3[7,8,9] libri.Durante i primi anni del ventunesimo secolo, i principi snelli sono stati utilizzati per descrivere il motivo per il quale i metodi Agile sono i migliori.Lean spiega che i metodi Agile consentono pochi "sprechi" e pertanto hanno prodotto un risultato economico migliore.I principi Lean sono stati utilizzati come "datore di autorizzazione" per adottare i metodi Agile.

Lean oltre Agile

In anni recenti il Lean Software Development è effettivamente emerso come disciplina indipendente, correlata ma non specificamente un sottoinsieme del movimento Agile.Questa evoluzione è iniziata con la sintesi delle idee del Lean Product Development e del lavoro di Donald G.Reinertsen[10,11] e idee che emergono dal mondo non Agile di progettazione di sistemi su vasta scala, nonché opere di James Sutton e Peter Middleton[12].Inoltre è stato sintetizzato il lavoro di Eli Goldratt e W.Edwards Deming ha puntato l'attenzione sul flusso anziché sulla riduzione degli sprechi[13].In seguito all'ordine di Reinertsen verso il 2005, è stato introdotto l'utilizzo dei sistemi kanban che limitano il lavoro in corso e "prendono" più lavoro solo quando il sistema è pronto per elaborarlo.Alan Shalloway ha aggiunto ciò che pensa sullo sviluppo del software Lean nel libro pubblicato nel 2009 sull'argomento[14].Dal 2007, la comparsa di lean come nuova forza nell'avanzamento della professione di sviluppo software è stata incentrata sul miglioramento del flusso, la gestione del rischio e il miglioramento (gestione) del processo decisionale.Kanban è diventato un fattore importante per le iniziative Lean in attività correlate all'IT.Indica che l'attenzione al flusso, anziché all'eliminazione dello spreco, sia un catalizzatore migliore per il miglioramento continuo all'interno delle attività di lavoro cognitivo, come lo sviluppo del software.

Definizione di Lean Software Development

La definizione di Lean Software Development è impegnativa in quanto non è disponibile alcun metodo o processo specifico di Lean Software Development.Lean non equivale a Personal Software Process, V-Model, Spiral Model, EVO, Feature-Driven Development, Extreme Programming, Scrum o Test-Driven Development.Un processo del ciclo di vita dello sviluppo software o un processo di gestione dei progetti può essere definito "lean" se si osserva che è allineato ai valori del movimento e dei principi di Lean Software Development.Pertanto quelli che prevedono una semplice ricetta che può essere seguita e denominata Lean Software Development saranno delusi.È necessario adattare o adattare il proprio processo di sviluppo software la conoscenza dei principi snelli e con i valori principali di magra.

Esistono diverse scuole di pensiero all'interno del Lean Software Development.Il più grande e discutibilmente comportare, scuola sono la società magra dei sistemi, che include Donald Reinertsen, JIM Sutton, Alan Shalloway, Bob Charette, Mary Poppendeick e David J.Anderson.Lavoro di Tom e di Mary Poppendieck compilata separatamente prima della formazione della società e dei supporti di ritengo, come esegue il lavoro di Craig Larman, di Bas Vodde[15,16]e, recente, di JIM Coplien[17].Ricerca di questo articolo per essere largamente rappresentante del punto di vista essenziale della società dei sistemi come espresso nel relativo ritengo e fornire una sintesi e un riepilogo delle idee.

Valori

La società magra dei sistemi ha pubblicato il relativo ritengo[18] a 2012 conferenza[19]magra dei sistemi & software.Ciò è basata su un insieme di valori immessi un anno precedente.I valori includono:

• Accettare la condizione umana

• Accettare che la complessità e l'incertezza sono naturali nella competenza del lavoro

• Lavorare per un migliore risultato economico

• Permettendo al contempo un miglior risultato sociologico

• Ricercare, adottare e porre domande su idee da una vasta gamma di discipline

• La community basata sul valore migliora la velocità & la profondità delle modifiche positive

Accettare la condizione umana

Il lavoro cognitivo come lo sviluppo del software è intrapreso da esseri umani.Noi umani siamo esseri intrinsecamente complessi. Sebbene siamo pensatori logici, ci facciamo anche guidare dalle nostre emozioni e da alcuni tratti istintivi che non riusciamo ragionevolmente a superare.La nostre psicologia e neuropsicologia deve essere presa in considerazione quando si progettano sistemi o processi in cui lavoriamo.Anche il comportamento sociale deve essere considerato.Gli esseri umani sono implicitamente emotivi, sociali e tribali e i nostri comportamenti cambiano con la fatica e lo stress.I processi con esito positivo saranno quelli che adottano e combinano la condizione umana rispetto a quelli che tentano di negarla e presuppongono un comportamento logico e simile a un computer.

Accettare che la complessità e l'incertezza sono naturali nella competenza del lavoro

Il comportamento dei clienti e dei mercati sono imprevedibili.Il flusso di lavoro attraverso un processo e una raccolta di lavoratori è imprevedibile.I difetti e la rielaborazione richiesta sono imprevedibili.Esiste una probabilità intrinseca o un comportamento apparentemente casuale a più livelli all'interno dello sviluppo software.Lo scopo, i fini e l'ambito dei progetti tendono a cambiare nell'arco della produzione.Parte di questa incertezza e variabilità, sebbene inizialmente sconosciuta, sia riconoscibile nel senso che può essere studiata e quantificata e i relativi rischi gestiti, ma una certa variabilità non è riconoscibile in anticipo e non può essere adeguatamente prevista.Pertanto, i sistemi di Lean Software Development devono essere in grado di rispondere agli eventi di espansione e il sistema deve essere in grado di adattarsi alle circostanze in continua evoluzione.Pertanto il processo Lean Software Development deve esistere all'interno di un framework che consente l'adattamento (del processo) agli eventi di espansione.

Lavorare per un migliore risultato economico

Le attività umane come il Lean Software Development devono essere incentrate sulla creazione di risultati più economici.Il capitalismo è accettabile quando contribuisce al valore dell'azienda e al vantaggio del cliente.Investitori e proprietari di aziende meritano un utile sugli investimenti (ROI).Gli impiegati e gli operai meritano un livello retributivo legittimo per un impegno appropriato nell'eseguire il lavoro.I clienti meritano un buon prodotto o un'assistenza che lo consegna con i vantaggi promessi in cambio di un prezzo corretto.I migliori risultati economici includeranno più valore ai clienti, a più basso costo, mentre si gestisce il capitale distribuito dagli investitori o dai proprietari nel modo più efficace possibile.

Abilitare un miglior risultato sociologico

I migliori risultati economici non devono essere forniti a scapito di quelli che eseguono il lavoro.La creazione di un'area di lavoro che rispetta le persone accettando la condizione umane e che fornisce i sistemi di lavoro che rispettano la natura psicologica e sociologica di persone è essenziale.La creazione di un luogo piacevole in cui lavorare bene è un valore principale della community di Lean Software Development.

Principi

La community Lean Software & Systems sembra essere d'accordo su alcuni principi alla base dei processi di Lean Software Development.

• Utilizzare un approccio al concetto di sistema e progettazione

• I risultati emergenti possono essere influenzati creando l'architettura del contesto di un sistema adattivo complesso

• Rispettare le persone di (come parte del sistema)

• Utilizzare il metodo scientifico per impostare i miglioramenti

• Incoraggiare la leadership

• Generare la visibilità (nelle operazioni di lavoro, del flusso di lavoro e di sistema)

• Ridurre il tempo di flusso

• Ridurre lo spreco per migliorare l'efficienza

Utilizzare un approccio al concetto di sistema e progettazione

Nella letteratura Lean si parla di "ottimizzazione del tutto", che implica che sia l'output dell'intero sistema (o processo) che si desidera ottimizzare e che non si debbano ottimizzare le parti nella speranza che venga di conseguenza ottimizzato il tutto.La maggior parte dei professionisti ritiene vero il corollario, che l'ottimizzazione delle parti (ottimizzazione locale) sortirà un risultato non ottimale.

Un approccio al concetto di sistema Lean e progettazione richiede che si considerino le esigenze sul sistema eseguite dalle parti interessate esterne, ad esempio i clienti e il risultato previsto richiesto dalle parti interessate.È necessario considerare la natura della richiesta e confrontarla con la capacità del sistema di rispondere a tale richiesta.La richiesta includerà la cosiddetta "richiesta di valore", per cui i clienti sono disposti a pagare e la "richiesta di assistenza" che è in genere una rielaborazione o una richiesta aggiuntiva causata da un errore nella fornitura della richiesta di valore.La richiesta di assistenza presenta spesso due forme: modificare la richiesta di valore precedentemente distribuita e i servizi aggiuntivi o supportare in seguito a un errore nella fornitura della richiesta di valore.Nello sviluppo software la richiesta di errore corrisponde in genere a richieste di correzioni dei bug e richieste a una funzione di assistenza clienti o supporto tecnico.

Un approccio di progettazione di sistemi richiede di seguire l'approccio PDSA per elaborare la progettazione e il miglioramento.Edwards Deming ha utilizzato la parola "studio" e "capacità" per intendere che tutti noi studiamo la filosofia naturale del nostro comportamento di sistema.Questo sistema è costituito dal processo di sviluppo software e da tutte le persone che vi operano.Avrà un comportamento osservabile in termini di lead time, qualità, quantità di funzionalità o funzioni realizzate (a cui viene fatto riferimento nella letteratura Agile come "velocità") e così via.Queste metriche mostreranno una certa variabilità e, studiando la media e l'estensione della variazione, sarà possibile sviluppare una conoscenza della capacità.Se ciò non corrisponde alla richiesta e alle aspettative del cliente, il sistema dovrà essere riprogettato per colmare il divario.

Deming ci ha inoltre insegnato che la funzionalità è influenzata per il 95% dalla progettazione del sistema e le prestazioni degli utenti contribuiscono solo per il 5%.In altre parole, è possibile rispettare le persone evitando di rimproverarle per una lacuna in termini di capacità rispetto alla domanda e riprogettando il sistema in modo tale che abbiano successo.

Per comprendere la progettazione di sistema, è necessario avere una conoscenza tecnica della dinamica della capacità di sistema e di come potrebbe essere influenzata.I modelli vengono sviluppati per stimare la dinamica del sistema.Esistono numerosi modelli possibili, molti sono di uso comune: la conoscenza dei costi economici; i cosiddetti costi di coordinamento e transazioni correlati alla realizzazione di prodotti o servizi apprezzati dai clienti; la teoria dei vincoli, vale a dire la comprensione dei colli di bottiglia; e la teoria della conoscenza approfondita, ovvero lo studio e il riconoscimento della variabilità come elemento comune alla progettazione di sistema o come elemento speciale ed esterno alla progettazione di sistema.

I risultati emergenti possono essere influenzati creando l'architettura del contesto per un sistema adattivo complesso

I sistemi complessi hanno condizioni di avvio e semplici regole che, una volta eseguite in modo iterativo, producono un risultato emergente.I risultati emergenti sono difficili o impossibili da prevedere date le condizioni di avvio.L'esperimento di informatica "The Game of Life" è un esempio di sistema complesso.Un sistema adattivo complesso ha al suo interno una determinata autoconsapevolezza e un metodo interno di reflection che consente di considerare come il set di regole corrente sta per ottenere un risultato desiderato.Il sistema adattivo complesso può quindi scegliere per adattare – per modificare le regole semplici (per eliminare il divario tra il risultato corrente e il risultato previsto.Se Game of Life si adattasse al punto da rendere possibile riscrivere le regole durante il gioco sarebbe un sistema adattivo complesso.

Nei processi di sviluppo software, le "semplici regole" dei sistemi adattivi complessi sono i criteri che costituiscono la definizione del processo.Il principio chiave è basato sulla convinzione che lo sviluppo di servizi e prodotti software non è un'attività deterministica, quindi un processo che non può adattarsi non sarà una risposta appropriata a eventi imprevisti.Pertanto, il processo progettato come parte dell'approccio al concetto di sistema e progettazione deve essere adattabile.Si adatta alla modifica dei criteri di cui è stata costituito.

L'approccio Kanban al Lean Software Development utilizza questo concetto considerando i criteri del sistema pull di kanban come "regole semplici". Le condizioni iniziali sono che il lavoro e il flusso di lavoro vengono visualizzati, che il flusso viene gestito mediante una conoscenza della dinamica dei sistemi e che l'organizzazione utilizza un approccio scientifico per capire, proporre e implementare i miglioramenti.

Rispettare le persone

La community Lean adotta la definizione di consapevolezza nel lavoro di Peter Drucker in cui si afferma che i lavoratori sono più competenti se sono più consapevoli del lavoro che svolgono rispetto ai loro responsabili.Ciò implica che la posizione ottimale dei lavoratori è quella dove possono prendere decisioni su come eseguire un lavoro e come modificare i processi per migliorare l'esecuzione del lavoro.Pertanto la voce del lavoratore deve essere rispettata.I lavoratori dovrebbero potersi organizzare autonomamente per completare il lavoro e raggiungere i risultati desiderati.Devono avere inoltre la facoltà di suggerire e implementare opportunità di miglioramento dei processi o "eventi kaizen" come sono chiamate nella letteratura del pensiero Lean.Tendendo espliciti i criteri di processo in modo che i lavoratori conoscano le regole che li vincolano costituisce un altro modo per rispettarli.Le regole ben definite incoraggiano l'organizzazione autonoma rimuovendo il timore e la necessità di farsi coraggio.Rispetto agli utenti autorizzandole e fornendo un set di criteri dichiarati in modo esplicito tiene fede al valore principale di rispetto della condizione umana.

Utilizzare il metodo scientifico.

Cercare di utilizzare i modelli per comprendere la dinamica di esecuzione del lavoro e il funzionamento del sistema Lean Software Development.Osservare e valutare il sistema e le relative funzionalità e quindi compilare e applicare i modelli per stimare il comportamento.Raccogliere i dati quantitativi nei propri studi e utilizzare tali dati per comprendere il modo in cui il sistema è in esecuzione e per stimare come potrebbe cambiare quando il processo viene modificato.

La community Lean Software Development utilizza metodi statistici, quali i grafici statistici di controllo dei processi e gli istogrammi di analisi spettrale dei dati non elaborati per il lead time e la velocità per determinare la capacità di un sistema.Si utilizzano modelli quali: la teoria dei vincoli per individuare i colli di bottiglia, il sistema di conoscenza approfondita per comprendere la variazione interna alla progettazione del sistema rispetto a quella influenzata esternamente; l'analisi dei costi economici sotto forma di attività eseguite solo per coordinare, configurare, consegnare o pulire dopo che il prodotto o i servizi valutati dal cliente sono stati creati.Alcuni altri modelli cominciano a essere utilizzati, come Real Option Theory, che cerca di applicare la teoria delle opzioni finanziarie della gestione dei rischi finanziari al processo decisionale reale.

Il metodo scientifico suggerisce le seguenti fasi: studio; stesura di un postulato su un risultato basato su un modello; modifica del sistema sulla base di tale previsione e osservazione per verificare se la modifica del sistema ha prodotto i risultati prospettati nel modello.In caso contrario, controlleremo i dati e verificheremo di nuovo se il nostro modello è accurato.L'utilizzo di modelli per dirigere i miglioramenti del processo trasforma il metodo in un'attività scientifica e lo eleva da un'attività scaramantica a un'attività basata sull'intuizione.

Incoraggiare la leadership

Leadership e gestione non sono la stessa cosa.Per management si intende l'attività di progettare i processi, creare, modificare ed eliminare criteri, di prendere decisioni strategiche e operative, riunire le risorse, fornire mezzi finanziari e strutture e comunicare informazioni sul contesto come strategia, obiettivi e risultati desiderati.La leadership è la visione, la strategia, le tattiche, il coraggio, l'innovazione, il giudizio, l'appoggio e molti altri attributi.La leadership può e deve provenire da chiunque in un'organizzazione.I piccoli atti di leadership da parte dei lavoratori creeranno una sovrapposizione dei miglioramenti che consentiranno di ottenere le modifiche necessarie per creare un processo di Lean Software Development.

Generare la visibilità

Il lavoro cognitivo è invisibile.Se non è possibile visualizzare qualcosa, è (quasi) impossibile gestirla.È necessario generare visibilità del lavoro intrapreso e del flusso di tale lavoro tramite una rete di individui, competenze e reparti fino al completamento.È necessario creare la visibilità nella progettazione del processo individuando modalità di visualizzazione del flusso del processo e definendo i criteri del processo espliciti che ognuno può vedere e da considerare.Quando tutto è chiaro, diventa possibile utilizzare il metodo scientifico e si possono intavolare discussioni obiettive e collaborative sui miglioramenti potenziali.Il miglioramento del processo di collaborazione è quasi impossibile se il lavoro e il flusso di lavoro sono invisibili e se i criteri del processo non sono espliciti.

Ridurre il tempo di flusso

I professionisti dello sviluppo software e gli accademici che studiano informatica si sono sempre concentrati sulla misurazione del tempo dedicato allo svolgimento di un'attività.La community Lean Software Development ha scoperto che potrebbe risultare più utile misurare l'effettivo tempo di calendario impiegato per l'elaborazione di un prodotto.Questa operazione viene in genere definita come Durata ciclo e di solito viene qualificata dai limiti delle attività eseguite.Ad esempio, la durata ciclo da Analisi a Pronta per la distribuzione misura il tempo totale impiegato per un elemento di lavoro, ad esempio una storia utente, da analizzare, progettare, sviluppare, testare in modi diversi, e accordare pronta per la distribuzione a un ambiente di produzione.

Centrare l'attenzione sul tempo impiegato dal lavoro ad attraversare il processo è importante in diversi modi.I tempi di ciclo più lunghi sono stati visualizzati per la correlazione con una crescita non lineare nella frequenza di bug.Pertanto durate ciclo più brevi danno come risultato una qualità più alta.Questo comportamento è imprevisto in quanto sembra ridicolo che dei bug possano essere inseriti nel codice mentre è in coda e mentre nessuno lo sta utilizzando.I professionisti di informatica e gli accademici che studiano questa problematica hanno sempre ignorato il tempo di inattività.Tuttavia, l'evidenza empirica suggerisce che la durata ciclo è importante per la qualità iniziale.

Alan Shalloway ha inoltre parlato del concetto di "lavoro indotto". La sua osservazione è che un ritardo nell'esecuzione di un'attività può portare a un lavoro richiesto molto superiore per tale attività.Ad esempio, la correzione di un bug individuato e corretto immediatamente può richiedere solo 20 minuti, ma se tale bug viene valutato, accodato e quindi attende diversi giorni o settimane per essere corretto, potrebbero volerci molte ore per eseguire la correzione.Pertanto, il ritardo della durata ciclo ha "causato" lavoro aggiuntivo.Poiché è possibile evitare questo lavoro, in termini Lean, deve essere considerato come "spreco".

Il terzo motivo per concentrarsi sul tempo del ciclo è legato al mercato.Ogni funzionalità, funzione, o storia utente ha un valore.Il valore può essere incerto, tuttavia, è presente un valore.Il valore può variare nel tempo.Il concetto di valore che varia nel tempo può essere espresso economicamente come funzione di profitto di mercato.Una volta compresa la funzione di profitto per un elemento di lavoro, anche se la funzione mostra una gamma estesa di valori, indicando così incertezza, è possibile valutare "un costo di ritardo", il quale consente di mettere un valore sulla riduzione del tempo di ciclo.

Con alcuni elementi di lavoro, la funzione di profitto non inizia fino a una determinata data futura.Ad esempio, una funzionalità progettata per essere utilizzata durante la festività del 4 luglio negli Stati Uniti non ha valore prima di tale data.La riduzione del tempo di ciclo e la capacità di prevedere il tempo di ciclo con qualche certezza è comunque utile in tale esempio.Idealmente, vorremmo iniziare il lavoro in modo che la funzionalità venga fornita "al momento giusto", ovvero quando è richiesta e non troppo in anticipo rispetto alla data desiderata, né in ritardo, poiché una consegna tardiva comporta un costo per il ritardo.La fornitura JIT garantisce l'utilizzo ottimale delle risorse disponibili.Una fornitura anticipata implica la possibilità di aver eseguito il lavoro su qualcosa di diverso e di dover implicitamente affrontare un costo del ritardo.

Come conseguenza di questi tre motivi, Lean Software Development cerca di ridurre al minimo il tempo di flusso e di registrare i dati che consentono previsioni sul tempo di flusso.È necessario limitare la richiesta di assistenza per bug, lo spreco derivante da un sovraccarico causato da un ritardo nella correzione dei bug e ottimizzare il valore restituito evitando sia il costo del ritardo che il costo opportunità dei rinvii.

Ridurre lo spreco per migliorare l'efficienza

Per ciascuna attività con valore aggiunto esistono attività di impostazione, pulizia e consegna necessarie ma che non aggiungono valore per sé stesseAd esempio, un'iterazione di progetto che sviluppa un incremento di software funzionante richiede una pianificazione (o un'attività di installazione), un ambiente ed eventualmente una diramazione del codice nel controllo della versione (noto comunemente come gestione della configurazione e anche un'attività di installazione), un piano di rilascio e l'esecuzione della versione effettiva (un'attività di consegna), una dimostrazione al cliente (un'attività di consegna) e probabilmente un teardown o una riconfigurazione dell'ambiente (un'attività di pulizia). In termini economici, le attività di impostazione, pulizia e consegna sono costi di transazione sull'esecuzione del lavoro a valore aggiunto.Questi costi, o costi generali, sono considerati uno spreco nel pensiero Lean.

Qualsiasi forma di sovraccarico di comunicazione può essere considerato residuo.Le riunioni per determinare lo stato del progetto e per pianificare e assegnare il lavoro ai membri del team saranno considerate un costo di coordinamento nel linguaggio economico.Tutti i costi di coordinamento sono considerati come spreco nel concetto Lean.I metodi Lean Software Development cercano di eliminare o ridurre i costi di coordinamento tramite l'uso dell'allocazione condivisa dei membri del team, brevi riunioni end-to-end, come le riunioni rapide, e controlli visivi come i "card wall".

La terza forma comune di spreco secondo il Lean Software Development è la richiesta di assistenza.La richiesta di assistenza è un peso nel sistema di sviluppo software.La richiesta di assistenza è in genere una rielaborazione o nuove forme di lavoro generate come effetto collaterale di qualità scadente.Le forme più comuni di richiesta di assistenza nello sviluppo software sono i bug, i difetti di produzione e le attività del servizio clienti determinate da un errato utilizzo del software.La percentuale di lavoro in corso che è richiesta di assistenza viene spesso indicata con il termine "failure load".La percentuale di lavoro a valore aggiunto rispetto alla richiesta di assistenza è una misura dell'efficienza del sistema.

La percentuale di lavoro a valore aggiunto rispetto al lavoro totale, inclusi tutti i costi di transazione e di coordinamento senza valore aggiunto, determina il livello di efficienza.Un sistema senza costi di coordinamento e transazioni e nessun carico di interruzione verrà considerato efficiente al 100%.

In genere, l'economia aziendale occidentale ha sempre insegnato che si può migliorare l'efficienza aumentando le dimensioni del batch di lavoro.In genere, i costi di transazione e di coordinamento sono fissi o aumentano solo leggermente con l'aumento della dimensione del batch.Di conseguenza, ampi batch di lavoro sono più efficaci.Questo concetto è noto come "economia di scala". Tuttavia, nei problemi di competenze, i costi di coordinamento tendono ad aumentare in modo non lineare con la dimensione del batch, mentre i costi possono spesso presentare una crescita lineare.Di conseguenza, l'approccio tradizionale del ventesimo secolo relativo all'efficienza non è appropriato per i problemi di consapevolezza nel lavoro come lo sviluppo del software.

È preferibile concentrarsi sulla riduzione dei sovraccarichi e limitare le dimensioni del batch per migliorare l'efficienza.Pertanto, il modo snello di essere efficienti consiste nel ridurre gli sprechi.I metodi Lean Software Development si concentrano su metodi di pianificazione veloci, economici e rapidi, sovraccarico di comunicazione ridotto ed efficaci meccanismi di coordinamento con sovraccarico ridotto, ad esempio i controlli visivi in sistemi kanban.Questi metodi incoraggiano l'automazione dei test e della distribuzione per ridurre i costi di transazione della consegna.Gli strumenti moderni per ridurre i costi di impostazione e il teardown dell'ambiente, come i moderni sistemi di controllo della versione e l'utilizzo della virtualizzazione, consentono inoltre di migliorare l'efficienza di piccole batch di sviluppo software.

Procedure

Lean Software Development non prescrive procedure.È più importante verificare che le effettive definizioni di processo siano allineate con principi e valori.Tuttavia, vengono comunemente adottate alcune procedure.In questa sezione viene fornita una breve panoramica di alcune di queste procedure.

Organigrammi cumulativi

Gli organigrammi cumulativi sono stati una parte standard della creazione di rapporti in Team Foundation Server dal 2005.Gli organigrammi cumulativi tracciano un grafico ad aree degli elementi di lavoro cumulativi in ogni stato di un flusso di lavoro.I diagrammi contengono numerose informazioni e possono essere utilizzati per derivare il tempo di ciclo medio tra i passaggi in un processo nonché la velocità effettiva (o “velocità").I processi differenti del ciclo di vita dello sviluppo software producono firme visive diverse sugli organigrammi cumulativi.I professionisti possibile apprendere come riconoscere i modelli di malfunzionamento del processo visualizzato nel grafico area.Un vero processo Lean mostrerà le aree di colore distribuite in modo uniforme, distribuiti di colore, aumentando uniformemente a un passo costante.L'immagine avrà un aspetto uniforme senza rugosità o macchie visibili di colore.

Nella forma più semplice, i diagrammi di flusso cumulativi vengono utilizzati per visualizzare la quantità di lavoro in corso in un determinato passaggio del ciclo di vita dell'elemento di lavoro.Può essere utilizzato per individuare i colli di bottiglia e osservare gli effetti di "mura" (variabilità nel flusso).

Controlli visivi

Oltre all'utilizzo di diagrammi di flusso cumulativi, i team di Lean Software Development utilizzano schede fisiche o proiezioni di sistemi di visualizzazione elettronici per visualizzare il lavoro e osservarne il flusso.Tali visualizzazioni aiutano i membri del team a osservare il lavoro in corso che si accumula e consentono di individuare colli di bottiglia e gli effetti di "mura". I controlli visivi consentono ai membri del team di organizzarsi per selezionare il lavoro e collaborare senza pianificazione o l'intervento o l'indicazione specifica del management.Questi controlli visivi vengono spesso definiti “card wall" o talvolta, erroneamente, “bacheche kanban".

Sistemi Kanban virtuali

Un sistema kanban è una procedura adottata dalla produzione snella.Utilizza un sistema delle carte fisiche per limitare la quantità di lavoro in corso in una qualsiasi fase specificata nel flusso di lavoro.Tali sistemi limitati di lavoro in corso creano un "pull" in cui il lavoro verrà avviato solo quando sono disponibili kanban per indicare che nuovo lavoro può essere "prelevato" in un particolare stato e il lavoro può proseguire.

In Lean Software Development, i kanban sono virtuali e spesso vengono rilevati impostando un numero massimo per un determinato passaggio nel flusso di lavoro di un tipo di elemento di lavoro.In alcune implementazioni, i sistemi elettronici tengono traccia del kanban virtuale e forniscono un segnale quando può essere iniziato un nuovo lavoro.Il segnale può essere visivo o sotto forma di avviso come un messaggio di posta elettronica.

I sistemi kanban virtuali vengono spesso utilizzati insieme a dei controlli visivi per offrire un sistema kanban virtuale visivo che rappresenta il flusso di lavoro di uno o più tipi di elementi di lavoro.Tali sistemi vengono spesso definiti "schede kanban" o "sistemi elettronici kanban". Un sistema kanban virtuale visivo è disponibile come plug-in per Team Foundation Server, denominato Visual WIP[20].Questo progetto è stato sviluppato come open source da Hakan Forss in Svezia.

Piccole dimensioni del batch/flusso di singole parti

Lean Software Development richiede che il lavoro venga intrapreso in piccoli batch, spesso indicati come "iterazioni" o "incrementi" o che il flusso degli elementi di lavoro sia indipendente, definito "flusso di singole parti" che richiede una strategia di gestione della configurazione avanzata per abilitare la consegna del lavoro completato ed evitare che il lavoro non completato non venga rilasciato accidentalmente.In genere ciò si ottiene utilizzando strategie di branching nel sistema di controllo della versione.Una piccola batch di lavoro viene in genere considerato un batch che può essere eseguito da un piccolo team di 8 utenti in meno di 2 settimane.

I piccoli batch e flusso di singole parti richiedono l'interazione frequente con titolari di azienda per riempire il backlog o la coda o il lavoro.Richiedono inoltre la capacità di pubblicare frequenti release.Per abilitare l'interazione frequente con il personale dell'azienda e la distribuzione frequente, è necessario ridurre i costi di coordinamento e di transazione di entrambe le attività.Un metodo comune per ottenere questo risultato è l'utilizzo dell'automazione.

Automazione

Lean Software Development prevede un livello elevato di automazione per abilitare economicamente il flusso di singole parti e per favorire l'alta qualità e la riduzione della richiesta di assistenza.L'utilizzo di test automatizzati, la distribuzione automatizzata e i software factory per automatizzare la distribuzione di modelli di progettazione e la creazione delle sezioni ripetitive di scarsa variabilità del codice sorgente saranno tutti comuni nei processi di Lean Software Development.

Eventi kaizen

Nella letteratura di produzione snella, il termine kaizen significa "miglioramento continuo" e un evento kaizen è l'atto di apportare una modifica a un processo o uno strumento che può determinare un miglioramento.

I processi Lean Software Development utilizzano diverse attività per generare eventi kaizen.Queste attività sono elencate di seguito.Ognuna di queste attività è progettata per stimolare una conversazione sui problemi che causano una riduzione della funzionalità e, di conseguenza, la possibilità di consegnare in base alle richieste.Il principio di kaizen sulla consapevolezza nel lavoro essenzialmente afferma è che è necessario spingere i gruppi di membri di team diversi e di competenze diverse a confrontarsi sui problemi.

Riunioni giornaliere in piedi

I team di sviluppatori di software, spesso fino a 50, in genere si incontrano davanti a un sistema di controllo visiva come una lavagna che presenta una visualizzazione del lavoro in corso.Vengono illustrati la dinamica di flusso e i fattori che influiscono sul flusso di lavoro.L'attenzione particolare viene effettuata a lavoro esternamente bloccato e al lavoro in ritardo a causa dei bug.Problemi relativi al processo sono spesso evidenti in una serie di riunioni rapide.Il risultato è che un gruppo ristretto di persone potrebbe fermarsi dopo la riunione per discutere il problema e proporre una soluzione o una modifica al processo.Seguirà un evento di kaizen.Le riunioni spontanee vengono spesso definite nella letteratura meno recente circoli di qualità spontanei.Tali riunioni spontanee sono alla base di una vera cultura kaizen.I manager incoraggeranno la comparsa di eventi kaizen gli eventi dopo le riunioni rapide giornaliere per determinare l'adozione di Lean all'interno dell'organizzazione.

Analisi retrospettive

I team di progetto possono impostare le riunioni periodiche per riflettere le prestazioni recenti.Questi incontri vengono spesso organizzati dopo che sono stati completati specifici risultati finali del progetto o dopo incrementi di durata fissa dello sviluppo noti come iterazioni o sprint nello sviluppo software Agile.

Le analisi retrospettive utilizzano generalmente un approccio aneddotico per la reflection utilizzando le applicazioni come "cosa è andato bene?", "cosa faremmo in modo diverso?" e "cosa non dovremo più fare"?

Le analisi retrospettive in genere producono un backlog dei suggerimenti per eventi kaizen.Il team può quindi dare priorità ad alcuni di questi nell'implementazione.

Revisioni di operazioni

La revisione di operazioni è in genere più ampia di una retrospettiva e include rappresentanti di un intero flusso di valore.È comune per un massimo di 12 reparti per presentare obiettivi, dati quantitativi che illustrano la richiesta che hanno ricevuto e riflettere la capacità di soddisfare la richiesta.Le revisioni di operazioni sono in genere eseguite mensilmente.Le principali differenze tra una revisione delle operazioni e un'analisi retrospettiva è che la prima spazia tra un set di funzioni più ampio, in genere un portafoglio di progetti e di altre iniziative, e utilizza dati quantitativi e oggettivi.Le analisi retrospettive, in confronto, tendono a essere limitate a un singolo progetto, includere solo alcuni team durante l'analisi, sviluppo e test; e sono in genere aneddotico in natura.

La revisione di operazioni genera discussioni sulle dinamiche che interessano le prestazioni tra team.Forse un team genera una richiesta di assistenza che viene elaborata da un altro team?Probabilmente la richiesta di assistenza è invasiva e causa al secondo team la mancanza di rispetto dei propri impegni e l'impossibilità di consegnare secondo le aspettative?La revisione di operazioni consente di illustrare tali problemi e di proporre modifiche.Le revisioni delle operazioni in genere producono un piccolo backlog di potenziali eventi kaizen che è possibile classificare in ordine di priorità e programmare per l'implementazione futura.

Non c'è nulla come un singolo processo di Lean Software Development.Un processo può definirsi Lean se è allineato chiaramente con i valori e i principi del Lean Software Development.Lean Software Development non prescrive alcuna procedura, ma alcune attività sono diventate comuni.Le organizzazioni Lean cercano di incoraggiare kaizen tramite la visualizzazione del flusso di lavoro e del lavoro in corso e mediante la comprensione delle dinamiche del flusso e dei fattori, quali colli di bottiglia, disponibilità non immediata, variabilità e spreco, che hanno effetto su di esse.I miglioramenti al processo sono consigliati e giustificati come mezzi per ridurre le origini di variabilità, eliminare lo spreco, aggiornare il flusso, o migliorare la consegna del valore o la gestione dei rischi.Di conseguenza, i processi Lean Software Development si evolveranno sempre e in modo univoco in modo adeguato all'organizzazione all'interno della quale si evolvono.Non sarà semplice copiare semplicemente una definizione del processo di un'organizzazione a un'altra e aspettarsi che funzioni in un contesto diverso.Sarà inoltre improbabile che ritornando a un'organizzazione dopo alcune settimane o mesi si trovi il processo in uso uguale a quello osservato precedentemente.Sarà sempre in evoluzione.

L'organizzazione che utilizza un processo di sviluppo software snello sarebbe ritenuta snella, ovvero Lean, se esibisse solo piccole quantità di spreco in tutti e tre i form ("mura", "muri" e "muda") e potesse dimostrare che sta ottimizzando il valore attraverso un'efficace gestione dei rischi.La ricerca della perfezione nel pensiero Lean è sempre lunga e complessa.Non è prevista alcuna destinazione.Le organizzazioni che sono veramente basate sul pensiero Lean sono sempre alla ricerca di un modo per migliorare ulteriormente.

Lean Software Development è ancora un campo emergente e si prevede che continuerà ad evolversi nel prossimo decennio.

1. Anderson, David J., Kanban: Successful Evolutionary Change for your Technology Business, Blue Hole Press, 2010

2. Anderson, David J., Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, Prentice Hall PTR, 2003

3. Womack, James P., Daniel T.Jones e Daniel Roos, The Machine That Changed the World: The Story of Lean Production, edizione aggiornata del 2007, Free Press, 2007

4. Womack, James P. e Daniel T.Jones, Lean Thinking: Banish Waste and Create Wealth in your Corporation, 2a edizione, Free Press, 2003

5. Beck, Kent et al, The Manifesto for Agile Software Development, 2001 http://www.agilemanifesto.org/

6. Highsmith, James A., Agile Software Development Ecosystems, Addison Wesley, 2002

7. Poppendieck, Mary e Tom Poppendieck, Lean Software Development: An Agile Toolkit, Addison Wesely, 2003

8. Poppendieck, Mary e Tom Poppendieck, Implementing Lean Software Development: From Concept to Cash, Addison Wesley, 2006

9. Poppendieck, Mary e Tom Poppendieck, Leading Lean Software Development: Results are not the Point, Addison Wesley, 2009

10. Reinertsen, Donald G., Managing the Design Factory, Free Press, 1997

11. Reinertsen, Donald G., The Principles of Product Development Flow: Second Generation Lean Product Development, Celeritas Publishing, 2009

12. Sutton, James and Peter Middleton, Lean Software Strategies: Proven Techniques for Managers and Developers, Productivity Press, 2005

13. Anderson, David J., Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, Prentice Hall PTR, 2003

14. Shalloway, Alan e Guy Beaver e James R.Trott, Lean-Agile Software Development: Achieving Enterprise Agility, Addison Wesley, 2009

15. Larman, Craig and Bas Vodde, Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-scale Scrum, Addison Wesley Professional, 2008

16. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Addison Wesley Professional, 2010

17. Coplien, James O.e Gertrud Bjornvig, Lean Architecture: for Agile Software Development, Wiley, 2010

18. http://leansystemssociety.org/credo/

19. http://lssc12.leanssc.org/

20. http://hakanforss.wordpress.com/2010/11/23/visual-wip-a-kanban-board-for-tfs/