questo discorso è in realtà lo stesso discorso che ho dato
Kanpur del suo chef, un mese fa e io
in realtà l’ ho creato per andare da Audrey
l’anno scorso perché Jean Kim stava andando a
Dare questo discorso e ha creato il titolo
e l’astratto e poi circa un mese
prima che dia la parola lui lui
Non ha avuto il tempo per lavorare su più così
mi ha fatto scrivere e dare così questo
in realtà si parla di jeans ma uno che io
progettato e sto per darti ed è
davvero di tornare alle radici di
magro che è la produzione Toyota
sistema e guardando come può
informare l’adozione di DevOps perché
davvero DevOps torna a questo insieme
tipo di lean lean thinking e quindi noi
inizia con la storia della frusta e poi vai
nel modo in cui puoi effettivamente applicarlo
la vita reale e l’attenzione come potresti
l’aspettativa è sulla cultura e sulle pratiche no
sulle cose che le persone effettivamente tendono
concentrarsi su quali sono gli strumenti e il tipo di
roba tattica perché è sbagliato
cosa su cui concentrarsi e questo è giusto
cose su cui concentrarsi così sul sociale
il sistema di produzione viene originariamente da
la linea di produzione di auto da costruzione e
questa è una foto di una fabbrica di Toyota in
il Regno Unito e qui vai che qui è il
macchine che rotolano giù la linea di produzione
e il sistema di produzione di giocattoli parla
su come possiamo rendere questo processo più
efficiente più rispondente alle esigenze degli utenti
e otteniamo cose come lo sai
sistemi basati sulla gestione del processo lavorativo
Kanban tutti questi concetti che sono
sviluppo del software applicato originariamente
provenire dalla linea di produzione tuttavia
c’è un problema con questo intendo quello
questo è in realtà la produzione reale
cose nella vita reale nel contesto di
costruzione di prodotti basati su software e
servizi dove è la linea di produzione
abbiamo una metafora che possiamo
in qualche modo applica questa cosa e il
principi che governano come farlo
efficiente a questo completamente diverso
cosa e in realtà è importante
ricorda che questa è una metafora
non esiste una linea di produzione attuale qui
non ci sono macchine che attraversano questo
ufficio a meno che qualcosa di molto brutto sia
accade normalmente che è un segno che
c’è qualcosa di sbagliato con il tuo
processo di sviluppo se le persone lo sono
guidando letteralmente le macchine attraverso così come
applichi effettivamente quei principi
e quel tipo di filosofia per questo
cosa e persone completamente diverse
ho provato a decomprimere questo in un mucchio di
modi diversi quindi c’è un grande libro
di Charles Betts chiamato architettura e
varietà di brevetti in cui dice bene te
conosci in realtà il modo in cui la gente pensa spesso
a riguardo è la fabbrica che costruisce il
fabbrica nella progettazione della fabbrica nel
le linee di produzione sono come il nostro prodotto
portfolio life cycle e poi cosa cosa
le macchine sono se ti piace l’individuo
manufatti che escono
il nostro portafoglio di servizi e questo è un modo
di tipo di prendere quelle macchine da costruzione
metafora e applicandola in un altro modo
a pensare a questo proposito è che in realtà la
la fabbrica è il ciclo di vita di uno
servizio individuale che gradualmente
si evolve nel tempo e poi il
transazioni individuali quando lo sapete
comprare qualcosa o richiedere un servizio a quelli
sono come le macchine che escono dal
linea di produzione il servizio individuale
la richiesta è come quella di chiedere a
auto da costruire e quella che esce dal
linea di produzione e quindi si può certamente
pensaci in questi modi e c’è
cose fruttuose si può uscire da questi
metafore per te conosci il prodotto
portafoglio o il portafoglio di servizi IT
e c’è un grande libro di un ragazzo chiamato
Don Rhine al CERN ha definito i principi
del flusso di sviluppo del prodotto che tu
sai prende questa metafora di te lo sai
magra come sviluppo del prodotto e deriva
una grande quantità di molto molto interessante
roba da quello è davvero grandiosa
libro per le persone che sono geek in giro
processo e sviluppo del prodotto e
gestione dello sviluppo del prodotto e
attinge a molte idee snelle anche se come
Don sottolinea quando scriveva su
questa roba 20 anni fa nessuno lo farebbe
in realtà il termine lean non era nemmeno stato
inventato a quel punto, quindi lui tipo di
precede quella applicazione
metafora che vediamo molto nel software
lo sviluppo particolare è l’idea di
la tavola Kanban o lo storyboard e
qui queste singole cose che sono
pezzi di lavoro come storie o correzioni di bug
o qualunque cosa siano come le macchine
in movimento
la linea di produzione e quello che facciamo noi
pensa a come migliorare il
efficienza del processo di consegna entro
sai creare un sistema di pool qui da
guardando quanto tempo ci vuole individuale
storie da spostare su tutta la linea
ma non è una metafora perfetta di un sacco di
le cose che vanno nella Toyota
Sistema di produzione sul miglioramento
l’efficienza si basa sul sapere cosa
le persone stanno facendo e vedendo quello che sono
facendo e effettivamente guardando e vedendo
cosa stanno facendo e vedendo come le persone
effettivamente guardando come possono migliorare
il loro stesso processo c’è il suo concetto di
andando a gamba in magra che è in realtà
visitare la fabbrica e i tempi
persone che fanno cose e parlano insieme
su come questo processo potrebbe essere migliorato
è molto difficile farlo in questo
ambiente non puoi semplicemente sapere parlare
Bene, passeremo il tempo per quanto tempo
serve per costruire un test per questa storia
e vai a sederti vicino ai modi principali e sii
come non cronometrare quanto dura
ti porta a costruire il test di accettazione
Io nessuno lo fa perché sarebbe
un po ‘raccapricciante e alla gente non piacerebbe
e la variabilità è veramente alta e
è molto diverso per ogni persona in modo
anche il concetto di standardizzazione in
questo contesto è davvero molto difficile e a
molte delle idee che vanno in Toyota
Ovviamente, il sistema di produzione non si applica
quando pensiamo a te, conosci il concetto di
le auto che si muovono sulla linea di produzione
come storie su un muro di storie quindi è così
importante tenere a mente che abbiamo un
molto da questa idea di Kanban come gestione
storie o gestione di bug di compiti qualunque
ma è solo una metafora ed è di no
significa una metafora perfetta
quindi quali altre metafore potrebbero esserci
per la linea di produzione nel software
sviluppo bene nel 2006 io e un nord
chi presenta oggi penso giusto
fingi alla sessione prima di me e
Chris Reid che è anche qui oggi noi
Ho scritto un documento Ciao Chris, ecco Chris
Chris e me e Dan hanno scritto questo documento
2006 per la conferenza agile in cui
se ti ricordi di Minneapolis, penso
quando lui senza sforzo e
e ha deciso che avrebbe chiamato questo
la linea di produzione di dispiegamento fondamentalmente
a causa di questa metafora e solo
mi è venuto in mente molto più tardi che in realtà
che è che permette di applicare un sacco di
principi snelli a ciò che stiamo pensando
ma il concetto chiave in questo era quello
in realtà ciò che stiamo guardando è
l’unità di base del lavoro è un cambiamento in
controllo della versione e modifica della versione
il controllo crea una build e la build
progredisce attraverso la linea di spiegamento
alla produzione e quando colpisce
produzione offre valore alle persone
e e e quindi è molto diverso
metafora da tutte le altre quelle del
idea ricostruire è molto concreta e
si scopre che puoi prenderne un sacco
roba interessante da questa metafora
della linea di produzione come processo per
distribuire i cambiamenti e l’individuo
l’unità è cambiata in controllo di versione
cambiare portando ad una costruzione, quindi cosa funziona
possiamo uscire da quello per
capisci cosa ci dà questo
diverso dalle altre metafore noi
dovevo tornare alle radici di Toyota così
chissà cosa stava costruendo la Toyota
prima stavano costruendo macchine tessili
roba sì, più o meno
così la Toyota non fu originariamente chiamata
Toyota è la famiglia che ha creato Toyota
in realtà chiamato la famiglia Toyota e
i loro prodotti innovativi erano i
Telaio automatico Toyota tipo G e questo è
una foto di esso, quindi penso che fosse
gli anni ’20 non riesco a ricordare esattamente ma
intorno a così sai quasi un secolo
fa ora e la svolta chiave in questo
un particolare prodotto era che poteva
rilevare quando c’era un problema, quindi se lo fosse
esaurito thread o se il tipo di telaio
di sono coinvolti o qualcosa di simile
se ci fosse qualche problema nel processo
di produrre il tessuto che avrebbe fatto Lu
fermarsi e notificare automaticamente il
operatore che ha avuto un problema e questo
ha creato un enorme miglioramento in
la produttività prima di tutto è diventata
impossibile produrre prodotti difettosi
perché nel momento è successo qualcosa
quale risulterebbe in un difetto
prodotto che la macchina si fermerebbe in secondo luogo
fino al punto in cui questa macchina
è stato creato ogni volta che c’era un problema
l’ operatore dovrebbe stare a guardare
il telaio seduto al telaio a guardarlo
per convalidare manualmente ciò che è stato
prodotto era in realtà buono e un preavviso
immediatamente che c’era un problema e
fermati lì e poi così hai dovuto
avere una persona per ogni telaio manualmente
ispezionando i test di esecuzione dell’output se
ti piace manualmente per assicurarti che il
il prodotto era effettivamente buono e quando tu
avere un sistema che rileva i problemi
stesso e si ferma solo tu hai bisogno
una persona per stanza di telai puoi
avere una persona il cui compito è quello di
monitorare tutti i telai perché non lo fanno
devono fare tutto ciò che devono
attendere che il telaio rilevi un problema
e poi si intervengono ora
questo è un punto di svolta in termini di
produttività per la produzione di tessuti
ma si scopre che questa idea è
centrale non solo per la produzione di Toyota
delle auto ma anche allo sviluppo del software
ed è così importante che, naturalmente,
c’è un termine giapponese per questo e
ogni volta che c’è una cosa importante
concetto snello devi conoscere il
Termine giapponese che è molto importante bene
Penso che la storia di questo termine sia
tipo di interessante se andate a leggere
Toyota dispiace il libro di Ono su Tai Chi
libro del proprietario sulla gestione del posto di lavoro lui
tipo di parla della storia di questo
termine che sono venuti con così questo è
la parola giapponese per l’automazione è
in realtà caratteri cinesi e poi
questo è il carattere cinese di a
persona e quindi quello che hanno fatto è stato detto
beh, abbiamo l’automazione dell’automazione
conosci il telaio automatico ma abbiamo bisogno
persone per poter intervenire
quando qualcosa va storto e se prendiamo
questi due concetti e metterli insieme
arriviamo con questo termine e cosa è
è successo nella lingua
è che questo personaggio si trasforma in a
radicale che è aggiunto qui che è come
questa parola è diversa da questa parola
abbiamo questo potrebbe avere un extra
qui radicale che rappresenta l’ aggiunta
di persone al processo e questo dà
noi automa emozione che a volte è
tradotto come automazione con un essere umano
elemento e l’idea è che sfruttiamo
macchine e persone per le loro cose
che sono particolarmente bravi a
le macchine sono buone per l’esecuzione
compiti ripetitivi per gli umani
risolvere problemi
e il modo in cui produciamo l’alta qualità
i prodotti è che usiamo le macchine per
fai il noioso lavoro automatico ripetutamente
e usiamo gli umani per risolvere il
problemi e creiamo sistemi in cui
questi due elementi possono fare quello che sono
meglio e combinandoli è così
costruiamo la qualità in qualunque cosa sia
stiamo producendo e quindi questo è centrale
al sistema di produzione Toyota questo
concetto di judoka e in particolare il
idea del rilevamento automatico
i problemi e la notifica degli utenti sopravvive
i concetti della mano su corde e
la sfera di visualizzazione che ti dice quando
qualcosa che non va in modo che ha sentito della
mano su corde così in una fabbrica di Toyota
c’è una chiamata che puoi tirare quale
fa sapere alla gente che hai un
problema quindi in pratica se sei sul
linea di produzione e questi marchi sul
Fondamentalmente sono il tempo in secondi
che sta prendendo questa macchina per muoversi
oltre l’area di lavoro di questa persona e se questo
la persona non ha completato l’attività che è
supposto per completare dal momento in cui ottiene
a qui poi quello che faranno è che lo faranno
tira il cavo e sul cavo e quella volontà
convocare un gestore di venire ad aiutarli
e se non riescono a risolvere il problema
insieme, quindi, possono annullare l’annullamento
di nuovo il cavo e fermerà effettivamente il
linea di produzione ora questi due concetti
sono davvero rivoluzionari da circa 20 anni
fa
GM ha creato una joint venture con Toyota
ed è stata la prima volta che la Toyota ha avuto
stato in una joint venture con un altro
compagnia e hanno creato una pianta chiamata
Noomi a Fremont in California e nel
le piante di nume erano state appena chiuse
da GM perché aveva la peggiore forza lavoro
il sindacato ha ammesso che era il lavoro
la peggiore forza lavoro e ha avuto il peggio
gestione e prodotto il peggio
prodotti di qualità e così si spengono
la pianta e hanno detto bene che useremo
questo per la nostra prima joint venture e
poi Toyota ha fatto qualcosa tipo di
radicalmente hanno effettivamente riassunto tutti quelli
persone e li mandò in Giappone per allenarsi
loro per creare il nuovo piano me che è
la joint venture così hanno detto che siamo
andando ad assumere tutte queste persone che erano
la peggiore forza lavoro in GM negli Stati Uniti e
useremo queste persone come
base per il nostro nuovo tipo di fabbrica di noci
cose da fare
sai che questa forza lavoro era conosciuta per
fare le cose come se fossero così incazzato
con il loro lavoro farebbero cose
come bottiglie di coke piuttosto vuoti all’interno
le porte in modo che le porte potessero vibrare
quando ti chiudi che li apri
è così miserabile e scontento
Erano con il loro lavoro così loro sono
entrato in una padella e ottenuto il tipo di toyota
formazione e sono tornati e quando io
pensa a qualche mese di avvio del
nuovo me pianta il nuovo me pianta era il
forza lavoro più produttiva in tutto il
USA nel portafoglio di GM e anche loro
prodotti prodotti in termini di automobili che
erano di alta qualità come le auto che
sono stati prodotti nello stabilimento Toyota di
Il Giappone e c’erano molte cose
che penso così se tu ci sia un
podcast su questa e questa vita americana
podcast sul nuovo piano di me che io
lo consiglio vivamente a tutti ascolta I
significa che questa vita americana è comunque grande
ma il nuovo podcast è davvero molto
brillante e due delle cose che il
le persone intervistano le persone che
effettivamente stavano lavorando nella pianta GM
e andò e ha ottenuto l’allenamento di due cose
che erano diversi in primo luogo, conosci il
idea che se qualcosa ti va male
può tirare un cavo e un manager arriverà
e quel manager ti aiuterà
era una specie di concetto rivoluzionario
piuttosto che il manager che viene e
urlando contro di te e poi cercando di sparare
tu che il manager avrebbe davvero aiutato
tu Wow e poi l’altro rivoluzionario
concetto è l’idea che ha un lavoratore
il potere di fermare la linea così in GM
fabbriche tradizionalmente cosa vorrebbe
capita non è nessuno la linea non sarebbe mai stata
fermato giusto quello che succederebbe è il
le auto sarebbero uscite dalla linea di produzione
molti di loro avrebbero avuto dei difetti
metterli in un sacco e sistemarli più tardi
e c’era un sacco enorme pieno di macchine
accumulando che aveva difetti di vario
tipi e quindi con la sua produzione di paranco
sistema ogni volta che trovi i difetti se
non puoi aggiustarlo nel tempo in cui tiri il
cord la linea di produzione si ferma così
era un concetto rivoluzionario quindi una cosa
la gente non capisce è quanto spesso il e
il cavo lungo è tirato così quante volte lo fa
pensi che l’ analogico venga tutto tirato dentro
la fabbrica Toyota ha qualche ipotesi
una volta al mese assumere centinaia di volte a
giorno noleggio mille volte di nuovo giorno di noleggio
quindi in realtà sono circa tremila
volte al giorno che arriva l’ end encore
tirato in modo che la loro linea di produzione non lo faccia
fermati ogni volta che arriva la chiamata sconosciuta
tirato dal muro di Berlino viene tirato
tre mila volte al giorno in media
è molto più spesso di quanto la gente pensi
e questo dimostra il livello di
collaborazione all’interno dell’organizzazione
tra le persone e facendo il lavoro
e la gestione è molto
ambiente collaborativo quindi questa idea
di fermare effettivamente la linea dell’avere
un sistema per rilevare problemi di qualità a
nel momento in cui si verificano piuttosto che
aspettando che escano
quindi gli utenti hanno un analogo nel software
lo sviluppo e l’analogico è continuo
integrazione quindi chi è nel pubblico
praticando l’integrazione continua su
la loro squadra va bene tenere le mani in alto mantenere
le tue mani in alto mantengono le tue mani
il tuo esercizio per questa sessione manterrà il tuo
mani in alto, quindi metti le mani
giù a meno che tutti gli ingegneri sul tuo
la squadra sta controllando nel bagagliaio circa una volta
un giorno o più spesso di quello
quindi se questo non è vero se gli sviluppatori sono
trekking in feature branch che
non vengono poi uniti in mesi di tronco
un giorno o se stanno controllando no
verificarlo e mettere le mani
giù altrimenti li può tenere il passo giusto
quindi abbiamo perso circa i due terzi del
persone così se ogni check-in non lo fa
portare a test di unità di costruzione in esecuzione
metti giù le mani altrimenti tienili
va bene così abbiamo perso un paio e poi
quando la costruzione si rompe se poi non lo fa
si risolve entro una decina di minuti
metti giù le mani se la build è
spesso rotto per più di dieci minuti
metti giù le mani altrimenti tienili
va bene quindi ci sono circa dieci persone dentro
la stanza che stanno facendo davvero questo
integrazione così rotonda di applausi per te
ragazzi è fantastico continuo
l’integrazione è davvero difficile non lo è
correre Jenkins contro le tue caratteristiche
rami e poi ignorando la build
quando diventa rosso è la pratica di
assicurandoti che il tuo software sia sempre
lavoro
nel momento in cui trovi un problema lo aggiusti
subito se il conto diventa rosso e
tutti lo ignorano è come lo sai
loro il telaio rileva un problema e
si ferma e l’operatore va lì
fottendoti un tessuto da carico
è ottenuto rotture in esso si sa tutto
come lasciare che la macchina scenda
linea di produzione e lo inseriremo in a
molto e poi lo ripareremo più tardi , sai
questo è quello che stai dicendo è fondamentalmente
che tu conosci bene, non importa che c’è un
problema ma qualunque cosa ho intenzione di portare
scrivendo codice perché è quello che ho
come fare così la pratica del continuo
l’integrazione è meglio descritta nella mia
opinione in un articolo di James Shaw che
parla dell’integrazione in dollari al giorno
e questo è il processo che sto scrivendo
codice ho finito quello che sto facendo io corro il
costruisci e prova localmente per assicurarti che
lavoro e loro passarono così così a quello
punto che ho intenzione di unire il tronco anteriore a
assicurati che il mio lavoro si armonizzi e
si fonde correttamente con il lavoro che
altre persone stanno facendo nella mia squadra, quindi sono
andando a tirare il baule anteriore nel mio
locale dove posso copiare e quindi unire
ed esegui la build e prova nuovamente per creare
sicuro che ciò funzioni è come farlo
questo è il doppio di come distinguiamo il mio bug
da un bug causato dall’unione a quello
punto che voglio spingere nel bagagliaio
controllo della versione perché voglio condividere
il mio lavoro con la versione di altre persone
il controllo è principalmente un meccanismo di condivisione
è uno strumento di comunicazione prima di me
che ho intenzione di camminare su questo vecchio
postazione di lavoro nell’angolo del
stanza e vado a vedere se la gomma
polli non c’è, intendo
qualcun altro è il check-in devo
aspetta il pollo di gomma quando lo fa
diventa disponibile prendo la gomma
il pollo torna al mio computer, controllo
in spinta in tronco e poi tornare a piedi
la vecchia workstation e poi controllo
dal tronco eseguire la build e testare
l’altra macchina per dimostrare che il
la cosa in realtà funziona su una macchina che è
non la mia macchina
non solo la mia macchina yay se è vero
e funziona
Metto giù il pollo della spazzatura e porto il
bell ding hooray Ho finito, non ho finito
ma fatto nel senso di opere sul
macchina che non è solo mia, se è così
non funziona non ottengo a suonare il
campana costruisce strade Ho due opzioni
l’opzione uno prova e risolve il problema che ho
ho un paio di minuti per provare e trovare
il file che ho dimenticato di controllare o
qualunque sia la mia opzione per il rollback
assolutamente corretto il più egoista
cosa che puoi fare come sviluppatore è
lasciare i codici rotto su una build di rotta su
tronco perché significa che tutti gli altri
sta lavorando su qualcosa che non lo è
noto per essere buono quindi sì, se trovi un
problema e non è possibile risolvere il problema direttamente
via estrae la tua modifica dalla versione
controllo
questo è molto molto importante e un
pratica sottoutilizzata quindi sì per
essere in grado di fare questo abbiamo bisogno di assicurarsi
tutti stanno controllando nel bagagliaio almeno
una volta al giorno e che effettivamente paghiamo
attenzione quando quella cosa diventa rossa così
il problema è il pollo di gomma
non scala quindi cosa scala
bene ancora una volta, nonostante questo discorso
la scorsa notte ho dimenticato di aggiungere il
a destra scivolo nel mio mazzo di diapositive che era
un chiaro fallimento di judoka ci vediamo così
se posso averlo qui
questo dovrebbe essere più veloce della scorsa notte
perché in realtà so dove si trova adesso
sì, così hey questo è ciò che è questo
lo fanno a Google e trovo queste statistiche
abbastanza stupefacente così 10.000 sviluppatori
in oltre 40 uffici più di 2000
progetti in sviluppo
praticamente tutto tranne chrome e
Android è controllato in un enorme
perforce repository e tutto è
costruito fuori dal tronco e da tutti gli sviluppatori
check-in nel bagagliaio ottengono circa 20 plus
il codice cambia in trunk al minuto e
a picchi a 60 circa il 50% del cambio di codice
ogni mese tutto è sviluppato e
rilasciati dal bagagliaio passano tutti i conti
fonte e corrono oltre un centinaio
ecco qui milioni di casi di test al giorno
un’altra diapositiva che ho rubato da Google loro
avere circa 200 mila suite di prova in
il loro codebase esegue dieci milioni di test
Suite al giorno oltre 60 milioni
singoli casi di test al giorno e
crescendo più di quattromila ci
costruisce un giorno quindi questo è l’equivalente
del telaio che rileva i problemi
subito dopo averli controllati
questo è ciò che fa Google questo è il
equivalente della cosa che era
inventato da Sakichi Toyoda
negli anni ’20 per la costruzione di tessuti ma
nel 2014 per la costruzione di software scala uguale
cosa fondamentalmente e si basa su avere
estremamente buono automazione di test che è
molto completo e possiamo eseguirlo
molto molto rapidamente e ottenere un feedback
subito e in modo cruciale una volta arrivati
quel feedback facciamo effettivamente qualcosa
su di esso e risolvere il problema piuttosto che
stendendo la build rimani letto e uno
delle cose che sono una pratica in
Google è questo se qualcosa va in
tronco ed è rotto a chiunque altro
ripristina quel cambiamento, quindi se ti rompi
qualcuno a valle di te quella persona
puoi ripristinare i tuoi cambiamenti e va bene
così quel concetto di codice collettivo
la proprietà che tutti possiedono i codici
e che chiunque può ripristinare qualcuno
il resto è un brutto cambiamento dal tronco
parte della cultura e questo è molto molto
importante
comunque solo avendo quei test di base
questa parte del processo CI non lo è
abbastanza e il tipo di Google
scala le cose per le ombre che così semplicemente
avendo una configurazione CI di base che vuoi
costruire per eseguire in pochi minuti perché
si desidera ottenere il feedback veloce ma
quel feedback non sarà
completo che è il motivo per cui è necessario a
molti altri test di accettazione
e poi altre cose come l’utente
test di accettazione test di prestazioni I
significa che questo è un diagramma molto semplice ma
il tuo processo sarebbe più complesso di
che c’è un certo numero di differenti
convalide che hai provato prima di te
può portare cose alla produzione e così via
la domanda è come costruiamo questo dove
iniziamo come lo evolviamo e in
per rispondere a quelle domande che sono
andando a darvi un caso di studio da a
società che ha fatto questo su larga scala e questo
la compagnia è Hewlett Packard e il team
quello ha fatto è la squadra che ha costruito il
firmware per il laser di Hewlett Packard
gira così il team del firmware HP LaserJet
circa 400 persone distribuite in 400 persone
in tutti e tre i continenti c’è una squadra
a porto alegre in brasile c’è una squadra
a Boise Idaho e c’è un’altra squadra
Penso sia a Delhi che a Bangalore
India e così dispiaciuta dilettarsi o Bengaluru in
India e quindi distribuzione di 400 persone
attraverso tre fusi orari e avevano a
problema il loro problema era che erano
andando troppo lentamente non erano in grado di farlo
tenere il passo anche con le nuove versioni di
la dell’hardware che sono stati in uscita
per non parlare della costruzione di nuove funzionalità per nuovi
i prodotti su cui si trovavano sul software
il percorso critico e questo è un comune
motivo per cui vediamo le persone adottare
la consegna continua è quando il software è
sul percorso critico che è quando le persone
Iniziamo dicendo che abbiamo bisogno di ottenere una migliore
facendo questo e così la prima cosa che loro
ha fatto bene, in realtà non è il primo
cosa hanno fatto prima che effettivamente
provato a progettare la loro strada dopo il
problema hanno provato a licenziare le persone
le persone che esternalizzano la gente tutto il solito
cose che fanno le grandi aziende e quando
niente di tutto ciò funziona allora il marketing e
la gente del prodotto è venuta agli ingegneri e
per favore aiutaci a risolvere questo problema
usando l’ingegneria che è come lo sai
le cose vanno veramente male quando le persone lo sono
chiedere aiuto agli ingegneri e così via
la prima cosa che hanno guardato è ciò che sono
in realtà stanno spendendo il loro tempo
e così l’hanno scoperto
basicamente usando un abbastanza leggero
sistema informale di chiedere semplicemente le persone
cosa stavano facendo il loro tempo facendo
e questo è quello che hanno trovato
quindi per capire perché questo è vero te
devo capire che ogni volta un nuovo
linea di dispositivi è venuto fuori che avrebbero
creare un ramo nel controllo della versione per
quella nuova linea di dispositivi così avevano a
numero di rami diversi ogni volta
aggiungono una funzionalità o creano un bug-fix
devono portare quella correzione di bug o
funzionalità attraverso tutti questi diversi
filiali quindi stavano spendendo il 10% di
il loro tempo facendo l’ integrazione del codice del 20% di
il loro tempo facendo pianificazione dei dettagli del 25% di
il loro tempo porting codice tra filiali
25% del loro tempo sul supporto del prodotto
cosa ti dice che grande?
numero sul supporto del prodotto che cosa fa
dire 50 problema di qualità giusto 50 era
dicendo che c’è un alto test manuale
sottrai questo dal 100% e cosa
si è lasciato con è del 5%, che hanno
sosteneva invece il tempo speso a innovare
di quello che avrei fatto
sarebbe stato sdraiato sul pavimento con
una grossa bottiglia di vodka dichiararono
stavano innovando, quindi questo è carino
male e cosa decidono di fare bene
hanno deciso di fare quello che è in realtà
la cosa più rischiosa che si possa fare
e chi entra nel kamil più spinoso parlava
prima di me sì, così hanno fatto un grande
riscrivere che è una cosa pazza per farlo
Non lo consiglio ma ci riescono
per ragioni che esploreremo un po ‘
più tardi e la chiave architettonica
la decisione che hanno preso sono stati architetti
il sistema per testabilità e loro
architettato il sistema per essere in grado di fare
integrazione continua così loro
subordinato il loro architettonico
preoccupazioni per la costruzione di qualità nel
prodotto e cosa significava fare
sicuro che il software fosse tutto
era costruito con il tronco e loro avevano
test automatizzati in atto per tutto
quindi questo significava una completa riscrittura perché
hanno dovuto cambiare il modo in cui loro
gestire la diversità del
portafoglio di prodotti che era il firmware
schierato così in fondo quello che succede è
hanno messo le levette sulla posizione così
dispositivo si avvia il firmware degli stivali
cosa sono io oh sono una stampante, quindi vado
per disattivare queste funzioni di scansione
e spento queste funzionalità di rete
e ho solo le mie funzioni di stampa o
L’hardware batte il firmware degli stivali cosa sono io
oh sono uno scanner, quindi ho intenzione di girare
fuori dal
quindi in pratica gestiscono il tipo di
eterogeneità del hardware utilizzando
funzione alterna in modo che possano costruirne uno
binario per ogni dispositivo fuori dal bagagliaio e
tutti potevano lavorare fuori dal bagagliaio e cosa
quello che ha permesso loro di fare è praticare
integrazione continua hanno iniziato
praticando a proprio agio l’integrazione e
ha iniziato a costruire automazione di test e
molto presto hanno scoperto che la build
è stato letto tutto il tempo e quindi il ragazzo che
è stato VP di ingegneria che segue
che HP ha gestito dalla pratica HP
la pratica di gestione è chiamata gestione
camminando intorno ed è fondamentalmente
andando e camminando e chiedendo
domande imbarazzanti che è
in realtà risulta molto vicino al
tipo di sistema di produzione Toyota andare a
gamba vai a vedere cosa sono le persone
in realtà quello era la sua gestione
stile comincerebbe a dire come possiamo
fermare le persone che controllano gli errori nel bagagliaio e
le persone sarebbero come noi ovviamente noi
non lo farei se sapessimo e tu
sapere spazzarlo via e pensare che lo fosse
un idiota e alla fine qualcuno si avvicinò
con quello che era in realtà abbastanza intelligente
idea quindi dopo due anni di lavoro
si sono evoluti dalla loro configurazione di base
una pipeline di distribuzione molto potente
che ti mostrerò sottolineando
che questo è dopo due anni di valore
funziona questo non è qualcosa a cui sono venuti
tu subito ma fondamentalmente tutto
i loro sviluppatori avevano il loro
le code individuali su git avrebbero spinto
i loro cambiamenti individuali nella loro chiave
un cancello che innescherebbe una costruzione e
due ore di test in corso
solo quel cambiamento individuale se quello
passa tutte le modifiche è stato eseguito il backup e
promosso alla seconda fase e che si fonde
tutti i cambiamenti che hanno attraversato il palcoscenico
uno e corre build e circa due ore
vale la pena di test contro solo quel lotto
se fallisce se c’è un’unione
conflitto o sviluppatori di test falliti
ricevi un’email che loro configurano
workstation in modo che gli sviluppatori possano
premere un pulsante e riprodurre il test
fallimento sulle loro workstation usando
virtualizzazione e un emulatore che
emula la piattaforma hardware quando
hai una build che va avanti
qui che passa dalla valutazione al livello due
che è gestito due ore di test che sono
eseguire su un emulatore hanno costruito il proprio
emulatore per gli Asics personalizzati che erano
il loro tipo di dispositivi logici molto complessi
che alimentano stampanti e multifunzione
dispositivi in modo da scrivere il proprio emulatore
un po ‘di lavoro piuttosto sofisticato e
allora se il conto passa al secondo livello allora
va al livello tre che viene eseguito su a
mazzo
schede logiche che sono effettivamente in Iraq
così la scheda logica accenderà il download
ultima versione della firma che è passato
livello 2 e quindi vengono eseguiti automaticamente
prova come inviare segnali a
schede logiche quindi è carino
cose sofisticate che effettivamente porto
giro una copia di questo libro che non ho
oggi ma normalmente lo porto in giro
ai clienti in modo che chiunque si lamenta
che l’automazione del test è troppo difficile
sculacciali con questo libro perché se tu
può costruire l’automazione di test per il firmware
su schede logiche nessuno ha un problema
così difficile da sapere che questo è un
problema risolvibile è solo che stai andando
mettere un lavoro sufficiente per risolverlo
quindi questa è una cosa piuttosto sofisticata
e ci sono voluti molto tempo per costruire se
tu vai attraverso il livello 4
che è per 24 ore durante la notte
Conosco infatti 30.000 ore di valore
test automatizzati che sono massivamente
paralizzato e ottieni un feedback all’interno di a
giorno sulla qualità del tuo software così
questo cambia completamente l’economia di
il processo di sviluppo del software e
questo è qualcosa che ci è voluto molto tempo
tempo per arrivare e ha richiesto un sacco di
investimento ma qui ci sono i risultati
dopo tre anni stanno spendendo molto
meno tempo su integrazione continua o on
integrazione perché lo stanno facendo
continuamente sono in grado di massicciamente
ridurre la quantità di tempo che loro
spendere per la pianificazione e non ho tempo
per discutere perché questo è fondamentalmente da
avere un Chakra più prevedibile
processo di sviluppo hanno costruito fiducia
con il lato prodotto delle cose e così via
la gente del prodotto richiede molto meno
dettaglio in termini di pianificazione così
Hanno detto che ti lasceremo cambiare
la tua mente in qualsiasi momento e in cambio
creeremo molto meno dettagli
piani e hanno costruito quella fiducia e quella
li ha aiutati a ridurre la quantità di tempo
stanno spendendo per una pianificazione dettagliata
non stanno portando il codice tra
rami più stanno lavorando su uno
il supporto del prodotto principale della filiale va giù
dal 25 percento al 10 percento che cosa fa
che ti dice di migliorare la qualità sì
alta qualità molto meno tempo speso per
il test di supporto del prodotto va giù e
aumentano la quantità di tempo
sono stati spesi innovando da un fattore di
otto persone ora il intelligenti nel
il pubblico noterà che questi no
aggiungere fino al 100% e il motivo per questo
è perché stavano spendendo il 23%
del loro tempo sulla gestione automatizzata
test
costruendoli a trovarli
feedback su di loro quindi c’era a
investimento sostanziale coinvolto in
creando questo massiccio aumento in
produttività sì mi dispiace yeah quindi CP è
solo il loro processo per triaging bug
prego
e così questo cambia l’economia del
processo di sviluppo del software e il
La ragione per cui amo questo case study è perché
hanno misurato questi numeri e poi
hanno scritto un libro e tu puoi andare a comprare
questo è un libro favoloso e questo è un
farti scivolare, so solo che puoi averlo
puoi scaricare le diapositive in qualsiasi momento
qualcuno ti chiede qual è il valore
la proposizione è di consegna continua o
il ritorno sull’investimento è possibile
dai loro questa diapositiva quindi ne ho solo 50
sono rimasti pochi minuti per concentrarmi veramente
su è come hanno ottenuto da A a B hanno fatto
non pianificare questa distribuzione molto complessa
conduttura che hanno costruito che non era
qualcosa che sapevano che stavano per
creare tutto ciò che era parte di loro
la pianificazione si è evoluta nel tempo così come il loro
tutta l’architettura come tutta la loro
approccio alla costruzione del sistema e cosa
ho guidato questo intendo questo è un po ‘
straordinario ciò che ha spinto sono loro
inventato autonomamente il continuo
consegna stavano facendo questo prima del
il libro è uscito anche loro in modo indipendente
inventato qualcosa chiamato il
taglierina di miglioramento quindi questo tipo Mike
ruther è un ricercatore davvero brillante
è un ricercatore presso l’ Università di
dov’è dove si trova Ann Arbor
Michigan quindi è all’Università di
Michigan è un professore che ha scritto a
libro chiamato imparare a vedere quale è
sulla mappatura di Valley Stream è lui
ha ricercato Toyota per molti anni lui
ha scritto recentemente due anni fa questo Shingo
libro pluripremiato che è favoloso
lo consiglio vivamente e parte del suo lavoro
è stato per aiutarci a provare i produttori e
riprodurre ciò che la Toyota è stata in grado di fare in
le loro fabbriche quindi andrebbe a vedere
cosa stava facendo la Toyota e poi lo sai
I produttori statunitensi lo impiegheranno per provare
e insegnare loro come riprodurre la Toyota
risultati e direbbe che lo sono
facendo queste cose forse dovresti provare
facendo queste cose intendo che era di più
sofisticato, ma c’era un
elemento di quello
e poi tornerebbe al giocattolo
fabbriche un paio di anni più tardi e
guarda cosa stavano facendo e notato
non stavano più facendo quelle cose
quindi è stato un po ‘ imbarazzante perché
ha detto a queste aziende di andare e di fare
queste cose e loro non stavano facendo loro
più e poi direbbe bene ora
loro stanno facendo queste cose forse tu
dovrebbe cercare quello e poi tornare indietro e
poi due anni dopo non stavano facendo
anche quelle cose e così via
scopre che sai che in realtà è un
elemento molto importante di complessità
teoria questa idea che possiamo prendere a
pratica da un sistema complesso e
Trapiantalo in un altro complesso
sistema e si aspettano gli stessi risultati a
si svolge è falso l’intero punto di
sistemi complessi è che se prendi il
stessa serie di cose e trapianti
li otterrai diversi risultati questo
è il motivo per cui le metodologie non funzionano
le metodologie sono fondamentalmente post hoc
razionalizzazioni di qualcosa che
è successo a lavorare in un particolare complesso
sistema in un momento particolare e se tu
prendilo e mettilo in un altro complesso
sistema non otterrete lo stesso
risultati e quindi cosa vedi se guardi
in un’organizzazione ad alte prestazioni e tu
guarda le pratiche che stanno facendo
per vedere se è possibile copiarli e migliorare
la tua performance è ciò che stai vedendo
non le migliori pratiche ciò che stai vedendo è
contromisure al particolare
problemi che quell’organizzazione è
incontro in questo momento e se ci provi
e copiare le contromisure in modo diverso
ambiente in cui non produrranno il
lo stesso risultato, quello che devi fare è imparare
come mettere efficacemente le contromisure
sul posto ed evolvere quelli
contromisure e questo è fondamentalmente
quello che Toyota sa fare meglio di
chiunque altro e questo è formalizzato in
cosa potrebbe piuttosto causare il miglioramento
il cutter e il cutter di miglioramento è come
impari come essere in grado di metterli
contromisure in atto e questo termine
Catto è un po ‘importante allora
chi è visto nel drago
okay, allora entra nel film del drago Bruce Lee
Il film di Bruce Lee mi dispiace che sia Bruce Lee
volando nei cattivi ragazzi le isole hanno ottenuto un
l’isola ovviamente sta ancora aspettando la mia
isola in ogni caso il ragazzo malvagio ha un’isola e
tutti i cattivi ragazzi scagnozzi tutti
praticando le loro mosse di judo sul
isole Non posso fare judo, quindi sta andando
al ridicolo ma sono fondamentalmente
sai fare lo stesso
più e più volte ha e questo è ciò a
gatto è katha sta prendendo una mossa di base e
praticandolo più e più volte è
come fare le scale se lo sei
imparare musica o qualsiasi tipo di base
cosa ripetuta c’è un’unità di
qualunque sia la pratica più ampia è quella
lo stai facendo e quindi l’idea è che tu l’abbia
per imparare le basi prima e poi tu
metterli insieme e improvvisare e
combinali e sai creare cose
e così bene come l’intuizione era quella gente
chi sta facendo il lavoro è sempre
praticare come migliorare la qualità di
il loro lavoro è un’abitudine così da imparare
come eseguire esperimenti per provare nuove cose
migliorare e porre contromisure in
posizionare e vedere se funzionano è un’abitudine
che tutti alla Toyota stanno facendo tutto
giorno e il lavoro di gestione è a
creare l’ ambiente in cui le persone
può praticare questa abitudine di provare
cose nuove e miglioranti e lui
fondamentalmente in questo libro e ci sto provando
riassumere questo libro in dieci minuti che
è piuttosto difficile e io davvero
consiglio di andare e leggerlo questo è
fondamentalmente il ciclo di come funziona
prima di tutto capiamo la direzione
quindi guardiamo dove vogliamo entrare
come un paio d’anni quindi per HP
Firmware LaserJet loro visione era che
voleva un aumento di dieci volte in
produttività che era la loro visione
misurabile è un obiettivo che sarà
difficile da raggiungere non sappiamo come siamo
andando a farlo è la direzione allora
noi cogliamo le condizioni attuali come stanno
cose adesso e afferrando il
la condizione attuale è qui questo è il
condizione attuale destra e poi il
la prossima cosa che guardi è qual è il
la prossima condizione dell’obiettivo e questo è a
orizzonte di circa due o sei settimane fuori così
guardiamo dove vogliamo essere in due a
sei settimane e poi non pianifichiamo come
ci arriveremo perché noi
non so come ci arriveremo
perché stiamo facendo processo di innovazione
innovazione di miglioramento e in qualsiasi momento noi
innovare non è possibile pianificare esattamente come
lo farai perché poi è così
non innovazione e questo è davvero
cruciali le persone che fanno il lavoro hanno
per cercare di capire come stanno andando a
raggiungere la condizione obiettivo attraverso a
processo di sperimentazione PDCA è
plan-do-check-act è il ciclo di Deming
è fondamentalmente il metodo scientifico
esperimento di progettazione eseguire Nix
e raccogliere i risultati capire se
quella cosa è qualcosa che dovresti portare
fare o se dovresti smettere
farlo e questo ciclo è nel cuore
della Lean Startup ed è al
cuore del miglioramento dei processi ed è a
il cuore dello sviluppo del prodotto e
allora basato su questo lo farai
c’è un ciclo di feedback per il prossimo set
di condizioni che hai intenzione di provare
e stabilire il prossimo mese e anche
è la vostra visione complessiva in modo che
il ciclo di feedback è davvero importante
non necessariamente andando a realizzare tutto
quelle condizioni obiettivo e così e in
il corso del tentativo di raggiungerli
stai andando a scoprire un sacco di
cose che ti faranno resettare
quali sono le tue prossime condizioni di destinazione
tutto questo suona un po ‘ astratto
quindi ti darò un esempio di a
serie di condizioni target rispetto all’HP
Le persone del firmware LaserJet sono state installate
così hanno chiamato queste cose che hanno chiamato
le loro iterations mini milestones e
li hanno avuti ogni mese e questo è un
tabella dei loro obiettivi di mini-traguardo
per mini milestone anni ’30 ce ne sono due
e mezzo anni in così rango zero loro
voleva che le questioni prioritarie si aprissero di meno
di una settimana e due guasti di livello due
risolto entro 24 ore e livello uno loro
avevano un rilascio trimestrale che erano
la priorità cambia le richieste commerciali
risolti volevano l’errore di affidabilità
tasso a qualunque criterio di rilascio
era e puoi vedere che hanno un intero
gruppo di risultati obiettivo misurabili loro
voglio raggiungere entro un mese da oggi e
questo era praticamente l’intera pianificazione
per tutto il prossimo mese per il
intero programma di 400 persone si adatta a
un’unica pagina questi sono i misurabili
risultati che vogliamo raggiungere nel prossimo
mese per l’ intero programma e non lo facciamo
sapere come faremo a modo nostro
lo scopriremo è dalle persone
provando un sacco di cose per capire come
ci arriveremo e ci baseremo
sui risultati che stiamo andando a sapere
per mini milestone 31 ce ne sarà bisogno
essere un nuovo set e potrebbe includere alcuni
delle stesse cose o potrebbe essere un po ‘
cose diverse e siamo sempre
cambiando ciò che misuriamo e ciò che noi
preoccuparsi in base ai risultati di cosa
le persone hanno provato l’ultima volta , ad esempio
sai che le persone vogliono sempre sapere cosa
cose su misura e c’è molto
cose che potresti misurare ti darò un
ottimo esempio abbiamo fatto un progetto una volta
dove volevamo l’ 80% di copertura di test da
le persone hanno ragione
test unitari e abbiamo ottenuto una copertura del test dell’80%
che è stato grandioso
quasi rapidamente e poi noi
guardato le prove e abbiamo scoperto che
tutti i test contenuti alla fine
asserire vero quindi stavano chiamando tutto il
metodi nella base di codice e sono stati
affermando vero che ha creato test al 100%
copertura e alcuni test totalmente inutili
e tu sai una cosa molto comune
metti un bersaglio sul posto che la gente farà
trova sempre un modo per raggiungere l’ obiettivo
ma non può essere il modo in cui si
aspettarsi e quindi lavorare davvero
se l’obiettivo produce il giusto
comportamento e modifica degli obiettivi e
le cose che misurate come parte di ciò
processo è molto molto molto importante
la cosa cruciale sono le persone che in realtà
capire cosa fare
sono le persone che fanno il lavoro alla gente
effettivamente arrivare a venire le idee per
come raggiungere quei risultati sono i
le persone che fanno il lavoro sono loro
idee le idee non sono impostate da
gestione che proverai questi
le cose vanno fuori e fanno le persone che
stanno facendo il lavoro a inventare il loro
proprie idee e questo è così importante
perché significa che lo sai
è molto più eccitante da trasmettere
un’idea che ti è venuta in mente di quanto non sia
per far passare l’idea che qualcuno dentro
gestione si avvicinò con non solo come
eccitante per implementare qualcun altro
idea e provando le tue idee e
scoprire cosa funziona e cosa no
impari come migliorare di quello che tu
fare e questo è cruciale per qualsiasi culturale
il cambiamento all’interno di un’organizzazione è il
persone che fanno il lavoro che devi lavorare
fuori come migliorare in quello che fanno
loro stessi e il processo deve
incoraggiare le persone a capire come ottenere
meglio se stessi ed è così che tu
creare un’organizzazione di apprendimento ogni giorno
in questo modello la gente chiede cosa sono
stiamo cercando di ottenere adesso cosa c’è
la condizione attuale siamo di fronte a ciò che è
impedendoci di raggiungerlo quale
di quelle cose che stiamo per affrontare
in questo momento quali esperimenti stiamo andando
eseguire per provare e risolvere il problema e
dove possiamo andare a vedere ciò che impariamo
da quel che è come si è conclusa con
questa potente pipeline di distribuzione
in sostanza un sacco di cose che loro
provato
per vedere se funzionano e gradualmente
ha assunto questa forma così non l’hanno fatto
implementare distribuire la consegna continua di
leggendo il libro che hanno implementato
consegna continua provando a
mucchio di cose e loro tipo di
è venuto in modo indipendente con esso perché
risultato essere una buona idea così può a
un paio di pensieri conclusivi me e
Jean Kim e i laboratori di burattini hanno recentemente eseguito un
sondaggio l’anno scorso del sondaggio DevOps così
alcuni di voi potrebbero aver compilato il
Indagine DevOps che abbiamo messo fine a
l’anno scorso una delle domande che abbiamo posto
è fino a che punto la tua organizzazione è a
alta cultura della fiducia e c’è davvero
bel modello per capire se il tuo
la cultura culturale è una cultura di alta fiducia
da un tizio chiamato Westrom, quindi il westrom era un
ragazzo che stava inventando investigando
sicurezza nell’assistenza sanitaria e si è inventato
questa tipologia di culture organizzative
per guardare la sicurezza nell’assistenza sanitaria ma
in realtà risulta questa tipologia
è una specie di utile per pensare a qualsiasi
organizzazione e ciò che abbiamo scoperto
il sondaggio è che questo è molto alto
correlato con i risultati di business così tu
può effettivamente prevedere i risultati di business
in una certa misura da cui le persone cadono su
questo modello come si ottiene da A a B
come si ottiene se sei patologico o
burocratico come si ottiene così
bene generativo è molto molto difficile
non ho un proiettile d’argento ma un
una parte importante di questo è dare il
persone che fanno il lavoro al potere
cambia il loro processo e modifica il loro
elaborare e provare nuove cose e poi no
punendoli quando vanno queste cose
sbagliato questa intera idea che il fallimento
causa l’inchiesta non fallimento è coperto
e nuove idee di benvenuto non nuove idee
sono schiacciati, è molto importante
parte della creazione di una cultura di alta fiducia
qual è il modo in cui crei una cultura di
miglioramento continuo che è come te
innovare così in termini di leadership
davvero tutti questi problemi iniziano e finiscono
con la leadership e c’è una divisione
di lavoro i leader decidono i risultati
con un breve orizzonte e il corto
l’orizzonte è davvero importante perché tu
non so se i risultati desiderati
quindi effettivamente i risultati desiderati
e vi accorgerete che il vostro genere
idee su come specificare i risultati prodotti
il comportamento sbagliato, quindi devi avere
un breve orizzonte temporale in modo da poterlo convalidare
così i leader decidono cosa deve fare
essere fatto, ma le persone che fanno il lavoro
decidere come sarà fatto
la divisione del lavoro è un leader essenziale
non dovrebbe essere decisivo e manager
non dovrebbe dire alla gente come fare
il loro lavoro le persone che fanno il lavoro
dovrebbe decidere come stanno andando a fare
il loro lavoro e poi il lavoro dei manager
è quello di aiutare le persone che stanno lavorando
per loro di eseguire esperimenti e provare a
mucchio di cose e fondamentalmente eseguire il
metodo scientifico e quindi cruciale
stiamo andando ad aggiornare i nostri risultati del nostro
visivo nelle nostre metriche basate su cosa
abbiamo imparato nel processo di provare a
un sacco di cose così finalmente il lavoro di
l’automazione è di aiutarci a rilevare
problemi in modo che noi come esseri umani possiamo andare
in un problem solving che è ciò che noi
bravi a usare i computer per fare le loro cose
le cose che sono brave a cui è
eseguendo attività ripetitive che usi
le persone per le cose in cui sono bravi
che risolve i problemi, funziona sempre
piccoli lotti perché quando sei
lavorando un sistema complesso e ci provi
qualcosa sta andando rapidamente
divergono da ciò che ti aspetti che accada
e dici che vuoi limitare il possibile
svantaggio di cose che vanno male e ottenere
un feedback molto stretto scorre ciò che vuoi
la misura migliora in ultima analisi è il cliente
i risultati e troppe poche persone sono concentrate
sulla misurazione dei risultati del cliente
la consegna continua passa dall’idea a
risultato misurabile per i clienti e se
non stai misurando il cliente
risultato dei miglioramenti che sei
provando quindi non hai modo di saperlo
se stanno effettivamente migliorando il
qualità del prodotto che sei
costruendo e poi finalmente se lo si desidera
impara come implementare DevOps o
implementare la consegna continua o carina
molto implementare tutto ciò la risposta è
lo fai attraverso il miglioramento continuo
e per citare il mio ex collega e amico
Il continuo di Mike Roberts è molto di più
spesso di quanto pensi
alla fine voglio solo citare Jesse
Robbins Jesse Robbins come co-fondatore
i codici operativi è stato il principale disastro in
Amazon è un pompiere nei suoi pezzi di ricambio
tempo e fondamentalmente solo un enorme
overachiever Jesse Robbins ha una regola
Jesse dice di non combattere stupido di fare di più
fantastico e quindi se ti stai chiedendo cosa
puoi fare per rendere la tua organizzazione
solo un po ‘meglio come fai tu
quello è che ognuno entra nel lavoro ogni
giorno e pensa come posso rendere la vita a
un po ‘più fantastico per tutti
altro intorno a me e se tutti noi lo facessimo
ogni giorno è così che costruisci un grande
cultura e una grande compagnia
tu
Kanpur del suo chef, un mese fa e io
in realtà l’ ho creato per andare da Audrey
l’anno scorso perché Jean Kim stava andando a
Dare questo discorso e ha creato il titolo
e l’astratto e poi circa un mese
prima che dia la parola lui lui
Non ha avuto il tempo per lavorare su più così
mi ha fatto scrivere e dare così questo
in realtà si parla di jeans ma uno che io
progettato e sto per darti ed è
davvero di tornare alle radici di
magro che è la produzione Toyota
sistema e guardando come può
informare l’adozione di DevOps perché
davvero DevOps torna a questo insieme
tipo di lean lean thinking e quindi noi
inizia con la storia della frusta e poi vai
nel modo in cui puoi effettivamente applicarlo
la vita reale e l’attenzione come potresti
l’aspettativa è sulla cultura e sulle pratiche no
sulle cose che le persone effettivamente tendono
concentrarsi su quali sono gli strumenti e il tipo di
roba tattica perché è sbagliato
cosa su cui concentrarsi e questo è giusto
cose su cui concentrarsi così sul sociale
il sistema di produzione viene originariamente da
la linea di produzione di auto da costruzione e
questa è una foto di una fabbrica di Toyota in
il Regno Unito e qui vai che qui è il
macchine che rotolano giù la linea di produzione
e il sistema di produzione di giocattoli parla
su come possiamo rendere questo processo più
efficiente più rispondente alle esigenze degli utenti
e otteniamo cose come lo sai
sistemi basati sulla gestione del processo lavorativo
Kanban tutti questi concetti che sono
sviluppo del software applicato originariamente
provenire dalla linea di produzione tuttavia
c’è un problema con questo intendo quello
questo è in realtà la produzione reale
cose nella vita reale nel contesto di
costruzione di prodotti basati su software e
servizi dove è la linea di produzione
abbiamo una metafora che possiamo
in qualche modo applica questa cosa e il
principi che governano come farlo
efficiente a questo completamente diverso
cosa e in realtà è importante
ricorda che questa è una metafora
non esiste una linea di produzione attuale qui
non ci sono macchine che attraversano questo
ufficio a meno che qualcosa di molto brutto sia
accade normalmente che è un segno che
c’è qualcosa di sbagliato con il tuo
processo di sviluppo se le persone lo sono
guidando letteralmente le macchine attraverso così come
applichi effettivamente quei principi
e quel tipo di filosofia per questo
cosa e persone completamente diverse
ho provato a decomprimere questo in un mucchio di
modi diversi quindi c’è un grande libro
di Charles Betts chiamato architettura e
varietà di brevetti in cui dice bene te
conosci in realtà il modo in cui la gente pensa spesso
a riguardo è la fabbrica che costruisce il
fabbrica nella progettazione della fabbrica nel
le linee di produzione sono come il nostro prodotto
portfolio life cycle e poi cosa cosa
le macchine sono se ti piace l’individuo
manufatti che escono
il nostro portafoglio di servizi e questo è un modo
di tipo di prendere quelle macchine da costruzione
metafora e applicandola in un altro modo
a pensare a questo proposito è che in realtà la
la fabbrica è il ciclo di vita di uno
servizio individuale che gradualmente
si evolve nel tempo e poi il
transazioni individuali quando lo sapete
comprare qualcosa o richiedere un servizio a quelli
sono come le macchine che escono dal
linea di produzione il servizio individuale
la richiesta è come quella di chiedere a
auto da costruire e quella che esce dal
linea di produzione e quindi si può certamente
pensaci in questi modi e c’è
cose fruttuose si può uscire da questi
metafore per te conosci il prodotto
portafoglio o il portafoglio di servizi IT
e c’è un grande libro di un ragazzo chiamato
Don Rhine al CERN ha definito i principi
del flusso di sviluppo del prodotto che tu
sai prende questa metafora di te lo sai
magra come sviluppo del prodotto e deriva
una grande quantità di molto molto interessante
roba da quello è davvero grandiosa
libro per le persone che sono geek in giro
processo e sviluppo del prodotto e
gestione dello sviluppo del prodotto e
attinge a molte idee snelle anche se come
Don sottolinea quando scriveva su
questa roba 20 anni fa nessuno lo farebbe
in realtà il termine lean non era nemmeno stato
inventato a quel punto, quindi lui tipo di
precede quella applicazione
metafora che vediamo molto nel software
lo sviluppo particolare è l’idea di
la tavola Kanban o lo storyboard e
qui queste singole cose che sono
pezzi di lavoro come storie o correzioni di bug
o qualunque cosa siano come le macchine
in movimento
la linea di produzione e quello che facciamo noi
pensa a come migliorare il
efficienza del processo di consegna entro
sai creare un sistema di pool qui da
guardando quanto tempo ci vuole individuale
storie da spostare su tutta la linea
ma non è una metafora perfetta di un sacco di
le cose che vanno nella Toyota
Sistema di produzione sul miglioramento
l’efficienza si basa sul sapere cosa
le persone stanno facendo e vedendo quello che sono
facendo e effettivamente guardando e vedendo
cosa stanno facendo e vedendo come le persone
effettivamente guardando come possono migliorare
il loro stesso processo c’è il suo concetto di
andando a gamba in magra che è in realtà
visitare la fabbrica e i tempi
persone che fanno cose e parlano insieme
su come questo processo potrebbe essere migliorato
è molto difficile farlo in questo
ambiente non puoi semplicemente sapere parlare
Bene, passeremo il tempo per quanto tempo
serve per costruire un test per questa storia
e vai a sederti vicino ai modi principali e sii
come non cronometrare quanto dura
ti porta a costruire il test di accettazione
Io nessuno lo fa perché sarebbe
un po ‘raccapricciante e alla gente non piacerebbe
e la variabilità è veramente alta e
è molto diverso per ogni persona in modo
anche il concetto di standardizzazione in
questo contesto è davvero molto difficile e a
molte delle idee che vanno in Toyota
Ovviamente, il sistema di produzione non si applica
quando pensiamo a te, conosci il concetto di
le auto che si muovono sulla linea di produzione
come storie su un muro di storie quindi è così
importante tenere a mente che abbiamo un
molto da questa idea di Kanban come gestione
storie o gestione di bug di compiti qualunque
ma è solo una metafora ed è di no
significa una metafora perfetta
quindi quali altre metafore potrebbero esserci
per la linea di produzione nel software
sviluppo bene nel 2006 io e un nord
chi presenta oggi penso giusto
fingi alla sessione prima di me e
Chris Reid che è anche qui oggi noi
Ho scritto un documento Ciao Chris, ecco Chris
Chris e me e Dan hanno scritto questo documento
2006 per la conferenza agile in cui
se ti ricordi di Minneapolis, penso
quando lui senza sforzo e
e ha deciso che avrebbe chiamato questo
la linea di produzione di dispiegamento fondamentalmente
a causa di questa metafora e solo
mi è venuto in mente molto più tardi che in realtà
che è che permette di applicare un sacco di
principi snelli a ciò che stiamo pensando
ma il concetto chiave in questo era quello
in realtà ciò che stiamo guardando è
l’unità di base del lavoro è un cambiamento in
controllo della versione e modifica della versione
il controllo crea una build e la build
progredisce attraverso la linea di spiegamento
alla produzione e quando colpisce
produzione offre valore alle persone
e e e quindi è molto diverso
metafora da tutte le altre quelle del
idea ricostruire è molto concreta e
si scopre che puoi prenderne un sacco
roba interessante da questa metafora
della linea di produzione come processo per
distribuire i cambiamenti e l’individuo
l’unità è cambiata in controllo di versione
cambiare portando ad una costruzione, quindi cosa funziona
possiamo uscire da quello per
capisci cosa ci dà questo
diverso dalle altre metafore noi
dovevo tornare alle radici di Toyota così
chissà cosa stava costruendo la Toyota
prima stavano costruendo macchine tessili
roba sì, più o meno
così la Toyota non fu originariamente chiamata
Toyota è la famiglia che ha creato Toyota
in realtà chiamato la famiglia Toyota e
i loro prodotti innovativi erano i
Telaio automatico Toyota tipo G e questo è
una foto di esso, quindi penso che fosse
gli anni ’20 non riesco a ricordare esattamente ma
intorno a così sai quasi un secolo
fa ora e la svolta chiave in questo
un particolare prodotto era che poteva
rilevare quando c’era un problema, quindi se lo fosse
esaurito thread o se il tipo di telaio
di sono coinvolti o qualcosa di simile
se ci fosse qualche problema nel processo
di produrre il tessuto che avrebbe fatto Lu
fermarsi e notificare automaticamente il
operatore che ha avuto un problema e questo
ha creato un enorme miglioramento in
la produttività prima di tutto è diventata
impossibile produrre prodotti difettosi
perché nel momento è successo qualcosa
quale risulterebbe in un difetto
prodotto che la macchina si fermerebbe in secondo luogo
fino al punto in cui questa macchina
è stato creato ogni volta che c’era un problema
l’ operatore dovrebbe stare a guardare
il telaio seduto al telaio a guardarlo
per convalidare manualmente ciò che è stato
prodotto era in realtà buono e un preavviso
immediatamente che c’era un problema e
fermati lì e poi così hai dovuto
avere una persona per ogni telaio manualmente
ispezionando i test di esecuzione dell’output se
ti piace manualmente per assicurarti che il
il prodotto era effettivamente buono e quando tu
avere un sistema che rileva i problemi
stesso e si ferma solo tu hai bisogno
una persona per stanza di telai puoi
avere una persona il cui compito è quello di
monitorare tutti i telai perché non lo fanno
devono fare tutto ciò che devono
attendere che il telaio rilevi un problema
e poi si intervengono ora
questo è un punto di svolta in termini di
produttività per la produzione di tessuti
ma si scopre che questa idea è
centrale non solo per la produzione di Toyota
delle auto ma anche allo sviluppo del software
ed è così importante che, naturalmente,
c’è un termine giapponese per questo e
ogni volta che c’è una cosa importante
concetto snello devi conoscere il
Termine giapponese che è molto importante bene
Penso che la storia di questo termine sia
tipo di interessante se andate a leggere
Toyota dispiace il libro di Ono su Tai Chi
libro del proprietario sulla gestione del posto di lavoro lui
tipo di parla della storia di questo
termine che sono venuti con così questo è
la parola giapponese per l’automazione è
in realtà caratteri cinesi e poi
questo è il carattere cinese di a
persona e quindi quello che hanno fatto è stato detto
beh, abbiamo l’automazione dell’automazione
conosci il telaio automatico ma abbiamo bisogno
persone per poter intervenire
quando qualcosa va storto e se prendiamo
questi due concetti e metterli insieme
arriviamo con questo termine e cosa è
è successo nella lingua
è che questo personaggio si trasforma in a
radicale che è aggiunto qui che è come
questa parola è diversa da questa parola
abbiamo questo potrebbe avere un extra
qui radicale che rappresenta l’ aggiunta
di persone al processo e questo dà
noi automa emozione che a volte è
tradotto come automazione con un essere umano
elemento e l’idea è che sfruttiamo
macchine e persone per le loro cose
che sono particolarmente bravi a
le macchine sono buone per l’esecuzione
compiti ripetitivi per gli umani
risolvere problemi
e il modo in cui produciamo l’alta qualità
i prodotti è che usiamo le macchine per
fai il noioso lavoro automatico ripetutamente
e usiamo gli umani per risolvere il
problemi e creiamo sistemi in cui
questi due elementi possono fare quello che sono
meglio e combinandoli è così
costruiamo la qualità in qualunque cosa sia
stiamo producendo e quindi questo è centrale
al sistema di produzione Toyota questo
concetto di judoka e in particolare il
idea del rilevamento automatico
i problemi e la notifica degli utenti sopravvive
i concetti della mano su corde e
la sfera di visualizzazione che ti dice quando
qualcosa che non va in modo che ha sentito della
mano su corde così in una fabbrica di Toyota
c’è una chiamata che puoi tirare quale
fa sapere alla gente che hai un
problema quindi in pratica se sei sul
linea di produzione e questi marchi sul
Fondamentalmente sono il tempo in secondi
che sta prendendo questa macchina per muoversi
oltre l’area di lavoro di questa persona e se questo
la persona non ha completato l’attività che è
supposto per completare dal momento in cui ottiene
a qui poi quello che faranno è che lo faranno
tira il cavo e sul cavo e quella volontà
convocare un gestore di venire ad aiutarli
e se non riescono a risolvere il problema
insieme, quindi, possono annullare l’annullamento
di nuovo il cavo e fermerà effettivamente il
linea di produzione ora questi due concetti
sono davvero rivoluzionari da circa 20 anni
fa
GM ha creato una joint venture con Toyota
ed è stata la prima volta che la Toyota ha avuto
stato in una joint venture con un altro
compagnia e hanno creato una pianta chiamata
Noomi a Fremont in California e nel
le piante di nume erano state appena chiuse
da GM perché aveva la peggiore forza lavoro
il sindacato ha ammesso che era il lavoro
la peggiore forza lavoro e ha avuto il peggio
gestione e prodotto il peggio
prodotti di qualità e così si spengono
la pianta e hanno detto bene che useremo
questo per la nostra prima joint venture e
poi Toyota ha fatto qualcosa tipo di
radicalmente hanno effettivamente riassunto tutti quelli
persone e li mandò in Giappone per allenarsi
loro per creare il nuovo piano me che è
la joint venture così hanno detto che siamo
andando ad assumere tutte queste persone che erano
la peggiore forza lavoro in GM negli Stati Uniti e
useremo queste persone come
base per il nostro nuovo tipo di fabbrica di noci
cose da fare
sai che questa forza lavoro era conosciuta per
fare le cose come se fossero così incazzato
con il loro lavoro farebbero cose
come bottiglie di coke piuttosto vuoti all’interno
le porte in modo che le porte potessero vibrare
quando ti chiudi che li apri
è così miserabile e scontento
Erano con il loro lavoro così loro sono
entrato in una padella e ottenuto il tipo di toyota
formazione e sono tornati e quando io
pensa a qualche mese di avvio del
nuovo me pianta il nuovo me pianta era il
forza lavoro più produttiva in tutto il
USA nel portafoglio di GM e anche loro
prodotti prodotti in termini di automobili che
erano di alta qualità come le auto che
sono stati prodotti nello stabilimento Toyota di
Il Giappone e c’erano molte cose
che penso così se tu ci sia un
podcast su questa e questa vita americana
podcast sul nuovo piano di me che io
lo consiglio vivamente a tutti ascolta I
significa che questa vita americana è comunque grande
ma il nuovo podcast è davvero molto
brillante e due delle cose che il
le persone intervistano le persone che
effettivamente stavano lavorando nella pianta GM
e andò e ha ottenuto l’allenamento di due cose
che erano diversi in primo luogo, conosci il
idea che se qualcosa ti va male
può tirare un cavo e un manager arriverà
e quel manager ti aiuterà
era una specie di concetto rivoluzionario
piuttosto che il manager che viene e
urlando contro di te e poi cercando di sparare
tu che il manager avrebbe davvero aiutato
tu Wow e poi l’altro rivoluzionario
concetto è l’idea che ha un lavoratore
il potere di fermare la linea così in GM
fabbriche tradizionalmente cosa vorrebbe
capita non è nessuno la linea non sarebbe mai stata
fermato giusto quello che succederebbe è il
le auto sarebbero uscite dalla linea di produzione
molti di loro avrebbero avuto dei difetti
metterli in un sacco e sistemarli più tardi
e c’era un sacco enorme pieno di macchine
accumulando che aveva difetti di vario
tipi e quindi con la sua produzione di paranco
sistema ogni volta che trovi i difetti se
non puoi aggiustarlo nel tempo in cui tiri il
cord la linea di produzione si ferma così
era un concetto rivoluzionario quindi una cosa
la gente non capisce è quanto spesso il e
il cavo lungo è tirato così quante volte lo fa
pensi che l’ analogico venga tutto tirato dentro
la fabbrica Toyota ha qualche ipotesi
una volta al mese assumere centinaia di volte a
giorno noleggio mille volte di nuovo giorno di noleggio
quindi in realtà sono circa tremila
volte al giorno che arriva l’ end encore
tirato in modo che la loro linea di produzione non lo faccia
fermati ogni volta che arriva la chiamata sconosciuta
tirato dal muro di Berlino viene tirato
tre mila volte al giorno in media
è molto più spesso di quanto la gente pensi
e questo dimostra il livello di
collaborazione all’interno dell’organizzazione
tra le persone e facendo il lavoro
e la gestione è molto
ambiente collaborativo quindi questa idea
di fermare effettivamente la linea dell’avere
un sistema per rilevare problemi di qualità a
nel momento in cui si verificano piuttosto che
aspettando che escano
quindi gli utenti hanno un analogo nel software
lo sviluppo e l’analogico è continuo
integrazione quindi chi è nel pubblico
praticando l’integrazione continua su
la loro squadra va bene tenere le mani in alto mantenere
le tue mani in alto mantengono le tue mani
il tuo esercizio per questa sessione manterrà il tuo
mani in alto, quindi metti le mani
giù a meno che tutti gli ingegneri sul tuo
la squadra sta controllando nel bagagliaio circa una volta
un giorno o più spesso di quello
quindi se questo non è vero se gli sviluppatori sono
trekking in feature branch che
non vengono poi uniti in mesi di tronco
un giorno o se stanno controllando no
verificarlo e mettere le mani
giù altrimenti li può tenere il passo giusto
quindi abbiamo perso circa i due terzi del
persone così se ogni check-in non lo fa
portare a test di unità di costruzione in esecuzione
metti giù le mani altrimenti tienili
va bene così abbiamo perso un paio e poi
quando la costruzione si rompe se poi non lo fa
si risolve entro una decina di minuti
metti giù le mani se la build è
spesso rotto per più di dieci minuti
metti giù le mani altrimenti tienili
va bene quindi ci sono circa dieci persone dentro
la stanza che stanno facendo davvero questo
integrazione così rotonda di applausi per te
ragazzi è fantastico continuo
l’integrazione è davvero difficile non lo è
correre Jenkins contro le tue caratteristiche
rami e poi ignorando la build
quando diventa rosso è la pratica di
assicurandoti che il tuo software sia sempre
lavoro
nel momento in cui trovi un problema lo aggiusti
subito se il conto diventa rosso e
tutti lo ignorano è come lo sai
loro il telaio rileva un problema e
si ferma e l’operatore va lì
fottendoti un tessuto da carico
è ottenuto rotture in esso si sa tutto
come lasciare che la macchina scenda
linea di produzione e lo inseriremo in a
molto e poi lo ripareremo più tardi , sai
questo è quello che stai dicendo è fondamentalmente
che tu conosci bene, non importa che c’è un
problema ma qualunque cosa ho intenzione di portare
scrivendo codice perché è quello che ho
come fare così la pratica del continuo
l’integrazione è meglio descritta nella mia
opinione in un articolo di James Shaw che
parla dell’integrazione in dollari al giorno
e questo è il processo che sto scrivendo
codice ho finito quello che sto facendo io corro il
costruisci e prova localmente per assicurarti che
lavoro e loro passarono così così a quello
punto che ho intenzione di unire il tronco anteriore a
assicurati che il mio lavoro si armonizzi e
si fonde correttamente con il lavoro che
altre persone stanno facendo nella mia squadra, quindi sono
andando a tirare il baule anteriore nel mio
locale dove posso copiare e quindi unire
ed esegui la build e prova nuovamente per creare
sicuro che ciò funzioni è come farlo
questo è il doppio di come distinguiamo il mio bug
da un bug causato dall’unione a quello
punto che voglio spingere nel bagagliaio
controllo della versione perché voglio condividere
il mio lavoro con la versione di altre persone
il controllo è principalmente un meccanismo di condivisione
è uno strumento di comunicazione prima di me
che ho intenzione di camminare su questo vecchio
postazione di lavoro nell’angolo del
stanza e vado a vedere se la gomma
polli non c’è, intendo
qualcun altro è il check-in devo
aspetta il pollo di gomma quando lo fa
diventa disponibile prendo la gomma
il pollo torna al mio computer, controllo
in spinta in tronco e poi tornare a piedi
la vecchia workstation e poi controllo
dal tronco eseguire la build e testare
l’altra macchina per dimostrare che il
la cosa in realtà funziona su una macchina che è
non la mia macchina
non solo la mia macchina yay se è vero
e funziona
Metto giù il pollo della spazzatura e porto il
bell ding hooray Ho finito, non ho finito
ma fatto nel senso di opere sul
macchina che non è solo mia, se è così
non funziona non ottengo a suonare il
campana costruisce strade Ho due opzioni
l’opzione uno prova e risolve il problema che ho
ho un paio di minuti per provare e trovare
il file che ho dimenticato di controllare o
qualunque sia la mia opzione per il rollback
assolutamente corretto il più egoista
cosa che puoi fare come sviluppatore è
lasciare i codici rotto su una build di rotta su
tronco perché significa che tutti gli altri
sta lavorando su qualcosa che non lo è
noto per essere buono quindi sì, se trovi un
problema e non è possibile risolvere il problema direttamente
via estrae la tua modifica dalla versione
controllo
questo è molto molto importante e un
pratica sottoutilizzata quindi sì per
essere in grado di fare questo abbiamo bisogno di assicurarsi
tutti stanno controllando nel bagagliaio almeno
una volta al giorno e che effettivamente paghiamo
attenzione quando quella cosa diventa rossa così
il problema è il pollo di gomma
non scala quindi cosa scala
bene ancora una volta, nonostante questo discorso
la scorsa notte ho dimenticato di aggiungere il
a destra scivolo nel mio mazzo di diapositive che era
un chiaro fallimento di judoka ci vediamo così
se posso averlo qui
questo dovrebbe essere più veloce della scorsa notte
perché in realtà so dove si trova adesso
sì, così hey questo è ciò che è questo
lo fanno a Google e trovo queste statistiche
abbastanza stupefacente così 10.000 sviluppatori
in oltre 40 uffici più di 2000
progetti in sviluppo
praticamente tutto tranne chrome e
Android è controllato in un enorme
perforce repository e tutto è
costruito fuori dal tronco e da tutti gli sviluppatori
check-in nel bagagliaio ottengono circa 20 plus
il codice cambia in trunk al minuto e
a picchi a 60 circa il 50% del cambio di codice
ogni mese tutto è sviluppato e
rilasciati dal bagagliaio passano tutti i conti
fonte e corrono oltre un centinaio
ecco qui milioni di casi di test al giorno
un’altra diapositiva che ho rubato da Google loro
avere circa 200 mila suite di prova in
il loro codebase esegue dieci milioni di test
Suite al giorno oltre 60 milioni
singoli casi di test al giorno e
crescendo più di quattromila ci
costruisce un giorno quindi questo è l’equivalente
del telaio che rileva i problemi
subito dopo averli controllati
questo è ciò che fa Google questo è il
equivalente della cosa che era
inventato da Sakichi Toyoda
negli anni ’20 per la costruzione di tessuti ma
nel 2014 per la costruzione di software scala uguale
cosa fondamentalmente e si basa su avere
estremamente buono automazione di test che è
molto completo e possiamo eseguirlo
molto molto rapidamente e ottenere un feedback
subito e in modo cruciale una volta arrivati
quel feedback facciamo effettivamente qualcosa
su di esso e risolvere il problema piuttosto che
stendendo la build rimani letto e uno
delle cose che sono una pratica in
Google è questo se qualcosa va in
tronco ed è rotto a chiunque altro
ripristina quel cambiamento, quindi se ti rompi
qualcuno a valle di te quella persona
puoi ripristinare i tuoi cambiamenti e va bene
così quel concetto di codice collettivo
la proprietà che tutti possiedono i codici
e che chiunque può ripristinare qualcuno
il resto è un brutto cambiamento dal tronco
parte della cultura e questo è molto molto
importante
comunque solo avendo quei test di base
questa parte del processo CI non lo è
abbastanza e il tipo di Google
scala le cose per le ombre che così semplicemente
avendo una configurazione CI di base che vuoi
costruire per eseguire in pochi minuti perché
si desidera ottenere il feedback veloce ma
quel feedback non sarà
completo che è il motivo per cui è necessario a
molti altri test di accettazione
e poi altre cose come l’utente
test di accettazione test di prestazioni I
significa che questo è un diagramma molto semplice ma
il tuo processo sarebbe più complesso di
che c’è un certo numero di differenti
convalide che hai provato prima di te
può portare cose alla produzione e così via
la domanda è come costruiamo questo dove
iniziamo come lo evolviamo e in
per rispondere a quelle domande che sono
andando a darvi un caso di studio da a
società che ha fatto questo su larga scala e questo
la compagnia è Hewlett Packard e il team
quello ha fatto è la squadra che ha costruito il
firmware per il laser di Hewlett Packard
gira così il team del firmware HP LaserJet
circa 400 persone distribuite in 400 persone
in tutti e tre i continenti c’è una squadra
a porto alegre in brasile c’è una squadra
a Boise Idaho e c’è un’altra squadra
Penso sia a Delhi che a Bangalore
India e così dispiaciuta dilettarsi o Bengaluru in
India e quindi distribuzione di 400 persone
attraverso tre fusi orari e avevano a
problema il loro problema era che erano
andando troppo lentamente non erano in grado di farlo
tenere il passo anche con le nuove versioni di
la dell’hardware che sono stati in uscita
per non parlare della costruzione di nuove funzionalità per nuovi
i prodotti su cui si trovavano sul software
il percorso critico e questo è un comune
motivo per cui vediamo le persone adottare
la consegna continua è quando il software è
sul percorso critico che è quando le persone
Iniziamo dicendo che abbiamo bisogno di ottenere una migliore
facendo questo e così la prima cosa che loro
ha fatto bene, in realtà non è il primo
cosa hanno fatto prima che effettivamente
provato a progettare la loro strada dopo il
problema hanno provato a licenziare le persone
le persone che esternalizzano la gente tutto il solito
cose che fanno le grandi aziende e quando
niente di tutto ciò funziona allora il marketing e
la gente del prodotto è venuta agli ingegneri e
per favore aiutaci a risolvere questo problema
usando l’ingegneria che è come lo sai
le cose vanno veramente male quando le persone lo sono
chiedere aiuto agli ingegneri e così via
la prima cosa che hanno guardato è ciò che sono
in realtà stanno spendendo il loro tempo
e così l’hanno scoperto
basicamente usando un abbastanza leggero
sistema informale di chiedere semplicemente le persone
cosa stavano facendo il loro tempo facendo
e questo è quello che hanno trovato
quindi per capire perché questo è vero te
devo capire che ogni volta un nuovo
linea di dispositivi è venuto fuori che avrebbero
creare un ramo nel controllo della versione per
quella nuova linea di dispositivi così avevano a
numero di rami diversi ogni volta
aggiungono una funzionalità o creano un bug-fix
devono portare quella correzione di bug o
funzionalità attraverso tutti questi diversi
filiali quindi stavano spendendo il 10% di
il loro tempo facendo l’ integrazione del codice del 20% di
il loro tempo facendo pianificazione dei dettagli del 25% di
il loro tempo porting codice tra filiali
25% del loro tempo sul supporto del prodotto
cosa ti dice che grande?
numero sul supporto del prodotto che cosa fa
dire 50 problema di qualità giusto 50 era
dicendo che c’è un alto test manuale
sottrai questo dal 100% e cosa
si è lasciato con è del 5%, che hanno
sosteneva invece il tempo speso a innovare
di quello che avrei fatto
sarebbe stato sdraiato sul pavimento con
una grossa bottiglia di vodka dichiararono
stavano innovando, quindi questo è carino
male e cosa decidono di fare bene
hanno deciso di fare quello che è in realtà
la cosa più rischiosa che si possa fare
e chi entra nel kamil più spinoso parlava
prima di me sì, così hanno fatto un grande
riscrivere che è una cosa pazza per farlo
Non lo consiglio ma ci riescono
per ragioni che esploreremo un po ‘
più tardi e la chiave architettonica
la decisione che hanno preso sono stati architetti
il sistema per testabilità e loro
architettato il sistema per essere in grado di fare
integrazione continua così loro
subordinato il loro architettonico
preoccupazioni per la costruzione di qualità nel
prodotto e cosa significava fare
sicuro che il software fosse tutto
era costruito con il tronco e loro avevano
test automatizzati in atto per tutto
quindi questo significava una completa riscrittura perché
hanno dovuto cambiare il modo in cui loro
gestire la diversità del
portafoglio di prodotti che era il firmware
schierato così in fondo quello che succede è
hanno messo le levette sulla posizione così
dispositivo si avvia il firmware degli stivali
cosa sono io oh sono una stampante, quindi vado
per disattivare queste funzioni di scansione
e spento queste funzionalità di rete
e ho solo le mie funzioni di stampa o
L’hardware batte il firmware degli stivali cosa sono io
oh sono uno scanner, quindi ho intenzione di girare
fuori dal
quindi in pratica gestiscono il tipo di
eterogeneità del hardware utilizzando
funzione alterna in modo che possano costruirne uno
binario per ogni dispositivo fuori dal bagagliaio e
tutti potevano lavorare fuori dal bagagliaio e cosa
quello che ha permesso loro di fare è praticare
integrazione continua hanno iniziato
praticando a proprio agio l’integrazione e
ha iniziato a costruire automazione di test e
molto presto hanno scoperto che la build
è stato letto tutto il tempo e quindi il ragazzo che
è stato VP di ingegneria che segue
che HP ha gestito dalla pratica HP
la pratica di gestione è chiamata gestione
camminando intorno ed è fondamentalmente
andando e camminando e chiedendo
domande imbarazzanti che è
in realtà risulta molto vicino al
tipo di sistema di produzione Toyota andare a
gamba vai a vedere cosa sono le persone
in realtà quello era la sua gestione
stile comincerebbe a dire come possiamo
fermare le persone che controllano gli errori nel bagagliaio e
le persone sarebbero come noi ovviamente noi
non lo farei se sapessimo e tu
sapere spazzarlo via e pensare che lo fosse
un idiota e alla fine qualcuno si avvicinò
con quello che era in realtà abbastanza intelligente
idea quindi dopo due anni di lavoro
si sono evoluti dalla loro configurazione di base
una pipeline di distribuzione molto potente
che ti mostrerò sottolineando
che questo è dopo due anni di valore
funziona questo non è qualcosa a cui sono venuti
tu subito ma fondamentalmente tutto
i loro sviluppatori avevano il loro
le code individuali su git avrebbero spinto
i loro cambiamenti individuali nella loro chiave
un cancello che innescherebbe una costruzione e
due ore di test in corso
solo quel cambiamento individuale se quello
passa tutte le modifiche è stato eseguito il backup e
promosso alla seconda fase e che si fonde
tutti i cambiamenti che hanno attraversato il palcoscenico
uno e corre build e circa due ore
vale la pena di test contro solo quel lotto
se fallisce se c’è un’unione
conflitto o sviluppatori di test falliti
ricevi un’email che loro configurano
workstation in modo che gli sviluppatori possano
premere un pulsante e riprodurre il test
fallimento sulle loro workstation usando
virtualizzazione e un emulatore che
emula la piattaforma hardware quando
hai una build che va avanti
qui che passa dalla valutazione al livello due
che è gestito due ore di test che sono
eseguire su un emulatore hanno costruito il proprio
emulatore per gli Asics personalizzati che erano
il loro tipo di dispositivi logici molto complessi
che alimentano stampanti e multifunzione
dispositivi in modo da scrivere il proprio emulatore
un po ‘di lavoro piuttosto sofisticato e
allora se il conto passa al secondo livello allora
va al livello tre che viene eseguito su a
mazzo
schede logiche che sono effettivamente in Iraq
così la scheda logica accenderà il download
ultima versione della firma che è passato
livello 2 e quindi vengono eseguiti automaticamente
prova come inviare segnali a
schede logiche quindi è carino
cose sofisticate che effettivamente porto
giro una copia di questo libro che non ho
oggi ma normalmente lo porto in giro
ai clienti in modo che chiunque si lamenta
che l’automazione del test è troppo difficile
sculacciali con questo libro perché se tu
può costruire l’automazione di test per il firmware
su schede logiche nessuno ha un problema
così difficile da sapere che questo è un
problema risolvibile è solo che stai andando
mettere un lavoro sufficiente per risolverlo
quindi questa è una cosa piuttosto sofisticata
e ci sono voluti molto tempo per costruire se
tu vai attraverso il livello 4
che è per 24 ore durante la notte
Conosco infatti 30.000 ore di valore
test automatizzati che sono massivamente
paralizzato e ottieni un feedback all’interno di a
giorno sulla qualità del tuo software così
questo cambia completamente l’economia di
il processo di sviluppo del software e
questo è qualcosa che ci è voluto molto tempo
tempo per arrivare e ha richiesto un sacco di
investimento ma qui ci sono i risultati
dopo tre anni stanno spendendo molto
meno tempo su integrazione continua o on
integrazione perché lo stanno facendo
continuamente sono in grado di massicciamente
ridurre la quantità di tempo che loro
spendere per la pianificazione e non ho tempo
per discutere perché questo è fondamentalmente da
avere un Chakra più prevedibile
processo di sviluppo hanno costruito fiducia
con il lato prodotto delle cose e così via
la gente del prodotto richiede molto meno
dettaglio in termini di pianificazione così
Hanno detto che ti lasceremo cambiare
la tua mente in qualsiasi momento e in cambio
creeremo molto meno dettagli
piani e hanno costruito quella fiducia e quella
li ha aiutati a ridurre la quantità di tempo
stanno spendendo per una pianificazione dettagliata
non stanno portando il codice tra
rami più stanno lavorando su uno
il supporto del prodotto principale della filiale va giù
dal 25 percento al 10 percento che cosa fa
che ti dice di migliorare la qualità sì
alta qualità molto meno tempo speso per
il test di supporto del prodotto va giù e
aumentano la quantità di tempo
sono stati spesi innovando da un fattore di
otto persone ora il intelligenti nel
il pubblico noterà che questi no
aggiungere fino al 100% e il motivo per questo
è perché stavano spendendo il 23%
del loro tempo sulla gestione automatizzata
test
costruendoli a trovarli
feedback su di loro quindi c’era a
investimento sostanziale coinvolto in
creando questo massiccio aumento in
produttività sì mi dispiace yeah quindi CP è
solo il loro processo per triaging bug
prego
e così questo cambia l’economia del
processo di sviluppo del software e il
La ragione per cui amo questo case study è perché
hanno misurato questi numeri e poi
hanno scritto un libro e tu puoi andare a comprare
questo è un libro favoloso e questo è un
farti scivolare, so solo che puoi averlo
puoi scaricare le diapositive in qualsiasi momento
qualcuno ti chiede qual è il valore
la proposizione è di consegna continua o
il ritorno sull’investimento è possibile
dai loro questa diapositiva quindi ne ho solo 50
sono rimasti pochi minuti per concentrarmi veramente
su è come hanno ottenuto da A a B hanno fatto
non pianificare questa distribuzione molto complessa
conduttura che hanno costruito che non era
qualcosa che sapevano che stavano per
creare tutto ciò che era parte di loro
la pianificazione si è evoluta nel tempo così come il loro
tutta l’architettura come tutta la loro
approccio alla costruzione del sistema e cosa
ho guidato questo intendo questo è un po ‘
straordinario ciò che ha spinto sono loro
inventato autonomamente il continuo
consegna stavano facendo questo prima del
il libro è uscito anche loro in modo indipendente
inventato qualcosa chiamato il
taglierina di miglioramento quindi questo tipo Mike
ruther è un ricercatore davvero brillante
è un ricercatore presso l’ Università di
dov’è dove si trova Ann Arbor
Michigan quindi è all’Università di
Michigan è un professore che ha scritto a
libro chiamato imparare a vedere quale è
sulla mappatura di Valley Stream è lui
ha ricercato Toyota per molti anni lui
ha scritto recentemente due anni fa questo Shingo
libro pluripremiato che è favoloso
lo consiglio vivamente e parte del suo lavoro
è stato per aiutarci a provare i produttori e
riprodurre ciò che la Toyota è stata in grado di fare in
le loro fabbriche quindi andrebbe a vedere
cosa stava facendo la Toyota e poi lo sai
I produttori statunitensi lo impiegheranno per provare
e insegnare loro come riprodurre la Toyota
risultati e direbbe che lo sono
facendo queste cose forse dovresti provare
facendo queste cose intendo che era di più
sofisticato, ma c’era un
elemento di quello
e poi tornerebbe al giocattolo
fabbriche un paio di anni più tardi e
guarda cosa stavano facendo e notato
non stavano più facendo quelle cose
quindi è stato un po ‘ imbarazzante perché
ha detto a queste aziende di andare e di fare
queste cose e loro non stavano facendo loro
più e poi direbbe bene ora
loro stanno facendo queste cose forse tu
dovrebbe cercare quello e poi tornare indietro e
poi due anni dopo non stavano facendo
anche quelle cose e così via
scopre che sai che in realtà è un
elemento molto importante di complessità
teoria questa idea che possiamo prendere a
pratica da un sistema complesso e
Trapiantalo in un altro complesso
sistema e si aspettano gli stessi risultati a
si svolge è falso l’intero punto di
sistemi complessi è che se prendi il
stessa serie di cose e trapianti
li otterrai diversi risultati questo
è il motivo per cui le metodologie non funzionano
le metodologie sono fondamentalmente post hoc
razionalizzazioni di qualcosa che
è successo a lavorare in un particolare complesso
sistema in un momento particolare e se tu
prendilo e mettilo in un altro complesso
sistema non otterrete lo stesso
risultati e quindi cosa vedi se guardi
in un’organizzazione ad alte prestazioni e tu
guarda le pratiche che stanno facendo
per vedere se è possibile copiarli e migliorare
la tua performance è ciò che stai vedendo
non le migliori pratiche ciò che stai vedendo è
contromisure al particolare
problemi che quell’organizzazione è
incontro in questo momento e se ci provi
e copiare le contromisure in modo diverso
ambiente in cui non produrranno il
lo stesso risultato, quello che devi fare è imparare
come mettere efficacemente le contromisure
sul posto ed evolvere quelli
contromisure e questo è fondamentalmente
quello che Toyota sa fare meglio di
chiunque altro e questo è formalizzato in
cosa potrebbe piuttosto causare il miglioramento
il cutter e il cutter di miglioramento è come
impari come essere in grado di metterli
contromisure in atto e questo termine
Catto è un po ‘importante allora
chi è visto nel drago
okay, allora entra nel film del drago Bruce Lee
Il film di Bruce Lee mi dispiace che sia Bruce Lee
volando nei cattivi ragazzi le isole hanno ottenuto un
l’isola ovviamente sta ancora aspettando la mia
isola in ogni caso il ragazzo malvagio ha un’isola e
tutti i cattivi ragazzi scagnozzi tutti
praticando le loro mosse di judo sul
isole Non posso fare judo, quindi sta andando
al ridicolo ma sono fondamentalmente
sai fare lo stesso
più e più volte ha e questo è ciò a
gatto è katha sta prendendo una mossa di base e
praticandolo più e più volte è
come fare le scale se lo sei
imparare musica o qualsiasi tipo di base
cosa ripetuta c’è un’unità di
qualunque sia la pratica più ampia è quella
lo stai facendo e quindi l’idea è che tu l’abbia
per imparare le basi prima e poi tu
metterli insieme e improvvisare e
combinali e sai creare cose
e così bene come l’intuizione era quella gente
chi sta facendo il lavoro è sempre
praticare come migliorare la qualità di
il loro lavoro è un’abitudine così da imparare
come eseguire esperimenti per provare nuove cose
migliorare e porre contromisure in
posizionare e vedere se funzionano è un’abitudine
che tutti alla Toyota stanno facendo tutto
giorno e il lavoro di gestione è a
creare l’ ambiente in cui le persone
può praticare questa abitudine di provare
cose nuove e miglioranti e lui
fondamentalmente in questo libro e ci sto provando
riassumere questo libro in dieci minuti che
è piuttosto difficile e io davvero
consiglio di andare e leggerlo questo è
fondamentalmente il ciclo di come funziona
prima di tutto capiamo la direzione
quindi guardiamo dove vogliamo entrare
come un paio d’anni quindi per HP
Firmware LaserJet loro visione era che
voleva un aumento di dieci volte in
produttività che era la loro visione
misurabile è un obiettivo che sarà
difficile da raggiungere non sappiamo come siamo
andando a farlo è la direzione allora
noi cogliamo le condizioni attuali come stanno
cose adesso e afferrando il
la condizione attuale è qui questo è il
condizione attuale destra e poi il
la prossima cosa che guardi è qual è il
la prossima condizione dell’obiettivo e questo è a
orizzonte di circa due o sei settimane fuori così
guardiamo dove vogliamo essere in due a
sei settimane e poi non pianifichiamo come
ci arriveremo perché noi
non so come ci arriveremo
perché stiamo facendo processo di innovazione
innovazione di miglioramento e in qualsiasi momento noi
innovare non è possibile pianificare esattamente come
lo farai perché poi è così
non innovazione e questo è davvero
cruciali le persone che fanno il lavoro hanno
per cercare di capire come stanno andando a
raggiungere la condizione obiettivo attraverso a
processo di sperimentazione PDCA è
plan-do-check-act è il ciclo di Deming
è fondamentalmente il metodo scientifico
esperimento di progettazione eseguire Nix
e raccogliere i risultati capire se
quella cosa è qualcosa che dovresti portare
fare o se dovresti smettere
farlo e questo ciclo è nel cuore
della Lean Startup ed è al
cuore del miglioramento dei processi ed è a
il cuore dello sviluppo del prodotto e
allora basato su questo lo farai
c’è un ciclo di feedback per il prossimo set
di condizioni che hai intenzione di provare
e stabilire il prossimo mese e anche
è la vostra visione complessiva in modo che
il ciclo di feedback è davvero importante
non necessariamente andando a realizzare tutto
quelle condizioni obiettivo e così e in
il corso del tentativo di raggiungerli
stai andando a scoprire un sacco di
cose che ti faranno resettare
quali sono le tue prossime condizioni di destinazione
tutto questo suona un po ‘ astratto
quindi ti darò un esempio di a
serie di condizioni target rispetto all’HP
Le persone del firmware LaserJet sono state installate
così hanno chiamato queste cose che hanno chiamato
le loro iterations mini milestones e
li hanno avuti ogni mese e questo è un
tabella dei loro obiettivi di mini-traguardo
per mini milestone anni ’30 ce ne sono due
e mezzo anni in così rango zero loro
voleva che le questioni prioritarie si aprissero di meno
di una settimana e due guasti di livello due
risolto entro 24 ore e livello uno loro
avevano un rilascio trimestrale che erano
la priorità cambia le richieste commerciali
risolti volevano l’errore di affidabilità
tasso a qualunque criterio di rilascio
era e puoi vedere che hanno un intero
gruppo di risultati obiettivo misurabili loro
voglio raggiungere entro un mese da oggi e
questo era praticamente l’intera pianificazione
per tutto il prossimo mese per il
intero programma di 400 persone si adatta a
un’unica pagina questi sono i misurabili
risultati che vogliamo raggiungere nel prossimo
mese per l’ intero programma e non lo facciamo
sapere come faremo a modo nostro
lo scopriremo è dalle persone
provando un sacco di cose per capire come
ci arriveremo e ci baseremo
sui risultati che stiamo andando a sapere
per mini milestone 31 ce ne sarà bisogno
essere un nuovo set e potrebbe includere alcuni
delle stesse cose o potrebbe essere un po ‘
cose diverse e siamo sempre
cambiando ciò che misuriamo e ciò che noi
preoccuparsi in base ai risultati di cosa
le persone hanno provato l’ultima volta , ad esempio
sai che le persone vogliono sempre sapere cosa
cose su misura e c’è molto
cose che potresti misurare ti darò un
ottimo esempio abbiamo fatto un progetto una volta
dove volevamo l’ 80% di copertura di test da
le persone hanno ragione
test unitari e abbiamo ottenuto una copertura del test dell’80%
che è stato grandioso
quasi rapidamente e poi noi
guardato le prove e abbiamo scoperto che
tutti i test contenuti alla fine
asserire vero quindi stavano chiamando tutto il
metodi nella base di codice e sono stati
affermando vero che ha creato test al 100%
copertura e alcuni test totalmente inutili
e tu sai una cosa molto comune
metti un bersaglio sul posto che la gente farà
trova sempre un modo per raggiungere l’ obiettivo
ma non può essere il modo in cui si
aspettarsi e quindi lavorare davvero
se l’obiettivo produce il giusto
comportamento e modifica degli obiettivi e
le cose che misurate come parte di ciò
processo è molto molto molto importante
la cosa cruciale sono le persone che in realtà
capire cosa fare
sono le persone che fanno il lavoro alla gente
effettivamente arrivare a venire le idee per
come raggiungere quei risultati sono i
le persone che fanno il lavoro sono loro
idee le idee non sono impostate da
gestione che proverai questi
le cose vanno fuori e fanno le persone che
stanno facendo il lavoro a inventare il loro
proprie idee e questo è così importante
perché significa che lo sai
è molto più eccitante da trasmettere
un’idea che ti è venuta in mente di quanto non sia
per far passare l’idea che qualcuno dentro
gestione si avvicinò con non solo come
eccitante per implementare qualcun altro
idea e provando le tue idee e
scoprire cosa funziona e cosa no
impari come migliorare di quello che tu
fare e questo è cruciale per qualsiasi culturale
il cambiamento all’interno di un’organizzazione è il
persone che fanno il lavoro che devi lavorare
fuori come migliorare in quello che fanno
loro stessi e il processo deve
incoraggiare le persone a capire come ottenere
meglio se stessi ed è così che tu
creare un’organizzazione di apprendimento ogni giorno
in questo modello la gente chiede cosa sono
stiamo cercando di ottenere adesso cosa c’è
la condizione attuale siamo di fronte a ciò che è
impedendoci di raggiungerlo quale
di quelle cose che stiamo per affrontare
in questo momento quali esperimenti stiamo andando
eseguire per provare e risolvere il problema e
dove possiamo andare a vedere ciò che impariamo
da quel che è come si è conclusa con
questa potente pipeline di distribuzione
in sostanza un sacco di cose che loro
provato
per vedere se funzionano e gradualmente
ha assunto questa forma così non l’hanno fatto
implementare distribuire la consegna continua di
leggendo il libro che hanno implementato
consegna continua provando a
mucchio di cose e loro tipo di
è venuto in modo indipendente con esso perché
risultato essere una buona idea così può a
un paio di pensieri conclusivi me e
Jean Kim e i laboratori di burattini hanno recentemente eseguito un
sondaggio l’anno scorso del sondaggio DevOps così
alcuni di voi potrebbero aver compilato il
Indagine DevOps che abbiamo messo fine a
l’anno scorso una delle domande che abbiamo posto
è fino a che punto la tua organizzazione è a
alta cultura della fiducia e c’è davvero
bel modello per capire se il tuo
la cultura culturale è una cultura di alta fiducia
da un tizio chiamato Westrom, quindi il westrom era un
ragazzo che stava inventando investigando
sicurezza nell’assistenza sanitaria e si è inventato
questa tipologia di culture organizzative
per guardare la sicurezza nell’assistenza sanitaria ma
in realtà risulta questa tipologia
è una specie di utile per pensare a qualsiasi
organizzazione e ciò che abbiamo scoperto
il sondaggio è che questo è molto alto
correlato con i risultati di business così tu
può effettivamente prevedere i risultati di business
in una certa misura da cui le persone cadono su
questo modello come si ottiene da A a B
come si ottiene se sei patologico o
burocratico come si ottiene così
bene generativo è molto molto difficile
non ho un proiettile d’argento ma un
una parte importante di questo è dare il
persone che fanno il lavoro al potere
cambia il loro processo e modifica il loro
elaborare e provare nuove cose e poi no
punendoli quando vanno queste cose
sbagliato questa intera idea che il fallimento
causa l’inchiesta non fallimento è coperto
e nuove idee di benvenuto non nuove idee
sono schiacciati, è molto importante
parte della creazione di una cultura di alta fiducia
qual è il modo in cui crei una cultura di
miglioramento continuo che è come te
innovare così in termini di leadership
davvero tutti questi problemi iniziano e finiscono
con la leadership e c’è una divisione
di lavoro i leader decidono i risultati
con un breve orizzonte e il corto
l’orizzonte è davvero importante perché tu
non so se i risultati desiderati
quindi effettivamente i risultati desiderati
e vi accorgerete che il vostro genere
idee su come specificare i risultati prodotti
il comportamento sbagliato, quindi devi avere
un breve orizzonte temporale in modo da poterlo convalidare
così i leader decidono cosa deve fare
essere fatto, ma le persone che fanno il lavoro
decidere come sarà fatto
la divisione del lavoro è un leader essenziale
non dovrebbe essere decisivo e manager
non dovrebbe dire alla gente come fare
il loro lavoro le persone che fanno il lavoro
dovrebbe decidere come stanno andando a fare
il loro lavoro e poi il lavoro dei manager
è quello di aiutare le persone che stanno lavorando
per loro di eseguire esperimenti e provare a
mucchio di cose e fondamentalmente eseguire il
metodo scientifico e quindi cruciale
stiamo andando ad aggiornare i nostri risultati del nostro
visivo nelle nostre metriche basate su cosa
abbiamo imparato nel processo di provare a
un sacco di cose così finalmente il lavoro di
l’automazione è di aiutarci a rilevare
problemi in modo che noi come esseri umani possiamo andare
in un problem solving che è ciò che noi
bravi a usare i computer per fare le loro cose
le cose che sono brave a cui è
eseguendo attività ripetitive che usi
le persone per le cose in cui sono bravi
che risolve i problemi, funziona sempre
piccoli lotti perché quando sei
lavorando un sistema complesso e ci provi
qualcosa sta andando rapidamente
divergono da ciò che ti aspetti che accada
e dici che vuoi limitare il possibile
svantaggio di cose che vanno male e ottenere
un feedback molto stretto scorre ciò che vuoi
la misura migliora in ultima analisi è il cliente
i risultati e troppe poche persone sono concentrate
sulla misurazione dei risultati del cliente
la consegna continua passa dall’idea a
risultato misurabile per i clienti e se
non stai misurando il cliente
risultato dei miglioramenti che sei
provando quindi non hai modo di saperlo
se stanno effettivamente migliorando il
qualità del prodotto che sei
costruendo e poi finalmente se lo si desidera
impara come implementare DevOps o
implementare la consegna continua o carina
molto implementare tutto ciò la risposta è
lo fai attraverso il miglioramento continuo
e per citare il mio ex collega e amico
Il continuo di Mike Roberts è molto di più
spesso di quanto pensi
alla fine voglio solo citare Jesse
Robbins Jesse Robbins come co-fondatore
i codici operativi è stato il principale disastro in
Amazon è un pompiere nei suoi pezzi di ricambio
tempo e fondamentalmente solo un enorme
overachiever Jesse Robbins ha una regola
Jesse dice di non combattere stupido di fare di più
fantastico e quindi se ti stai chiedendo cosa
puoi fare per rendere la tua organizzazione
solo un po ‘meglio come fai tu
quello è che ognuno entra nel lavoro ogni
giorno e pensa come posso rendere la vita a
un po ‘più fantastico per tutti
altro intorno a me e se tutti noi lo facessimo
ogni giorno è così che costruisci un grande
cultura e una grande compagnia
tu
Please follow and like us: