In dieser Podcast-Episode diskutieren Dierk Söllner und der Gast Thomas Demmich, der Übersetzer des „Phoenix-Projekts“ und des „DevOps-Handbuchs“, detailliert über DevOps. Sie erörtern verschiedene Aspekte wie die Übertragung von Produktionsprinzipien auf die IT, die Herausforderungen bei der Implementierung von DevOps in Unternehmen, und die Bedeutung einer Fehlerkultur. Sie reflektieren auch über die Charaktere und Ereignisse im „Phoenix-Projekt“ und wie diese die Realitäten in IT-Organisationen widerspiegeln, während sie gleichzeitig praktische Ansätze aus dem „DevOps-Handbuch“ hervorheben.
Inhalt
- Einführung und Vorstellung von Thomas Demmich
- Definition und Bedeutung von DevOps
- Diskussion über das „Phoenix-Projekt“ und Charakteranalyse
- Einblicke in das „DevOps-Handbuch“
- Automatisierung und Herausforderungen in DevOps
- Bedeutung von Fehlerkultur und technischen Schulden
- Anwendung von DevOps-Prinzipien in realen IT-Umgebungen
- Abschließende Gedanken und Aha-Effekte
Shownotes
- „Das Phoenix-Projekt“ Buch – Link
- „Das DevOps-Handbuch“ Buch – Link
- Gene Kim (Autor) – Link
- O’Reilly Verlag (Thomas Demmich arbeitet als Übersetzer für sie) – Link
Transkript (automatisiert, daher keine Gewähr 🙂 )
Herzlich Willkommen zu einer neuen Folge des Podcasts DevOps – Auf die Ohren und ins Hirn.
Mein Name ist Dirk Söllner und ich begrüße die Zuhörer und Abonnenten auch im Namen von Alex Lichtenberger.
Der ist leider heute Abend krank, den hat die Grippe ins Bett geworfen, also insofern haben wir heute eine Premiere für diesen Podcast.
Die Premiere ist nur einer der beiden Gastgeber am Mikrofon, aber ich denke, das kriegen wir hin.
Unser Ziel ist es, spannende Interviews und Fachgespräche zu aktuellen DevOps-Themen zu liefern.
Wir sprechen alle DevOps-Interessierten an, die mit dem Medium podcasten.
Und gerne etwas dazu hören, sei es beim Autofahren, in der U-Bahn, S-Bahn oder abends im Hotel oder auch vielleicht zu Hause.
Wir möchten das Thema DevOps inhaltlich mit Praxisberichten und hörenswerten Folgen zu den vielen Themen bereichern, die in DevOps enthalten sind.
Und für diese Folge haben wir was ganz Besonderes.
Wir haben Gene Kim. Na gut, wir haben natürlich nicht Gene Kim selber.
Wir haben die deutsche Stimme von Gene Kim, Thomas Demick, der die Bücher von Gene Kim,
übersetzt hat, das DevOps-Handbuch und das Phoenix-Project.
Also haben wir heute ein Fachgespräch mit der deutschen Stimme von Gene Kim.
Mit diesem Podcast wollen wir eben die Hörer und Hörerinnen etwas näher und etwas besser an das etwas schwammige Thema DevOps heranführen.
Wir wollen Dinge verstehen und erklären und wir liefern Vorschläge, Konzepte, Interviews mit Experten und mit Praktikern,
damit wir Sie, liebe Zuhörer, liebe Zuhörerinnen, persönlich,
weiterbringen, damit Sie persönlich durchblicken können und Ihr Unternehmen und Ihr Team erfolgreicher machen können.
Heute haben wir das Thema, wie ich eben schon gesagt habe,
The Phoenix Project und begrüßen dazu Thomas Demick, den deutschen Übersetzer.
Und in diesem Podcast werden Sie etwas über die Inhalte vom Phoenix Project hören,
einen Roman über DevOps.
Wir werden Ihnen ein bisschen die einzelnen Charaktere näherbringen, etwas über Sarah und über Eric erzählen, etwas über Patty und Wes.
Wir werden auch ein bisschen was über die anderen Charaktere sprechen.
Wir werden über das DevOps Handbuch sprechen.
Wir werden zum Beispiel darstellen, was das bedeutet, sichtbar machen von Arbeit, was es bedeutet, über technische Schulden zu sprechen.
Wir werden versuchen, den Aha-Effekt so ein bisschen rauszuarbeiten, den die Autoren für sich damals hatten, um dann das Buch zu schreiben.
Wir werden ein paar andere Dinge ansprechen, die in dem Buch beschrieben sind.
Wir sprechen über die vier Arten von Arbeit.
Wir sprechen über die drei Wege, über das Drei-Wege-Modell.
Also insofern werden wir hoffentlich eine schöne Podcast-Folge produzieren,
die die Leichtigkeit des Romans ein wenig übernimmt und ein wenig auf diesen Podcast überträgt.
Lieber Thomas, vielen Dank für die Unterstützung und deine Begleitung heute.
Herzlich willkommen zu unserem Podcast hier, DevOps auf die Ohren und ins Hören.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbuch.
Wir sprechen heute über das Phoenix Project und das DevOps Handbook.
Wir sprechen heute über das Phoenix Project und das DevOps Handbook.
Wir sprechen heute über das Phoenix Project und das DevOps Handbook.
Wir sprechen heute über das Phoenix Project und das DevOps Handbook.
Wir sprechen heute über das Phoenix Project und das DevOps Handbook.
Wir sprechen heute über das Phoenix Project und das DevOps Handbook.
Wir sprechen heute über das Phoenix Project und das DevOps Handbook.
immer zu Anfang eine kurze Vorstellung unseres Gastes und dann die Frage,
wie würdest du DevOps definieren?
Also insofern würde ich sagen, lass uns loslegen, lieber Thomas.
Starten wir mit der Vorstellung und mit deiner Einstiegsdefinition von DevOps.
Ja, hallo. Also ich bin Thomas Demmich.
Ich bin eigentlich Entwickler, nebenberuflich auch Übersetzer,
vor allem für O’Reilly und den D-Punkt-Verlag mittlerweile.
Arbeite sonst hauptberuflich in einem großen deutschen Softwareunternehmen,
habe in, ich glaube, vorletztes Jahr ist das jetzt schon das Phoenix-Projekt übersetzt
und auch dann danach das DevOps-Handbuch.
Fand das sehr spannend und sehr interessant und freue mich darüber jetzt mal zu reden.
Du hast es ja schon gesagt, DevOps-Handbuch, Phoenix-Projekt.
Geht es um das Thema DevOps? Wie würdest du DevOps definieren?
Kann man das überhaupt definieren? Würdest du das beschreiben?
Ich würde das definieren als engere Zusammenarbeit zwischen der Entwicklung
und dem darauffolgenden Operations-Unternehmen.
Wobei versucht wird, eben möglichst viel zu automatisieren
und möglichst viele Zeitfresser und Hindernisse aus dem Weg zu räumen, nach und nach.
Ja, sehr schön. Das ist auch schon mal ein interessanter Punkt.
Zeitfresser, ich denke, ich weiß, woher du diesen Begriff hast
und die Hindernisse aus dem Weg räumen, das sind ja schon Dinge,
die aus dem Buch auch so hervorgehen.
Aber vielleicht mal so zu Beginn noch eine ganz andere Frage.
Gar nicht so fachlich.
Wie wird man Übersetzer und wie muss ich mir als jemand,
der die übersetzten Bücher liest, wie muss ich mir das vorstellen?
Was macht ein Übersetzer oder wie arbeitet der?
Ich bin das geworden, weil mein Vater es schon war.
Der hat das gemacht damals, musste dann damals noch zu Windows 2000-Zeiten
gleich so vier Bände auf einmal übersetzen bzw. betreuen
und hat mich damals gefragt, ob ich das nicht auch mal machen will.
Dann habe ich damals einen von den Bänden übersetzt
und der damalige Lektor war halt angetan davon
und hat mich, als bei der damals gerade den Verlag gewechselt hat, mitgenommen.
Und dann habe ich, ich glaube, erst für Hansa übersetzt und für METP.
Und das ist dann irgendwann, ist das eingeschlafen
und dann habe ich mich mal bei O’Reilly beworben sozusagen,
habe da einfach mal angefragt, habe eine Probeübersetzung gemacht
und seitdem bin ich seit vielen Jahren irgendwie schon da.
Insofern, du hast ja ein Privileg, glaube ich, du bist ja etwas ganz Besonderes.
Ich denke, du bist einer der wenigen auf der Welt,
der quasi das Original und die deutsche Übersetzung gelesen hat.
Also insofern bist du da schon was Besonderes.
Nicht nur die deutsche Stimme von Gene Kim,
sondern auch jemand, der, wie gesagt, beide Bücher gelesen hat.
Gut, das heißt, die Arbeit als Übersetzer,
wie stark nimmt dich das ein oder wie stark beschäftigt ist es in deiner Freizeit?
Es sind im Prinzip dann die Abende, die ich damit verbringe.
Also nicht den ganzen Abend, aber immer schon so,
zwei, drei Stunden, aber eben nicht jeden Abend.
Also ich gucke, dass ich dann, wenn es geht,
das terminlich so absprechen kann mit dem Verlag,
dass ich quasi dann auch eine Fünf-Tage-Woche habe,
sodass ich dann immer ein, zwei Abende die Woche nichts tun muss
und auch kein schlechtes Gewissen haben muss, wenn ich mal nichts tue.
Okay, ja. Aber es ist schon anstrengend sozusagen oder schon auch durchgetaktet?
Ja, es ist schon anstrengend auf Dauer dann.
Also es macht immer Spaß, wenn ich was Neues anfange
und wenn ich dann auch wieder gleich wieder,
wenn ich dann auch wieder was Neues anfange,
immer wieder was am Stück kriege, ist das auch schön natürlich.
Aber wenn dann mal Pause ist, ist das auch nicht schlecht.
Aber nach so zwei, drei Monaten Pause, das kommt ja auch mal vor,
freue ich mich dann auch wieder, wenn ich dann mal wieder was machen kann,
weil ich es einfach auch spannend finde, weil es immer wieder mal was Neues ist.
Die Themen ja auch immer wieder variieren.
Das ist im Vergleich zu dem, was ich in meiner,
sagen wir mal, in meiner Brotarbeit tue,
ist das halt quasi ein Spielbein für mich.
Ja, ja, das ist doch interessant.
Ich finde es auch schön, wenn man ein bisschen noch was quasi
nah am Fachlichen dran hat.
Weil ich gehe immer schon davon aus,
dass du auch das eine oder andere von deinen Übersetzungen
auch mitnehmen kannst fachlich.
Also du kriegst ja quasi das Lesen bezahlt.
Ja, also ich denke, ich habe in vielen Bereichen,
habe ich mal was erfahren.
Ich bin nirgendwo so richtig tief drin.
Also es ist jetzt, es gibt immer,
auch in meinem Umfeld auf der Arbeit,
immer genug Leute, die irgendwas auf jeden Fall deutlich besser können.
Aber ich habe von allem schon mal gehört.
Und das finden viele irgendwie finden,
das muss ich auch zugeben,
viele sind spannend, wenn die davon hören,
was ich halt nebenbei noch mache.
Und die freuen sich auch immer wieder mal,
wenn ich dann ein fertiges Buch mitbringe,
die dann da drin auch lesen können.
Ja, okay.
Wenn wir jetzt mal auf das Phoenix Project gehen.
Also ich finde, das ist ja ein wahnsinnig tolles Buch.
Wie ging dir das, als du das zum ersten Mal so bekommen hast
und dann gelesen hast?
Es wird ja als Roman beworben oder dargestellt.
Würdest du es auch als Roman bezeichnen?
Oder ist das für dich auch eher ein,
ein Fachbuch?
Also wie war so dein erster Eindruck,
als du das Buch bekommen hast?
Es ist schon ein Roman,
finde ich auf jeden Fall.
Ein Roman mit einer, mit einem,
ja, wie soll ich sagen,
nicht mit dem erhobenen Zeigefinger,
aber mit einem, der versucht halt,
eine Message rüberzubringen.
Der versucht ja, Informationen zu vermitteln,
die Leute dazu zu bringen, zu sagen,
Mensch, das kenne ich doch bei mir genauso.
Vielleicht sollte ich das mal irgendwie auch angehen.
Aber es ist, im Endeffekt ist es eine Geschichte,
eine schöne Geschichte, die erzählt wird,
in der sich, glaube ich, wirklich viele IT-Leute,
viele IT-Leute wiederfinden.
Ganz viele, glaube ich.
Und beim Übersetzen,
also habe ich dann auch schon gemerkt,
es gibt immer wieder Stellen, wo ich dann auch kurz gezögert habe,
weil es, weil mir dann irgendwie
was komisch vorkam.
Aber letztendlich
wird damit alles erzählt oder vieles
erzählt, was jetzt dann nachher auch im Handbuch quasi
etwas trockener aus, aus fachlicher
Sicht dann nochmal ausführlicher beschrieben wird.
Ja, okay.
Gut, dann würde ich sagen, es ist ein Roman, weil er einfach
eine Geschichte erzählt, könnte die
Geschichte, könnte dieser Roman
in der Wirklichkeit so stattgefunden haben
oder ist das auch zu viel Fiktion
für dich mit dabei? Also die, sagen wir mal so,
der Zeitrahmen,
den finde ich etwas herausfordernd.
Den kann ich mir so nicht vorstellen in der Realität,
aber es ist halt ein Roman. Es ist eine
Erzählung. Ja, okay.
Und die
ziehen letztendlich,
also zumindest auf der IT-Seite ziehen mehr oder weniger
alle mit.
Die Bösen sind ja dann quasi auf der
Business-Seite eher.
Ja, okay.
Ich glaube gerne, dass viele das gerne
mitmachen, aber ich vermute eher, dass auch immer
mehr eher dann welche dabei sind,
die das irgendwie doof finden oder
nicht richtig finden oder das irgendwie aus
Prinzip nicht mitmachen wollen.
Und das geht da ein bisschen unter, aber
es soll ja halt auch,
es soll halt die Geschichte erzählt werden und da finde ich
das in Ordnung. Ja, okay.
Du hast ja vorhin schon auch so ein paar
Details ausgesprochen,
Zeitfresser und so weiter. Eben hatte ich ja
noch danach gefragt, wie du das so empfunden hast.
Wenn du jetzt,
wenn dich jemand fragen würde, der
von IT vielleicht nicht so viel Ahnung
hat, ein guter Freund, ein guter Bekannter,
würdest du ihm dieses Buch
empfehlen, quasi eben,
weil es ja ein Roman ist und
sagt, Mensch, wenn du mal wissen
willst, wie das in manchen Firmen abgeht, liest du
mal dieses Buch durch? Ich glaube schon,
also im Vergleich zu irgendeinem Fachbuch auf jeden
Fall, aber auch da
ist es, glaube ich, so, man profitiert eher davon,
wenn man schon mal das alles irgendwie mitgemacht hat,
zumindest am Rande.
Ich kann mir vorstellen, dass das auch für die
Businessleute durchaus von Interesse ist, weil die dann
nämlich mal sehen, warum dann irgendwas nicht so läuft,
wie sie es sich vorstellen.
Dieses Klassische,
das ist doch aber eigentlich ganz einfach, ja,
aber aus historischen Gründen ist das eben doch
nicht so einfach.
Aber ich denke, so für jemanden, der so
von ganz, gar nichts
mit bisher zu tun hatte, ist das Problem,
dass er
auch da vieles nicht verstehen wird, warum
das denn jetzt so kompliziert ist.
Wie es in der Realität halt
dann auch ist.
Ja, okay.
Also ich habe mit
vielen Kollegen gesprochen,
Beraterkollegen an der Stelle und
die haben eigentlich immer so
ähnlich so beschrieben,
ihr Lesegefühl. Sie haben
dabei geweint und gelacht, also
gelacht unter dem Motto, das habe ich alle
schon genau so erlebt und als Berater
weiß man ja, dass diese Dinge in
vielen Firmen passieren. Die Firmen
sagen ja immer, das ist nur bei uns so schlimm und dann,
ich sage dann immer, nee, das ist überall so schlimm,
in unterschiedlichen Ausprägungen.
Also die haben geweint und gelacht und gelacht,
wie gesagt, weil sie es erlebt haben und
geweint, weil sie einfach sagen, hey, es könnte
ja, wenn man den Roman mal
richtig umsetzen könnte, könnte ja so
einfach sein, das alles sozusagen in Griff zu
kriegen an der Stelle.
Ja, also ich gehe auch davon aus, dass
das eigentlich letztendlich
in so gut wie allen Firmen so ist,
mehr oder weniger. Ich bin halt
nur nicht immer ganz sicher, ob dieses, also
ich glaube, man profitiert auf jeden Fall, wenn man
versucht, DevOps umzusetzen
bei sich, soweit es eben geht.
Aber ich denke, es gibt auch immer
wieder Szenarien, Situationen,
in denen das dann schwierig wird, das
komplett umzusetzen. Also ich bin
halt im UI-Umfeld unterwegs
bei uns. Da sehe ich
zumindest, wie knifflig
das ist, sagen wir mal,
Code, also Tests zu automatisieren,
die dann mit Browsern zu tun haben,
zum Beispiel, weil das
nicht so einfach ist.
Okay, ja. Ja klar,
also wenn es einfach wäre, könnte es ja
jeder, okay, hast du vielleicht
ein paar Beispiele, weil Browser ist ja
ein schönes Beispiel dafür. Also,
wenn man irgendwie so eine Control-
Bibliothek hat,
dann, also zumindest bei uns im Umfeld
ist das so, da werden dann die Tests automatisiert
und dafür werden dann automatisch
Screenshots erstellt und dann verglichen mit der
letzten Version. Und wenn jetzt
zum Beispiel der Browser sich entscheidet,
eine neue Rendering-Engine zu nehmen und das um
zwei Pixel zu verschieben, dann ist erstmal alles rot,
alle Tests.
Okay.
Erstmal alle und dann muss man ja sehen, ist das jetzt nur rot,
weil es sich um den Pixel verschoben hat oder hat
sich doch irgendwas geändert, sowas zum Beispiel.
Ja. Also das sind halt
so Dinge, da kommt man
glaube ich eher an seine Grenzen.
Oder, wo ich
vorher beteiligt war, da ging es um
so eine Integrationsumgebung,
in der Code
aus, also oder halt im Prinzip
Services aus verschiedenen Umgebungen
integriert wurden.
Und da haben wir sehr viele
Mocs geschrieben und
da hatte ich dann teilweise das Gefühl, dass
mit 90% der Zeit dafür draufging,
die Umgebung zu simulieren,
damit, um zu gucken, ob der
eigene Code funktioniert. Das hat jetzt nicht
explizit was mit DevOps zu tun, das ist mir schon klar,
das ist ja eher dann das,
überhaupt das Automatisieren und ich weiß auch, dass es
trotzdem sinnvoll ist, aber ich fürchte, da
kommt man irgendwo an eine Grenze,
wo es dann letztendlich doch zu teuer
wird und man vielleicht dann
doch einfach sagen muss, okay, wir laufen,
wir nehmen in Kauf, dass wir ab und zu mal
irgendwas kaputt machen und dann müssen wir es halt dann
reparieren. Ja,
das ist richtig und das ist dann natürlich auch
das Schöne an einem Roman, da muss man sich um
diese Banalitäten nicht kümmern.
Da schreibt man einfach die Geschichte weiter.
Ja, aber immerhin im Roman
kommen ja auch Szenen vor, in denen dann
sie haben schon versucht und trotzdem ist es noch
mal alles drunter und drüber gegangen.
Ja, das stimmt und das sind auch die
Realitäten wieder an der Stelle.
Also was ich
in diesem Roman so schön finde, sind die
verschiedenen Personen.
Ich habe auch wieder
von vielen gehört, die im Unternehmen
sind, die haben gesagt, wenn ich
jetzt meinen Kollegen sowieso sehe
auf dem Flur, dann weiß ich,
hey, das ist Brent oder das ist
der oder das ist der. Also die haben
eigentlich die ganzen Protagonisten
in dem Buch, finden sie wieder
in ihrem eigenen Unternehmen. Geht
dir das auch so? Ja.
Also ich
sehe das ja nun eher,
man könnte vielleicht sagen, sie sind ein wenig
teilweise zu schablonenhaft, aber sie sollen
ja halt auch einfach den Leuten
Wiedererkennungswert bieten und das
tun sie damit natürlich schon. Ich denke, niemand ist
exakt so wie in dem Buch.
Der Brent, der irgendwie an allem
mitwirbelt und
von allen gebraucht wird. Also
ich denke, so ein Brent kennt
tatsächlich jeder in der Art und Weise
vielleicht nicht so extrem. Es ist vielleicht ein bisschen
überzeichnet. Eine Sarah, die
von Business-Seite aus immer
versucht, irgendwie zu
intrigieren.
Stimmt auch.
Aber das soll natürlich
helfen, dass man die Leute wieder
erkennt. Und vielleicht freut man sich dann auch,
dass die Leute in der eigenen Firma nicht ganz so
extrem sind wie in dem Buch.
Ja, gut. Also klar, eine Freude
dann, eine ganz kleine Freude natürlich.
Und wenn man dann auf dem Flur
im Unternehmen daran vorbeigeht,
ey, guck mal, da kommt wieder die Sarah.
Kann man doch mit der Geheimsprache sprechen.
Ja, okay. Also Brent und Sarah hast du angesprochen.
Was ist
als Charakter noch für dich so hängen geblieben?
Wer ist noch so schön darstellbar?
Wer lebt in dem Buch?
Die Patty, die
irgendwie Operations sozusagen
durchzieht, aber dann auch immer
vernünftig ist und immer organisiert ist.
Solche Leute gibt es, glaube ich, auch in vielen
Unternehmen. Ich glaube, wenn es sowas nicht gäbe, dann würden
die Unternehmen ganz schön untergehen.
Und den Wes, der halt tatsächlich
auch schräg ist und sagt, was er
denkt, aber eigentlich dann doch sehr
hilfreich und häufig auch gute Ideen hat.
Also die gibt es eigentlich, sind die alle
offensichtlich.
Der CEO, der Steve, der ist
für mich zu weit weg, als dass ich das jetzt ernsthaft
vergleichen könnte.
Der Eric, der ist ja so
eine Art irgendwie
Jedi-Vater.
Das ist, glaube ich, jetzt wirklich
so eine Figur,
die, glaube ich, jetzt in der Realität dann doch eher selten
hervorkommt. Aber ich finde,
sie passt gut dazu, um so die Geschichte ein bisschen
oder um die Geschichte voranzutreiben
und
der Hauptfigur Bill
dann einfach die richtigen Stichworte zu geben.
Ja, und wahrscheinlich
auch, du hast auch gesagt, die Geschichte vorantreiben,
und immer an den richtigen Stellen
die richtigen Erläuterungen geben.
Und wenn ich mir das anschaue,
also ich habe mir das Buch,
als ich es mir durchgelesen habe, habe ich gleich angefangen,
als die immer in der Fabrik sind
und einfach diese
Geschichten erklärt werden
über die verschiedenen Arten der Arbeit
und so weiter. Da habe ich mir gleich so
Post-its dran gemacht, so kleine
Zettelchen, wo ich weiß, ich kann diese
Geschichtsteile in der Fabrik
quasi nochmal, immer mal wieder nachlesen,
weil ich das einfach schön erklärt finde,
an der Stelle.
Es passt halt auch gut, dass das gerade eine Firma ist, die tatsächlich
richtige Fabrikhallen
hat.
Das haben ja viele IT, also
Firmen im IT-Umfeld dann ja doch
eher nicht mehr, aber
natürlich ist das
da sehr geschickt und es gibt es natürlich
ja natürlich auch, also dass die IT-Abteilungen
in echten produzierenden Firmen
dann Probleme haben.
Ja, das ist richtig, das ist ja wohl
richtig, jawohl. Was ich so
schön finde, sind die vier Arten der
Arbeit. Hast du da für dich auch
Parallelen entdeckt? Kannst du das nachvollziehen?
Ja.
Ja, in meinem Umfeld ist es so, dass
wir quasi nur IT-Projekte haben,
aber ich
sehe das bei unseren Kunden durchaus,
dass das ja dann nochmal mehr oder
weniger getrennt ist und dass
IT Sachen machen muss, wo Business
sagt, wofür brauchen wir das, aber es ist halt notwendig.
Also ich sehe das im Prinzip
so auch, gerade die ungeplante Arbeit
dann im Rahmen von Änderungen gerne
vor allem. Ja.
Über die man halt erst stolpert, wenn
ja, wenn sie dann vor einem
steht und es nicht weitergeht.
Ja, dann wird das ja in dem Buch sehr schön
dann weiterentwickelt, wie man mit dieser
ungeplanten Arbeit umgehen sollte,
dass man die eliminieren sollte,
Engpass-Theorie und so weiter.
Jetzt hast du natürlich
nicht den direkten Bezug zu
DevOps. Wäre das denn, oder ist das
für dich nachvollziehbar aus dem Buch, wo das
im Buch so erklärt wird, auch wenn
es ein Roman ist?
Ja, also
ich finde das auch gut.
In meinem Umfeld
wird jetzt gerade damit begonnen
im Prinzip, das möglichst tatsächlich
zu automatisieren, zu gucken, wo bleibt es denn
hängen.
Dieses Continuous Integration,
Continuous Deployment
wird versucht anzustreben
im Rahmen des historisch machbaren
oder aus historischen Gründen
eingeschränkten.
Und da sehe ich auch, dass tatsächlich es
anscheinend wirklich gut ist, wenn eben
der Bild plötzlich nicht mehr vier Stunden,
sondern nur noch eine dauert,
um eben mal schneller zu testen,
ob das, was man da eingecheckt hat, in Ordnung ist.
Da sind wir halt noch nicht bei
irgendwie,
und bevor ich eingecheckt habe,
ist auf jeden Fall alles einmal durchgelaufen.
Aber ich sehe das auch so.
Und auch die ungeplante Arbeit,
dass es gut ist, die zu
reduzieren durch
vor allem automatisieren und vereinfachen.
Das denke ich auch.
Ja, nun wird ja in Ihrem Buch
immer die Parallele
bezogen quasi, dass die IT
ja eigentlich genauso arbeiten könnte,
genauso arbeiten sollte und organisiert
werden sollte, wie ein
Produktionsunternehmen. Und dann
kenne ich den einen oder anderen ITler, der sagt,
nein, nein, nein, nein, das ist bei uns alles ganz anders
und wir sind ja Wissensarbeiter.
Wie stehst du zu dieser
Übertragbarkeit?
Ich denke, es gibt ja nicht schwarz und weiß.
Ich denke, man kann sich
viele Anregungen
vom Band holen,
aber eben
nicht alles tatsächlich, weil es dann doch
also ich kann mir eher vorstellen, dass es
es ist ja noch mehr Kreativität dabei
als beim reinen Herstellen nachher.
Und es passieren, glaube ich, auch eher
ungeplante Dinge als beim Herstellen.
Was hoffentlich dann nach
einer Einschwingphase dann so läuft,
wie man es sich vorstellt.
Wo man dann noch optimieren kann.
Aber ich habe das Gefühl, im
IT-Umfeld sind
eher immer wieder mal etwas andere Dinge.
Es gibt immer wieder mal was Neues.
Aber
dieses
das kann ja gar nichts, ist überhaupt nicht so wie
im herstellenden Bereich. Das finde ich
eben nun auch nicht. Also ich denke schon, dass man da vieles
also zumindest, dass man sich inspirieren
lassen kann davon, ja.
Also im DevOps-Handbuch wird da noch mehr
drauf eingegangen, auf diese Enden-Cord und sowas.
Das ist vielleicht gar nicht so schlecht.
Ich denke nur, das Verhältnis
zur
Produktionsstraße ist dann doch
ein bisschen anders, was Änderungen angeht.
Also die Häufigkeit von Änderungen.
Ja, okay. Du hast das
zweite Buch angesprochen, das DevOps-Handbuch.
Du hast ja auch gesagt,
da gibt es dann nochmal so ein bisschen Erläuterungen
dazu. Das heißt, jemand,
der diese Aha-Effekte hatte
aus dem Phoenix-Project, das, was die ja auch
als, was die Autoren ja auch wollen,
der kann diese Aha-Effekte auch im DevOps-Handbuch
quasi nochmal vertiefen.
Ja, ich denke, das
Phoenix-Project, das ist
quasi zum, ja, damit die Leute sagen,
Mensch, das ist ja tatsächlich so wie bei uns.
Aber wenn man sich dann ernsthaft damit
befassen will, dann muss man eigentlich das
DevOps-Handbuch dazu lesen. Das ist dann
das, was tatsächlich die Grundlage bietet.
War eine von den, oder eins von den
beiden Büchern einfacher zu übersetzen, oder
nimmt sich das nichts?
Unterschiedlich einfach. Also das
DevOps-Handbuch ist ja nun wirklich
eher ein Fachbuch und
ich will jetzt schon mal sagen, Fachbücher
lassen sich im Allgemeinen, wenn man
das Thema halbwegs beherrscht,
leichter übersetzen. Während der,
das Phoenix-Project halt als Roman,
da ist es, dann geht es mal flapsiger zu, dann
werden lustige Sachen gesagt.
Das ist, ich finde es anspruchsvoller.
Also ich finde, bewundere auch jeden
ernsthaften Literaturübersetzer, weil das
dann nochmal ein ganz anderes Niveau ist, meiner Meinung nach.
Ja. Und das
Phoenix-Project ist jetzt keine hohe Literatur,
aber es ist, ich fand es einfach
in der Hinsicht anspruchsvoller.
Ja, wir haben jetzt eben so ein paar über die Charaktere
des Phoenix-Project gesprochen. Wir haben
über die
vier Arten von Arbeit gesprochen.
Und dann ist natürlich noch,
ich finde, ein ganz wichtiger Punkt, das sind, so ist
dieses Drei-Wege-Modell von dem,
Kim, kannst du da mal was zu erläutern?
Ja, im Prinzip
gibt es einmal den,
muss man sehen, dass man seine Arbeit
quasi in den Flow kriegt, dass die
also eben läuft, durch
Automatisierung, dass nicht die Sachen
dauernd in irgendwelchen Queues hängen und darauf warten,
dass der Nächste sich darum kümmert.
Ich glaube, das ist auch ein zentraler Punkt von diesem
ersten Weg, dass es einfach
gar nicht das Problem ist, irgendeine
Aufgabe mal schnell zu erledigen, sondern dass
das Problem ist, wenn die Aufgabe von vier Leuten
nacheinander erledigt werden muss, dass dann
die immer viel zu lange in irgendwelchen Warteschlangen
rumhängt.
Der zweite Teil ist dieses,
dass man kontinuierlich Feedback
braucht, um eben den Prozess
wiederum zu verbessern, um
zu erfahren, der, der nach mir
damit zu tun hat, kämpft immer wieder und dann
wäre es vielleicht besser, wenn wir da was anpassen könnten.
Und das dritte ist immer
kontinuierliches Lernen, Experimentieren,
wenn man irgendwelche Sachen
erforscht, dass man dabei möglichst wissenschaftlich
vorgeht und nicht nur nach Bauchgefühl.
Das sind im Prinzip diese
drei Wege, denen man nach und nach
folgen soll. Also erstmal den Flow einrichten,
Flaschenhälse erkennen, Batchgrößen
reduzieren, dann Feedback
regelmäßig einholen und das
auch berücksichtigen und
dann gucken, dass alles, was man
auch im Kleinen herausbekommen hat, dass
das für alle hilft und alle davon
profitieren können und lernen können.
Ja, okay. Wenn du jetzt diese
drei Wege so mal vergleichst
oder die mal so betrachtest,
denkst du, dass man die quasi sozusagen nacheinander
durchschreiten kann oder
wie kann ein Unternehmen
quasi mit diesen drei Wegen arbeiten?
Kannst du dir da was vorstellen?
Also ich würde mal sagen, die bauen
aufeinander auf. Also
ohne einen vernünftigen Flow
braucht man mit dem, also
helfen die nächsten beiden Schritte dann gar nicht mehr
so sehr, weil dieses
Feedback einholen ist
natürlich immer sinnvoll, aber
wenn man dadurch seinen Flow
verbessern kann und den gesamten
diesen Ablauf dann
fehlerfreier oder schneller machen kann, für
alle, dann hilft
das erst dann richtig.
Und das Lernen und Experimentieren
ist natürlich auch immer sinnvoll, aber auch da
denke ich, dass das
auch vom Flow und von dem Feedback dann
auch, also dass es
dann am besten funktioniert, wenn man das
als Grundlage hat schon.
Ja, okay.
Du hast eben so ein schönes Wort gesagt, Lernen und
Experimentieren. Nun sind
ja nicht alle Unternehmen so erfreut
drüber, dass man eine
Fehlerkultur einrichten muss, dass man
experimentiert und so weiter.
Was hast du aus dem Buch da
so ein paar Dinge rausgezogen, wo
du für dich abgerechnet hast? Das
macht eigentlich Sinn, mit so einer Kultur zu
arbeiten? Ja, ich
also ich habe das nach
dem Buch, sehe ich das noch eher, dass das sinnvoll
ist. Wir haben das auch schon bei uns
im Umfeld schon mal vorher versucht und
ich würde sagen, man kann
das, wenn man die Möglichkeit hat, auch im
Kleinen durchaus versuchen, im eigenen Team,
wenn einem das von außen auch
ermöglicht wird, aber
wenn die so insgesamt in der Firma
das nicht, sagen wir mal, honoriert
oder unterstützt wird, dann ist das natürlich
schwierig. Dann kann man das für sich vielleicht
einfach zum eigenen Vorteil nutzen oder zum
Vorteil des eigenen Teams dann was machen, aber
ich glaube, das bringt nur dann was, wenn man,
wenn das tatsächlich akzeptiert wird, auch von
außen, auch nach außen hin, also nach außen
heißt außerhalb des Teams oder außerhalb einer Abteilung
oder so. Ja. Denn das
bringt nicht so viel, wenn man irgendwie zwar selbst
dann so vorgeht und
sagt, es tut uns leid, wir
haben jetzt gesagt, wir können nur das und das machen,
das andere wird zu viel und dann gesagt wird, ist ja schön,
aber wir brauchen es trotzdem. Und man es dann
doch machen muss, notgedrungen.
Es muss schon sein, dass so weit
wie möglich das umgesetzt werden kann
und man nicht nur mit seinen eigenen zehn Leuten
oder so das versucht umzusetzen,
weil dann klappt es meistens
auf Dauer doch nicht, weil man ja mit den anderen doch
interagieren muss. Ja, ich
empfehle in meinen DevOps-Trainings
immer das Buch als Lektüre
und eigentlich würde ich mich so hinstellen
und sagen, das sollte eigentlich eine Standardlektüre
für IT-Manager
sein.
Nein. Siehst du das auch so,
abgesehen davon, dass du vielleicht als Übersetzer ein bisschen
voreingenommen bist?
Ja, würde ich auch sagen. Also natürlich
bin ich auch voreingenommen, aber
würde das auch tatsächlich jedem ans Herz
legen und durchaus auch
auch Managern ans Herz legen,
die mit IT zu tun haben, eben im
Business-Umfeld. Ja.
Vielleicht auch, um damit ein bisschen mehr
Verständnis zu wecken. Und
denkst du, dass man dann,
wenn man in den Situationen ist, die du
eben gerade beschrieben hast, dass es
eben nicht ausreicht, wenn ein Team alleine
sich so aufstellt,
wenn es quasi zum Business oder so
eben genau die Schwierigkeiten hat, dass man
dann sagt, hier, lest euch mal das Buch
durch und dann reden wir weiter. Also glaubst du,
dass man mit dem Buch auch Überzeugungsarbeit
leisten kann, konkret?
Ich glaube schon. Ich weiß, ich glaube
auch, da hängt es dann wieder von der Firmenkultur
ab, inwieweit nachher
nicht gesagt wird, ja, da habt ihr schon recht,
aber es hilft uns nicht, weil wir brauchen
es trotzdem. Und ich glaube, es mag
bestimmt Firmen geben,
die dann sagen, stimmt, habt ihr recht, lasst uns das mal
probieren. Aber ich fürchte, es gibt auch welche,
die dann sagen, das ist doch alles
Quatsch, wir brauchen das jetzt einfach und seht zu,
wie ihr fertig werdet. Ja, gut.
Gibt es noch andere Punkte, die du dir
so aus diesem Buch herausgezogen
hast, die du von dir aus noch so ein bisschen
darstellen würdest? Also ich
fand interessant, wie sie halt
beim Deployen immer am Anfang
sehr gehadert haben und nachher immer
noch gekämpft haben, aber es dann besser wurde.
Das sehe ich
bei mir im Umfeld auch tatsächlich so und
das fand ich durchaus
interessant, wie das da ablief.
Also ich meine, bei uns ist es nun nicht mehr so,
dass irgendwie dann sich morgens die Pizzaschachteln
stapeln, aber
es wurde doch früher
mehr gekämpft. Mittlerweile wird es halt besser,
weil mehr automatisiert ist, weil
tatsächlich in kleineren Einheiten
deployed wird.
Und uns hilft natürlich noch ein bisschen das in dem Umfeld, wo ich
tätig bin. Was wir machen,
wird erstmal von anderen genutzt
und das, was die machen, wird dann wiederum
von anderen genutzt und das erst geht an den Kunden,
letztendlich, wirklich ernsthaft.
Da haben wir natürlich immer noch einen gewissen
Puffer.
Wobei natürlich das Ziel ja wäre, dass
wenn ich da, ich, klar, ich kenne euer
Umfeld nicht, aber letztendlich wäre ja das
Ziel, dass ihr das, was du machst,
in einem Team passiert, was direkt mit
dem Kunden interagiert.
Das stimmt, aber dafür
sind wir zu groß, würde ich
vermuten, um das direkt zu machen.
Es gibt bei uns auch Gruppen, die
näher, also die
letztendlich, sagen wir mal, auch UI-Entwicklung
machen und trotzdem nah am
Kunden sind, aber
ist halt, ich glaube,
ab einer gewissen Größe, auch ab einer gewissen,
sagen wir mal, Entwicklungsgröße,
wird es dann tatsächlich schwieriger, weil
zumindest ich sehe dann durchaus, dass es auch
von Vorteil ist, wenn man
mehr Schichten hat, in denen das
vorgegeben ist, in denen, wenn man sagt,
die Buttons müssen ein bisschen anders werden,
dass dann auch alle Buttons anders werden und man
nicht die halben Entwicklermannschaft anschreiben
muss, dass sie jetzt alle bitte was anpassen sollen.
Also,
da,
ich glaube, irgendwann wird es dann schwierig,
einen guten Weg
zu finden zwischen, es muss alles
exakt vorgegeben
sein, wie etwas umzusetzen ist
und
es wäre schön, wenn das
halt nah am Kunden ist. Da muss man irgendwie
einen Zwischenweg finden, der, glaube ich,
nicht immer geht.
Ja, ich glaube auch, dass es gar nicht
den Zwischenweg gibt oder den
goldenen Mittelweg. Das muss ein Unternehmen
für sich herausarbeiten.
Muss man auch einfach mal ein bisschen organisatorisch
probieren und dann glaube ich auch, dass es
auch immer wieder so Pendelbewegungen gibt.
Das heißt, man probiert das mal aus.
Man hat ein paar Erkenntnisse, man hat Erfolge,
man hat auch Restriktionen, die man
dann eben bemerkt und dann muss man eben
gegensteuern oder weiterentwickeln
und denke mal,
das ganze Thema agile Entwicklung
und das ist ja die Basis von DevOps,
zumindest im Development-Bereich,
ist ja, glaube ich,
auch das Thema, wie skaliere ich das?
Wie gehe ich jetzt mit mehr als neun oder
zehn oder elf Entwicklern um?
Das, glaube ich, ist ja auch die große Herausforderung
für viele andere Unternehmen, wenn ich noch
nicht mal den Betrieb mit dazu nehme.
Also rein nur, wie skaliere ich agile
Entwicklungsteams, wenn ich wirklich ein paar mehr
Leute dabei habe?
Ja, also ich habe schon das Gefühl, dass es sinnvoll ist,
dass die möglichst autark agieren können.
Aber wenn man halt in einem
Umfeld tätig ist, in dem man
noch viel mehr beachten muss
oder in dem noch viel mehr Leute mitspielen,
dann wird es halt schwierig.
Oder wenn es darum geht, zum Beispiel
eine Barrierefreiheit sicherzustellen,
dann ist es natürlich
gut, wenn die dann trotzdem auf alles
achten und nicht sagen, ach, das machen wir nächstes Mal, weil
das können wir jetzt gerade nicht.
Ja, okay. Wenn ich mal ein bisschen auf das
schaue, was du in deiner
Brotarbeit genannt
tust, wenn du an deine Kollegen
denkst oder auch an dich,
würdest du das Buch oder hättest du das Buch gelesen
oder gekauft
oder glaubst du, dass das halt ein Buch ist, was
für einen Entwickler vielleicht gar nicht mal
so interessant ist?
Ich glaube,
interessant ist es. In meinem
speziellen Umfeld sehe ich
jetzt nur eher, dass
das jetzt
auch tatsächlich, was da drin steht, mehr oder
weniger, sagen wir mal, verfolgt wird. Also
jetzt weniger das wirkliche DevOps,
aber so ein Continuous Delivery,
dass das angestrebt
wird und anscheinend auch gut ist.
Ja, okay, gut.
Hast du noch andere Punkte, die so für dich,
die du rausgezogen hast, die du auch vielleicht mit deinen
Kollegen besprochen hast, die du in deiner Arbeit
eingebracht hast?
Also ich habe mich neulich mit unserem Architekten
unterhalten, gerade da über das,
über den Podcast auch und
über das DevOps und da
kamen wir halt auch drauf, dass
das halt gewisse Grenzen
gibt, was ich vorhin schon sagte mit UI-Tests.
Ist alles möglich, aber wird
dann halt irgendwann ganz schön teuer.
Wo ich mich dann frage,
ist das dann einfach so teuer, wenn man es
ordentlich machen will oder muss man in Kauf nehmen,
dass man dann irgendwo dann unsauber wird?
Das geht jetzt in dem Buch natürlich ein bisschen
unter, weil da geht es um dieses schwierige,
schwierige Aspekte weniger.
Ja, ja.
Das sind ja eher Sachen, die sich leichter machen
lassen. Ich könnte mir auch vorstellen,
dass das dann, dann gibt es vielleicht schon
einen Business Case, der irgendetwas durchrechnet,
aber der geht ja immer nur von irgendwelchen Annahmen
aus. Das heißt, vielleicht wird es
dann so sein, dass ein Team sich so entscheidet,
also wenn sie autonom entscheiden
können und ein anderes Team oder
ein anderer Bereich wird anders entscheiden.
Also das würde ich jetzt mal so tippen,
weil ich glaube nicht, dass es genau die Wahrheit
gibt, die man auch im Vorfeld
genau berechnen kann.
Ja, natürlich. Also
ich denke, das Autonome, das finde ich
gut. Das scheint auch bei uns
so mehr oder weniger zu funktionieren
oder das zumindest
hingenommen wird, wenn dann die
Product Owner
aus einzelnen Bereichen sagen, das ist
gut, das machen wir. Das hört sich zwar auch gut an,
aber das können wir einfach im Moment nicht machen. Und dann
wird das auch akzeptiert. Das mag
dann aber eher an der Kultur liegen der Firma
und weniger daran,
wie gut man dadurch vorankommt, weiß ich natürlich nicht.
Ja, wir haben ja schon einiges
rausgezogen aus dem
Phoenix Project. Gibt es noch andere
Punkte, die du hast, Thomas? Vielleicht auch aus
dem DevOps-Handbuch? Also aus
dem Phoenix Project finde ich
eigentlich gut und ich glaube auch
hilfreich in der täglichen Arbeit ist, dass
versucht wird, Aufgaben sichtbar
zu machen. Dass man sich wundert,
warum irgendwas denn dann zwei Wochen dauert, wo das
doch nur eine kleine Änderung ist
und dass man das mal zeigt,
aus wie vielen Schritten das besteht, wie viele Leute
beteiligt sind, damit dann auch
vielleicht eben die Stakeholder
aus dem Business sehen, oh, okay, ja,
das ist jetzt doch nicht so einfach, wie ich dachte.
Das
ist, glaube ich, was, was
helfen kann. Zumindest kann man
sich dann besser fühlen, wenn man das mal gemacht hat und
die anderen sagen, ist mir egal, ich will es trotzdem,
dann kann man zumindest, ist man sich sicher,
dass man sich nicht da vertut und sich
nicht wundert, warum das alles so lange dauert.
Und
die technischen Schulden, dass
man die tatsächlich angehen sollte, das ist, glaube
ich, eher aus dem DevOps-Handbuch,
dass man, wenn man mal schnell was
macht, das ist in Ordnung, aber
das kommt irgendwann wieder meistens
und dann tut es richtig weh.
Das sehe ich auch tatsächlich bei mir im Umfeld.
Ja.
Man baut Sachen ein, die irgendwie
in dem Moment gerade geholfen haben,
aber sich im Nachhinein
nur ganz schlecht wieder rausnehmen lassen und dann
alle ärgern. Und die
muss man regelmäßig, glaube ich, angehen, um die
abzuarbeiten. Ja,
was ich so an dem Begriff der technischen
Schulden auch so schön finde, ist,
dass man damit,
wenn das Business
darauf eingeht, dass man denen damit das
erklären kann. Also ganz
klar, Business, wenn du das haben willst,
lieber Stakeholder, das können wir machen,
aber wir bauen eben Schulden auf damit.
Das ist genauso, als wenn du dir jetzt ein Haus
kaufen würdest. Du kannst dir Geld
von der Bank leihen, dann musst du einfach
Zinsen bezahlen. Du hast Schulden, die du
abstottern musst. Und wenn du kein Geld
verdienst, dann wird das Haus auch gepfändet
und so weiter. Also dieser Vergleich
zwischen technischen Schulden und der
Realität finde ich sehr, sehr schön,
Idee. Und ja, das sehe ich
wie du. Das wird sehr schön beschrieben,
sehr schön plastisch beschrieben.
Ja, und was ich auch einen tollen
Schritt fand, da weiß ich
nicht, wie realistisch das machbar ist, ist,
dass die mal eine Zeit lang sagen, wir machen gar nichts
Neues. Wir bauen jetzt mal zwei Wochen lang oder so,
wie lange das war, alles ab. Oder versuchen
zwei Wochen lang nur Sachen zu erledigen, die
wir schon immer mal machen wollten oder immer mal
machen mussten eigentlich, um
damit eben dann ordentlich Schulden abzuarbeiten.
Irgendwann geht es wahrscheinlich, kommt man nicht
drum rum, dann wieder neue Sachen zu machen. Aber
ich denke, das ist
was, was ich zumindest sehr
charmant finde und sehr hilfreich.
Also
ich habe das einmal erlebt bei
einem Scrum-Team, die
wirklich einen Sprint von zwei Wochen, also
das war wirklich eine sehr überschaubare
Größe, dass sie in einem
Sprint von zwei Wochen sich mal nur
um die Problems gekümmert haben.
Also nur darum mal gekümmert haben,
Bugs zu beseitigen,
die sie immer wieder mit Workarounds gefixt
haben und wo sie gesagt haben, wenn wir da mal
Zeit hätten, dann könnten wir das mal
richtig beseitigen. Und die Zeit hat
man ihnen in der Entwicklungsphase
nicht gegeben. Aber als dann so ein gewisses
Grundgerüst da war, da haben sie wirklich
dann mal in einem Sprint von
zwei Wochen wirklich nur
Storys bearbeitet, die eben diese klassischen
ITIL-Problems beseitigt
haben oder nur daran gearbeitet.
Und das Schöne fand ich jetzt auch
im Vergleich dazu,
das ist im Buch ja auch so beschrieben,
dass das quasi auch aus dem Team herausgekommen
ist. Das Entwicklungsteam hat keine
Ahnung von ITIL gehabt. Die haben sich nicht um
IT-Service-Management gekümmert.
Die haben aber einfach für sich
gesagt, wir haben jetzt hier wieder einen Bug,
den haben wir beseitigt, Quick und Dirty,
weil wir ihn schnell beseitigen müssen.
Lieber PO, das sollten
wir mal in Ruhe angehen und eben
genau diese Schulden beseitigen.
Also ein Beispiel habe ich so
für diese zwei Wochen.
Ob das Team so ganz glücklich war, sich zwei Wochen
nur darum zu kümmern, das weiß ich jetzt gar nicht
mehr, weil man ja eigentlich
versucht, das immer so ein bisschen zu mischen an der Stelle.
Ja, das ist natürlich
auch eine Variante, dass man tatsächlich, wenn man das
kann, so und so viel Prozent
der Kapazität
der eigenen dafür dann
pro Sprint beiseite zu legen
und dann das immer wieder was, also
quasi kontinuierlich was zu machen.
Das ist, denke ich, die andere Variante. Aber ich könnte
mir vorstellen, dass man so, und wenn man es nur einmal
im Jahr macht, irgendwann in der Zeit,
wo dann gerade mehr oder weniger
es etwas ruhiger ist,
dass man dann einfach Sachen mal abarbeitet.
Ich glaube, das tut einem auch gut. Natürlich ist das
spannend, da neue Sachen zu machen, aber
ich glaube, man fühlt sich danach richtig gut, wenn
man dann mal Sachen ordentlich gemacht hat
wieder. Ja, also ich habe
schon einen oder anderen Entwickler getroffen,
der gesagt hat, technische Schulden
sind mir suspekt. Also der fand
diesen Begriff gar nicht gut an der Stelle, aber ich glaube,
das sind ganz wenige Entwickler, die so denken.
Ja, ich glaube aber, also der
Begriff ist, da kann man bestimmt auch darüber diskutieren,
aber ich glaube, was dahinter steckt, das dürfte
fast alle stören. Ja, okay.
Ja, klar, natürlich. Also dieses,
mach mal schnell,
das stimmt schon so.
Ja, und was
auch noch ein Aspekt von dem Buch ist, ist dieses
Change Management, was
manchmal dann vielleicht ein bisschen eskaliert,
aber was
in einem gewissen Rahmen, glaube ich, tatsächlich
notwendig ist, um eben
zu vermeiden, dass der eine eine Änderung
macht, die dann alles andere
kaputt macht, aber
ihm ist das gar nicht bewusst vorher.
Ich glaube, das kann man nicht ganz
vermeiden, weil sonst landet man
nachher in einem wirklich bürokratischen Monster.
Aber so in einem gewissen Rahmen
ist das, denke ich, sehr hilfreich und kann
viele Situationen entschärfen.
Ja, ich glaube, dass du mit dieser Aussage,
die ja von einem Entwickler
kommt, vielen
Leuten aus dem IT-Service-Management
und IT-Umfeld aus der Seele gesprochen hast,
weil die natürlich
sich jetzt auch fragen, ja, das ist ja wunderschön,
alles agil, alle schöne bunte Zettel,
alles visuell, aber wir brauchen auch
ein paar Prozesse und das glaube ich auch, das ist einer
der Prozesse, der unheimlich wichtig
ist und den man nicht einfach abschaffen
kann. Also selbst wenn man die Verantwortung
in Teams gibt, ein paar Sachen
muss man schon noch über Prozesse
regeln und ja, das ist, denke ich, einer
der Kernprozesse, die man
trotzdem geregelt kriegen muss, auch
wenn man die Teams eben autonom
aufstellt und eine andere
Art der Arbeit propagiert.
Ja, ich glaube, das ist auch so ein bisschen, also das
jetzt im Phoenix-Projekt kommt das, glaube ich, mehr oder weniger
kaum vor, so ein Scrum of Scrums oder
wie das manchmal genannt wird.
Das ist ja auch nicht Thema des Buches, aber
auf jeden Fall muss, glaube ich, jede
Firma oder jede Organisation
irgendwie für sich einen Weg finden,
diese möglichst
autonom agierenden Sachen trotzdem
zu organisieren.
Das ist richtig, das stimmt, ja.
Und klar, man muss natürlich die Dinge auch
zusammenbringen und das ist eben im Kleinen
wie im Großen zu tun. Also insofern,
ja, die Frage ist, wie man es
organisiert, aber du hast auch recht, im
Buch war es nicht das Thema und unser Thema
ist ja das Buch. Also insofern,
ich glaube, wir haben ziemlich viel,
ähm, angesprochen aus dem Buch und
ich hoffe auch, dass wir, ähm,
dem einen oder anderen, der das Buch noch nicht gelesen
hat, so ein bisschen das in den Mund fässrig
gemacht haben. Was mich eben
bei diesem Buch begeistert hat,
war, dass ich diesen Aha-Effekt
hatte. Den Aha-Effekt, den die vier Autoren
sehr schön zu Anfang in ihrem Vorwort
beschreiben, dass die alle irgendwann
so einen Aha-Effekt hatten und gesagt haben,
hey, wir müssen das anders
machen. Und, ähm, ich hatte
quasi nach dem Lesen des Buches meinen
Aha-Effekt. Ähm,
wie sieht das bei dir aus? Hast du auch deinen Aha-Effekt
bei der Übersetzung gehabt oder
hast du den vielleicht schon vorher gehabt?
Ich,
wir haben vorher schon zum Teil agil
gearbeitet. Da hatte ich schon viel
Aha. Ähm, und
beim Automatisieren von Tests
und all solchen Sachen, das ist
also beim Buch selbst jetzt gar nicht so
sehr, da hatte ich eher Wiedererkennungseffekte,
dass ich gedacht habe, hey, das kennst du doch von irgendwo her.
Und wenn es vor zehn Jahren ist oder so, also ich habe
auch schon in kleinen Firmen vorher gearbeitet, da
ist das dann nochmal anders Aha gewesen.
Und ich habe, ich habe jetzt im Nachhinein
diesen Aha-Effekt, wo ich in meinem Umfeld sehe, wie
Dinge aus, die in dem Buch vorkommen,
auch in
meinem Umfeld versucht werden, umzusetzen.
Und
das finde ich dann, da denke ich,
ach, guck mal an, das kenne ich doch irgendwo her.
Ja, okay. Also bei mir ist das jetzt so ein bisschen
verzögert, weil ich selbst
weniger
damit zu tun hatte bisher, sagen wir so.
Aber ich kannte halt von
früher vieles und ich sehe jetzt in meinem Umfeld,
dass durchaus da Aktivitäten,
Ablaufen, die dem aus dem
Buch oder aus dem DevOps-Handbuch auch
durchaus entsprechen. Ja,
okay. Ja, das ist doch schön. Also insofern ist
das schon ja schon ein bisschen Bezug zur Praxis
oder vielleicht nicht nur ein bisschen, sondern ein bisschen mehr auch.
Gut, das heißt also,
einwandfreie
Kaufempfehlung für das Buch,
wie gesagt, auch wenn du,
wenn du, für beide ja eigentlich,
für beide, also das denke ich, müssen wir mal
festhalten. Wir haben zwar das Phoenix Project
als Aufhänger genommen, aber ich glaube, es ist
auch rausgekommen, dass das Phoenix Project,
diese Aha-Effekte produziert,
die die Sache einfach ein bisschen plastischer
und lesbarer näherbringt
und wer wirklich tiefer einsteigen will
und Praxis haben will, der braucht natürlich
das DevOps-Handbuch. Ja, das
auf jeden Fall. Also ich würde das
Phoenix-Handbuch tatsächlich jedem ans Herz
legen, eigentlich, der mal länger im IT-Bereich
gearbeitet hat oder mit
IT zu tun hat. Das DevOps-Handbuch
ist, glaube ich, also
wenn man sich ernsthaft damit danach dann damit
befassen will, dann ist das DevOps-Handbuch auch
unvermeidlich, unverzichtbar.
Aber dann wirklich, weil wenn man
damit was, wenn man sich da richtig mit,
wenn man da richtig einsteigen will.
Ja. Gut.
Thomas, dann danke ich
dir für diese schöne dreiviertel
Stunde. Ich fand das sehr, sehr kurzweilig.
Ich glaube, das haben wir sehr gut hinbekommen.
Und würde sagen,
viel Spaß und Erfolg mit
den weiteren Büchern. Ich hoffe, da kommt noch
ein bisschen was vom Gene Kim
für das Thema DevOps. Und
dann bis zum nächsten Mal.
Ja, vielen Dank für die Einladung. Ich habe mich auch
sehr gefreut.
Vielen Dank.