{"id":34157,"date":"2019-10-31T21:56:43","date_gmt":"2019-10-31T18:56:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-nachat-devops-transformatsiyu\/"},"modified":"2019-10-31T21:56:43","modified_gmt":"2019-10-31T18:56:43","slug":"kak-nachat-devops-transformatsiyu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-nachat-devops-transformatsiyu","title":{"rendered":"Come iniziare la trasformazione DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Se non capisci cos'\u00e8 il DevOps, ecco un breve promemoria. DevOps \u00e8 un insieme di pratiche che riduce le paure degli ingegneri<\/strong> e diminuisce il numero di guasti nella produzione di software. Di solito, esse ridurranno il tempo di immissione sul mercato<\/strong> \u2014 il periodo dall'idea alla consegna del prodotto finale ai clienti, consentendo di eseguire rapidamente esperimenti aziendali<\/strong>.<\/p>\n

Come iniziare una trasformazione DevOps? In breve: selezioniamo il servizio con cui iniziare il processo, identifichiamo chi \u00e8 coinvolto nel servizio, costruiamo una Value Stream Map, creiamo un team temporaneo che si occuper\u00e0 della trasformazione inizialmente e diamo loro un compito. Ripetiamo il ciclo il numero di volte necessario.<\/p>\n

\"Come<\/p>\n

Un piano dettagliato per la trasformazione DevOps con esempi e istruzioni \u00e8 disponibile nel documento relazione<\/a><\/noindex> Andrey Alexandrov<\/b> \u2014 di un ingegnere dell'azienda Express42, che fornisce consulenze per sviluppare DevOps, accelerando questo processo poich\u00e9 ha gi\u00e0 costruito una mappa degli ostacoli. Se pensi che la trasformazione non ti possa servire, o se la tua specificit\u00e0 \u00e8 tale che le pratiche DevOps non si applicano, utilizza la relazione come una guida per identificare e rimuovere i vincoli.
\n<\/a><\/noindex>
\nSe hai domande sulla trasformazione DevOps, significa che hai una grande azienda e devi gradualmente scalare questo processo in tutta la struttura. Finch\u00e9 c'\u00e8 necessit\u00e0 di trasformare un team o rimuovere un vincolo, puoi ripetere l'algoritmo qui sotto.<\/p>\n

Scelta del servizio<\/h2>\n

\nIl piano \u00e8 stato impostato, iniziamo dal primo passo: la scelta del servizio. Il primo criterio \u00e8 la vita utile<\/strong>: ci sono servizi obsoleti \u2014 legacy, e nuovi. Puoi iniziare con entrambi.<\/p>\n

Scegliere un servizio giovane \u00e8 logico<\/strong>. \u00c8 fresco, non ci sono ancora processi di lavoro consolidati nel team che lo gestisce. Non c'\u00e8 un accumulo di debito tecnico, non \u00e8 necessario ripararlo continuamente. Possiamo farne ci\u00f2 che vogliamo.<\/p>\n

Nel caso di un servizio vecchio, ci sono problemi legati al fatto che cambiare \u00e8 sempre difficile<\/strong>. Ci sono gi\u00e0 serie limitazioni, ma potrebbero esserci persone pronte a rivoluzionare tutto \u2014 sono stufe e vogliono fare qualcosa in modo diverso, perch\u00e9 \u00e8 doloroso per loro.<\/p>\n

Lavorare con un servizio vecchio crea un forte precedente<\/strong> nella tua azienda \u2014 si possono apportare modifiche. Se hai modificato un nuovo servizio, che viene lanciato in produzione 100 volte all'ora, e tutto funziona bene, allora le persone nella tua azienda possono dire:<\/p>\n

\u2014 Questo \u00e8 un nuovo servizio! Era tutto cos\u00ec semplice, provate a fare qualcosa con la nostra vecchia carcassa.<\/em><\/p>\n

Ha senso prendere un servizio legacy per la trasformazione quando lo fate con qualcuno, per esempio, se avete invitato un consulente esterno. Siamo onesti, la trasformazione metter\u00e0 sotto pressione tutto ci\u00f2 che \u00e8 possibile.<\/strong>. Sperimentate e non sapete dove arriverete, quali tecnologie e perch\u00e9 utilizzerete, dove e quali insidie si presenteranno nei processi. Pertanto, \u00e8 pi\u00f9 facile cambiare il nuovo.<\/p>\n

Se fate tutto da soli e in azienda non ci sono competenze serie \u2014 prendete il nuovo servizio. Se conoscete un consulente esterno e ci sono fondi \u2014 scegliete il vecchio.<\/p><\/blockquote>\n

\nCi sono servizi che sono semplicemente interfacce per gli utenti, come un sito semplice o un'app mobile. Ma ci sono anche cose serie come la fatturazione. Se qualcosa va storto con la fatturazione \u2014 sar\u00e0 difficile risolvere. Qui abbiamo anche una scelta.<\/p>\n

Lavoriamo o con un servizio critico<\/strong>, ma gi\u00e0 a causa di esso soffriamo, crea vincoli, oppure lavoriamo con un'interfaccia<\/strong>. Questo \u00e8 il secondo criterio di scelta. Analogamente, c'\u00e8 la possibilit\u00e0 di coinvolgere un consulente esperto \u2014 lavoriamo con la variante pesante.<\/p>\n

Ma anche in questo caso non consiglio di procedere in questo modo, perch\u00e9, finch\u00e9 non c'\u00e8 comprensione di cosa lavorare e in quale direzione trasformare, prendere qualcosa di critico e ristrutturalo \u2014 non \u00e8 una buona idea. Pertanto, in questo caso, preferiamo lavorare con un'interfaccia, il cui malfunzionamento non \u00e8 critico.<\/p>\n

Passiamo a il team del servizio<\/b>. Con coloro che si occupano di questo servizio, ci tocca lavorare costantemente e interagire in un contatto molto stretto.<\/p>\n

Le persone nel team sono convenzionalmente divise in due categorie: conservatori<\/strong> \u2014 vivono nel vecchio mondo, oppure non sanno niente di DevOps, e innovatori<\/strong>, che portano tutte le pratiche alla moda. I secondi non sempre comprendono a fondo la materia, ma almeno sono pronti ad affrontarla.<\/p>\n

Da un lato, i conservatori sono persone esperte: sono in azienda da molto tempo, capiscono tutto, ma non conoscono le pratiche. Dall'altro lato, gli innovatori hanno sentito parlare di qualcosa, ma probabilmente lavorano in azienda da non molto tempo. Con chi \u00e8 meglio lavorare?<\/p>\n

I conservatori dovranno essere coinvolti in ogni caso, poich\u00e9 questo \u00e8 il loro servizio. Dovremo comunicare con loro, capire la specificit\u00e0 del servizio, cosa si pu\u00f2 fare in un modo e cosa in un altro. Siamo dipendenti dai loro consigli. Sicuramente dovremo affidare loro qualche compito, perch\u00e9 conoscono meglio il loro servizio. \u00c8 quindi importante con quale squadra avremo contatto alla fine.<\/p>\n

\u00c8 logico scegliere innovatori per il team, poich\u00e9 i conservatori potrebbero fare cose sbagliate.\n<\/p><\/blockquote>\n

\nNella pratica, spesso accade che le persone conservative abbiano un'esperienza significativa, ma non capiscano come andare avanti. Hanno semplicemente paura che dopo la trasformazione e la revisione del servizio, saranno licenziati per mancata necessit\u00e0. A volte, a causa della mancanza di comprensione di ci\u00f2 che sta succedendo, boicottano il lavoro.<\/p>\n

Ho avuto un caso in cui un ragazzo del team riparava qualsiasi cosa, perch\u00e9 sosteneva che fosse pi\u00f9 critico rispetto a quello che stavamo facendo. Impostiamo un compito: completare questo pezzo oggi \u2014 no, dall'altra parte del mondo c'\u00e8 un incendio, andiamo a sistemarlo. Lavorare con persone cos\u00ec \u00e8 difficile.<\/p>\n

Le persone nel team dei conservatori spesso ignorano i compiti o li rimandano all'ultimo minuto. E se, Dio non voglia, commettete un errore e assegnate loro KPI per il numero di compiti completati, e una parte di essi non \u00e8 inclusa nel KPI, non faranno nulla. In realt\u00e0, avrebbero ragione, perch\u00e9 allora perderebbero il bonus.<\/p>\n

Con gli innovatori \u00e8 pi\u00f9 facile \u2014 sono pi\u00f9 leali.<\/strong>Hanno gi\u00e0 sentito qualcosa, vogliono andare da qualche parte, quindi aiuteranno. Abbiamo bisogno di persone pronte a soffrire per un po': se il servizio cambia, tutte le difficolt\u00e0 e i problemi li affronteranno gli innovatori come pionieri. Gli innovatori desiderano tutto ci\u00f2 che \u00e8 nuovo e alla moda, e sono disposti a soffrire.<\/p>\n

I conservatori possono essere convertiti in seguito. Quando mostrerete che avete cambiato un pezzo e tutto funziona bene, probabilmente vorranno provare anche loro e accetteranno la nuova religione DevOps.<\/p>\n

\"Come
\n<\/p>\n

In sintesi. Se facciamo tutta la trasformazione nella nostra azienda da soli, scegliamo: un nuovo servizio, preferibilmente con un'interfaccia semplice, per non soffrire troppo a causa dei suoi guasti, e un team di innovatori.<\/p><\/blockquote>\n

\nSe c'\u00e8 la possibilit\u00e0 di chiamare un consulente esterno, invece di uno nuovo, prendiamo il vecchio servizio, che ci causa gi\u00e0 problemi. Le persone che si sono occupate di trasformazioni piuttosto a lungo in diverse aziende hanno visto casi diversi e gi\u00e0 comprendono come fare le cose nel modo giusto e in quale direzione andare.<\/p>\n

Chi \u00e8 coinvolto?<\/h2>\n

\nDobbiamo trovare tutti coloro che hanno anche solo un qualche rapporto con il servizio: sviluppatori, tester, amministratori, esperti di sicurezza, manager e, forse, Product Owners. Nonostante i Product Owners non siano tecnici, hanno un legame con il servizio: prendono decisioni e definiscono compiti.<\/p>\n

\"Come
\n<\/p>\n

Dobbiamo trovare, conoscere e interagire con tutti coloro che prendono decisioni e influenzano ci\u00f2 che accade al servizio.<\/p><\/blockquote>\n

\nA cosa ci servono? Per sapere con chi trattare.<\/strong>. Durante la trasformazione, quando il modo abituale di lavorare con il servizio cambia, ci saranno comunque delle turbolenze. Ci saranno interruzioni finch\u00e9 testiamo nuovi approcci. Le persone devono essere pronte e concordare su questo.<\/p>\n

In seguito dovremo costruire la Value Stream Map e senza queste persone non potremo farlo, perch\u00e9 solo insieme conoscono l'intera situazione. Una sola persona non sa mai tutto ci\u00f2 che accade con il servizio.<\/p>\n

Loro consiglieranno persone per il team. Pi\u00f9 avanti discuteremo perch\u00e9 \u00e8 necessaria un'\u00e9quipe separata. Dovremo coinvolgere persone dai reparti esistenti. Chi ha un rapporto con il servizio potr\u00e0 raccomandare colleghi che pensano nella nostra direzione, utili e competenti in ci\u00f2 di cui abbiamo bisogno.<\/p>\n

Dopo raccoglieremo tutte queste persone da reparti diversi in una stanza e iniziamo a costruire la Value Stream Map.<\/p>\n

Costruiamo la Value Stream Map.<\/h2>\n

\nLa Value Stream Map \u00e8 un diagramma o una mappa che mostra il flusso di valori fino al cliente.<\/strong>. Si tratta di tutto il processo dalla generazione dell'idea fino alla sua realizzazione, inclusi tutti i passaggi intermedi e come il valore alla fine arriva ai nostri clienti.<\/p>\n

La Value Stream Map \u00e8 necessaria per visualizzare tutte le fasi dello sviluppo<\/strong>, localizzare i problemi attraverso le misurazioni esistenti nel processo attuale e iniziare a risolverli, e stabilire un obiettivo iniziale<\/strong>. Questo \u00e8 il punto in cui inizieremo a fare qualcosa di concreto.<\/p>\n

Metriche<\/h3>\n

\nLa letteratura sulla Value Stream Map descrive molte metriche diverse, ma per iniziare ci bastano tre.<\/p>\n

Lead Time \u2014 ritardo\/attesa<\/strong> \u2014 tempo in cui aspettiamo qualcosa. Ad esempio, un tester aspetta che un banco di test diventi libero e in quel momento non pu\u00f2 fare nulla.<\/p>\n

Value Added Time \u2014 tempo di lavoro utile<\/strong> \u2014 quello che abbiamo impiegato in una certa fase per creare un valore finale per l'utente. Ad esempio, il tester ha avviato il suo test e ha iniziato a controllare qualcosa. Questo \u00e8 il tempo di lavoro utile, quando facciamo realmente qualcosa per il prodotto. \u00c8 ci\u00f2 per cui i clienti pagano \u2014 per software di qualit\u00e0.<\/p>\n

%C\/A \u2014 percentuale di lavoro accettato. <\/strong>Abbiamo una fase \u2014 sviluppo, la seconda fase \u2014 collaudo. Quante funzionalit\u00e0 sono state accettate dai tester dagli sviluppatori, e c'\u00e8 questa percentuale.<\/p>\n

Circa cos\u00ec appare la nostra mappa.<\/p>\n

\"Come
\n
\nPu\u00f2 apparire diversa a seconda della struttura dell'organizzazione, del numero di reparti e di cosa vi occupate. Ma in generale sulla mappa ci saranno due fasi: un'idea <\/strong>e analisi<\/strong>. In questa fase si attendono dati, ad esempio, Lead Time 2 settimane e Value Added Time 2 giorni.<\/p>\n

Le metriche coprono assolutamente tutte le fasi.<\/p><\/blockquote>\n

\nBacklog<\/strong> \u2014 quante attivit\u00e0 erano in attesa dopo che gli analisti le hanno concepite.<\/p>\n

Sviluppo<\/strong> \u2014 quante settimane gli sviluppatori hanno aspettato chiarimenti sulle attivit\u00e0, banchi di prova o attrezzature \u2014 non importa, ma stanno aspettando qualcosa. Ad esempio, implementano una funzionalit\u00e0 per 4 giorni. Qui entra in gioco la metrica %C\/A. Gli sviluppatori hanno preso dal backlog solo l'80% delle attivit\u00e0. Ritengono che per il restante 20% non ci siano requisiti sufficientemente chiari e li hanno inviati per revisione.<\/p>\n

Test<\/strong>. Nello schema LT \u00e8 impostato a 4 giorni. Ad esempio, i tester hanno aspettato la liberazione del banco di prova, VA 2 giorni in cui realizzano effettivamente dei test, e %C\/A = 40%. \u2014 solo il 40% del codice o delle funzionalit\u00e0 che gli sviluppatori hanno inviato \u00e8 stato considerato adeguato dai tester. Tutto il resto non \u00e8 piaciuto per qualche motivo.<\/p>\n

Non mi soffermer\u00f2 a lungo su come effettuare queste misurazioni; alla fine dell'articolo consiglier\u00f2 della letteratura da cui \u00e8 possibile trarre informazioni.<\/p>\n

L'unica cosa che consiglio \u00e8 di non fidarvi delle persone che compileranno con voi la Value Stream Map. Rappresentano quanto tempo ci vogliono diversi processi, ma queste valutazioni non sono sempre corrette, quindi \u00e8 meglio misurare voi stessi.<\/p>\n

Ci sono stati casi in cui siamo entrati nel reparto Operations e abbiamo chiesto quanto tempo ci vuole per consegnare una nuova funzionalit\u00e0 in produzione. Ci hanno risposto che ci vogliono 10 minuti e ci siamo detti: perch\u00e9 siamo venuti in questa azienda? \u00c8 emerso che 10 minuti \u00e8 il tempo di esecuzione di uno script che prende il codice e lo consegna al server. Ma prima di questo, il rilascio rimane sul server per tre giorni e semplicemente rimane inutilizzato \u2014 c'\u00e8 un compito nel Backlog che deve essere implementato. Risultato: prima della fase di deploy c'\u00e8 una fase di attesa in cui il progetto rimane in sospeso. Se non avessimo portato un bloc-notes, non avessimo notato il compito in Jira e non avessimo iniziato a monitorarlo passo passo, avremmo pensato che tutto andasse bene e che non ci fossero problemi.<\/p>\n

Pertanto, sar\u00e0 necessario effettuare le misurazioni da soli, preferibilmente non solo una volta, per avere un'idea vicina alla realt\u00e0. In base alla Value Stream Map, prenderete decisioni su da dove iniziare e cosa correggere per primo.<\/p>\n

Team temporaneo<\/h2>\n

\nMolte aziende che hanno deciso di implementare DevOps creano team, ma non temporanei, bens\u00ec esistenti da diversi anni. Se consultate il servizio DevOps apologize, che descrive vari schemi per la costruzione della struttura organizzativa in DevOps, capirete che si tratta di un antipattern.<\/p>\n

Quando un team DevOps esiste costantemente per diversi anni, \u00e8 un grande errore, perch\u00e9 DevOps riguarda la comunicazione tra i reparti, velocit\u00e0 ed efficienza.<\/p><\/blockquote>\n

\nSe il team esiste tra i reparti solo per fare qualcos'altro di separato e esiste a lungo, crea un ulteriore ostacolo. Ora il programmatore, invece di andare direttamente all'amministratore per risolvere il problema, deve prima contattare il reparto DevOps, e questo poi andr\u00e0 avanti.<\/p>\n

Pertanto, per iniziare, \u00e8 necessario creare un team temporaneo<\/strong>. Durer\u00e0 convenzionalmente sei mesi, al massimo un anno, a seconda dell'obiettivo stabilito, solo per eliminare un vincolo che abbiamo scelto. Dopo, morir\u00e0. Se scegliamo il prossimo punto in cui ci fa molto male e capiamo che anche per questo abbiamo bisogno di un team separato, allora lo creeremo di nuovo. Ma in modo permanente, tali team non dovrebbero esistere \u2014 altrimenti interrompono la comunicazione e assumono compiti del tutto separati, solo per fare qualcosa. Questi compiti potrebbero non essere affatto correlati a DevOps e alla trasformazione. Perch\u00e9 non possiamo affidare questo compito ai reparti esistenti?<\/p>\n

Perch\u00e9 \u00e8 necessario un team temporaneo<\/h3>\n

\nConflitto con i processi attuali<\/strong>. La trasformazione DevOps \u00e8 un cambiamento non solo delle tecnologie e degli strumenti che utilizziamo, ma anche del processo di lavoro, della mentalit\u00e0 e dei valori. Se il team lavora come \u00e8 gi\u00e0 abituato, non riuscir\u00e0 a provare approcci diversi.<\/p>\n

Queste persone devono vivere secondo altre regole: ignorare tutti i KPI in azienda, perch\u00e9 stanno cercando di lavorare in modo diverso. I team temporanei non presenteranno richieste per ottenere un server, ma andranno direttamente al dipartimento che se ne occupa, chiedendo di avere per primi ci\u00f2 di cui hanno bisogno, perch\u00e9 \u00e8 un compito prioritario e perch\u00e9 stanno cercando di vivere in modo diverso. Il team ha un conflitto totale con tutti i processi attuali. Affinch\u00e9 i metodi di lavoro esistenti non interferiscano ora con loro e loro non interferiscano con gli altri, isolemo queste persone, costituendo un team separato.<\/p>\n

Evitare la burocrazia negli esperimenti<\/strong>. Nei team temporanei non c'\u00e8 burocrazia, non compilano report sulle ore lavorate, non rendono conto ai manager. Questo \u00e8 un mondo completamente separato, in cui le persone vivono e pensano in modo diverso, e si dedicano a cose completamente diverse. Non devono essere disturbati inutilmente.<\/p>\n

Lavoro incessante sul servizio<\/strong>. Nel primo punto abbiamo scelto qualcosa su cui sperimentare. Gli esperimenti e la ricerca di modi migliori per lavorare sono utili, ma vogliamo anche realizzare delle funzionalit\u00e0. Se l'intero team si dedica alla trasformazione invece che alle funzionalit\u00e0, iniziamo a perdere entrate, i bug rimarranno a lungo \u2014 non \u00e8 ci\u00f2 di cui abbiamo bisogno. Creare un team temporaneo consente di sperimentare, senza fermare il lavoro sul prodotto.<\/p>\n

Non perdere tempo con i compiti lavorativi<\/strong>. Si tratta di nuovo del prodotto. Ci vuole molto tempo affinch\u00e9 il team provi altri strumenti e altro ancora. Per permettere alle persone di apprendere gli strumenti, iniziare a implementarli e usarli correttamente, passer\u00e0 almeno mezzo anno. Se si occupano anche del prodotto, quel mezzo anno si allungher\u00e0 in modo esponenziale. Se le persone si occupano del prodotto, lavorano di nuovo con i vecchi processi \u2014 non ne abbiamo bisogno.<\/p>\n

Ecco perch\u00e9 selezioniamo persone da diversi reparti per creare un team separato, che si occuper\u00e0 della trasformazione del servizio. Di conseguenza, il servizio funziona, continua a evolversi e nel contempo facciamo esperimenti su di esso.<\/p>\n

Il team temporaneo si occupa solo della trasformazione DevOps \u2014 eliminando quelle limitazioni che abbiamo trovato, e nient'altro.<\/p><\/blockquote>\n

\nIl team \u00e8 composto da persone versatili<\/strong>. Questo significa che non abbiamo preso solo sviluppatori. Non siamo entrati nel servizio per portare via met\u00e0 del team \u2014 no, abbiamo preso persone da diversi reparti<\/strong>. Alcuni punti fa abbiamo identificato diversi reparti e impiegati coinvolti nel servizio che stiamo trasformando. Da loro formiamo un team perch\u00e9 deve essere versatile \u2014 cambieremo sia il processo di test, sia il processo di sviluppo che il processo di gestione del servizio. Sono necessarie diverse competenze.<\/p>\n

Di solito prendiamo un sviluppatore, un tester e un ingegnere \u2014 uno ciascuno, e insieme a loro inventiamo una soluzione che ci permette di vivere diversamente.<\/p>\n

\u00c8 preferibile che queste persone abbiano autorit\u00e0 all'interno dell'organizzazione<\/strong>. Potrebbe essere necessario prendere un conservatore, anche se non ci piace. Se abbiamo una grande azienda, non tutti crederanno nella nostra iniziativa, e qualcuno potrebbe ostacolarci, ad esempio non assegnando un ambiente di prova. Qui ci vuole un \u00abautorevole\u00bb \u2014 una persona rispettata con molta esperienza, che ha guadagnato la stima dei colleghi. L'autorit\u00e0 di un membro del team semplificher\u00e0 il compito e il lavoro del team temporaneo. Le persone penseranno:<\/p>\n

\u2014 Ah, questo tizio \u00e8 fantastico, lo conosciamo e lo amiamo, si \u00e8 unito a noi \u2014 evidentemente c'\u00e8 qualcosa nel DevOps che merita attenzione!<\/em><\/p>\n

Poniamo un obiettivo<\/h2>\n

\nAbbiamo raccolto le persone, scelto il servizio, esaminato le limitazioni, identificato le persone su cui avremo un impatto. Ora dobbiamo fissare un obiettivo e deve essere chiaro secondo il metodo SMART<\/strong> \u2014 tutto come ci piace.<\/p>\n

Specifico \u2014 specifica<\/strong>.<\/p>\n

Misurabile \u2014 misurabile<\/strong>. Questo \u00e8 un punto molto importante dello SMART. Se non puoi misurare qualcosa, non puoi cambiarlo e capire cosa hai fatto meglio o peggio.<\/p>\n

Realizzabile \u2014 realizzabile<\/strong>. Fai una considerazione sulla tua specificit\u00e0. Se sei un'impresa con una lunga storia e un grande carico di responsabilit\u00e0, che rilascia una versione di prodotto all'anno, non potrai raggiungere una versione ogni ora in sei mesi. Non \u00e8 possibile. Pertanto, fissa un obiettivo realistico, che possa essere raggiunto in un tempo accettabile.<\/p>\n

Rilevante \u2014 rilevante. <\/strong>Eliminiamo solo quella limitazione che perseguita realmente i nostri obiettivi attuali.<\/p>\n

Limitato nel tempo \u2014 limitato nel tempo<\/strong>. Se non c'\u00e8 una scadenza, il team si occuper\u00e0 di qualsiasi cosa: provare 15 tecnologie invece di 3, scrivere enormi rapporti, condurre ricerche inutili, rifinire la propria implementazione fino alla perfezione, quando l'obiettivo \u00e8 gi\u00e0 stato raggiunto.<\/p>\n

L'obiettivo lo prendiamo proprio con l'aiuto della Value Stream Map \u2014 raccogliamo nuovamente tutte le persone e disegniamo. Ma ora, sulla base della precedente Value Stream Map, disegniamo ci\u00f2 che vogliamo ottenere.<\/p>\n

\"Come
\n
\nIsoliamo una limitazione che andremo ad eliminare subito, che sar\u00e0 il compito del team. Ad esempio, ho preso l'attesa tra il rilascio pronto e il suo deployment in produzione: \u00e8 la limitazione pi\u00f9 comune per cui le persone si rivolgono ai consulenti.<\/p>\n

Sulla base di questo, poniamo un compito: vogliamo che l'attesa tra il rilascio pronto e l'uscita in azione, sia massimo di un'ora.<\/p>\n

Esempi di compiti.<\/p>\n