{"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 avviare una trasformazione DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Se non sai cosa sia 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 software. Di norma, esse riducono il time-to-market<\/strong> \u2014 il periodo che va dall'idea alla consegna del prodotto finale ai clienti, permettendo di condurre rapidamente esperimenti aziendali.<\/strong>.<\/p>\n

Come avviare una trasformazione DevOps? In breve: scegliamo il servizio da cui iniziare il processo, identifichiamo le persone coinvolte nel servizio, costruiamo una Value Stream Map, creiamo un team temporaneo che si occuper\u00e0 della trasformazione per il primo periodo e assegnamo loro un compito. Ripetiamo il ciclo il numero necessario di volte.<\/p>\n

\"Come<\/p>\n

Un piano dettagliato per la trasformazione DevOps con esempi e istruzioni \u00e8 disponibile nell'articolo a seguire del relatore<\/a><\/noindex> Andrei Alexandrov<\/b> \u2014 di un ingegnere della compagnia Express42, che offre consulenze per implementare DevOps, accelerando questo processo grazie alla mappatura delle difficolt\u00e0. Se pensi che la trasformazione non ti riguardi o che le pratiche DevOps non siano adatte alla tua specificit\u00e0, utilizza il rapporto come guida per identificare e risolvere i vincoli.
\n<\/a><\/noindex>
\nSe hai preoccupazioni riguardo alla trasformazione DevOps, significa che hai una grande azienda e devi scalare gradualmente questo processo in tutta la struttura. Fintanto che c'\u00e8 la necessit\u00e0 di trasformare il team o di risolvere qualche limitazione, l'algoritmo qui sotto pu\u00f2 essere ripetuto.<\/p>\n

Scelta del servizio<\/h2>\n

\nPiano definito, iniziamo con il primo passo: la scelta del servizio. Il primo criterio \u00e8 la durata<\/strong>: ci sono servizi obsoleti - legacy, e nuovi. Si pu\u00f2 iniziare sia con i vecchi che con i nuovi.<\/p>\n

Scegliere un servizio giovane \u00e8 logico<\/strong>. \u00c8 fresco, non c'\u00e8 ancora un processo di lavoro consolidato nel team che ci lavora. Non c'\u00e8 un'enorme quantit\u00e0 di debito tecnico, non \u00e8 necessario ripararlo continuamente. Possiamo fare tutto ci\u00f2 che vogliamo con esso.<\/p>\n

Nel caso di un servizio vecchio ci sono problemi legati al fatto che cambiare \u00e8 sempre difficile<\/strong>. Ci sono gi\u00e0 un certo numero di limitazioni significative, ma potrebbe esserci qualcuno che \u00e8 gi\u00e0 pronto a rivedere tutto \u2014 sono stanchi e vogliono fare le cose in modo diverso, perch\u00e9 stanno soffrendo.<\/p>\n

Lavorare con un servizio vecchio crea un potente precedente<\/strong> nella vostra azienda - c'\u00e8 spazio per dei cambiamenti. Se avete introdotto un nuovo servizio, questo va in produzione 100 volte all'ora e funziona bene, le persone nella vostra azienda potrebbero dire:<\/p>\n

\u2014 Questo \u00e8 un nuovo servizio! Prima era tutto semplice, provate a fare qualcosa con il nostro cocciuto.<\/em><\/p>\n

Ha senso prendere in considerazione un servizio legacy per la trasformazione quando la si fa insieme a qualcuno, per esempio se avete invitato un consulente esterno. Siamo onesti, la trasformazione metter\u00e0 alla prova tutto ci\u00f2 che \u00e8 possibile.<\/strong>. Stai sperimentando e non sai dove arriverai, quali tecnologie e perch\u00e9 utilizzerai, dove e quali insidie emergeranno nei processi. Quindi \u00e8 pi\u00f9 facile cambiare se \u00e8 nuovo.<\/p>\n

Se fai tutto tu stesso e in azienda non ci sono competenze solide, scegli un nuovo servizio. Se conosci un consulente esterno e hai i fondi - opta per quello vecchio.<\/p><\/blockquote>\n

\nCi sono servizi che sono semplicemente un'interfaccia per 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, sar\u00e0 complicato risolvere il problema. Qui abbiamo anche una scelta.<\/p>\n

Lavoriamo o con un servizio critico<\/strong>, ma gi\u00e0 a causa di questo stiamo soffrendo, crea vincoli, o lavoriamo con l'interfaccia<\/strong>. Questo \u00e8 il secondo criterio di scelta. Allo stesso modo, c'\u00e8 la possibilit\u00e0 di coinvolgere un consulente esperto - lavoriamo con la variante complessa.<\/p>\n

Ma anche in questo caso non lo consiglierei, perch\u00e9, finch\u00e9 non c'\u00e8 comprensione su cosa lavorare e in quale direzione trasformarsi, prendere qualcosa di critico e modificarlo - non \u00e8 una buona idea. Pertanto, in questo caso preferiamo lavorare con l'interfaccia, il cui malfunzionamento non \u00e8 critico.<\/p>\n

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

Le persone nel team si dividono convenzionalmente in due categorie: conservatori<\/strong> - vivono nel vecchio mondo, oppure semplicemente non sanno nulla di DevOps, e innovatori<\/strong>, che portano tutte le pratiche alla moda. I secondi non sempre comprendono l'argomento, ma almeno sono pronti ad affrontarlo.<\/p>\n

Da un lato ci sono i conservatori: persone esperte che sono in azienda da tempo e conoscono ogni cosa, ma non sanno esattamente come applicare le pratiche. Dall'altro lato ci sono gli innovatori, che hanno sentito parlare di qualcosa, ma probabilmente non lavorano in azienda da molto tempo. Con chi di loro \u00e8 meglio lavorare?<\/p>\n

Dovremo interagire con i conservatori in ogni caso, poich\u00e9 questo \u00e8 il loro servizio. Sar\u00e0 necessario parlare con loro, comprendere la specificit\u00e0 del servizio e capire cosa si pu\u00f2 fare e cosa no. Siamo dipendenti dalle loro consulenze. Sicuramente dovremo affidare loro dei compiti, perch\u00e9 conoscono meglio il loro servizio. Pertanto, \u00e8 importante quale team alla fine avremo modo di contattare.<\/p>\n

\u00c8 logico scegliere gli innovatori per il team, perch\u00e9 i conservatori potrebbero ostacolare il progresso.\n<\/p><\/blockquote>\n

\nIn pratica, spesso succede che le persone conservative abbiano una notevole esperienza, ma non comprendano come andare avanti. Hanno solo paura che, dopo la trasformazione e la riprogettazione del servizio, verranno licenziati per superfluit\u00e0. A volte, semplicemente per mancanza di comprensione di ci\u00f2 che sta accadendo, sabotano il lavoro.<\/p>\n

Ho avuto un caso in cui un ragazzo del team riparava qualunque cosa, perch\u00e9 era suppostamente pi\u00f9 critico di ci\u00f2 che stavamo facendo in quel momento. Assegniamo un compito: implementare oggi questo pezzo - no, dall'altra parte del mondo c'\u00e8 un incendio, andiamo a ripararlo. Lavorare con queste persone \u00e8 difficile.<\/p>\n

Le persone del team conservatore spesso trascurano i compiti o li rimandano fino all'ultimo. E se, Dio non voglia, commetti un errore e assegni loro KPI basati sul numero di compiti completati, mentre una parte non \u00e8 inclusa nei KPI, allora non faranno niente. In effetti, avranno ragione perch\u00e9 perderebbero il premio.<\/p>\n

Con gli innovatori \u00e8 pi\u00f9 semplice: sono pi\u00f9 leali.<\/strong>Hanno gi\u00e0 sentito qualcosa, vogliono andare da qualche parte, quindi saranno d'aiuto. Ci servono persone pronte a soffrire all'inizio: se il servizio cambia, tutte le difficolt\u00e0 e le sfide ricadranno sugli innovatori come pionieri. Gli innovatori vogliono tutto ci\u00f2 che \u00e8 nuovo e alla moda, e sono pronti a soffrire.<\/p>\n

I conservatori possono essere convertiti pi\u00f9 tardi. Quando mostrerai che hai cambiato un pezzo e tutto funziona bene, probabilmente vorranno anche loro provare e accetteranno la nuova religione DevOps.<\/p>\n

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

Riassumiamo. Se facciamo tutta la trasformazione internamente, scegliamo: un nuovo servizio, preferibilmente con un'interfaccia semplice, in modo da non soffrire troppo per eventuali malfunzionamenti, e un team di innovatori.<\/p><\/blockquote>\n

\nSe \u00e8 possibile coinvolgere un consulente esterno, invece di adottare un nuovo servizio, utilizziamo quello vecchio, con cui gi\u00e0 abbiamo delle difficolt\u00e0. Le persone che si sono occupate di trasformazioni in diverse aziende per un lungo periodo hanno visto casi differenti e comprendono gi\u00e0 come procedere in modo corretto e quale direzione prendere.<\/p>\n

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

\nDobbiamo trovare tutti coloro che hanno anche solo un minimo di relazione con il servizio: sviluppatori, tester, amministratori, professionisti della sicurezza, manager e, forse, Product Owners. Anche se i Product Owners non sono tecnici, hanno un ruolo nel servizio: prendono decisioni e impostano compiti.<\/p>\n

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

Dobbiamo trovare, conoscere e comunicare 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 negoziare<\/strong>. Durante la trasformazione, quando il consueto modo di lavorare con il servizio cambia, ci saranno comunque delle difficolt\u00e0. Per un certo periodo si verificheranno guasti mentre testiamo nuovi approcci. Le persone devono essere pronte e accettare questo.<\/p>\n

In seguito sar\u00e0 necessario costruire la Value Stream Map e senza queste persone non sar\u00e0 possibile, perch\u00e9 solo loro insieme conoscono il quadro completo. Un singolo individuo non conosce mai tutto ci\u00f2 che accade con il servizio.<\/p>\n

Possono consigliare persone per il team. Pi\u00f9 avanti discuteremo del perch\u00e9 sia necessaria una squadra separata. Dobbiamo coinvolgere persone dai reparti esistenti. Coloro che hanno a che fare con il servizio potranno consigliare colleghi che la pensano come noi, in grado di aiutarci e con le competenze necessarie.<\/p>\n

Successivamente riuniamo tutte queste persone da diversi reparti 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 valore verso il cliente<\/strong>. \u00c8 l'intero processo dall'ideazione fino all'implementazione, 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 presenti nel processo attuale e iniziare a risolverli, e definire un obiettivo iniziale<\/strong>. \u00c8 qui che iniziamo a fare qualcosa di concreto.<\/p>\n

Metriche<\/h3>\n

\nNella letteratura sul Value Stream Map vengono descritte molte metriche diverse, ma per iniziare ci bastano solo tre.<\/p>\n

Lead Time \u2014 ritardo\/attesa<\/strong> \u2014 \u00e8 il tempo in cui aspettiamo qualcosa. Ad esempio, un tester aspetta che si liberi un banco per i test e in quel tempo non pu\u00f2 fare nulla.<\/p>\n

Value Added Time \u2014 tempo di lavoro utile<\/strong> \u2014 \u00e8 il tempo speso in una certa fase per creare valore finale per l'utente. Ad esempio, il tester avvia il suo test e inizia a controllare qualcosa. Questo \u00e8 il tempo di lavoro utile, quando stiamo effettivamente facendo qualcosa per il prodotto. \u00c8 ci\u00f2 per cui i clienti pagano: per un software di qualit\u00e0.<\/p>\n

%C\/A \u2014 percentuale di lavoro accettato. <\/strong>Abbiamo una fase \u2014 sviluppo, una seconda fase \u2014 test. Quante funzioni i tester hanno accettato 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 si fa. Ma in generale, nella mappa ci saranno due fasi: idea <\/strong>e analisi<\/strong>. In questa fase ci si aspetta di avere dati, ad esempio, Lead Time 2 settimane e Value Added Time 2 giorni.<\/p>\n

Copriamo metriche per tutte le fasi.<\/p><\/blockquote>\n

\nBacklog<\/strong> \u2014 quante attivit\u00e0 sono rimaste dopo che gli analisti le hanno generate.<\/p>\n

Sviluppo<\/strong> \u2014 quante settimane gli sviluppatori hanno atteso chiarimenti su attivit\u00e0, stand o attrezzature: non importa, ma stanno aspettando qualcosa. Ad esempio, per 4 giorni implementano una funzionalit\u00e0. Qui compare la metrica %C\/A. Gli sviluppatori hanno preso dal Backlog solo l'80% delle attivit\u00e0. Ritengono che il 20% rimanente non abbia un chiaro specificatione dei requisiti e lo hanno rimandato per ulteriori lavori.<\/p>\n

Test<\/strong>. Nello schema LT sono previsti 4 giorni. Ad esempio, i tester hanno atteso la liberazione dello stand di test, VA 2 giorni stanno realmente testando qualcosa, e %C\/A = 40%. \u2014 solo il 40% del codice o delle funzionalit\u00e0 che gli sviluppatori hanno inviato \u00e8 stato ritenuto adeguato dai tester. Tutto il resto non \u00e8 piaciuto per qualche motivo.<\/p>\n

Non approfondir\u00f2 come eseguire queste misurazioni; alla fine dell'articolo consiglier\u00f2 della letteratura in cui si pu\u00f2 approfondire.<\/p>\n

L'unico consiglio che posso darvi \u00e8 di non fidarvi delle persone che vi aiuteranno a creare una Value Stream Map. Possono indicare quanto tempo impiegano i vari processi, ma queste stime non sono sempre corrette; quindi \u00e8 meglio misurare voi stessi.<\/p>\n

Ci siamo trovati in una situazione in cui siamo andati nel reparto Operations e abbiamo chiesto quanto tempo ci volesse per portare una nuova funzionalit\u00e0 in produzione. Ci hanno risposto che ci volevano 10 minuti, e noi ci siamo chiesti perch\u00e9 fossimo mai entrati in questa azienda. Si \u00e8 scoperto che i 10 minuti riguardano il tempo necessario allo script per prelevare il codice e inviarlo al server. Ma prima di questo, il rilascio rimane per tre giorni sul server a prendere polvere \u2014 c'\u00e8 un'attivit\u00e0 nel Backlog che deve essere distribuita. In pratica, prima della fase di deploy c'\u00e8 una fase di attesa in cui il progetto rimane fermo. Se non fossimo andati con un taccuino, non avessimo notato l'attivit\u00e0 in Jira e non avessimo iniziato a monitorarla passo dopo passo, avremmo pensato che tutto andasse benissimo e che non ci fossero problemi.<\/p>\n

Pertanto, sar\u00e0 necessario effettuare le misurazioni da soli, preferibilmente non una sola volta, per avere un'idea vicina alla realt\u00e0. A seconda della 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 un team che non \u00e8 temporaneo, ma esiste da diversi anni. Se consultate il servizio DevOps apologize, che descrive diversi modelli di struttura organizzativa in DevOps, capirete che si tratta di un anti-modello.<\/p>\n

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

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

Pertanto, per iniziare, \u00e8 necessario creare un team temporaneo.<\/strong>. Avr\u00e0 una durata approssimativa di sei mesi, al massimo un anno, a seconda dell'obiettivo stabilito, solo per rimuovere una limitazione che abbiamo scelto. Poi, terminer\u00e0. Se scegliamo il prossimo punto in cui abbiamo un forte dolore e comprendiamo che per quello ci serve un altro team, lo ricreeremo. Ma le squadre non dovrebbero esistere in modo 'permanente' \u2014 altrimenti disturbano la comunicazione e assumono compiti a s\u00e9 stanti, solo per fare qualcosa. Queste attivit\u00e0 potrebbero non avere nulla a che fare con DevOps e con la trasformazione. Perch\u00e9 non affidare questo compito ai dipartimenti esistenti?<\/p>\n

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

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

Queste persone devono vivere secondo regole diverse: ignorare tutti i KPI dell'azienda, poich\u00e9 stanno cercando di lavorare in modo differente. I team temporanei non compileranno le richieste per ottenere un server, ma andranno direttamente al dipartimento che se ne occupa, richiedendo di ricevere 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. Per fare in modo che i metodi di lavoro esistenti non ostacolino loro ora e che loro non ostacolino gli altri, isoliamo queste persone creando 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. Questa \u00e8 assolutamente un'altra dimensione, dove le persone vivono e pensano in modo diverso e si occupano di cose totalmente diverse. Non devono essere disturbati inutilmente.<\/p>\n

Lavoro continuo sul servizio<\/strong>. Nel primo punto abbiamo scelto qualcosa su cui sperimentare. Gli esperimenti e la ricerca di modi per lavorare meglio sono importanti, ma vogliamo anche sviluppare funzionalit\u00e0. Se l'intero team si concentra sulla trasformazione invece che sulle funzionalit\u00e0, inizieremo a perdere ricavi e i bug rimarranno a lungo irrisolti \u2014 questo 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 su attivit\u00e0 lavorative<\/strong>. Questo riguarda nuovamente il prodotto. Per far s\u00ec che il team provi altri strumenti e altro ancora, ci vuole molto tempo. Ci vorranno almeno sei mesi affinch\u00e9 le persone apprendano gli strumenti, inizino a implementarli e li utilizzino correttamente. Se sono anche occupati con il prodotto, sei mesi sembreranno un'eternit\u00e0. Se le persone si occupano del prodotto, torneranno a lavorare con i vecchi processi \u2014 questo non \u00e8 ci\u00f2 di cui abbiamo bisogno.<\/p>\n

Perci\u00f2, selezioniamo persone da diversi reparti per formare un team separato che si occuper\u00e0 della trasformazione del servizio. Di conseguenza, il servizio continua a funzionare e a evolversi, mentre sperimentiamo con esso.<\/p>\n

Il team temporaneo si occupa esclusivamente della trasformazione DevOps, rimuovendo le limitazioni che abbiamo individuato, e nient'altro.<\/p><\/blockquote>\n

\nIl team \u00e8 composto da persone multifunzionali<\/strong>. Questo significa che non abbiamo incluso solo sviluppatori. Non siamo entrati nel servizio e non abbiamo prelevato mezzo team, no, abbiamo scelto persone provenienti da diversi reparti<\/strong>. Pochi punti fa abbiamo identificato vari reparti e diversi dipendenti a cui interessa il servizio in trasformazione. Stiamo formando il team con loro, perch\u00e9 deve essere multifunzionale: cambieremo il processo di testing, il processo di sviluppo e il processo di gestione del servizio. Sono necessarie competenze diverse.<\/p>\n

Di solito prendiamo un sviluppatore, un tester e un ingegnere \u2014 uno di ciascuno, e insieme a loro sviluppiamo una soluzione che consenta di vivere in modo diverso.<\/p>\n

Ideale sarebbe che queste persone avessero autorevolezza all'interno dell'organizzazione<\/strong>. Potrebbe essere necessario coinvolgere un consulente, anche se non ne abbiamo voglia. Se abbiamo una grande azienda, non tutti crederanno nel nostro progetto, e qualcuno potrebbe ostacolarci, ad esempio, non assegnando uno spazio per il nostro stand. Qui servir\u00e0 un \u00abautorevole\u00bb \u2014 una persona rispettata con molta esperienza, che ha guadagnato una buona considerazione tra i colleghi. L'autorit\u00e0 di un membro del team faciliter\u00e0 il compito e il lavoro del team temporaneo. Le persone penseranno:<\/p>\n

\u2014 Ah, quel tizio fantastico che tutti conosciamo e apprezziamo \u00e8 coinvolto\u2014 evidentemente, in DevOps c\u2019\u00e8 qualcosa che merita attenzione!<\/em><\/p>\n

Fissiamo un obiettivo<\/h2>\n

\nAbbiamo radunato le persone, scelto il servizio, esaminato i limiti, definito su chi possiamo influenzare. Ora bisogna fissare un obiettivo e deve essere chiaro secondo il metodo SMART<\/strong> \u2014 tutto come piace a noi.<\/p>\n

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

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

Raggiungibile \u2014 raggiungibile<\/strong>. Fai attenzione alle tue specificit\u00e0. Se sei un'azienda enterprise con una lunga storia e un grande carico di responsabilit\u00e0, che rilascia una versione del prodotto una volta all'anno, non potrai raggiungere un rilascio di nuove versioni del prodotto ogni ora in sei mesi. Non \u00e8 possibile. Quindi, fissa un obiettivo realistico, che sia raggiungibile in un tempo ragionevole.<\/p>\n

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

Limitato nel tempo \u2014 limitato nel tempo<\/strong>. Se non c'\u00e8 scadenza, il team si occuper\u00e0 di qualsiasi cosa: prover\u00e0 15 tecnologie invece di 3, scriver\u00e0 enormi relazioni, condurr\u00e0 ricerche inutili, perfezioner\u00e0 la propria implementazione fino alla lucentezza, quando l'obiettivo \u00e8 gi\u00e0 stato raggiunto.<\/p>\n

Definiamo l'obiettivo proprio attraverso la Value Stream Map \u2014 riuniamo di nuovo tutte le persone e disegniamo. Ma stavolta, sulla base della Value Stream Map precedente, disegniamo ci\u00f2 che vogliamo ottenere.<\/p>\n

\"Come
\n
\nIdentifichiamo una restrizione che elimineremo in questo momento, e su questo si concentrer\u00e0 il team. Per esempio, ho preso l'attesa dal rilascio finale fino alla sua deployment in produzione \u2014 questa \u00e8 la restrizione pi\u00f9 comune con cui le persone si rivolgono ai consulenti.<\/p>\n

In base a questo, impostiamo un obiettivo: vogliamo che l'attesa tra il rilascio finale e l'entrata in produzione sia al massimo di un'ora.<\/p>\n

Esempi di obiettivi.<\/p>\n