Sono Garrett um Sono molto orgoglioso e felice
essere un compagno di colloquio, uno dei miei
hobby commerciali sta scrivendo libri e io
non parlerò più di me ma io
voglio voglio lamentarmi del
fatto che quasi nessuno che lavora in IT
ha imparato a conoscere in modo sistematico
ammodernamento o manutenzione migliorata
dei sistemi di tutti impariamo fin
cominciando come costruire sistemi da
zero e possiamo farlo abbastanza bene
ma non siamo molto bravi o in realtà noi
sono estremamente cattivi nel mantenere i sistemi
e correndo e migliorandoli o aggiungendo
funzionalità nel tempo, quindi è lì
c’è un po ‘di spazio per migliorare in questo
questo aspetto ti ho portato un diagramma
per favore dai un’occhiata alla linea verde I
spero che tu possa vederlo da dietro è
praticamente originale ho omesso il nome
del cliente o della società ma è come
Ho detto che è più o meno originale è
da una compagnia assicurativa
ha circa seicento software
sviluppatori che lavorano su una varietà di
sistemi e la linea verde ne descrivono alcuni
indicatori di prestazione di uno specifico
patch o sistema relativamente nuovo I
modificato i numeri esatti che non sono
molto interessante all’inizio del
sistema quando il sistema era inizialmente
costruito la squadra composta da circa 30-40
la gente quindi non è molto piccola e non a
un sistema molto grande potrebbe fornire un
numero relativamente elevato di caratteristiche per
rilascia questa azienda rilascia quattro volte
un anno che non è moderno non è alla moda
ma lo fanno è abbastanza ok per
loro nel tempo le prestazioni del
squadra la squadra è rimasta costante
tempo quindi non ci sono stati grandi cambiamenti in
persone
non vi era alcuna riduzione del personale in
squadra o qualcuno di questi dirigenti
tecniche così la squadra è rimasta costante
e la squadra non è complessivamente stupida ora
questo lavoro persone abbastanza comuni loro
capacità di offrire una nuova attività
funzionalità declinata nel tempo così tu
vedi qui un declino molto forte a
certo certo punto nel tempo non lo faccio
conosci la ragione esatta per cui ciò accade
Sono interessato alla curva in questo
diagramma la tendenza generale nel tempo
mostra che la capacità di una squadra di
consegnare il sistema diminuisce probabilmente tu
non hai questo schema esatto per il tuo
sistema ho creato un certo numero di questi
diagrammi per aziende per le imprese
per mostrare loro cosa succede loro
sistemi e lo chiamo molto normale
caso se hai un’opinione diversa
esperienza diversa essere molto felice
perché questo è lo standard del settore in
software in sistemi software quando
i sistemi vengono mantenuti quando i sistemi sono
ha funzionato nel tempo in cui marciscono davvero e
Robert Martin e altri e altri molto
persone intelligenti hanno scritto di questi
sintomi da quando le persone hanno inventato
refactoring a causa di questo fenomeno
nel mio caso probabilmente molto speciale un altro
cosa è successo in parallelo allo stesso
sistema la stabilità quindi il numero di
bug di produzione ne hai sempre qualcuno
bug di produzione che saranno la maggior parte
sempre succede ma il numero di
i bug di produzione sono aumentati nel tempo
mostrando che la squadra ha perso il controllo di
il sistema non erano molto chiari cosa
stavano facendo stavano modificando alcuni
fonti che modificano alcune strutture di dati
qualunque cosa e non avevano un’idea chiara di
la connessione
in produzione si lo testano e si
hanno avuto qualche integrazione con i test unitari
test e così via, ma dammi le tue mani
nessuno ha mai visto un fenomeno
così prima oh vedo poche mani
in aumento ora è questa la ragione per cui
per molti anni per cercare di migliorarlo
situazione per identificare i modelli e
pratiche per migliorare in questo caso
conosci questa città da qui
La Svizzera è basil um, lo sai
basilico
si sa che cosa il basilico ha a che fare con
il software è una grande industria del software
in basilico lo so, ma è così conosciuto il basilico
il settore finanziario perché ci sono
alcuni regolamenti chiamato il basilico
regolamenti che regolano molto rigorosamente
come possono i prestiti finanziari di profondità finanziaria
essere dato dalle banche quindi se qualcuno di voi
vuole comprare una casa o una casa o qualsiasi altra
altra cosa enorme vai alla tua banca per chiedere
soldi i criteri di base limitano il
l’ammontare di denaro che puoi ottenere si definiscono
quanto rischio una banca è autorizzata a prendere
cosa ha a che fare con il software in
software prendiamo rischi arbitrari che prendiamo
profondità tecnica o profondità sociale e
insieme con una profondità tecnica in un
importo arbitrario e illimitato e noi
non importa del rimborso quindi se tu se
stai hackerando il tuo sistema senza
pensando al futuro ne prendi un po ‘
tecnica non lo farai nessun ladro
programmatore avrebbe probabilmente fare che prendere
alcuni strumenti tecnici di profondità come
l’inferno e non pensa a ripagare
questo debito ed è per questo che probabilmente è un bene
l’idea di pensare a volte al basilico è a
bella città da visitare a proposito
quindi se persone diverse pensano al software
probabilmente in quella situazione degradante
volevo parlarti di informazioni tecniche
profondità nel mondo finanziario che devi
firmare un contratto in modo che la banca sia sicura di te
ripagerai che hai mai firmato
un contratto nel software che si ripagherà
il tuo debito tecnico non hai um là
è un limite massimo per la profondità tecnica
debito finanziario con cui ho visto sistemi
nessun limite superiore per la profondità tecnica
Probabilmente avete visto che anche oggi in
il bilancio annuale in tedesco è chiamato
essere finanziato nel bilancio annuale che hai
per mostrare la quantità di profondità che hai tu
devi rendere esplicito quanto è male il tuo
situazione finanziaria è che si può coprire
nel software hai appena costruito un altro livello
di complessità migrata verso i micro servizi
e probabilmente per alcuni anni puoi nasconderti
ma ti colpirà, ne sono sicuro
il software acquisisce profondità in modo accidentale
con un importo arbitrario senza chiaro
criteri
cos’è un rischio e qual è un problema e
così via e come sai tutto quello che è
la conoscenza implicita implicita è cattiva è
una bella fotografia delle diapositive che ottieni
per il download probabilmente la qualità è
meglio e non sarò sull’immagine così
le diapositive scaricate sono più belle io
prometti alcune cose che so di combattere
contro il pranzo Vorrei solo girare
prendere un’ora così ora um parlo
miglioramento sistemico del software um at
prima ti mostro un po ‘come identificare
o trova i tuoi problemi problemi in
software che poi risolvi parlerò
su come stai
Vince la tua gestione che vuoi
migliorare davvero migliorare gli interni e
struttura interna del tuo sistema che mostro
un po ‘come puoi farlo davvero
in pratica e ne ho parlato un po ‘
come puoi allineare il miglioramento con il tuo
attività giorno per giorno perché il tuo
business vuole caratteristiche non alcuni
miglioramenti interni nel software noi
di solito hanno due tipi di persone che parlano
su quei software sono molto molto
stereotipato qui, quindi generalizzo anch’io
molto probabilmente si dispone di gestione che
è un software molto più esperto ma
Ho incontrato molti manager che si sono lamentati
voi siete sempre troppo costoso è
il software che abbiamo qui il
sistemi software sono troppo costosi per
mantenerlo contiene troppi bug e
il time to market è troppo lungo
abbiamo bisogno delle funzionalità più velocemente che mai
sentito che qualcuno qui che non ha mai
sentito che quello sarebbe i ragazzi no
dal settore del software ora abbiamo
sono solo alcuni manager che temo di essere
manager maschile qui è lo stesso per il maschio
e le donne manager ed è lo stesso
per techies maschili e femminili hanno
un parere completamente diverso sul
sistemi che mantengono bene dicono
oh abbiamo troppo debito tecnico noi
migliorare troppo poco la nostra tecnologia
Non dico che la parola è male che abbiamo
poco in innovazione e non abbiamo mai
abbastanza tempo per farlo bene qualcuno ascoltato
che prima ora se li confronti
affermazioni che si potrebbero pensare
parlando di due cose diverse ma
in realtà stanno parlando queste persone
la stessa cosa solo da diversi
punti di vista oh è interessante
se sei un manager molto importante questi
sono i ragazzi con i soldi se loro
penso sia troppo costoso
è molto improbabile che ti diano
più soldi per il miglioramento se lo sei
già troppo costoso e raccontando
loro su una certa profondità tecnica astratta
usando la terminologia dell’ingegneria del software
probabilmente parlando di microservice e
meno server e qualunque cosa tu non voglia mai
convincere il ragazzo che pensa che tu sia troppo
costoso , semplicemente non ci riesci
comunicazione non è che tu sia un cattivo
sviluppatore di software sono abbastanza sicuro di te
tutti sanno come risolvere tecnicamente le cose
ma abbiamo un grosso problema nel convincere
i ragazzi a sinistra ora parliamo a
bit sul valore perché il valore potrebbe essere
un’idea di come puoi convincere il tuo
gestione se smetti di parlare
terminologia ingegneristica ma dillo al tuo
gestione hey ho avuto un’idea di come è possibile
salva migliaia di euro a settimana questo è un
dichiarazione che è interessante per il
ragazzi a sinistra quindi se lo fai
miglioramenti tecnici se lo dai a
unità come soldi o tempo potresti essere
in grado di convincere le persone che non hanno
idea del software e mi sono incontrato
abbastanza manager che non sono programmatori
chi sa usare Excel e molto
eccellente nei numeri e nel progetto
pianificazione e così via
ma non sono ragazzi del software, non lo fanno
capire accoppiamento coesione dotto
tratti e qualunque cosa tu abbia
capisci quindi mi piacerebbe parlare
valore ora abbiamo valore o il contrario
di valore chiamo costo in cui abbiamo valore
due aspetti differenti quando si parla di
miglioramenti la prima cosa che voglio io
voglio parlare brevemente di una cosa io
chiamata problema e in realtà è un problema
qualcosa di brutto nel tuo software che hai
a stretto accoppiamento tra due pacchetti
potresti avere una tecnologia orso
parte nel tuo sistema qualunque cosa chiamiamo
questo problema è un problema ostile
parola quali strumenti hai a disposizione a
problema o un inseguitore di un issue tracker
issue tracker è una parola più amichevole
quindi in questo progetto open source non l’ho fatto
ma parliamo di usare il termine problema per
denotano problemi rischiano tutte le cose cattive
hai nei tuoi sistemi e questi
le cose sono in qualche modo inquietanti
negativo in un certo senso lo rendono di più
difficile mantenere il sistema così
in qualche modo vuoi superare proprio questo
accoppiamento stretto o cattiva tecnologia
qualunque cosa tu pensi di alcuni
miglioramento ogni volta che ne leggi alcuni
codice sorgente si identifica un problema lì
è un codice scritto male e tipico
lo sviluppatore inizia subito a pensare
lo spazio della soluzione come posso migliorare
che come posso scrivere il codice in a
modo migliore e spesso iniziamo a farlo
penso che questa sia una cattiva idea
perché quando iniziamo immediatamente
risolvere questi problemi probabilmente
dimentica altre opzioni che abbiamo e io ho
un piccolo esempio di tale problema era
un piccolo negozio di e-commerce che ho lavorato
con i ragazzi in un piccolo
progetto e hanno avuto il problema che
il loro sistema divenne instabile
ogni giorno in produzione c’è molto
piccola azienda quindi il loro negozio si è rotto
giù una volta al giorno non avevano reale
reparto operativo quindi lo sviluppatore
dovuto alzarsi dalla scrivania passeggiata per il
il blocco della stanza del server nella console ne esegue alcuni
la magia riavvia il sistema e torna indietro
questo è un problema ora che cosa ha fatto il
gli sviluppatori propongono hanno detto oh, abbiamo bisogno
un nuovo negozio abbiamo avuto questo vecchio PHP basato
sistema lo abbiamo modificato e lo abbiamo rattoppato
di nuovo e abbiamo perso qualche quadro
aggiornamenti e ora è completamente
non mantenuto
quindi dobbiamo comprarlo deve comprare destra
o qualunque sia una nuova
e loro mi chiedono prima perché loro
prima che andassero alla loro direzione
Hanno detto che abbiamo bisogno di un nuovo negozio, vero?
d’accordo hanno bisogno di un nuovo negozio un nuovo
negozio quella soluzione a questo problema che ho
ha chiesto loro per un preventivo Quanto è grave
la situazione quanto spesso è necessario
Ricominciano a dirmi una volta al giorno che ho chiesto
lui quanto tempo ti ci hanno detto
oh, la stanza dei server è la porta accanto quindi io
alzati a piedi lì per circa 20 minuti
Un’ora ho detto uno sviluppatore mezzo an
ora al giorno che fa circa tre
ore settimanali che ne fanno cento e cinquanta
ore l’anno è male che ho chiesto loro
un’altra domanda quanto ne pensi
un nuovo negozio ti costerà?
circa e hanno detto per l’ultimo
avevamo bisogno di una persona per 200 anni
giorni ora confrontare i numeri 200 persone
giorni per costruirne uno nuovo e cento
cinquanta ore di persona ed è il costo di
il problema che ho chiesto loro ti ha perso
affari nel pomeriggio e hanno detto
no, abbiamo un robusto carrello della spesa quindi
cose nel carrello della spesa o non ottenere mai
mai perdersi il client ne tiene un po ‘
tipo di sessione in modo che il cliente finale
non sa nemmeno che il back- end
si rompe quindi perché diavolo vuoi?
per costruire un nuovo sistema è estremamente
costosi giorni per 200 persone per costruire un nuovo
sistema e questa è la stima degli sviluppatori
il costo reale sarebbe probabilmente un po ‘
più alto
il costo del problema è senso più basso io
ha chiesto loro c’è una seconda opzione come
potresti risolvere il problema che è no
nessun modo ho detto ho un’idea si può
insegnarmi come riavviare il sistema e
ha detto di sì , se puoi insegnarlo
per me puoi insegnarlo a qualcun altro
ragazzo sì, probabilmente ho detto oh dai un’occhiata
laggiù hai un marketing
dipartimento hai studenti che tu
Pratica il lavoro nella tua azienda per loro
sono qui per circa sei mesi
studenti di scienze informatiche e fate
loro disegnano le immagini di Photoshop che sono
probabilmente molto felice se possono lavorare
la console per mezz’ora ogni giorno
e non ti costa nessuno sviluppatore
tempo non ti costa niente in più
non mi hanno creduto
quindi l’abbiamo provato così ne abbiamo scelto uno
questi studenti e abbiamo scritto un po ‘
sceneggiatura cosa dovrebbero fare e a
riavviare il mio sequel database qualunque
e ha funzionato e ci siamo subito liberati
del problema oh non è il reale
problema ma abbiamo trovato una soluzione che è
più economico ed è per questo che ho un grande
problema nel lasciare solo il codice sorgente
influenza i nostri e i nostri miglioramenti
a volte abbiamo diverse opzioni come noi
può superare un problema ed è molto
buona idea in generale per calcolare o
stimare prima il costo del problema
prima di pensare a una soluzione se il
soluzione è estremamente economico il
lo sforzo di stima potrebbe essere troppo grande
ma molto spesso il costo del
il miglioramento è troppo alto e non vale
non è e non è abituato a
lavorare in questo modo per cui dobbiamo pensare
di diverse opzioni ora le cose
vedi qui che miglioramenti e
problemi e i costi associati è
qualcosa come un modello di dominio di
miglioramento del software um
L’ho trovato insieme allo chef fino a quando
tosse e altri l’ho trovato aperto
miglioramento dell’architettura del progetto di origine
metodo e abbiamo avuto un abbiamo un semplice
dominio modellato in modo che usiamo questi termini
per spiegare come dovrebbero funzionare le cose
e un’altra cosa interessante
questi due termini problemi e miglioramenti
hanno una relazione da M a fine
l’un l’altro così per un problema tu
probabilmente hanno bisogno di due o tre misure
miglioramenti quindi un singolo miglioramento
non risolverà il problema generale che potrebbe
sii che un miglioramento risolva uno
e-un-metà problemi, quindi mantenendo alcuni
relazione qualche idea se lo faccio io
ottenere il seguente effetto è difficile
cosa così non è sempre un one-to-one
rapporto non è sempre che si
avere un miglioramento per risolvere a
singolo problema potrebbe essere che se tu
risolvi un problema ne crei uno nuovo
si chiamano conseguenze negative
certo che tutti voi avete avuto questo effetto
fai qualcosa e ha un negativo
conseguenza crei un nuovo ogni giorno
non non lui ma ma il ragazzo alla sua destra
ora se inizi a parlare del costo
dei problemi che la tua gestione avrebbe iniziato
ascolta se tu se parli solo di noi
ho bisogno di un nuovo linguaggio di programmazione un micro
servire un mestiere o un po ‘di fantasia
accoppiando le cose a questi ragazzi della gestione
non ti capirò se glielo dirai
avere un miglioramento che ti salverebbe
150 ore all’anno possono capire
così che è una strategia come
affrontare solo il miglioramento generale del software
iniziare a fare le cose se il miglioramento
il costo del costo di fare qualcosa è
inferiore al costo del problema, quindi se
il problema non è grande probabilmente ignorato
anche se ti disturba, ignori
ora devi allineare questo tipo di
miglioramento con il tuo business quotidiano e
a proposito, abbiamo imparato la strada difficile
nel software che l’ iterazione è un grande
idea così il miglioramento del software come noi
propongo in questo in modo sistematico
l’approccio è rigorosamente iterativo
approccio abbiamo diviso questo in tre alcuni
valutiamo tre fasi che chiamiamo analisi
e migliorare questo miglioramento è una parte divertente
questo è dove il tuo refactoring che architetto
migliorare il tuo dominio e qualsiasi altra cosa
prima che tu faccia effettivamente le cose che dovresti
pensa un po ‘e io chiamo questa analisi
valutare e e e raccogliere ciò che è il
risultato di questo di questa analisi e
raccolgo è che hai un esplicito
panoramica quali sono i problemi nel mio
sistema quindi non è solo questo singolo
le classi sono mal implementate ma a
ampia panoramica che tipo di problemi voi
avere
e quali candidati abbiamo ciò che potrebbe
facciamo per superare questi problemi quando tu
avere questo tipo di liste
Mi piace molto iniziare con adesivi
su un muro quindi ho adesivi rossi per il
problemi ho adesivi verdi o blu
per i miglioramenti e quindi possiamo
discutere nel team cosa possiamo fare io
proposto e questo è ciò che valuti
pensa al costo di questi problemi
e il costo di questi miglioramenti così
puoi confrontare meglio quelli iniziamo
con i problemi perché è così
argomento complicato per analizzare i problemi
Mi piacerebbe fare un esempio dal vero
vita così se noi se prendiamo un complicato
sistema e io hai qui un qualche tipo di
zuppa di pomodoro è un sistema complicato
perché hai molti ingredienti e
si tratta di un non è un algoritmo per produrre, ma
c’è un po ‘di arte in cucina e così
Mi piacerebbe prendere questo come esempio se
pensi a qualche piatto o del cibo
e tu cerchi di identificare il problema così alcuni
cose che ti vengono in mente come utente
del cibo quindi sto combattendo contro il
lunchbox dei tuoi utenti di cibo e te
probabilmente penso al gusto che mi piace
o cattivo e il prezzo e ciò che lo fa
assomiglia e dove lo ottengo così questo
potrebbero essere fonti per voi lo farete
prenditi cura dei problemi ora passiamo a
prospettiva un po ‘ e pensiamo
il cuoco penserà ovviamente al cuoco
per quanto riguarda il gusto, ma un cuoco è piuttosto severo
in altre cose egli vorrà
probabilmente misurare la temperatura o la sensazione
la temperatura che cercherà
consistenza cercherà popolarità
perché questi ragazzi non vogliono cucinare
cose che nessuno comprerà
non stai pensando alla popolarità
non è il tuo criterio, lo farà il cuoco
probabilmente pensa al prezzo di acquisto così
se ordini delle strane cozze di mare
e sei disposto a pagare 20 euro per
ma questi ragazzi devono pagare 30 euro
e per quattro per il prezzo di mercato è
inutile
hanno una visione diversa dei problemi
ora c’è un altro ragazzo qui coinvolto
un laboratorio che stanno analizzando il
è zuppa di pomodoro per la radioattività
probabilmente un po ‘spy story russo
dissidente e presumibilmente è stato
ucciso a Londra da una overdose di alcuni
molto difficile rintracciare la radio
sostanza radioattiva ora che non è il
cosa si identifica come utente mentre
mangiare la zuppa è completamente insapore
avete bisogno di altre parti interessate in questo
Aspetti alimentari per cercare quelli e um
Molti di questi questi ragazzi sono alla ricerca di
il contenuto di un cibo da un completamente
prospettiva diversa ora ci sono anche
più parti interessate che vuoi ottenere
cibo al popolo um se vuoi farlo
in un industriale, se vuoi
produrre cibo in un set più ampio
non stai pensando al gusto
molto a cui pensi come posso comprimerlo
avvolgilo in modo che arrivi all’utente come posso
diamo mercato e così via e così via
quello che vedi in questo esempio che hai
molti molti criteri diversi che cosa è un
problema da diversi punti di vista da
diversi punti di vista delle parti interessate e in
in ogni sistema complicato hai un
varietà di fonti per problemi non lo farò
leggere tutte quelle e si deve regolare
alcuni e naturalmente noi sviluppatori che hai
sempre una visione brillante dei tipi di
problemi nei componenti che sei
Re molto spesso la tua opinione è limitata
alle cose che già conosci
hanno spesso problemi con il software con
i cosiddetti aspetti trasversali
il taglio trasversale è spesso tecnologia o
alcune regole e principi che sono
dovrebbe essere valido in tutto il sistema quando
Faccio la valutazione dell’architettura o del sistema
valutazione Ho riscontrato molto spesso problemi
nel processo di sviluppo
nel processo dei requisiti e nel test
processo ho trovato problemi che il
l’organizzazione non è adatta a mantenere il
il software è completamente diverso
fonte di problemi se poi si guarda
il codice sorgente di un singolo componente
lascia che ti dia un esempio molto piccolo
dallo spazio del codice sorgente assumiamo
hai quattro componenti e hai
qualche strumento come cubo solare nel luogo che
misura un po ‘su questi componenti
e l’hai trovato in questi componenti
hai una certa complessità e a
certa quantità di accoppiamento ora il
Maggiore è la complessità più difficile
è capire e mantenere questo a
pezzo di codice e alto accoppiamento come te
sa sembra una cattiva idea così solo da
questi numeri spero che tu possa leggerlo
nella parte posteriore solo da questi numeri
c’è un componente quello rosso
che grida forte mi fissa così tanto
complesso e sono così strettamente accoppiato io
ha bisogno di essere risolto e in molti molti
team di sviluppo ho sperimentato il
tutta la squadra si è riunita e ha iniziato a lavorare
su questo componente rosso ti dà un
bella sensazione ma probabilmente no
aggiungi qualsiasi valore perché
avere altre metriche che potremmo misurare
il DTF è metrico i giorni per fissare un dollaro
quanto tempo impiega la squadra
medio per risolvere un dollaro in un certo
componente e vediamo qui che i giorni
per sistemare la parte posteriore nel nostro rosso complicato
componente è sorprendente ma è basso
e non abbiamo molti bug
componente che non sembrava così male
inizialmente la correzione dei bug richiede anni
quattro volte più a lungo come questo oh wow, se
hai investito giorni e giorni nel miglioramento
quello che farebbe tutto questo
sarebbe ancora un fallimento, quindi lo faresti
abbiamo investito sul torto nel torto
area del tuo sistema
quello che probabilmente impari da quello è
non saltare alle conclusioni troppo presto
non guardare solo sul tuo cubo di sonar
numera questi set standard di metriche
e inizia a risolvere ciò che penso
a volte funziona, ma usa di più
gli indicatori usano più fonti di problemi
ampliare l’ambito di ricerca e i giorni a
ripararlo indietro o ore per risolvere il retro è
una metrica aggiuntiva molto buona perché
i giorni per correggere un bug sono direttamente associati
costare la complessità non lo farai mai
convincere il tuo manager o abbiamo alto
la complessità qui non mi interessa
problema se lo comunichi al tuo manager
ho bisogno di 8 giorni per correggere un bug qui um così se
possiamo ridurre questo del 20% guadagni molto
e puoi trasferirlo immediatamente
e valutare in denaro così la gente lo farà
ascoltami ora
Ti ho portato un altro esempio dal vero
vita di nuovo ho lasciato fuori il nome di
la compagnia stava facendo quasi quello
codice pulito raramente ho visto tale
codice sorgente stupendamente scritto piccolo
metodi grandi identificatori
um una struttura a strati che era veramente
pulito e il modello di dati più fottuto
Non ho visto tutta la mia vita no
divertente ora oggi è divertente quando ero dentro
questa situazione non era divertente in
tutti
perché è una specie di software standard
la società che vendeva il
software ad altre imprese e al
i clienti si lamentavano del basso
prestazioni e un tempo molto lungo per
dati di mercato um codice pulito non è sufficiente
per risolvere questi problemi avevano tutti vecchi
dati di cui stiamo parlando miliardi di
registra in quattro tabelle che è di per sé
non male avendo solo quattro tavoli ma
sai qualcosa di relazionale
database quante colonne ti aspetti
in un tipico settore industriale o commerciale
applicazione in una tabella dieci venti
cento forse l’ottimizzatore di query Oracle
smette di ottimizzare a circa 150 fino a
Lo so e avevano da 500 a 700 e
questo è completamente ovvio se tale
la cosa è rotta
non dirai mai oh, ho bisogno di qualcosa di nuovo
tipo di dati che di questi 700 dovrei
uso ne faccio uno nuovo ed è quello
perché questo tasso di consegna scende il
drenare
se qualcosa è così gli sviluppatori no
domanda il modello di dati che era santo
territorio e Pepperdine uno di questi
grandi esperti di database ne hanno scritti alcuni
aveva scritto una recensione interna su
questa struttura dati e anche lui ha detto
è il peggiore che abbia mai visto e
questo è il tasso più interessante di me
ritorno del codice pulito alla struttura dei dati
l’ha mai visto così se continui
refactoring del codice sorgente che hai speso a
molto tempo senza alcun effetto
sulla qualità complessiva del sistema ora
Ho fatto pubblicità un po ‘per allargare il tuo
portata di ricerca per problemi e ho portato
questo esempio da alcuni indiani di
Mercato delle spezie indiane dove hai molto
REE un sacco di diverse spezie da provare
da e penso in cerca di problemi
i nostri problemi nel software sono un po ‘simili
perché ha una così ampia varietà di
sistemi di aspetti in cui potresti guardare
per problemi dovuti al tempo a mia disposizione
qui non entrerò nei dettagli di tutti
quegli aspetti che mi stavano portando in giro
oggi così in un giorno posso insegnarti o
mostra che è tutto scritto in questo
stesso metodo in modo 42 non si è bloccato a
ascoltandomi si , tutti nel
lo spazio di sviluppo di software sta cercando
problemi nella struttura del codice ecco cosa
stiamo lavorando con ogni giorno che ho parlato
su quei problemi e dati e dati
strutture abbiamo spesso problemi
non abbiamo documentazione quindi nuove persone
non capisco il sistema che abbiamo molto
spesso problemi di sicurezza che non lo sono
direttamente correlato al codice sorgente che abbiamo
spesso problemi che lo sviluppo
processo non è adatto a mantenere questo
e così via e così via la mia proposta qui
è una ricerca di ampiezza in tedesco
il suo Bryton zu e probabilmente e così lo farei
piace farlo nelle iterazioni e nel mio
prima o iniziamo sempre da zero ma in
la mia prima iterazione mi piacerebbe avere un
guarda il codice sorgente ovviamente è molto
importante ma mi piace interrogare gli altri
persone giuste che lavorano sul sistema o lo fanno
probabilmente abbiamo bisogno di un diverso know-how
è il nostro contesto sono i nostri esterni
interfacce va bene o cosa abbiamo alcuna
problemi là dentro abbiamo problemi
con dati e così via e così via
Se noi
sfidiamo che abbiamo gravi problemi in
dati sì puoi fare una seconda iterazione
e indagare un po ‘di più qui
approcci iterativi hanno i vantaggi
che puoi lavorare in scatole del tempo e tu
può fare questa ricerca per problema
attività che chiamo analizzare che puoi
rendi questo un time box molto piccolo e con
clienti ho sperimentato quanto tempo
abbiamo bisogno di identificare problemi e persone
detto oh abbiamo bisogno di settimane e ho detto no no
dobbiamo integrarlo nel nostro solito
processo di mischia quindi fallo poche ore
iterazione abbastanza facile da gestire
un buon punto di partenza li ho portati
alcuni frammenti che ho trovato danno un’occhiata al tuo
il codice sorgente che snippet presuppone che tu sia
usando git e questo frammento trova il
file che sono stati modificati di più
spesso ci sono i file che potrebbero essere
critico e potresti voler ottimizzare
quelli che molte persone gestiscono ogni giorno
questo è solo un esempio molto piccolo ora
supponiamo dopo un po ‘di lavoro su
identificando i problemi si ottiene un numero
diciamo 20 30 40 di quelle cartoline rosse
attaccato al muro ogni carta contiene
un singolo problema ora vuoi
convincere la tua gestione che alcuni di
questi problemi devono essere risolti e come me
detto um penso che sia necessario valutare il
costo del problema maggior parte del software
sviluppatori o persone del software in generale
e ho parlato e ho chiesto
su questo argomento sulla stima o
valutare sempre valutare lo sforzo come
molto tempo ci vuole per fare qualcosa
e nessuno ha mai stimato quanto sia grave il
problema ho sentito un podcast con un molto
famoso ragazzo del software Steve McConnell lui
ha scritto questo
demistificare l’arte nera è molto
buon libro di stima e limiti
stima solo per la stima dello sforzo come
a lungo ci vuole per fare qualcosa ma io
non mi importa quanto ci metti
se il problema non è male ora se il
il costo del problema è di poche ore
anno non mi interessa io lascio così com’è
è e fa qualcos’altro aggiustarne un altro
problema è il motivo per cui sono piuttosto severo
qui voglio allegare stime um un po ‘
costo con i problemi che troviamo e il
problema con questo mi dispiace
c’era una struttura dati fottuta
costo estremamente alto in questo e sì loro
aveva alcune classi che avevano idee su come
potrebbe anche refactoring quelli senza alcun effetto
questo è fattibile, quindi ce ne sono alcuni
meccanici come si può stimare il
sforzo del F the the the
intensità del dolore che abbiamo con a
certo problema è il costo dei problemi
la cosa che dovresti assolutamente considerare
di nuovo in questo metodo m42 ne avevamo alcuni
avere una sorta di modello di dominio per
stima non è un tutorial come fare
ma almeno mostriamo alcuni passi
probabilmente la cosa più importante che tu
devi fare è devi identificare cosa
sono i fattori e mi piace chiamarli
fattori di costo quali sono i fattori di costo
influenzando il costo del mio problema in
quell’esempio che avevo prima dello sviluppatore
camminare verso il server e riavviare
qualcosa i fattori è ovvio come
spesso succede e quanto tempo dura
prende la persona e il terzo
fattore è quanto business perdi
quindi questi sono i fattori e ora per
ogni fattore faccio un’ipotesi su come
cattivo è quello
quanto costa quanto e
valore negativo produce così tu
ho chiesto
fatto sui tuoi fattori così definitivamente
stai abbattendo la tua stima
problema in stima più piccola o
problemi di indovinare ti propongo sempre
fai queste stime in un intervallo da
uno potrebbe essere lo sviluppatore ne usa solo cinque
minuti per avviare per avviare il negozio o
nel caso peggiore hanno bisogno di un’ora
quindi hai l’intervallo da cinque
minuti a un’ora qual è l’intervallo
buono per qualsiasi idea se l’intervallo è
abbastanza ampio tu mostri esplicitamente oh I’m
non sono sicuro se l’intervallo è più piccolo oh
potrebbero volerci cinque minuti o sette e
l’intervallo è abbastanza piccolo tu sei molto
sicuro di te stesso quindi se non sei sicuro
quanto è grave un problema, rendere l’intervallo a
un po ‘più ampia l’idea di base in questo
stima che vuoi convincere
gestione che questo problema sia
male o non così male e si confronta il
costo del problema per il costo del
misure di miglioramento ora questo è il
questa è la cosa che devi fare
ci vorrà del tempo ho fatto questi problemi
stime con squadre in time box così
abbiamo stimato che abbiamo avuto questo 30 a 50
carte attaccate al muro con esso alcuni
la pre stima approssimativa è molto pessima
male o un basso tipo di problema e abbiamo dato
ognuna di queste schede indicative circa la metà
un minuto o un minuto puoi farlo abbastanza
rapidamente nella tua solita mischia o qualsiasi altra cosa
sessioni di pianificazione per i primi due o
tre per problemi fai un dettaglio
stima approfondita che probabilmente investi
nella nostra gente non mi credevo
convinto che funzioni tra un’ora
stimare quasi
ogni problema sul pianeta la settimana scorsa ho
valutato con loro con uno svizzero
agenzia governativa il costo problema di
il loro mainframe ancora in produzione e
iBM è un po ‘sta aumentando i prezzi e
qualunque cosa la gente mi abbia detto o no
non posso stimare che li ho convinti
sì è possibile
Voglio solo fare pubblicità sistematica
approcci qui assumiamo per ora te
avere dei numeri per i tuoi problemi
troverai facilmente i numeri per
i tuoi miglioramenti perché questo è il tuo
affari quotidiani e stimando come
tempo ci vorrà ora ne abbiamo bisogno
la terza fase del miglioramento noi
ho bisogno di aggiustare le staccionate che ho preso così piccolo
esempio perché questo è un mestiere
ognuno di voi sa come riflettere
le tue lezioni e così via
roba di basso livello lo sai ma dentro
miglioramento sistematico che dobbiamo fare a
poco più si, qual era il mio um mio scherzo
per tenerti qui a parte il fatto
i pranzi stanno arrivando e ovviamente tu
dovrebbe funzionare nel software come se il tuo
il successore è pericoloso probabilmente lo faremo
capire lo scherzo durante il pranzo in
in questo metodo di miglioramento e noi proviamo
categorizzare possibili miglioramenti e
non volevamo limitare il raggio del
l’area in cui cerchi miglioramenti
a tutti i miglioramenti del codice di basso livello tutti
di voi sanno come migliorare il livello basso
codice ma ci sono opzioni in
cambiando il processo se il modo in cui lavoriamo
non è abbastanza buono e potremmo cambiare
in questo modo lavoriamo prima di riflettere
codice risorsa potremmo avere misure
migliorare l’ infrastruttura tecnica
tutto quel contenitore DevOps o qualsiasi altra cosa
tipo tecnologia e
che è mirato a migliorare il
infrastruttura DevOps non aggiusta il tuo
codice è un tipo completamente diverso di
misura di miglioramento e voglio solo
brevemente diamo qualche altro dettaglio ad alcuni
di questi ad alcuni di questi miglioramenti
categorie solo per mostrarvi che abbiamo
in quel progetto m42 raccolto molto ampio
varietà di idee quindi se stai cercando
per le idee come possiamo superare uno specifico
problema questo è questo open source
progettato per darti qualche idea
non ti dirò esattamente come te
dovrebbe comportarsi una cosa che i miei clienti
oi nostri clienti hanno trovato particolarmente
interessanti sono la lunga corsa
miglioramenti come organizziamo
i miglioramenti arrivano da un pessimo
sistema per due o tre anni a
qualcosa che è molto di più
mantenibile e lo chiamo così
approcci strategici Ava non ha avuto preoccupazioni
Non leggo tutti questi ci sono um questo
sono questi sono stati con successo
eseguito in realtà, quindi questo non lo è
invenzione teorica di alcuni strani
scienziato ma questo è davvero pragmatico
approcci come fare ora nel
all’inizio ho promesso alcune cose
Miglioramento sistemico promesso che ho mostrato
tu ci sei un qualche tipo di sistematico
approcci iterativi ho diviso che in
fasi e ho promesso che ti mostrerò come
trovare problemi si ho fatto
Ho appena toccato la superficie ma l’ho fatto
sembri in profondità non prima in profondità
come ad esempio il cubo sonar propone
profondità-prima no no buona idea leggere prima I
prova a mostrarti come convincere
gestione si parla di soldi non
sull’accoppiamento dell’ingegneria di coesione
principi modello CQRS
non capiscono parlare di soldi
parliamo di salvare una grande quantità di
soldi e poi ascolteranno i tuoi
proposte che è un buon modo per allinearsi
con il tuo lavoro di sviluppo, se tu
se non riesci a convincere la tua gestione
che stai davvero risparmiando denaro loro
vi darà un po ‘di tempo per farlo
facilitare l’allineamento con lo sviluppo
lavoro ora lo prometto a metà e a lungo
approcci di miglioramento del termine che ho mostrato
eppure ti ho mostrato almeno un po ‘
diagrammi non abbiamo tempo per tuffarci
loro in dettaglio se ti va di chiedermelo dopo
la sessione potremmo fare quello per ultimo
la pubblicità su di noi sta diventando um
hai fame sì lui non sta dicendo di si
ma lui annuisce si e tutti – è un
progetto open source siamo attivamente
cercando un paese di campagna, ma come ‘
il nostro ultimo contributore è seduto nel
anteriore quando um sta facendo grande lavoro su
profondità sociale in quella zona e io
davvero grazie mille per voi gente
qui sarò qui nel pomeriggio così
se hai altre domande, fallo
tramite l’applicazione o semplicemente attaccare me
personalmente, grazie mille, ho un
bello vicino
[Applausi]
grazie, Donald, lo vuoi ancora
prendere una domanda se ne hai
domande ho un’ultima cosa che so
potresti per favore votare per la sessione
sì, nell’ultima sessione non abbastanza
la gente ha votato così Ava era un po ‘arrabbiata
o nervoso quindi fagli un favore e vota
per questa sessione
grazie, in realtà non sono mai arrabbiato, okay
quindi penso che possiamo possiamo prendere solo uno
domande quindi raccomandi di
misurare i costi di non evolvere il sistema
per esempio un costo di no di no
evolvendo il sistema per esempio
aumento del costo di supporto nel tempo a causa di
utilizzando una tecnologia obsoleta in aumento
il costo del supporto è un problema, se così fosse
il costo del problema non è abbastanza alto
non lo cambierebbe ma aumentando i costi
è solitamente un indicatore molto forte per
gestione di fare almeno qualcosa così
sicuramente avrei gestito bene, grazie
molto piace il pranzo grazie
essere un compagno di colloquio, uno dei miei
hobby commerciali sta scrivendo libri e io
non parlerò più di me ma io
voglio voglio lamentarmi del
fatto che quasi nessuno che lavora in IT
ha imparato a conoscere in modo sistematico
ammodernamento o manutenzione migliorata
dei sistemi di tutti impariamo fin
cominciando come costruire sistemi da
zero e possiamo farlo abbastanza bene
ma non siamo molto bravi o in realtà noi
sono estremamente cattivi nel mantenere i sistemi
e correndo e migliorandoli o aggiungendo
funzionalità nel tempo, quindi è lì
c’è un po ‘di spazio per migliorare in questo
questo aspetto ti ho portato un diagramma
per favore dai un’occhiata alla linea verde I
spero che tu possa vederlo da dietro è
praticamente originale ho omesso il nome
del cliente o della società ma è come
Ho detto che è più o meno originale è
da una compagnia assicurativa
ha circa seicento software
sviluppatori che lavorano su una varietà di
sistemi e la linea verde ne descrivono alcuni
indicatori di prestazione di uno specifico
patch o sistema relativamente nuovo I
modificato i numeri esatti che non sono
molto interessante all’inizio del
sistema quando il sistema era inizialmente
costruito la squadra composta da circa 30-40
la gente quindi non è molto piccola e non a
un sistema molto grande potrebbe fornire un
numero relativamente elevato di caratteristiche per
rilascia questa azienda rilascia quattro volte
un anno che non è moderno non è alla moda
ma lo fanno è abbastanza ok per
loro nel tempo le prestazioni del
squadra la squadra è rimasta costante
tempo quindi non ci sono stati grandi cambiamenti in
persone
non vi era alcuna riduzione del personale in
squadra o qualcuno di questi dirigenti
tecniche così la squadra è rimasta costante
e la squadra non è complessivamente stupida ora
questo lavoro persone abbastanza comuni loro
capacità di offrire una nuova attività
funzionalità declinata nel tempo così tu
vedi qui un declino molto forte a
certo certo punto nel tempo non lo faccio
conosci la ragione esatta per cui ciò accade
Sono interessato alla curva in questo
diagramma la tendenza generale nel tempo
mostra che la capacità di una squadra di
consegnare il sistema diminuisce probabilmente tu
non hai questo schema esatto per il tuo
sistema ho creato un certo numero di questi
diagrammi per aziende per le imprese
per mostrare loro cosa succede loro
sistemi e lo chiamo molto normale
caso se hai un’opinione diversa
esperienza diversa essere molto felice
perché questo è lo standard del settore in
software in sistemi software quando
i sistemi vengono mantenuti quando i sistemi sono
ha funzionato nel tempo in cui marciscono davvero e
Robert Martin e altri e altri molto
persone intelligenti hanno scritto di questi
sintomi da quando le persone hanno inventato
refactoring a causa di questo fenomeno
nel mio caso probabilmente molto speciale un altro
cosa è successo in parallelo allo stesso
sistema la stabilità quindi il numero di
bug di produzione ne hai sempre qualcuno
bug di produzione che saranno la maggior parte
sempre succede ma il numero di
i bug di produzione sono aumentati nel tempo
mostrando che la squadra ha perso il controllo di
il sistema non erano molto chiari cosa
stavano facendo stavano modificando alcuni
fonti che modificano alcune strutture di dati
qualunque cosa e non avevano un’idea chiara di
la connessione
in produzione si lo testano e si
hanno avuto qualche integrazione con i test unitari
test e così via, ma dammi le tue mani
nessuno ha mai visto un fenomeno
così prima oh vedo poche mani
in aumento ora è questa la ragione per cui
per molti anni per cercare di migliorarlo
situazione per identificare i modelli e
pratiche per migliorare in questo caso
conosci questa città da qui
La Svizzera è basil um, lo sai
basilico
si sa che cosa il basilico ha a che fare con
il software è una grande industria del software
in basilico lo so, ma è così conosciuto il basilico
il settore finanziario perché ci sono
alcuni regolamenti chiamato il basilico
regolamenti che regolano molto rigorosamente
come possono i prestiti finanziari di profondità finanziaria
essere dato dalle banche quindi se qualcuno di voi
vuole comprare una casa o una casa o qualsiasi altra
altra cosa enorme vai alla tua banca per chiedere
soldi i criteri di base limitano il
l’ammontare di denaro che puoi ottenere si definiscono
quanto rischio una banca è autorizzata a prendere
cosa ha a che fare con il software in
software prendiamo rischi arbitrari che prendiamo
profondità tecnica o profondità sociale e
insieme con una profondità tecnica in un
importo arbitrario e illimitato e noi
non importa del rimborso quindi se tu se
stai hackerando il tuo sistema senza
pensando al futuro ne prendi un po ‘
tecnica non lo farai nessun ladro
programmatore avrebbe probabilmente fare che prendere
alcuni strumenti tecnici di profondità come
l’inferno e non pensa a ripagare
questo debito ed è per questo che probabilmente è un bene
l’idea di pensare a volte al basilico è a
bella città da visitare a proposito
quindi se persone diverse pensano al software
probabilmente in quella situazione degradante
volevo parlarti di informazioni tecniche
profondità nel mondo finanziario che devi
firmare un contratto in modo che la banca sia sicura di te
ripagerai che hai mai firmato
un contratto nel software che si ripagherà
il tuo debito tecnico non hai um là
è un limite massimo per la profondità tecnica
debito finanziario con cui ho visto sistemi
nessun limite superiore per la profondità tecnica
Probabilmente avete visto che anche oggi in
il bilancio annuale in tedesco è chiamato
essere finanziato nel bilancio annuale che hai
per mostrare la quantità di profondità che hai tu
devi rendere esplicito quanto è male il tuo
situazione finanziaria è che si può coprire
nel software hai appena costruito un altro livello
di complessità migrata verso i micro servizi
e probabilmente per alcuni anni puoi nasconderti
ma ti colpirà, ne sono sicuro
il software acquisisce profondità in modo accidentale
con un importo arbitrario senza chiaro
criteri
cos’è un rischio e qual è un problema e
così via e come sai tutto quello che è
la conoscenza implicita implicita è cattiva è
una bella fotografia delle diapositive che ottieni
per il download probabilmente la qualità è
meglio e non sarò sull’immagine così
le diapositive scaricate sono più belle io
prometti alcune cose che so di combattere
contro il pranzo Vorrei solo girare
prendere un’ora così ora um parlo
miglioramento sistemico del software um at
prima ti mostro un po ‘come identificare
o trova i tuoi problemi problemi in
software che poi risolvi parlerò
su come stai
Vince la tua gestione che vuoi
migliorare davvero migliorare gli interni e
struttura interna del tuo sistema che mostro
un po ‘come puoi farlo davvero
in pratica e ne ho parlato un po ‘
come puoi allineare il miglioramento con il tuo
attività giorno per giorno perché il tuo
business vuole caratteristiche non alcuni
miglioramenti interni nel software noi
di solito hanno due tipi di persone che parlano
su quei software sono molto molto
stereotipato qui, quindi generalizzo anch’io
molto probabilmente si dispone di gestione che
è un software molto più esperto ma
Ho incontrato molti manager che si sono lamentati
voi siete sempre troppo costoso è
il software che abbiamo qui il
sistemi software sono troppo costosi per
mantenerlo contiene troppi bug e
il time to market è troppo lungo
abbiamo bisogno delle funzionalità più velocemente che mai
sentito che qualcuno qui che non ha mai
sentito che quello sarebbe i ragazzi no
dal settore del software ora abbiamo
sono solo alcuni manager che temo di essere
manager maschile qui è lo stesso per il maschio
e le donne manager ed è lo stesso
per techies maschili e femminili hanno
un parere completamente diverso sul
sistemi che mantengono bene dicono
oh abbiamo troppo debito tecnico noi
migliorare troppo poco la nostra tecnologia
Non dico che la parola è male che abbiamo
poco in innovazione e non abbiamo mai
abbastanza tempo per farlo bene qualcuno ascoltato
che prima ora se li confronti
affermazioni che si potrebbero pensare
parlando di due cose diverse ma
in realtà stanno parlando queste persone
la stessa cosa solo da diversi
punti di vista oh è interessante
se sei un manager molto importante questi
sono i ragazzi con i soldi se loro
penso sia troppo costoso
è molto improbabile che ti diano
più soldi per il miglioramento se lo sei
già troppo costoso e raccontando
loro su una certa profondità tecnica astratta
usando la terminologia dell’ingegneria del software
probabilmente parlando di microservice e
meno server e qualunque cosa tu non voglia mai
convincere il ragazzo che pensa che tu sia troppo
costoso , semplicemente non ci riesci
comunicazione non è che tu sia un cattivo
sviluppatore di software sono abbastanza sicuro di te
tutti sanno come risolvere tecnicamente le cose
ma abbiamo un grosso problema nel convincere
i ragazzi a sinistra ora parliamo a
bit sul valore perché il valore potrebbe essere
un’idea di come puoi convincere il tuo
gestione se smetti di parlare
terminologia ingegneristica ma dillo al tuo
gestione hey ho avuto un’idea di come è possibile
salva migliaia di euro a settimana questo è un
dichiarazione che è interessante per il
ragazzi a sinistra quindi se lo fai
miglioramenti tecnici se lo dai a
unità come soldi o tempo potresti essere
in grado di convincere le persone che non hanno
idea del software e mi sono incontrato
abbastanza manager che non sono programmatori
chi sa usare Excel e molto
eccellente nei numeri e nel progetto
pianificazione e così via
ma non sono ragazzi del software, non lo fanno
capire accoppiamento coesione dotto
tratti e qualunque cosa tu abbia
capisci quindi mi piacerebbe parlare
valore ora abbiamo valore o il contrario
di valore chiamo costo in cui abbiamo valore
due aspetti differenti quando si parla di
miglioramenti la prima cosa che voglio io
voglio parlare brevemente di una cosa io
chiamata problema e in realtà è un problema
qualcosa di brutto nel tuo software che hai
a stretto accoppiamento tra due pacchetti
potresti avere una tecnologia orso
parte nel tuo sistema qualunque cosa chiamiamo
questo problema è un problema ostile
parola quali strumenti hai a disposizione a
problema o un inseguitore di un issue tracker
issue tracker è una parola più amichevole
quindi in questo progetto open source non l’ho fatto
ma parliamo di usare il termine problema per
denotano problemi rischiano tutte le cose cattive
hai nei tuoi sistemi e questi
le cose sono in qualche modo inquietanti
negativo in un certo senso lo rendono di più
difficile mantenere il sistema così
in qualche modo vuoi superare proprio questo
accoppiamento stretto o cattiva tecnologia
qualunque cosa tu pensi di alcuni
miglioramento ogni volta che ne leggi alcuni
codice sorgente si identifica un problema lì
è un codice scritto male e tipico
lo sviluppatore inizia subito a pensare
lo spazio della soluzione come posso migliorare
che come posso scrivere il codice in a
modo migliore e spesso iniziamo a farlo
penso che questa sia una cattiva idea
perché quando iniziamo immediatamente
risolvere questi problemi probabilmente
dimentica altre opzioni che abbiamo e io ho
un piccolo esempio di tale problema era
un piccolo negozio di e-commerce che ho lavorato
con i ragazzi in un piccolo
progetto e hanno avuto il problema che
il loro sistema divenne instabile
ogni giorno in produzione c’è molto
piccola azienda quindi il loro negozio si è rotto
giù una volta al giorno non avevano reale
reparto operativo quindi lo sviluppatore
dovuto alzarsi dalla scrivania passeggiata per il
il blocco della stanza del server nella console ne esegue alcuni
la magia riavvia il sistema e torna indietro
questo è un problema ora che cosa ha fatto il
gli sviluppatori propongono hanno detto oh, abbiamo bisogno
un nuovo negozio abbiamo avuto questo vecchio PHP basato
sistema lo abbiamo modificato e lo abbiamo rattoppato
di nuovo e abbiamo perso qualche quadro
aggiornamenti e ora è completamente
non mantenuto
quindi dobbiamo comprarlo deve comprare destra
o qualunque sia una nuova
e loro mi chiedono prima perché loro
prima che andassero alla loro direzione
Hanno detto che abbiamo bisogno di un nuovo negozio, vero?
d’accordo hanno bisogno di un nuovo negozio un nuovo
negozio quella soluzione a questo problema che ho
ha chiesto loro per un preventivo Quanto è grave
la situazione quanto spesso è necessario
Ricominciano a dirmi una volta al giorno che ho chiesto
lui quanto tempo ti ci hanno detto
oh, la stanza dei server è la porta accanto quindi io
alzati a piedi lì per circa 20 minuti
Un’ora ho detto uno sviluppatore mezzo an
ora al giorno che fa circa tre
ore settimanali che ne fanno cento e cinquanta
ore l’anno è male che ho chiesto loro
un’altra domanda quanto ne pensi
un nuovo negozio ti costerà?
circa e hanno detto per l’ultimo
avevamo bisogno di una persona per 200 anni
giorni ora confrontare i numeri 200 persone
giorni per costruirne uno nuovo e cento
cinquanta ore di persona ed è il costo di
il problema che ho chiesto loro ti ha perso
affari nel pomeriggio e hanno detto
no, abbiamo un robusto carrello della spesa quindi
cose nel carrello della spesa o non ottenere mai
mai perdersi il client ne tiene un po ‘
tipo di sessione in modo che il cliente finale
non sa nemmeno che il back- end
si rompe quindi perché diavolo vuoi?
per costruire un nuovo sistema è estremamente
costosi giorni per 200 persone per costruire un nuovo
sistema e questa è la stima degli sviluppatori
il costo reale sarebbe probabilmente un po ‘
più alto
il costo del problema è senso più basso io
ha chiesto loro c’è una seconda opzione come
potresti risolvere il problema che è no
nessun modo ho detto ho un’idea si può
insegnarmi come riavviare il sistema e
ha detto di sì , se puoi insegnarlo
per me puoi insegnarlo a qualcun altro
ragazzo sì, probabilmente ho detto oh dai un’occhiata
laggiù hai un marketing
dipartimento hai studenti che tu
Pratica il lavoro nella tua azienda per loro
sono qui per circa sei mesi
studenti di scienze informatiche e fate
loro disegnano le immagini di Photoshop che sono
probabilmente molto felice se possono lavorare
la console per mezz’ora ogni giorno
e non ti costa nessuno sviluppatore
tempo non ti costa niente in più
non mi hanno creduto
quindi l’abbiamo provato così ne abbiamo scelto uno
questi studenti e abbiamo scritto un po ‘
sceneggiatura cosa dovrebbero fare e a
riavviare il mio sequel database qualunque
e ha funzionato e ci siamo subito liberati
del problema oh non è il reale
problema ma abbiamo trovato una soluzione che è
più economico ed è per questo che ho un grande
problema nel lasciare solo il codice sorgente
influenza i nostri e i nostri miglioramenti
a volte abbiamo diverse opzioni come noi
può superare un problema ed è molto
buona idea in generale per calcolare o
stimare prima il costo del problema
prima di pensare a una soluzione se il
soluzione è estremamente economico il
lo sforzo di stima potrebbe essere troppo grande
ma molto spesso il costo del
il miglioramento è troppo alto e non vale
non è e non è abituato a
lavorare in questo modo per cui dobbiamo pensare
di diverse opzioni ora le cose
vedi qui che miglioramenti e
problemi e i costi associati è
qualcosa come un modello di dominio di
miglioramento del software um
L’ho trovato insieme allo chef fino a quando
tosse e altri l’ho trovato aperto
miglioramento dell’architettura del progetto di origine
metodo e abbiamo avuto un abbiamo un semplice
dominio modellato in modo che usiamo questi termini
per spiegare come dovrebbero funzionare le cose
e un’altra cosa interessante
questi due termini problemi e miglioramenti
hanno una relazione da M a fine
l’un l’altro così per un problema tu
probabilmente hanno bisogno di due o tre misure
miglioramenti quindi un singolo miglioramento
non risolverà il problema generale che potrebbe
sii che un miglioramento risolva uno
e-un-metà problemi, quindi mantenendo alcuni
relazione qualche idea se lo faccio io
ottenere il seguente effetto è difficile
cosa così non è sempre un one-to-one
rapporto non è sempre che si
avere un miglioramento per risolvere a
singolo problema potrebbe essere che se tu
risolvi un problema ne crei uno nuovo
si chiamano conseguenze negative
certo che tutti voi avete avuto questo effetto
fai qualcosa e ha un negativo
conseguenza crei un nuovo ogni giorno
non non lui ma ma il ragazzo alla sua destra
ora se inizi a parlare del costo
dei problemi che la tua gestione avrebbe iniziato
ascolta se tu se parli solo di noi
ho bisogno di un nuovo linguaggio di programmazione un micro
servire un mestiere o un po ‘di fantasia
accoppiando le cose a questi ragazzi della gestione
non ti capirò se glielo dirai
avere un miglioramento che ti salverebbe
150 ore all’anno possono capire
così che è una strategia come
affrontare solo il miglioramento generale del software
iniziare a fare le cose se il miglioramento
il costo del costo di fare qualcosa è
inferiore al costo del problema, quindi se
il problema non è grande probabilmente ignorato
anche se ti disturba, ignori
ora devi allineare questo tipo di
miglioramento con il tuo business quotidiano e
a proposito, abbiamo imparato la strada difficile
nel software che l’ iterazione è un grande
idea così il miglioramento del software come noi
propongo in questo in modo sistematico
l’approccio è rigorosamente iterativo
approccio abbiamo diviso questo in tre alcuni
valutiamo tre fasi che chiamiamo analisi
e migliorare questo miglioramento è una parte divertente
questo è dove il tuo refactoring che architetto
migliorare il tuo dominio e qualsiasi altra cosa
prima che tu faccia effettivamente le cose che dovresti
pensa un po ‘e io chiamo questa analisi
valutare e e e raccogliere ciò che è il
risultato di questo di questa analisi e
raccolgo è che hai un esplicito
panoramica quali sono i problemi nel mio
sistema quindi non è solo questo singolo
le classi sono mal implementate ma a
ampia panoramica che tipo di problemi voi
avere
e quali candidati abbiamo ciò che potrebbe
facciamo per superare questi problemi quando tu
avere questo tipo di liste
Mi piace molto iniziare con adesivi
su un muro quindi ho adesivi rossi per il
problemi ho adesivi verdi o blu
per i miglioramenti e quindi possiamo
discutere nel team cosa possiamo fare io
proposto e questo è ciò che valuti
pensa al costo di questi problemi
e il costo di questi miglioramenti così
puoi confrontare meglio quelli iniziamo
con i problemi perché è così
argomento complicato per analizzare i problemi
Mi piacerebbe fare un esempio dal vero
vita così se noi se prendiamo un complicato
sistema e io hai qui un qualche tipo di
zuppa di pomodoro è un sistema complicato
perché hai molti ingredienti e
si tratta di un non è un algoritmo per produrre, ma
c’è un po ‘di arte in cucina e così
Mi piacerebbe prendere questo come esempio se
pensi a qualche piatto o del cibo
e tu cerchi di identificare il problema così alcuni
cose che ti vengono in mente come utente
del cibo quindi sto combattendo contro il
lunchbox dei tuoi utenti di cibo e te
probabilmente penso al gusto che mi piace
o cattivo e il prezzo e ciò che lo fa
assomiglia e dove lo ottengo così questo
potrebbero essere fonti per voi lo farete
prenditi cura dei problemi ora passiamo a
prospettiva un po ‘ e pensiamo
il cuoco penserà ovviamente al cuoco
per quanto riguarda il gusto, ma un cuoco è piuttosto severo
in altre cose egli vorrà
probabilmente misurare la temperatura o la sensazione
la temperatura che cercherà
consistenza cercherà popolarità
perché questi ragazzi non vogliono cucinare
cose che nessuno comprerà
non stai pensando alla popolarità
non è il tuo criterio, lo farà il cuoco
probabilmente pensa al prezzo di acquisto così
se ordini delle strane cozze di mare
e sei disposto a pagare 20 euro per
ma questi ragazzi devono pagare 30 euro
e per quattro per il prezzo di mercato è
inutile
hanno una visione diversa dei problemi
ora c’è un altro ragazzo qui coinvolto
un laboratorio che stanno analizzando il
è zuppa di pomodoro per la radioattività
probabilmente un po ‘spy story russo
dissidente e presumibilmente è stato
ucciso a Londra da una overdose di alcuni
molto difficile rintracciare la radio
sostanza radioattiva ora che non è il
cosa si identifica come utente mentre
mangiare la zuppa è completamente insapore
avete bisogno di altre parti interessate in questo
Aspetti alimentari per cercare quelli e um
Molti di questi questi ragazzi sono alla ricerca di
il contenuto di un cibo da un completamente
prospettiva diversa ora ci sono anche
più parti interessate che vuoi ottenere
cibo al popolo um se vuoi farlo
in un industriale, se vuoi
produrre cibo in un set più ampio
non stai pensando al gusto
molto a cui pensi come posso comprimerlo
avvolgilo in modo che arrivi all’utente come posso
diamo mercato e così via e così via
quello che vedi in questo esempio che hai
molti molti criteri diversi che cosa è un
problema da diversi punti di vista da
diversi punti di vista delle parti interessate e in
in ogni sistema complicato hai un
varietà di fonti per problemi non lo farò
leggere tutte quelle e si deve regolare
alcuni e naturalmente noi sviluppatori che hai
sempre una visione brillante dei tipi di
problemi nei componenti che sei
Re molto spesso la tua opinione è limitata
alle cose che già conosci
hanno spesso problemi con il software con
i cosiddetti aspetti trasversali
il taglio trasversale è spesso tecnologia o
alcune regole e principi che sono
dovrebbe essere valido in tutto il sistema quando
Faccio la valutazione dell’architettura o del sistema
valutazione Ho riscontrato molto spesso problemi
nel processo di sviluppo
nel processo dei requisiti e nel test
processo ho trovato problemi che il
l’organizzazione non è adatta a mantenere il
il software è completamente diverso
fonte di problemi se poi si guarda
il codice sorgente di un singolo componente
lascia che ti dia un esempio molto piccolo
dallo spazio del codice sorgente assumiamo
hai quattro componenti e hai
qualche strumento come cubo solare nel luogo che
misura un po ‘su questi componenti
e l’hai trovato in questi componenti
hai una certa complessità e a
certa quantità di accoppiamento ora il
Maggiore è la complessità più difficile
è capire e mantenere questo a
pezzo di codice e alto accoppiamento come te
sa sembra una cattiva idea così solo da
questi numeri spero che tu possa leggerlo
nella parte posteriore solo da questi numeri
c’è un componente quello rosso
che grida forte mi fissa così tanto
complesso e sono così strettamente accoppiato io
ha bisogno di essere risolto e in molti molti
team di sviluppo ho sperimentato il
tutta la squadra si è riunita e ha iniziato a lavorare
su questo componente rosso ti dà un
bella sensazione ma probabilmente no
aggiungi qualsiasi valore perché
avere altre metriche che potremmo misurare
il DTF è metrico i giorni per fissare un dollaro
quanto tempo impiega la squadra
medio per risolvere un dollaro in un certo
componente e vediamo qui che i giorni
per sistemare la parte posteriore nel nostro rosso complicato
componente è sorprendente ma è basso
e non abbiamo molti bug
componente che non sembrava così male
inizialmente la correzione dei bug richiede anni
quattro volte più a lungo come questo oh wow, se
hai investito giorni e giorni nel miglioramento
quello che farebbe tutto questo
sarebbe ancora un fallimento, quindi lo faresti
abbiamo investito sul torto nel torto
area del tuo sistema
quello che probabilmente impari da quello è
non saltare alle conclusioni troppo presto
non guardare solo sul tuo cubo di sonar
numera questi set standard di metriche
e inizia a risolvere ciò che penso
a volte funziona, ma usa di più
gli indicatori usano più fonti di problemi
ampliare l’ambito di ricerca e i giorni a
ripararlo indietro o ore per risolvere il retro è
una metrica aggiuntiva molto buona perché
i giorni per correggere un bug sono direttamente associati
costare la complessità non lo farai mai
convincere il tuo manager o abbiamo alto
la complessità qui non mi interessa
problema se lo comunichi al tuo manager
ho bisogno di 8 giorni per correggere un bug qui um così se
possiamo ridurre questo del 20% guadagni molto
e puoi trasferirlo immediatamente
e valutare in denaro così la gente lo farà
ascoltami ora
Ti ho portato un altro esempio dal vero
vita di nuovo ho lasciato fuori il nome di
la compagnia stava facendo quasi quello
codice pulito raramente ho visto tale
codice sorgente stupendamente scritto piccolo
metodi grandi identificatori
um una struttura a strati che era veramente
pulito e il modello di dati più fottuto
Non ho visto tutta la mia vita no
divertente ora oggi è divertente quando ero dentro
questa situazione non era divertente in
tutti
perché è una specie di software standard
la società che vendeva il
software ad altre imprese e al
i clienti si lamentavano del basso
prestazioni e un tempo molto lungo per
dati di mercato um codice pulito non è sufficiente
per risolvere questi problemi avevano tutti vecchi
dati di cui stiamo parlando miliardi di
registra in quattro tabelle che è di per sé
non male avendo solo quattro tavoli ma
sai qualcosa di relazionale
database quante colonne ti aspetti
in un tipico settore industriale o commerciale
applicazione in una tabella dieci venti
cento forse l’ottimizzatore di query Oracle
smette di ottimizzare a circa 150 fino a
Lo so e avevano da 500 a 700 e
questo è completamente ovvio se tale
la cosa è rotta
non dirai mai oh, ho bisogno di qualcosa di nuovo
tipo di dati che di questi 700 dovrei
uso ne faccio uno nuovo ed è quello
perché questo tasso di consegna scende il
drenare
se qualcosa è così gli sviluppatori no
domanda il modello di dati che era santo
territorio e Pepperdine uno di questi
grandi esperti di database ne hanno scritti alcuni
aveva scritto una recensione interna su
questa struttura dati e anche lui ha detto
è il peggiore che abbia mai visto e
questo è il tasso più interessante di me
ritorno del codice pulito alla struttura dei dati
l’ha mai visto così se continui
refactoring del codice sorgente che hai speso a
molto tempo senza alcun effetto
sulla qualità complessiva del sistema ora
Ho fatto pubblicità un po ‘per allargare il tuo
portata di ricerca per problemi e ho portato
questo esempio da alcuni indiani di
Mercato delle spezie indiane dove hai molto
REE un sacco di diverse spezie da provare
da e penso in cerca di problemi
i nostri problemi nel software sono un po ‘simili
perché ha una così ampia varietà di
sistemi di aspetti in cui potresti guardare
per problemi dovuti al tempo a mia disposizione
qui non entrerò nei dettagli di tutti
quegli aspetti che mi stavano portando in giro
oggi così in un giorno posso insegnarti o
mostra che è tutto scritto in questo
stesso metodo in modo 42 non si è bloccato a
ascoltandomi si , tutti nel
lo spazio di sviluppo di software sta cercando
problemi nella struttura del codice ecco cosa
stiamo lavorando con ogni giorno che ho parlato
su quei problemi e dati e dati
strutture abbiamo spesso problemi
non abbiamo documentazione quindi nuove persone
non capisco il sistema che abbiamo molto
spesso problemi di sicurezza che non lo sono
direttamente correlato al codice sorgente che abbiamo
spesso problemi che lo sviluppo
processo non è adatto a mantenere questo
e così via e così via la mia proposta qui
è una ricerca di ampiezza in tedesco
il suo Bryton zu e probabilmente e così lo farei
piace farlo nelle iterazioni e nel mio
prima o iniziamo sempre da zero ma in
la mia prima iterazione mi piacerebbe avere un
guarda il codice sorgente ovviamente è molto
importante ma mi piace interrogare gli altri
persone giuste che lavorano sul sistema o lo fanno
probabilmente abbiamo bisogno di un diverso know-how
è il nostro contesto sono i nostri esterni
interfacce va bene o cosa abbiamo alcuna
problemi là dentro abbiamo problemi
con dati e così via e così via
Se noi
sfidiamo che abbiamo gravi problemi in
dati sì puoi fare una seconda iterazione
e indagare un po ‘di più qui
approcci iterativi hanno i vantaggi
che puoi lavorare in scatole del tempo e tu
può fare questa ricerca per problema
attività che chiamo analizzare che puoi
rendi questo un time box molto piccolo e con
clienti ho sperimentato quanto tempo
abbiamo bisogno di identificare problemi e persone
detto oh abbiamo bisogno di settimane e ho detto no no
dobbiamo integrarlo nel nostro solito
processo di mischia quindi fallo poche ore
iterazione abbastanza facile da gestire
un buon punto di partenza li ho portati
alcuni frammenti che ho trovato danno un’occhiata al tuo
il codice sorgente che snippet presuppone che tu sia
usando git e questo frammento trova il
file che sono stati modificati di più
spesso ci sono i file che potrebbero essere
critico e potresti voler ottimizzare
quelli che molte persone gestiscono ogni giorno
questo è solo un esempio molto piccolo ora
supponiamo dopo un po ‘di lavoro su
identificando i problemi si ottiene un numero
diciamo 20 30 40 di quelle cartoline rosse
attaccato al muro ogni carta contiene
un singolo problema ora vuoi
convincere la tua gestione che alcuni di
questi problemi devono essere risolti e come me
detto um penso che sia necessario valutare il
costo del problema maggior parte del software
sviluppatori o persone del software in generale
e ho parlato e ho chiesto
su questo argomento sulla stima o
valutare sempre valutare lo sforzo come
molto tempo ci vuole per fare qualcosa
e nessuno ha mai stimato quanto sia grave il
problema ho sentito un podcast con un molto
famoso ragazzo del software Steve McConnell lui
ha scritto questo
demistificare l’arte nera è molto
buon libro di stima e limiti
stima solo per la stima dello sforzo come
a lungo ci vuole per fare qualcosa ma io
non mi importa quanto ci metti
se il problema non è male ora se il
il costo del problema è di poche ore
anno non mi interessa io lascio così com’è
è e fa qualcos’altro aggiustarne un altro
problema è il motivo per cui sono piuttosto severo
qui voglio allegare stime um un po ‘
costo con i problemi che troviamo e il
problema con questo mi dispiace
c’era una struttura dati fottuta
costo estremamente alto in questo e sì loro
aveva alcune classi che avevano idee su come
potrebbe anche refactoring quelli senza alcun effetto
questo è fattibile, quindi ce ne sono alcuni
meccanici come si può stimare il
sforzo del F the the the
intensità del dolore che abbiamo con a
certo problema è il costo dei problemi
la cosa che dovresti assolutamente considerare
di nuovo in questo metodo m42 ne avevamo alcuni
avere una sorta di modello di dominio per
stima non è un tutorial come fare
ma almeno mostriamo alcuni passi
probabilmente la cosa più importante che tu
devi fare è devi identificare cosa
sono i fattori e mi piace chiamarli
fattori di costo quali sono i fattori di costo
influenzando il costo del mio problema in
quell’esempio che avevo prima dello sviluppatore
camminare verso il server e riavviare
qualcosa i fattori è ovvio come
spesso succede e quanto tempo dura
prende la persona e il terzo
fattore è quanto business perdi
quindi questi sono i fattori e ora per
ogni fattore faccio un’ipotesi su come
cattivo è quello
quanto costa quanto e
valore negativo produce così tu
ho chiesto
fatto sui tuoi fattori così definitivamente
stai abbattendo la tua stima
problema in stima più piccola o
problemi di indovinare ti propongo sempre
fai queste stime in un intervallo da
uno potrebbe essere lo sviluppatore ne usa solo cinque
minuti per avviare per avviare il negozio o
nel caso peggiore hanno bisogno di un’ora
quindi hai l’intervallo da cinque
minuti a un’ora qual è l’intervallo
buono per qualsiasi idea se l’intervallo è
abbastanza ampio tu mostri esplicitamente oh I’m
non sono sicuro se l’intervallo è più piccolo oh
potrebbero volerci cinque minuti o sette e
l’intervallo è abbastanza piccolo tu sei molto
sicuro di te stesso quindi se non sei sicuro
quanto è grave un problema, rendere l’intervallo a
un po ‘più ampia l’idea di base in questo
stima che vuoi convincere
gestione che questo problema sia
male o non così male e si confronta il
costo del problema per il costo del
misure di miglioramento ora questo è il
questa è la cosa che devi fare
ci vorrà del tempo ho fatto questi problemi
stime con squadre in time box così
abbiamo stimato che abbiamo avuto questo 30 a 50
carte attaccate al muro con esso alcuni
la pre stima approssimativa è molto pessima
male o un basso tipo di problema e abbiamo dato
ognuna di queste schede indicative circa la metà
un minuto o un minuto puoi farlo abbastanza
rapidamente nella tua solita mischia o qualsiasi altra cosa
sessioni di pianificazione per i primi due o
tre per problemi fai un dettaglio
stima approfondita che probabilmente investi
nella nostra gente non mi credevo
convinto che funzioni tra un’ora
stimare quasi
ogni problema sul pianeta la settimana scorsa ho
valutato con loro con uno svizzero
agenzia governativa il costo problema di
il loro mainframe ancora in produzione e
iBM è un po ‘sta aumentando i prezzi e
qualunque cosa la gente mi abbia detto o no
non posso stimare che li ho convinti
sì è possibile
Voglio solo fare pubblicità sistematica
approcci qui assumiamo per ora te
avere dei numeri per i tuoi problemi
troverai facilmente i numeri per
i tuoi miglioramenti perché questo è il tuo
affari quotidiani e stimando come
tempo ci vorrà ora ne abbiamo bisogno
la terza fase del miglioramento noi
ho bisogno di aggiustare le staccionate che ho preso così piccolo
esempio perché questo è un mestiere
ognuno di voi sa come riflettere
le tue lezioni e così via
roba di basso livello lo sai ma dentro
miglioramento sistematico che dobbiamo fare a
poco più si, qual era il mio um mio scherzo
per tenerti qui a parte il fatto
i pranzi stanno arrivando e ovviamente tu
dovrebbe funzionare nel software come se il tuo
il successore è pericoloso probabilmente lo faremo
capire lo scherzo durante il pranzo in
in questo metodo di miglioramento e noi proviamo
categorizzare possibili miglioramenti e
non volevamo limitare il raggio del
l’area in cui cerchi miglioramenti
a tutti i miglioramenti del codice di basso livello tutti
di voi sanno come migliorare il livello basso
codice ma ci sono opzioni in
cambiando il processo se il modo in cui lavoriamo
non è abbastanza buono e potremmo cambiare
in questo modo lavoriamo prima di riflettere
codice risorsa potremmo avere misure
migliorare l’ infrastruttura tecnica
tutto quel contenitore DevOps o qualsiasi altra cosa
tipo tecnologia e
che è mirato a migliorare il
infrastruttura DevOps non aggiusta il tuo
codice è un tipo completamente diverso di
misura di miglioramento e voglio solo
brevemente diamo qualche altro dettaglio ad alcuni
di questi ad alcuni di questi miglioramenti
categorie solo per mostrarvi che abbiamo
in quel progetto m42 raccolto molto ampio
varietà di idee quindi se stai cercando
per le idee come possiamo superare uno specifico
problema questo è questo open source
progettato per darti qualche idea
non ti dirò esattamente come te
dovrebbe comportarsi una cosa che i miei clienti
oi nostri clienti hanno trovato particolarmente
interessanti sono la lunga corsa
miglioramenti come organizziamo
i miglioramenti arrivano da un pessimo
sistema per due o tre anni a
qualcosa che è molto di più
mantenibile e lo chiamo così
approcci strategici Ava non ha avuto preoccupazioni
Non leggo tutti questi ci sono um questo
sono questi sono stati con successo
eseguito in realtà, quindi questo non lo è
invenzione teorica di alcuni strani
scienziato ma questo è davvero pragmatico
approcci come fare ora nel
all’inizio ho promesso alcune cose
Miglioramento sistemico promesso che ho mostrato
tu ci sei un qualche tipo di sistematico
approcci iterativi ho diviso che in
fasi e ho promesso che ti mostrerò come
trovare problemi si ho fatto
Ho appena toccato la superficie ma l’ho fatto
sembri in profondità non prima in profondità
come ad esempio il cubo sonar propone
profondità-prima no no buona idea leggere prima I
prova a mostrarti come convincere
gestione si parla di soldi non
sull’accoppiamento dell’ingegneria di coesione
principi modello CQRS
non capiscono parlare di soldi
parliamo di salvare una grande quantità di
soldi e poi ascolteranno i tuoi
proposte che è un buon modo per allinearsi
con il tuo lavoro di sviluppo, se tu
se non riesci a convincere la tua gestione
che stai davvero risparmiando denaro loro
vi darà un po ‘di tempo per farlo
facilitare l’allineamento con lo sviluppo
lavoro ora lo prometto a metà e a lungo
approcci di miglioramento del termine che ho mostrato
eppure ti ho mostrato almeno un po ‘
diagrammi non abbiamo tempo per tuffarci
loro in dettaglio se ti va di chiedermelo dopo
la sessione potremmo fare quello per ultimo
la pubblicità su di noi sta diventando um
hai fame sì lui non sta dicendo di si
ma lui annuisce si e tutti – è un
progetto open source siamo attivamente
cercando un paese di campagna, ma come ‘
il nostro ultimo contributore è seduto nel
anteriore quando um sta facendo grande lavoro su
profondità sociale in quella zona e io
davvero grazie mille per voi gente
qui sarò qui nel pomeriggio così
se hai altre domande, fallo
tramite l’applicazione o semplicemente attaccare me
personalmente, grazie mille, ho un
bello vicino
[Applausi]
grazie, Donald, lo vuoi ancora
prendere una domanda se ne hai
domande ho un’ultima cosa che so
potresti per favore votare per la sessione
sì, nell’ultima sessione non abbastanza
la gente ha votato così Ava era un po ‘arrabbiata
o nervoso quindi fagli un favore e vota
per questa sessione
grazie, in realtà non sono mai arrabbiato, okay
quindi penso che possiamo possiamo prendere solo uno
domande quindi raccomandi di
misurare i costi di non evolvere il sistema
per esempio un costo di no di no
evolvendo il sistema per esempio
aumento del costo di supporto nel tempo a causa di
utilizzando una tecnologia obsoleta in aumento
il costo del supporto è un problema, se così fosse
il costo del problema non è abbastanza alto
non lo cambierebbe ma aumentando i costi
è solitamente un indicatore molto forte per
gestione di fare almeno qualcosa così
sicuramente avrei gestito bene, grazie
molto piace il pranzo grazie
Please follow and like us: