Kundenschmerzorientiertes Kompetenzmodell für Verbesserungen der Systementwicklung unter Verwendung von DevOps-Methoden


Thèse de Master, 2020

143 Pages, Note: 1,0


Extrait


Inhaltsübersicht

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einleitung

2 DevOps

3 CI/CD-Pipeline

4 Grundlagen des Kompetenzmodells

5 Umsetzung des Kompetenzmodells

6 Umsetzung des Kostenmodells

7 Fazit

Anhang

Literaturverzeichnis

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Einleitung
1.1 Ausgangssituation der Arbeit
1.2 Motivation der Arbeit
1.3 Zielsetzung und Aufbau der Arbeit

2 DevOps
2.1 Entstehung der DevOps-Bewegung
2.2 Bedeutung von DevOps
2.3 Phoenix-Projekt

3 CI/CD-Pipeline
3.1 Software-Lebenszyklus
3.2 Phasen der Pipeline
3.3 Entwicklung der Pipeline

4 Grundlagen des Kompetenzmodells
4.1 Verbreitung von DevOps
4.2 DevOps im Embedded-Umfeld
4.3 Analyse bestehender Modelle

5 Umsetzung des Kompetenzmodells
5.1 Konzeption des Kompetenzmodells
5.2 Erstellung des Kompetenzmodells
5.3 Evaluierung des Kompetenzmodells

6 Umsetzung des Kostenmodells
6.1 Grundlage des Kostenmodells
6.2 Analyse bestehender Modelle
6.3 Erstellung des Kostenmodells

7 Fazit

Anhang
Anhangsverzeichnis - Kompetenzmodell
Anhangsverzeichnis - Kostenmodell

Literaturverzeichnis
Bibliographie
Onlinequellen

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

1: Wasserfallmodell und V-Modell

2: Auslastung einer Ressource im Verhältnis zur Wartezeit

3: Software-Lebenszyklus

4: Deployment Pipeline

5: Verteiltes Versionsverwaltungssystem

6: Zentrales Versionsverwaltungssystem

7: Continuous Integration Prozess

8: Continuous Integration Pipeline

9: Continuous Delivery Pipeline

10: Continuous Deployment Pipeline

11: Entwicklungsprozess MIL/SIL/HIL

12: Im Kompetenzmodell hinterlegte Logik der Verbesserungsvorschläge

13: Return on Investment - DevOps

14: Formel - Kosten ungeplante Arbeit

15: Formel - Reinvestition in neue Features

16: Formel - Ausfallkosten

17: Formel - Return on Investment

Tabellenverzeichnis

Tabelle 1: Performance der Softwarelieferung

Tabelle 2: Vier Metriken der Softwarebereitstellungs-Performance

Tabelle 3: Zeitaufwand

1 Einleitung

Tesla Owners Online @Model3Owners @Tesla @elonmusk „Werden Sie für diejenigen,1 die sich wegen des Hurrikans Dorian in Sicherheit bringen müssen, kostenlose Aufladungen und zusätzliche Reichweite freischal­ten?" Eton Musk @elonmusk „Ja" - Twitter, Aug 29, 20192

1.1 Ausgangssituation der Arbeit

Hurrikan Irma 2017, Michael 2018 und zuletzt Dorian im August 2019. Bereits zum dritten Mal reagierte Tesla in unter 24 Stunden auf die drohende Gefahr durch die herannahenden Hurrikans und den Wunsch der Kunden nach zusätzlicher Reichweite. In diesem Fall richtete sich der Kunde direkt per Twitter-Nachricht an Elon Musk, den Gründer von Tesla. Dabei hat Tesla wie bei den letzten beiden Hurrikans per Software-Update, in diesem Fall „Over-the- Air (OTA)“, die Reichweite der Tesla Autos erhöht bzw. diese freigeschaltet. So bekommen die Kunden die Möglichkeit, möglichst zügig und ohne zusätzliche rein Software-beschränkte Ladestopps die vom Hurrikan stark betroffenen Regionen oder sogar Evakuierungsgebiete verlassen zu können.3

Die OTA-Updates sind dabei vergleichbar mit dem Prinzip eines Downloads einer mobilen „App“4 oder eines automatischen Updates einer mobilen App, auf dem Smartphone. Das au­tomatische Update einer mobilen App erfolgt, wenn das Smartphone mit dem Strom und dabei parallel mit einem ihm bekannten „Wlan“5 verbunden ist. Alternativ kann das Update auch di­rekt per Mobilfunknetz z.B. LTE oder 5G durchgeführt werden, wenn dies durch den Benutzer eingestellt wurde. Beim OTA-Update, z.B. dem Tesla Modell S60 mit 60kWh Akkuleistung, er­folgt das Update über eine im Auto eingebaute Sim-Karte oder bei den neueren Modellen per eSim6 auf 75 kWh Akkuleistung. Alternativ kann das Auto auch per Wlan an einem Standort oder per Wlan Hotspot mit dem Smartphone verbunden werden. Dabei wird das Datenvolu­men des Smartphone-Vertrages verwendet. Die einzigen beiden Bedingungen seitens Tesla sind dabei: Die Übertragung via OTA kann nur erfolgen, wenn das Auto nicht in Fahrt und nicht beim Aufladen ist.7 Sobald das Auto über einen der unterschiedlichen Wege mit dem Internet verbunden ist, kann das Update, in diesem Fall mit der zusätzlichen Reichweite von 65km, aufgespielt werden. Bei den älteren Tesla-Generationen verbaute Tesla sowohl für die Standardversion als auch die reichweitenstärkere Version den gleichen Akku. Dieser wurde dabei durch die Software beschränkt. Dies hatte teilweise damit zu tun, dass Tesla versuchte, die Basisversion im Preis nach unten zu drücken, damit sie den verschiedenen Regularien der Länder bezüglich der Förderprämie für Elektroautos entsprach. Den Kunden wurde dabei direkt beim Kauf die Option für das spätere Upgrade um 15 kWh für damalige 9000 US-Dollar angeboten. 2017 wurde der Preis dafür auf 7000 US-Dollar reduziert.8

Bei der Aufspielung von Updates via OTA war Tesla der Vorreiter mit dem weltweit ersten Update im Jahr2012.9 Damit war Tesla den anderen Unternehmen in der Automobilbranche, vor allem was die Häufigkeit der OTA-Updates betrifft, einige Jahre vorausgeeilt. Ein gutes Beispiel dafür ist das Tesla Modell 3. Bei diesem erfolgten zwischen dem 24.12.2017 und dem 12.03.2020 über 120 Änderungen, die nach und nach via OTA ins System eingespielt wurden. Das ergibt im Durchschnitt alle 7,5 Tage ein neues Update oder die Aufspielung einer neuen Funktion und dabei sind wohl hauptsächlich die dem Kunden sichtbaren Änderungen aufgelistet.1011 Im Vergleich zu Tesla erfolgt bei den etablierten Automobilherstellern nur ei­ne Handvoll für den Kunden sichtbarer Updates im Jahr via OTA. Meistens betreffen diese nur das Kartenmaterial der Navigationssysteme oder kaum merkbare Anpassungen im Info- Entertaiment-System. Sicherheitskritische Updates, wie z.B. die des teilautonomen Autopilo­ten oder der Bremssysteme,12 die bei Tesla auch via OTA erfolgen, werden bei den deutschen Herstellern nur vorgenommen, wenn das Fahrzeug in der Werkstatt ist. Allerdings musste Tesla im Falle eines Autopiloten-Updates feststellen, dass sicherheitsrelevante Updates nicht immer reibungslos funktionieren via OTA und in diesem Fall zu einer Verschlechterung des Spurhalteassistenten bei Fahrbahngabelungen und Abfahrten führten.13 Trotz solcher kleine­ren Pannen hat Tesla den alteingesessenen Automobilherstellern einiges voraus. Das Auslie­fern der OTA-Updates sorgt zum einem dafür, dass die Sicherheitsupdates kontinuierlich auf dem neuesten Stand sind ohne zusätzliche Werkstattbesuche. Zum anderen führt es dazu, dass die Kunden zufriedener, regelrecht begeistert oder euphorisch sind, wenn Tesla wieder ein neues Update oder Feature aufspielt. Ein Beispiel hierfür ist die von den Tesla-Kunden regelrecht gehypte neue Funktion des Karaoke-Modus im Entertainment-Bereich, die dem Fahrer einen großen Fundus an Musik mit den dazugehörigen Songtexten bereitstellt. Die Rücksitzpassagiere fungieren dabei als Backupsänger.14 Tesla versteht es wie kaum ein an­derer Automobilhersteller, auf die Wünsche seiner Kunden einzugehen und das nahezu oh­ne Marketingausgaben. Ermöglicht wird Tesla dies durch die Art und Weise wie häufig neue Software bereitgestellt wird. Durch die kontinuierliche Softwarebereitstellung, Beispiel hierfür wiederum das Tesla Model 3 mit fast wöchentlichen Updates, erzeugt Tesla eine schnelle und kontinuierliche Feedbackschleife, da die Tesla Kunden in der Regel direkt nach Erscheinen eines Updates per Socialmedia, sei es über Twitter, Facebook oder Youtube, Feedback ge­ben.15 Tesla ist dadurch in der Lage, immer genau auf die Kundenbedürfnisse einzugehen und dabei die Qualität der Software ständig zu verbessern und letztendlich bessere Software zu bauen, die den Kunden begeistert. Vergleichen könnte man das Tesla-Phänomen mit der Geschichte von Apple und Steve Jobs, die damals mit dem iPhone und iPad etwas geschaffen haben, was es so vorher auf dem Markt noch nicht gab. Bevor es das iPhone und iPad gab, sah der Kunde diese gar nicht als notwendig an. Am Ende aber wollte es jeder haben und ein zu damaliger Zeit riesiger Hype um jedes neue Produkt und jede Vorstellung entstand.16

Mittlerweile haben auch andere Automobilhersteller, unter anderem BMW, erkannt, dass sie mitziehen und ihren Kunden ähnliche Updates anbieten müssen, um keine Kundenanteile an Tesla zu verlieren. BMW hat im Mai 2019 ein Software-Update via OTA durchgeführt und ein neues Betriebssystem für den 3er, 8er und X5 aufgespielt. Das rundum erneuerte Betriebs­system ermöglicht es BMW, auf nahezu alle Steuergeräte im Auto zuzugreifen und erhöht dadurch die Möglichkeit eine Vielzahl von neuen OTA-Updates bereitzustellen. Zudem wurde ab August 2019 die Möglichkeit gegeben, sofern die Autos damit bereits ausgestattet sind, durch ein Abo zusätzliche Funktionen wie z.B. Fernlichtassistent oder Abstandstempomat freizuschalten. Die neuen Autos werden damit serienmäßig ausgestattet, allerdings wird die Hardware durch Software deaktiviert. Dies ist vergleichbar mit der Reduzierung der Akkuka­pazität mittels Software bei Tesla.17 Begünstigt wird die in naher Zukunft wohl steigende Zahl an Updates via OTA zudem durch zwei Umstände. Zum einen durch den von der Europäi­schen Union verpflichtenden EU-weiten Einbau des Emergency Call (eCall)18 für Neuwagen, die seit dem 31. März 2018 ausgeliefert werden. Um dies zu gewährleisten, müssen die Auto­mobilhersteller eine Mobilfunkkarte bzw. Sim-Karte in das Auto einbauen. Über diese können dann auch die OTA-Updates empfangen werden. Zum anderen kommt hinzu, dass seit 2020 der Mobilfunkstandard 5G nach und nach in Deutschland freigeschaltet wird. Der neue Mobil­funkstandard 5G bietet im Vergleich zum aktuellen 4G und LTE wesentlich höhere Datenraten und kann damit zusätzlich dazu beitragen, dass wohl auch größere Updates via OTA aufge­spielt werden können.1920

Im Vergleich zu den klassischen Original Equipment Manufacturers (OEMs)21, die seit fast 100 Jahren Autos herstellen, agiert Tesla seit 2003 wie ein Softwareunternehmen, das moderne Softwareentwicklung betreibt und nebenher Autos baut. Dabei gelingt es Tesla wie keinem anderen Automobilhersteller, die Schmerzen der Kunden zu identifizieren. Der Kunde und die Software stehen bei Tesla im Vordergrund und nicht das Produkt Auto. Mittlerweile haben die OEMs verstanden, dass sie kundenschmerzorientierter22 handeln müssen. Dabei ist aber zu beachten, dass dies ein Prozess ist und nicht von jetzt auf gleich wie ein Schalter umgelegt werden kann. Einige OEMs haben bereits erkannt, dass ein Wandel vom klassischen Auto­mobilhersteller zum Softwarehersteller erfolgen muss. VW hat Anfang 2019 mit der „Fakultät 73“ eine eigene Ausbildungseinheit für Softwareentwickler gegründet, an der VW bis 2025 über 10.000 eigene IT-Experten ausbilden will.23 Das Problem ist jedoch, dass, neben dem Mangel an Entwicklern, die Unternehmenskultur in der Softwarebranche im Vergleich zu den OEMs ganz anders gestaltet ist. In den Softwareunternehmen wird meist Wert auf flache Hier­archien, Arbeitsfreiheit und intrinsische Motitvation gelegt. Bei den Autokonzernen herrscht meist hierarchisches Denken und strenge Disziplin. Tesla dagegen betreibt bereits seit der Gründung eine ganz andere Unternehmens- und Entwicklungskultur. Dies wurde zum einem durch den Standort in Kalifornien, dem „Software-Wunderland“, der aufkommenden agilen Software-Bewegung ab 2001 und der DevOps-Bewegung ab 2009 beeinflusst.24

1.2 Motivation der Arbeit

Wie bereits im vorherigen Unterkapitel 1.1 an dem Beispiel des disruptiven Automobilherstel­lers Tesla beschrieben, sind die Zeiten, in denen die Unternehmen getreu dem Motto „Busi­ness as usual" leben konnten und dabei wettbewerbsfähig blieben, vorbei. Um auf dem Markt mitzuhalten und dabei noch für potentielle Kunden aus der Masse hervorzustechen, müs­sen die Unternehmen die Dauer der Produkt- und Softwareentwicklung bis zur Platzierung des Produktes am Markt, im Englischen „Time-to-Market“, auf ein Minimum bis hin zu „On- Demand“-Auslieferung via OTA reduzieren.25 Dabei ist die kontinuierliche Fähigkeit der Aus­lieferung stark abhängig von der IT der Unternehmen, die hinter den Updates der Software steht. Dies gilt dabei nicht nur für die Automobilindustrie, sondern für die unterschiedlichsten Branchen und verschiedensten IT-Produkte. Diese reichen von der reinen Webentwicklung,26 wie z.B. bei den bekannten amerikanischen Unternehmen Facebook, Netflix und Amazon,27 bis hin zu speziellen hochsicherheitsrelevanten Systementwicklungen28 von Embedded-Sys- temen in der Medizintechnik wie z.B. der mobilen Herz-Lungen-Maschine oder dem Herz­schrittmacher. In der heutigen Zeit werden die Kundenerwartungen immer anspruchsvoller, individueller und verändern sich ständig. Überall dort, wo Software entwickelt wird und die Software immer schneller auf den Markt gebracht werden soll, um den Kunden kontinuierlich mit neuen Features zu versorgen, darf die Software-Qualität trotz dieser steigenden Kunden­erwartungen nicht leiden, sondern muss auf gleichbleibendem Niveau gehalten werden, bes­ser noch kontinuierlich gesteigert werden.29 Besonders bei den alteingesessenen Unterneh­men, in der Regel OEMs, fällt auf, dass diese immer häufiger von der Komplexität der ständig steigenden Kundenanforderungen überfordert sind und es immer häufiger vorkommmt, dass Liefertermine nicht eingehalten werden können und die Qualität der Software darunter leidet.

Die Kunden erhalten teilweise nicht mehr die hohen Standards, die sie über Jahre von den Herstellern gewohnt sind und erwarten.

In der IT-Welt wird gerade durch die Einführung der kollaborativen DevOps-Kultur (enge Ver­bindung zwischen Entwicklung und Betrieb) versucht, diesem Problem entgegenzuwirken. Der Fokus der Methoden liegt dabei auf schnellerem Feedback für die Entwickler und der da­durch einhergehenden Möglichkeit der schnelleren Auslieferung von Software-Verbesserung für den Kunden mit dem Ziel der Erhöhung der Kundenzufriedenheit. Dabei muss zwischen der reinen Webentwicklung und der Embedded-Systementwicklung unterschieden werden. Gerade bei der Einführung der DevOps-Methoden in der Systementwicklung verlaufen die ers­ten Schritte im Vergleich zur Webentwicklung nicht geradlinig. „Quality Gates“30 und Test- und Freigabebedingungen müssen angepasst werden. Schnittstellen zu „Fertigung“ und „Feld“31 verändern sich. Die kontinuierliche und schnellere Auslieferung und Bereitstellung von Soft­ware wird ein immer entscheidenderer Faktor für die Hersteller quer über alle Branchen hin­weg, die IT-Produkte entwickeln. Um sich auf dem Markt weiterhin behaupten zu können und nicht verdrängt zu werden, wird insbesondere in der Embedded-Systementwicklung für die Unternehmen ein steigender Beratungsbedarf entstehen.323334

Entstanden ist die Idee der Masterarbeit zu diesem Thema bei der ITK Engineering GmbH (im Folgenden ITK genannt) am Hauptsitz in Rülzheim in der Südpfalz. Das Unternehmen wurde 1994 als Ingenieurbüro für technische Kybernetik gegründet, woraus sich die Abkür­zung ITK ableitet. Seit 2017 ist die ITK zu 100% ein Tochterunternehmen der Robert Bosch GmbH. Die ITK hat sich als Ingenieur-Dienstleister auf die Tätigkeiten der Komplettsystem­entwicklung, Entwicklungsunterstützung, Projektmanagement und Beratung konzentriert. Die Kernkompetenzen liegen dabei in der modellbasierten Software- und Systementwicklung von Embedded-Systemen.35 Dabei betreut das Unternehmen Kunden aus den verschiedensten Branchen. Die Automobilindustrie ist aktuell die kundenstärkste Branche mit über 75%.36 In den nächsten Jahren soll der Anteil der Branchen und damit der Kunden etwas stärker di­versifiziert werden. Bereits 2020 gibt es neben den Kunden der Automobilbranche Kunden in verschiedenen anderen Branchen darunter unter anderem in der Bahntechnik, der Ge­bäudetechnik, der Luft- und Raumfahrttechnik und der Medizintechnik. Letztere wächst am stärksten. Neben der für jede der Branchen erforderlichen speziellen Fachexpertise konzen­triert sich die ITK auf die Querschnittsthemen der Branchen, darunter auf die Themenbereiche der Industrie 4.0, der Robotik und immer bedeutsamer werdenden Themen wie Safety37, Se­curity38 und Qualitätssicherung in der Softwareentwicklung.39 Die ITK sieht insgesamt in der Beratung und Unterstützung von Kunden ein großes Potential um die gesamte Branche vor­anzubringen, da bei den Kunden meist die eigene Expertise genauer gesagt das Know-how im Unternehmen fehlt, um DevOps im Bereich der Embedded-Systementwicklung einzufüh­ren.40

1.3 Zielsetzung und Aufbau der Arbeit

Das vorliegende Praxisbeispiel soll die Idee hinter der Masterarbeit verdeutlichen: Ein neuer Kunde tritt an die ITK heran, um sich über den Ist-Zustand seiner eigenen Entwicklungsmetho­dik sowie auf ihn zukommende Kosten bei nötiger Aktualisierung zu informieren. Der Kunde erwartet dabei eine individuelle Beratung mit anschließender Umsetzung zum Thema Dev­Ops, Systementwicklung und eine Einschätzung des Return-on-lnvestment (ROI). Darunter wird die prozentuale Relation zwischen Investition und Gewinn anders gesagt die Kapital­rentabilität verstanden. Einfacher ausgedrückt dient der ROI zur Messung der Rendite einer unternehmerischen Tätigkeit, in diesem Fall der Verbesserung und Aktualisierung der aktuel­len Entwicklungsmethodik gemessen am Erfolg der Umsetzung der Neuerung im Verhältnis zum dafür aufgewendeten Kapital.41 Ziel der ITK ist es somit, die Zufriedenheit des Kunden zu steigern, eine schnelle Erfassung und Darstellung des Ist-Zustands zu liefern, einen Überblick über entstehende Kosten bei Aktualisierung zu geben und dabei die langfristige Ersparnis bei Neuerung aufzuzeigen. Die nachfolgende Arbeit beschäftigt sich dabei primär mit der Ent­wicklung eines passenden Modells, um den Kunden bestmöglich zum Thema DevOps und Systementwicklung beraten zu können. Aus der beschriebenen Motivation der Arbeit und dem Praxisbeispiel ergibt sich die zugrundeliegende wissenschafftliche Fragestellung der vorlie­genden Thesis. Um diese Fragestellung zu klären, wurden vier Teil-Forschungsfragen erstellt.

Wie können Unternehmen ihre Softwareentwicklung gestalten, um weiterhin auf dem Markt mit der Konkurrenz mitzuhalten und den Kunden kontinuierlich schneller mit neuen Features und zugleich einem hohen Maß an Qualität zu versorgen?

Wie kann die DevOps-Entwicklungskultur dazu beitragen?

Zunächst soll bei dieser Frage in Kapitel 2 untersucht werden, wo genau die DevOps-Bewe- gung herkommt, wann diese angefangen hat und was genau darunter verstanden wird. Weiter ist in Kapitel 3 zu klären, wie der Software-Entwicklungszyklus bei DevOps aussieht, was genau unter CI/CD42 -Pipeline verstanden wird und wie diese bei dem Entwicklungsprozess verwendet wird.

Wie verbreitet ist die DevOps-Kultur und wie sehen die Unterschiede dabei zwischen Web­entwicklung und der Embedded-Systementwicklung aus?

Hierbei wird zunächst in Unterkapitel 4.1 die Verbreitung der DevOps-Kultur in den Unterneh­men in Deutschland untersucht, bevor auf die weltweite Verteilung eingegangen wird. Dabei wird geprüft, ob die DevOps-Kultur in den Unternehmen bereits vollständig umgesetzt wurde. Anschließend werden in Unterkapitel 4.2 die Unterschiede beim Einsatz von DevOps bei der Webentwicklung und bei der Embedded-Systementwicklung herausgearbeitet.

Welche Modelle existieren bereits?

Dabei sollen nun in Unterkapitel 4.3 die Erforschung und Analyse der bereits bestehenden Ansätze und Modelle am Markt im Vordergrund stehen, mit dem Fokus auf der Anwendbarkeit der Modelle für den Bereich der Embedded-Systementwicklung.

Wie müsste ein Konzept für ein Kompetenz- und Kostenmodell, das im Embedded-Systement- wicklungsbereich verwendet werden kann, aussehen?

Bei dieser Frage wird auf die Konzepterstellung eines eigenen Kompetenzmodells in Kapitel 5 und eines Kostenmodells in Kapitel 6 eingegangen. Der Fokus wird hierbei auf die Einfach­heit, Aussagekraft, Effizienz und Anwendbarkeit des Modells für den Embedded-Bereich ge­legt. Um dies gewährleisten zu können, wird bei den Fragen eine Gewichtung vorgenommen und die Fragen werden auf Signifikanz und Relevanz überprüft. Das Kompetenzmodell soll, im Gegensatz zu den am Markt weit verbreiteten Reifegradmodellen, die Kompetenzen über den Kundenschmerz ermitteln. Dabei liegt der Fokus auf der Verbesserung der Ergebnisse. Die Handhabung dieses Modells soll dem Kunden leicht zugänglich sein und diesem Verbes­serungen und den damit einhergehenden Benefit aufzeigen. Das Modell soll anschließend mittels interner und externer Projekte evaluiert werden.

2 DevOps

Dieses Kapitel beschäftigt sich mit der Unternehmens- und Entwicklungskultur DevOps, die die theoretischen Grundlagen der Masterarbeit bildet und entscheidend für die moderne Soft­wareentwicklung und-bereitstellung ist. Zunächst wird dabei die Herkunft des Begriffs DevOps erklärt, bevor näher auf die Bedeutung der DevOps-Kultur eingegangen wird.

2.1 Entstehung der DevOps-Bewegung

„DevOps stellt kein Ziel dar, sondern ist ein nicht endender Prozess der kontinu­ierlichen Verbesserung." - Jez Humble, 201543 Es gibt die unterschiedlichsten Aussagen und Meinungen darüber, was genau unter dem Be­griff „DevOps“ verstanden wird. Eine offizielle und allgemein gültige Definition gibt es bisher nicht. Der Begriff taucht an den verschiedensten Stellen bei Konferenzen, in der Fachliteratur und den unterschiedlichsten Webseiten auf und wird dabei immer beliebter. Dabei stellt sich die Frage, wo und wie der Begriff entstanden ist.4445

Patrick Debois, in der DevOps-Szene besser bekannt als der „Pate von DevOps“46, arbeitet 2007 in der Funktion als Systemadministrator an einer Rechenzentrumsmigration der belgi­schen Regierung. Debois bemerkt dabei auftretende Konflikte zwischen den Entwicklern und Systemadministratoren-Teams.47 Zugleich bewundert er die agilen Methoden, die von eini­gen Teams angewandt werden und ist davon begeistert, wie produktiv die Teams dadurch sind und wie schnell sie die Aufgaben erledigen können.48 Im darauf folgenden Jahr expe­rimentiert er selbst mit den agilen Methoden und verfasst ein „IEEE Papier“49. Dieses stellt er 2008 in Toronto auf der „Agile Conference“ vor, jedoch findet sein Vortrag mit dem Titel „Agile Infrastructure & Operations“50 geringen Anklang. Andrew Shafer, ebenfalls als Refe­rent in Toronto, hat einen Vortag zu Thema „agile Infrastruktur“ vorbereitet, allerdings findet sein Vortrag noch geringeren Anklang. Es stellt sich heraus, dass Debois der einzige Interes­sent bzw. Teilnehmer des Vortags ist. Daher beschließt Shafer, seinen Vortrag gar nicht erst zu halten. Trotzdem kommen die beiden ins Gespräch und gründen zusammen die Google Forum Gruppe „Agile System Administration“51.

Im Juni 2009 nimmt Debois aus seiner Heimat (Belgien) per Twitter an der O'Reilly Velocity Konferenz in San Jose (Kalifornien) an dem Vortrag „Zehn oder mehr Bereitstellungen pro Tag: Zusammenarbeit von Dev und Ops bei Flickr“52, gehalten von John Allspaw und Paul Hammond, die Leiter der IT-Operation- (IT-Betrieb) und System-Engineering- (Systement­wicklung) Gruppe bei Flickr sind, teil. Dieser Vortrag stellt dabei wohl die Initialzündung für die DevOps-Bewegung dar. Die beiden Referenten sprechen darüber, wie sie es geschafft haben bei Flickr sich nicht, statt wie damals weit verbreitet, an Konflikten zwischen den Entwickler-, Operation-, und Business-Teams aufzureiben oder gegeneinander zu arbeiten. Zu dieser Zeit herrschte meistens der traditionelle Gedanke, dass die Entwickler sich nur darum kümmern, dass neue Features entwickelt werden und das Operationen-Team versucht, dass das Sys­tem stabil bleibt und nicht bei jeder Änderung der Entwickler zusammenbricht.53 Sie berichten darüber, wie sie es durch Kollaboration der Teams zu einem gemeinsamen Unternehmensziel und Verständnis geschafft haben, sodass regelmäßig zehn oder mehr Bereitstellungen neuer Software durchgeführt werden konnten und das zu einer Zeit, in der IT-Unternehmen teilweise vierteljährlich oder monatlich Bereitstellungszyklen hatten. Bei Flickr ist diese Rate zu dieser Zeit bis zu tausendmal höher als in der Branche üblich.54

Sie vertreten die Meinung, dass die Aufgabe des IT-Betriebs nicht alleine die Gewährleis­tung der Stabilität der Webseite ist, sondern dass diese eine sogenannte „Enabler-Rolle“ ein­nehmen, zu Deutsch „Weichensteller“ oder „Ermöglicher“ für das Business. Zudem ist das Business wiederum abhängig von regelmäßigen Änderungen und Bereitstellungen durch die Entwickler. Um dies zu gewährleisten, muss das Risiko, dass es bei einer Änderung zum Ausfall oder generell zu Fehlern kommt, auf ein Minimum verringert werden. Dies kann er­möglicht werden durch den Einsatz geeigneter „Tools“, zu Deutsch „Werkzeuge“, wie sie bei der kontinuierlichen Bereitstellung über eine CI/CD-Pipeline verwendet werden.55 CI/CD ist dabei ein Akronym für „Continuous Integration (CI)“, zu Deutsch „Kontinuierliche Integrati­on“ von Software, „Continuous Delivery (CD)“, zu Deutsch „Kontinuierliche Auslieferung“ von Software und „Continuous Deployment (CD)“, zu Deutsch „Kontinuierliche Bereitstellung“ von Software. Durch die identische Abkürzung „CD“ kommt es des öfteren zur Verwechslung der beiden Begriffe. Die genauen Unterschiede werden im nächsten Kapitel 3 beschrieben.

Des Weiteren gehen sie auf vier Punkte der Kultur, die bereits auf DevOps anspielen, ein. Zum einem sollten sich alle im Team und Unternehmen respektieren, es sollte keine Nein­Sage-Kultur, sondern eine aufgeschlossene und transparente Kultur herrschen. Dabei sollen die Entwickler-Teams die IT-Betriebs-Teams darüber informieren, welche Änderungen vor­genommen werden, wie die Risiken dabei und was die ersten Anzeichen dafür sind, dass bei den Änderungen etwas schiefgegangen ist. Der zweite relevante Punkt ist Vertrauen. Die IT-Betriebs-Teams müssen den Entwickler-Teams vertrauen, dass sie bei Änderungen und Feature Diskussionen mit eingebunden werden. Genauso müssen die Entwickler darauf ver­trauen, dass sie vom IT-Betrieb über Änderungen bei der Infrastruktur mit einbezogen wer­den. Wenn sich alle Teams und Mitarbeiter gegenseitig vertrauen, hilft das dem Business. IT-Betrieb-Teams und Entwickler-Teams sollten die gleichen Zugriffe auf den „Source Code“, zu Deutsch „Quellcode“ oder „Quelltext“56 oder die Systeme haben. Der dritte Punkt ist ei­ne gesunde Einstellung zu Fehlern. Fehler werden immer passieren. Jeder sollte selbst die Verantwortung bei sich sehen und alles in seiner Macht stehende tun, um Fehler vorher zu vermeiden. Der vierte Punkt ist das Vermeiden von Anschuldigungen oder Schuldzuweisun­gen, wenn Fehler aufgetreten sind. Es sollte schnell und produktiv auf Fehler reagiert werden, um sie schnellstmöglich zu reparieren und am Ende die Fehler dokumentiert und sichtbar ge­macht werden, sodass aus den Fehlern gelernt werden kann und diese nicht ein zweites mal gemacht werden. Dabei sollte darauf geachtet werden, dass nur konstruktives Feedback ge­geben wird.57

Debois beklagt anschließend auf Twitter, dass er nicht persönlich an dem seiner Meinung nach phänomenalen Vortrag teilnehmen konnte. Daraufhin stellt Paul Nasrat, ein anderer Twitter-User, Debois die Frage, wieso er nicht selbst ein eigenes Velocity Event in Belgien organisieren wolle. Debois kommt der Aufforderung ganz euphorisch nach, da er nach dem Vortrag von Allspaw und Hammond endlich das Gefühl hat, dass er Gleichgesinnte gefunden hat, die sein agiles Verständnis teilen. Er organisiert noch im gleichen Jahr, nur ein paar Mo­nate später, im Oktober 2009 eine eigene Konferenz in Gent.5859 Da Debois der Name „Agile System Administration“, benannt wie seine Google-Forum-Gruppe, als Konferenzname zu lang erschien, überlegt er sich ein neues Wort und nennt die Konferenz „DevOpsDays“, der später gekürzte Hashtag lautet „#Devops“. Debois selbst und einige andere legen noch heute Wert darauf, dass das „o“ in „ops“ klein geschrieben wird. Durchgesetzt hat sich in den meisten Internetartikeln sowie in der Literatur jedoch der Name mit großgeschriebenem „0“ in „Ops“. Die Wortschöpfung DevOps ist dabei eine Zusammensetzung aus jeweils drei Buchstaben der beiden Wörter Development (Entwicklung) und Operation (Betrieb).60 Es dauert nach der Konferenz in Gent jedoch noch eine Weile, bis sich der Name DevOps global verbreitet.61 Das Interesse an DevOps ist dadurch zu erklären, dass DevOps den IT-Abteilungen eine mögliche Lösung anbietet, sich von der stetig steigenden Anzahl von verzögerten Projekten bis hin zu abbauender Softwarequalität und verpassten Lieferterminen zu befreien.62

Neben Tesla, wie bereits in Kapitel 1 beschrieben, konnten auch die großen amerikanischen Firmen, darunter Amazon, Etsy, Facebook und Netflix, bereits zeigen, wie DevOps dabei hel­fen kann, sich von den Wettbewerbern abzuheben und abzusetzen.6364 DevOps scheint sich zunehmend zum Branchenstandard vor allem für Unternehmen aus der Webanwendung und Entwicklung zu etablieren, da die Teams durch den Einsatz von DevOps-Software schneller und mit mehr Qualität entwickeln können.65

Wie bereits am Anfang des Abschnittes erwähnt, stellt sich dabei die Frage, was genau vom Gründer Debois unter DevOps verstanden wird, da es keine offizielle Definition gibt. Denn bei aller Euphorie, die DevOps in der IT-Branche ausgelöst hat, kommt zunehmend der Eindruck auf, dass die Unternehmen die unterschiedlichsten Vorstellungen haben, was genau Dev­Ops ist. Teilweise sind die Unternehmen der Meinung, sie würden DevOps bereits vollständig in ihrem Unternehmen verwenden, haben dabei aber in Wahrheit gerade erst angefangen oder sind sogar der Meinung, DevOps wären Tools, die sie bereits verwenden.66 Zwar hält Debois selbst auf seiner organisierten „DevOpsDay“-Konferenz 2009 keinen eigenen Vor­trag,67 jedoch gibt der damalige Vortrag68 von der „Agile Conference“ 2008 in Toronto bereits Aufschluss darüber, was Debois unter DevOps zur damaligen Zeit verstand. Der erste Teil des Vortags konzentrierte sich zunächst auf die fortschreitende Verbreitung und den Einsatz von agilen Methoden in der Softwareentwicklung der IT-Unternehmen in Amerika wie auch in Europa. Bereits in den Anfängen der 1990er Jahre sind die ersten Ansätze von agiler Soft­wareentwicklung zu finden, hier jedoch zunächst unter dem Begriff „lightweight“, zu Deutsch „leichtgewichtig“.69 70

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1 Wasserfallmodell und V-Modell70

Bis dahin wurde Software meistens nach der Wasserfallmethodik, in Abbildung 1 auf der linken Seite dargestellt, entwickelt. Bei dieser Methodik läuft die Softwareentwicklung nach einem linearen Ansatz, das heißt Schritt für Schritt bzw. stufenweise nach klar aufeinanderfolgen­den Projektphasen ab. Alternativ zum Wasserfallmodell war zudem die Entwicklung nach dem V-Modell beliebt, in Abbildung 1 auf der rechten Seite dargestellt. Dieses basiert auf dem Was­serfallansatz und verläuft dabei auch linear. Im V-Modell wurde das Wasserfallmodell zusätz­lich um Testphasen ergänzt, die dabei jeweils einer Entwicklungsphase gegenüber gestellt werden.717273

Popularität erlangte die agile Software-Bewegung gegen Ende der 1990er, genauer gesagt 1999, mit dem Buch von Kent Beck „Extreme Programming: Die revolutionäre Methode für Softwareentwicklung in kleinen Teams“. Extreme Programming (XP) stellt dabei eine revo­lutionäre neue Software-Entwicklungsmethode im Vergleich zu den gerade beschriebenen traditionellen Methoden wie Wasserfall oder V-Modell dar. XP wurde hauptsächlich von Kent Beck entwickelt und ist eine der ersten agilen Methoden. Durch das steigende Interesse an XP wird der Weg für agile Methoden und Prozesse geebnet. Tatsächlich ist XP in den spä­ten 90er und frühen 00er die dominierende Entwicklungsmethode. Dabei hat XP agile Metho- Test- den populär gemacht, die noch heute verwendet werden. Darunter kontinuierliche Integration, Driven- Depioy- Refactoring, Test-Driven-Development (TDD), Pair-Programming, einfaches Design und agile ment Planung.74 Der Begriff „Agile“ löst im Februar 2001 endgültig den bis dahin verbreiteten Be- pair- griff „lightweight“ ab. Hierzu kommt es, da bei einem Treffen in Utah ein Dokument von einem Pro­ gram- Kreis von Softwareentwicklern, darunter unter anderem der bereits erwähnte Kent Beck, der ming später beim Thema CI/CD noch eine Rolle spielende Martin Fowler und zusätzlich noch 15 weitere in der agilen Szene bekannte Autoren, verfasst wurde.75

Das Dokument wird unter dem Titel „Manifesto for Agile Software Development“, kürzer „Agile Manifesto“, zu Deutsch „Agiles Manifest“, veröffentlicht und enthält die bis heute gültigen fun- Agiie damentalen Leitsätze und Prinzipien der agilen Softwareentwicklung. Die vier grundlegends­ten Leitsätze lauten: Es wird mehr Wert gelegt auf Individuen und Interaktionen als auf Pro- Wäi6~ wick- zesse und Werkzeuge; mehr auf funktionierende Software als auf umfassende Dokumentati- lung on; Zusammenarbeit mit dem Kunden ist wertvoller als Vertragsverhandlung; Reagieren auf Veränderungen ist bedeutsamer als das Befolgen eines Plans.76 Letztendlich stellt die agile Softwareentwicklung eine Gegenbewegung zu den bereits beschriebenen traditionellen und schwergewichtigen Modellen dar. Dabei verfolgt der agile Ansatz das Ziel, den Entwicklungs­prozess im Vergleich zu den traditionellen Modellen flexibler und zugleich schlanker zu ge­stalten.77 Wie bereits beschrieben warXP die dominierende Software-Entwicklungsmethode. scrum Ab 2008 löst Serum XP ab und wird seitdem immer beliebter, während XP immer weiter zu­rückgeht.78 Im Jahr 2019 wurde nach einer Umfrage, auf die in Unterkapitel 4.1 noch genauer eingegangen wird, in den Software Teams 54% Serum und 32% Abwandlungen von Serum verwendet. XP hat dabei nur noch einen Anteil von 1%. Serum schließt aber nicht aus, dass agile Methoden, die in XP fest vorgeschrieben sind, in Serum freiwillig verwendet werden.79

Im zweiten Teil konzentrierte sich Debois auf Konflikte, die zwischen den Teams innerhalb des Software-Entwicklungsprozesses entstehen, so wie er es bereits selbst im zu Anfang geschilderten Beispiel bei der Rechenzentrumsmigration der belgischen Regierung erleben durfte. Dabei unterscheidet er zwischen drei verschiedenen Teams: dem Team der Entwickler (Programmierer und Tester), dem zweiten Team der IT-Administratoren (Infrastruktur, Server, Netzwerk) und dem dritten Team-Betrieb (Support für Endbenutzer bzw. Kunden).80

Debois hebt dabei zwei Grundprobleme der Entwickler hervor: Die Entwickler interessieren sich nicht für die Server oder das Netzwerk. Teilweise wird dies dadurch verursacht, dass den Entwicklern IT-Fähigkeiten fehlen. Dabei muss gesagt werden, dass Debois dies zur dama­ligen Zeit aus seiner Sicht des Systemadministrators betrachtet. Wichtig ist ihm dabei eine Stärkung der Zusammenarbeit der Teams und eine generelle teamübergreifende Arbeit in al­len Phasen der Entwicklung und ein gemeinsames Verständnis der Kultur im Unternehmen. Bei der Idee des gemeinsamen Kulturverständnisses beschreibt er das Problem, dass die Entwickler z.B. in einem Unternehmen bereits nach einem agilen Ansatz arbeiten, IT und Produktmanagement aber weiterhin nach dem Wasserfallmodell vorgehen. Zudem geht er in der Präsentation noch auf weitere grundlegende DevOps Prinzipien ein, indem er hervor hebt, dass vieles von der Häufigkeit der Deployments und der Häufigkeit der Tests abhängig ist. Bei alledem ist ihm wichtig, dass bei DevOps das Menschliche im Vordergrund steht. In der Szene wird DevOps auch gerne als Kultur beschrieben.81

2.2 Bedeutung von DevOps

Nach der Konferenz im Oktober 2009 in Gent verbreitet sich zunächst bei einigen der Ein­druck, „DevOps“ würde „Agile“ schlicht ersetzen. Das Problem war, dass sich der Schwer­punkt der Konferenz und die Vorträge der anderen Referenten hauptsächlich mit der „agilen Bewegung“ auseinandergesetzt hatten und daher der Begriff zunächst immer in Verbindung mit „Agile“ auftauchte.82 Dabei sind „Agile“ und „DevOps“ zueinander kompatibel oder an­ders ausgedrückt, DevOps ist die logische Fortsetzung des „agilen Weges“, der 2001 mit dem Manifest begonnen hat.83 Bei „Agile“ wird die Entwicklung als „Done", zu Deutsch „fer­tig“, angesehen, wenn die Entwickler fertig programmiert haben, bei DevOps dagegen erst, wenn der Source Code vollständig getestet wurde und auch in der Produktivumgebung funk­tioniert.84 Zudem konzentriert sich „DevOps“ auf die Kultur im Unternehmen und „Agile“ auf die Prozesse.85

Im Jahr 2011 findet Debois drei Gleichgesinnte, die von der DevOps-ldee genauso wie er von Anfang an begeistert sind. Sie erkennen das Potential, das DevOps bietet. Dabei haben sie die Ideen von DevOps weiterentwickelt und vorangetrieben, sei es bei Konferenzen oder in veröffentlichten Papieren und Büchern. Im Februar 2011 beschließt die vierköpfige Gruppe, darunter Patrick Debois, John Willis, Jez Humble und Gene Kim, in wöchentlichen Skype- Meetings, ein gemeinsames DevOps-Buch zu verfassen. Darin erklären sie in Form eines Leitfadens ihre Erfahrungen mit DevOps, was genau sie darunter verstehen und wie Unter­nehmen dieses selbst bei sich einführen können.86 Es dauerte drei Jahre bis das DevOps- Handbuch, von einigen in der DevOps-Szene gerne als die Bibel des DevOps bezeichnet, im Jahr 2016 veröffentlicht wurde.

John Willis, der selbst auf der von Debois organisierten Konferenz in Gent teilgenommen hat, organisiert anschließend 2010 mit Damon Edwards die erste „DevOpsDay“ Konferenz in den USA in Mountainview.87 Zusammen mit Damon Edwards entwirft er das Akronym „CAMS“, das DevOps in die vier Begriffe „Culture“, „Automation“, „Measurement“ und „Sharing“, zu Deutsch „Kultur“, „Automatisierung“, „Messbarkeit“ und „gemeinsame Nutzung“, unterteilte. Später wird dieses von Jez Humble um „L“ wie „Lean“ ergänzt und zu „CALMS“ erweitert.88 Kultur bedeutet bei DevOps: An erster Stelle stehen die Menschen und Prozesse. Wenn das Unternehmen keine Kultur hat, sind die Automatisierungsversuche erfolglos. Die Automati­sierung ist der nächste Schritt, wenn die Kultur verstanden wurde. Hierbei können Werkzeu­ge verwendet werden, die das „Release-Management“ zu Deutsch „Freigabe-Management“, die Bereitstellung, das Konfigurationsmanagement, die Systemintergration, die Überwachung und Steuerung automatisieren. Die Teams sollten „Lean“, zu Deutsch „schlanke und einfa­che Prinzipien“ verwenden. Auf dies wird im Nachfolgenden bei „Toyota-Produktionssystem (TPS)“ genauer eingegangen. Die Lean-Prinzipien bei DevOps besagen: Sichtbarkeit der Ar­beit, Reduzierung der Komplexität der Übergabe und der Wartezeiten und Minimierung des Work in Progress (WIP), zu Deutsch „laufende Arbeit“, in der Betriebswirtschaftslehre als „Umlaufbestand“ oder „Ware in Arbeit“ bezeichnet. Wenn es keine Metriken zum Messen gibt, dann kann die Kultur auch nicht verbessert werden. Bei einer erfolgreichen DevOps- Implementierung sollte alles so oft wie möglich gemessen werden. Dabei kann es z.B. Leis­tungsmetriken, Prozessmetriken oder sogar Personenmetriken geben. Teilen ist quasi die Feedbackschleife des CALMS-Zyklus. Die Schaffung einer Kultur respektive Arbeitsumge­bung, in der Menschen Ideen und Probleme austauschen, ist von entscheidender Bedeu­tung.89

Jez Humble selbst setzt sich parallel und unabhängig von den bereits im vorherigen Abschnitt beschriebenen Leitern des IT-Betriebs und Systementwicklungsgruppe bei Flickr, John All- spaw und Paul Hammond, mit der kontinuierlichen Bereitstellung von Software-Features aus­einander und kommt dabei zu ähnlichen Erkenntnissen. Im Zuge seines besonderen Interes­ses für bestimmte Werkzeuge, die bereits im Flickr-Vortrag kurz aufgelistet wurden, veröffent­licht er 2010 ein Buch mit dem Titel „Kontinuierliche Auslieferungen: Zuverlässige Software­Freigaben durch Automatisierung von Build, Test und Bereitstellung“90. Die in diesem Buch vorgestellten Werkzeuge stellen noch heute die wesentliche Grundlage für die CI/CD-Pipeline dar. Des weiteren hat Jez Humbel 2014 ein Buch unter dem Titel „Lean Enterprise: Mit agi­len Methoden zum innovativen Unternehmen veröffentlicht“91. Dies beruht auf dem von Eric Ries veröffentlichen „Lean Startup“92. Daher rührt auch die Änderung des Akronyms „CALM“ auf „CALMS“ durch Jez Humbel. In dem Buch „Lean Enterprise“ beschäftigt sich Jez Hum­ble damit, wie die von Startups bekannten Eigenschaften Flexibilität, Agilität und IT-Affinität auch auf etablierte Unternehmen übertragen werden können. Das Problem ist, dass auch die eher trägeren, alteingesessenen Unternehmen mittlerweile genauso wie die Startups einen dynamischen Markt mit sich schnell ändernden Kundenbedürfnissen vorfinden und sich dar­auf einstellen müssen. Von ihm stammt auch das zu Beginn des Abschnitts bereits zu lesende Zitat: „DevOps stellt kein Ziel dar, sondern ist ein nicht endender Prozess der kontinuierlichen Verbesserung“, das den Kern von DevOps treffend beschreibt.

Gene Kim, der vierte im Bunde, thematisiert 2013 in dem Business-Roman mit dem Titel „The Phoenix Project - A Novel About IT, DevOps and Helping Your Business Win“, wie DevOps da­bei helfen kann, eine Zukunftsstrategie für die IT, besser gesagt für das ganze Unternehmen, zu entwickeln.93 Das Buch stellt dabei die Hauptgrundlage für das gemeinsame „DevOps- Handbuch“ dar. Im „DevOps-Handbuch“ werden dabei die im Roman erwähnten Methoden ausführlich auseinandergenommen und durchleuchtet.94 Auf diese wird im nächsten Unterka­pitel 2.3 und bei der Erstellung des Kompetenzmodells in Unterkapitel 5.2 genauer eingegan­gen. Zudem veröffentlicht Gene Kim 2018 zusammen mit Jez Humble und Nicole Forsgren das Buch „Accelerate“95. Das Buch stellt den Forschungshintergrund für die „State of Dev­Ops Reports“, die in Unterkapitel 4.1 analysiert werden, dar. Ebenfalls veröffentlicht Gene Kim 2019 den Nachfolger vom „Phoenix-Projekt“ unter dem Namen „The Unicorn Project“. Das „Unicorn-Projekt“ beleuchtet dabei aus Sicht der technischen Mitarbeiter die gleichen Er- eignisse aus dem im nachfolgend beschriebenen „Phoenix-Projekt“ Buch und geht dabei auf die Schlüsselfragen der Teamdynamik und Führung genauer ein. Dabei geht es nicht um das „Was“ und „Warum“ von „DevOps“, wie es im „Phoenix-Projekt“ erklärt wurde, sondern um das „Was“ und „Warum“ der „digitalen Transformation“. Wichtig ist Gene Kim, dass jedem klar wird, dass DevOps so gut wie möglich im Unternehmen eingeführt werden kann. Wenn die Kundenbedürfnisse dabei aber auf der Strecke bleiben, bringt es letztendlich keinen Mehr­wert. Im Buch werden am Ende fünf Ideale aufgestellt.96

1. Lokalität und Einfachheit im Source Code und der Organisation.
2. Fokus, Fluss und Freude an der Arbeit.
3. Ermöglichung der Verbesserung der täglichen Arbeit.
4. Eine Kultur der psychologischen Sicherheit.
5. Ein unermüdlicher Fokus auf den Bedürfnissen der Kunden.

Im Nachfolgenden wird auf die Vorgeschichte das „Phoenix-Projekt“ eingegangen, da es die Grundlage des „DevOps-Handbuchs“ bildet und für Anhänger der DevOps-Bewegung einen Meilenstein darstellt. Die Bücher, an denen Gene Kim mitgeschrieben oder alleine geschrie­ben hat, werden durch seinen selbstgegründeten Verlag „IT Revolution“ veröffentlicht.

2.3 Phoenix-Projekt

Das „Phoenix-Projekt“ ist in Form eines Romans geschrieben, um so nicht nur IT-Experten, sondern auch nicht technikaffinen Personen und somit einer möglichst breiten Masse von Menschen die DevOps-Kultur näherzubringen. Darunter sollen vor allem auch Personen in Führungsebenen, die die Entscheidungsgewalt haben neue Methoden einzuführen, zu finden sein, denn diese Entscheidungen betreffen somit das gesamte Unternehmen bzw. Organisa­tion und nicht nur die IT allein. Der Roman handelt von einem IT-Teamleiter (Bill Palmer), der plötzlich in eine leitende Position zum IT-Manager bei einem fiktiven amerikanischen Unter­nehmen befördert wird und dabei direkt dem CEO unterstellt ist.97 Bill hat 90 Tage Zeit, um ein überbudgetiertes und kurz vor dem endgültigen Aus stehendes Mammutprojekt mit dem Codenamen „Phoenix-Projekt“ noch in letzter Minute zu retten. Falls dies nicht gelingt, soll die IT des Unternehmens ausgelagert werden und somit alle alten Kollegen von Bill ihren Job ver­lieren.98 Zunächst versucht Bill wie in seinem alten Job vorzugehen und für möglichst effiziente Arbeitsabläufe zu sorgen. Er stößt dabei aufgrund der Größe des Projekts und der Problema- tik, dass keiner mehr den Überblick über das Ganze hat und der hohen, am Anfang kaum messbaren Anzahl an verschiedensten Baustellen, die sich immer wieder auftun, schnell an seine Grenze.99100 Zudem wird die IT im gesamten Unternehmen nur als Arbeitslast und Kostenverursacher angesehen.101 Das Buch versucht dabei nach und nach aufzuzeigen, wie DevOps verwendet werden kann, um die IT in das gesamte Unternehmen zu integrieren und die Kommunikation und Effektivität der IT-Organisation zu verbessern. Damit die IT vom Ge­samtunternehmen nicht mehr länger als unnötiger Kostenpunkt für das Unternehmen ange­sehen wird, wird versucht, die IT von einer reinen Geschäftslast zu einem Business-Enabler umzubauen.102103104 Bill bekommt aus dem Aufsichtsrat einen Mentor (Erik Reid) an die Seite gestellt, der ihn mehrmals im Buch in eine Produktionshalle des Unternehmens mitnimmt und versucht ihm, anhand der Fertigungsstraße, Analogien zwischen den traditionellen Prozessen in der Produktion hin zur IT aufzuzeigen.105

Dabei wird auf den beim Automobilhersteller Toyota eingeführten TPS Ansatz eingegangen. Toyota Pro- Der Ansatz wurde von Taiichi Ohno erfunden und bereits 1978 in dem Buch mit dem Titel „To- duc­ tion yota seisan höshiki“ veröffentlicht. 1988 erschien dieses im Englischen unter dem Titel „Toyo- st^ (TPS) ta Production System: Beyond Large-Scale Production“106, zu Deutsch „Toyota-Produktions- system: Jenseits der Großserienproduktion“. Die Grundidee besteht darin, jede Art der Ver­schwendung zu vermeiden, die sich im Laufe der Zeit automatisch entwickelt. Ziel ist dabei eine hohe Produktivität bei gleichzeitig hoher Produktqualität und weiterhin pünktlicher Aus­lieferung.107108 Das Ganze beruht auf zwei Grundprinzipien: Das erste Prinzip ist die „Just-in- time-Produktion“. Dabei soll nur das produziert werden, was vom Kunden auch als nächstes verlangt wird, um nicht überzuproduzieren. Dabei darf explizit nur das gefertigt werden, was auch unbedingt für die nächste Kundenbestellung benötigt wird (Build-to-Order). Zusätzlich Butid- to- muss darauf geachtet werden, dass es einen kontinuierlichen Materialfluss unter Einhaltung Order einer vorgegebenen Taktzeit gibt.109 Das zweite Prinzip besagt, dass Qualität im Prozess ver­ankert sein muss (Built-In-Quality). Dabei bedarf es dreier Grundregeln: Zum einem muss die Bun­in­ Produktion bei einer Abweichungen sofort stoppen. Es muss standardisierte Prozesse sowie Quality genaue Arbeitsanweisungen geben und es muss versucht werden, Fehler generell zu vermei­den und diese am besten vorzubeugen. Letztendlich ergeben sich fundamentale Grundsätze für den Ansatz des TPS: Es muss versucht werden jegliche Verschwendung zu beseitigen. Die Prozesse müssen sich kontinuierlich weiterentwickeln und verbessern. Der Kunde bzw. Lieferant muss in den Prozess mit einbezogen werden.110

Erik gibt Bill die Aufgabe, in vier Arten zu unterscheiden, welche Arbeit seine Mitarbeiter ver­richten. Das Ergebnis: Es gibt zum einem Business-Projekte für den Kunden, zum anderen interne IT-Projekte. Die dritte Art der Arbeit sind Änderungen, die sich aus den vorherigen Arbeiten ergeben und in einem Ticketsystem erfasst werden sollten, auf das alle Mitarbeiter besser gesagt Teams Zugriff haben. Die vierte Art sind ungeplante Arbeiten oder Wieder­herstellungsarbeiten, die durch die ersten drei Arbeiten verursacht werden. Darunter werden Zwischenfälle und Probleme verstanden, die meist auf Kosten von bereits anders geplan­ter Arbeit umgesetzt werden müssen. Zunächst untersucht Bill nun, wo seine Mitarbeiter die meiste Zeit aufbringen müssen. Dabei stellt er fest, dass seine Mitarbeiter hauptsächlich da­mit beschäftigt sind, auf Systemausfälle zu reagieren um die Systeme schnellstmöglich wie­der online zu bringen. Vor lauter „Feuerlöschaktionen“ kommen die Mitarbeiter gar nicht dazu ihrer eigentlichen Arbeit, der Arbeit an neuen Features für das Projekt, nachzugehen.111 Im Tech- TFS System wird dabei auch von „Technischer Schuld“ der Systeme gesprochen. Für jedes nische schuld System, das ein Unternehmen bereitstellt, erhalten die Mitarbeiter eine gewisse „Technische Schuld“, die sie einplanen und berücksichtigen müssen, da jede neue Bereitstellung wieder zu einem Ausfall führen kann und damit zusätzliche, meist ungeplante Arbeit verursacht.112113

Danach schaut er sich den WIP an. Dabei werden die einzelnen Features des Projekts be­trachtet, die sich aktuell in der Entwicklung befinden, die bereits fertig sind und ins Gesamtpro­jekt eingebaut wurden. In der Autoproduktion sind das alles Materialen oder teilweise fertige Produkte, die sich in verschiedenen Phasen des Produktionsprozesses befinden. Dabei han­delt es sich meist um Investitionen, die keine direkte Rendite erzielen, sondern im Laufe der Zeit sogar an Wert verlieren können.114 In der IT ist dies der Fall, wenn ein Kunde sich ein neu­es Feature wünscht und es sich noch im Entwicklungsprozess befindet. Erst wenn es fertig im Projekt eingebaut ist und der Kunde das Feature benutzen kann, bringt es einen Wert ein. Je mehr Features in der Entwicklung feststecken, umso mehr behindert dies den gesamten „Work-Flow“, zu Deutsch „Wertefluss“, und es können kaum noch Features zu Ende entwi­ckelt werden.115 Daher hat Toyota in der Autoindustrie Kanban-Boards zur Visualisierung des WIP eingeführt, um möglichst genau zu erkennen, wie weit die einzelnen Materialien in der Produktion sind und wo eine Maschine gerade nicht ausgelastet oder überlastet ist.116117 Auf die IT übertragen können hier auch Kanban-Boards eingesetzt werden, um aufzuzeigen, wer an welchen Teil-Features gerade arbeitet, welches als nächstes fertig werden muss, damit ein anderer Entwickler nicht auf den Source Code eines anderen warten muss, um Weiterarbeiten zu können. Zudem kann so festgestellt werden, wer komplett ausgelastet ist mit Teil-Projekten oder wer noch Kapazität hat.118119

Des Weiteren wird im „Phoenix-Projekt“ auf das Problem vielmehr die Theorie des „Flaschen­halses“ eingegangen. Diese wird bereits von Eliyahu Goldratt in seinem Buch „Das Ziel - Ein Roman über Prozessoptimierung“ von 1984 beschrieben.120 In der Produktion gibt es immer eine Maschine, die die langsamste ist. Die anderen Maschinen können zwar in der gleichen Zeit wesentlich mehr produzieren, aber dann bilden sich wieder Stapel von nicht benötig­ten Teilen. Daher ist die Idee bei der „Flaschenhals-Theorie“, dass die langsamste Maschine identifiziert wird und sich der Rest dieser anpasst und unterordnet. Es muss versucht werden, diese Maschine optimal auszunutzen. Es muss versucht werden, dass bei der „Flaschenhals­Maschine“ immer genug Material vorhanden ist, da diese das Tempo der gesamten Fabrik beeinflusst. Es sollte zudem vermieden werden, dass die langsamste Maschine zu weit zu­rückbleibt. Dies kann über die bereits beschriebene WIP-Begrenzung geregelt werden. Im Buch wird dieser „Flaschenhals“ als Engpass beschrieben, da es zur Konzentration auf eine bestimmte Person (Brent) kommt, da diese am besten über alles Bescheid weiß und daher immer als Ansprechpartner für jedes Problem gerufen wird. Dabei ist aber das Problem, dass Brent zwar das meiste Wissen besitzt, um aktiv Neues für das Gesamtprojekt zu entwickeln, dies aber verhindert wird, wenn seine Zeit nur zum Aushelfen an anderer Stelle verbraucht wird.121122 Zudem wird auch, in Abbildung 2 zu sehen, gezeigt, was passiert wenn sich alles nach einer Person bzw. Ressource richtet und alles von dieser abhängig ist. Bereits ab 80% Auslastung einer Ressource, in diesem Fall eines Mitarbeiters, steigt die Wartezeit auf über 100% an und da Brent immer bei 100% Auslastung ist, kommen die verschiedensten Teilpro­ jekte an denen Brent arbeitet, da diese weiter hinten in der Wertschöpfungskette stehen und auch das Gesamtprojekt, insgesamt nicht weiter.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2 Auslastung einer Ressource im Verhältnis zur Wartezeit123

Jedes Mal wenn Bill von seinem Mentor in die Fertigungshalle mitgenommen wird, erklärt dieser ihm ein neues Konzept. Im Buch werden diese als die drei Wege bezeichnet. Der Weg steht dabei wohl als Metapher für das Ziel der kontinuierlichen Bereitstellung und Auslieferung von Software. Am Anfang des Buches ist das Phoenix-Projekt noch weit hinter dem Zeitplan der 90 Tage. Nachdem Bill es aber schafft, die drei Prinzipien umzusetzen, wird mehrmals am Tag oder so oft wie nötig ein neuer Source Code und ein neues Update bereitgestellt.

Der erste Weg ist der des Ablaufes:

Dabei muss zu jeder Zeit Verständnis darüber herrschen, wie sich Arbeit durch das System bewegt und dass Änderungen zufällige Auswirkungen haben können, die zu ungeplanter Ar­beit führen können. Es soll immer versucht werden, den Durchfluss durch das System zu be­schleunigen bzw. zu erhöhen, aber es sollten keine Fehler stromabwärts geleitet werden.123 124

Der zweite Weg ist der des Feedbacks:

Dabei sollen stets die Bedürfnisse von internen wie externen Kunden berücksichtigt werden. Die Feedbackschleife sollte dabei möglichst kurz sein.125

Der dritte Weg ist der des kontinuierlichen Lernens:

Im Unternehmen sollten Experimente gefördert werden. Es sollte aus Fehlern gelernt werden dürfen.126

3 CI/CD-Pipeline

Nachdem im vorherigen Kapitel bei der Entstehungsgeschichte der DevOps-Entwicklungs- kultur auf die verschiedensten Vorgehensmodelle bei der Softwareentwicklung genauer ein­gegangen wurde, werden nun in diesem Kapitel die Tools, die beim Software-Entwicklungs­prozess benötigt werden, beschrieben. Zunächst wird der allgemeine Software-Lebenszyklus erläutert, bevor im Detail auf die drei verschiedenen Automatisierungsstufen der CI/CD-Pipe- line, Continuous Integration, Continuous Delivery und Continuous Deployment eingegangen wird.

3.1 Software-Lebenszyklus

Neben dem reinen Schreiben des Source Codes, gibt es bei der Softwareentwicklung noch einige weitere Phasen, die der Source Code durchlaufen muss, um letztendlich auf dem Pro­duktivsystem aufgespielt zu werden. Produktivsystem kann dabei eine Webseite, App oder im Embedded-Bereich z.B. die „Electronic Control Unit (ECU)“, zu Deutsch das „Steuerge- ecu

(Elec- rät“ eines Auto oder ein Mikrocontroller, auf den der Source Code aufgespielt wird, sein. Die tronic con­einzelnen Phasen müssen dabei im Laufe des Lebenszyklus einer Software immer wieder y°'t) durchlaufen werden. Der genannte Vorgang stellt einen „iterativen Prozess“ dar. Dies ist je­des Mal der Fall, wenn eine Änderung am Source Code vorgenommen wird oder ein neuer Source Code hinzugefügt wird. Hierbei muss unterschieden werden, dass wir bei der Betrach­tung nicht vom ganzen Software-Lebenszyklus, sondern nur von einem Teilbereich sprechen.

Der gesamte Software-Lebenszyklus ist dabei etwas komplexer und umfasst noch weitere Phasen, die, je nachdem welches Vorgehensmodell dabei verwendet wird, entweder ein­malig in einer bestimmten Reihenfolge durchlaufen werden, wie z.B. beim Wasserfall oder V-Modell, oder mehrere Zyklen und Wiederholungen ablaufen, wie es bei Serum oder Kan­ban der Fall ist.127128 Die Grundidee für den Software-Lebenszyklus entstammt bereits den 1960er Jahren, damals für große Unternehmen entwickelt, um komplexe Geschäftssysteme zu verwalten, die eine Menge an Datenverarbeitung und Analyse erfordern.129 Meistens ist der Software-Lebenszyklus in sechs Phasen geteilt, wie in Abbildung 3 dargestellt. Es gibt mittlerweile aber die verschiedensten, teilweise in zehn Phasen unterteilte Modelle.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3 Software-Lebenszyklus130 In der ersten Phase der Planung werden die Anforderungen, die das spätere Produkt bes­ser gesagt die Software erfüllen soll, definiert. Die zweite Phase des Designs beinhaltet die Erstellung eines Grob- oder Feinentwurfs auf Basis der ersten Phase. Dabei wird die Archi­tektur der Software festgelegt und mögliche Schnittstellen und Komponenten bestimmt. Es wird eine Roadmap, ein Übersichtsplan, über das Projekt erstellt. Die Entwicklung findet in der dritten Phase statt, in der der Source Code programmiert wird. Die Programmierspra­che ist dabei projektabhängig. In dieser Phase findet die wesentliche Umsetzung statt. In der vierten Phase wird der Source Code der verschiedenen Entwickler zusammengebaut, in die­sem Zusammenhang kann auch von „Integration“ gesprochen werden. Außerdem wird dabei getestet, ob der Source Code die Anforderung aus Phase eins erfüllt und keine Fehler ent­hält. Die fünfte Phase umfasst die Bereitstellung und Auslieferung der Software. Unter der sechsten Phase wird die Wartung und Pflege der Software verstanden. Diese beinhalten zum einem die Inbetriebnahme und zum anderen die Hilfe bei später auftretenden Problemen. Des Weiteren kann es Weiterentwicklung am Projekt bzw. dem Source Code geben. Im Nachfol­genden wird auf die drei Phasen der dritten Phase der Entwicklung und Programmierung bis zur fünften Phase der Bereitstellung und Auslieferung eingegangen. Diese Phasen des Software-Lebenszyklus sind dabei unabhängig von der Art des Vorgehensmodells, die ver­wendet wird, und werden, wie anfangs geschrieben, bei jeder Änderung des Source Codes wieder komplett durchlaufen.131132

[...]


1 Diese Masterarbeit wurde mit ETEXverfasst.

2 Übersetzung aus dem englischen Original Twitter Tweet vom 29.08.2019 anlässlich des Hurrikans Dorian: Tesla Owners Online: „Will you be unlocking free Supercharging and extra range for those who need to get to safety because of hurricane Dorian?“ Retweet: Elon Musk: „Yes“ (Musk, Elon / Tesla Owners Online 2019).

3 Vgl. Lamber2019.

4 Application Software (App)“, zu Deutsch „Anwendungssoftware“.

5 „Wireless Local Area Network (Wlan)“, zu Deutsch „drahtloses lokales Netzwerk“.

6 „Embedded Subscriber Identity Module (eSim)“, zu Deutsch „eingebautes Teilnehmer-Identitätsmodul“.

7 Vgl. Tesla Deutschland (Hrsg.) 2020.

8 Vgl. Lamber 2020.

9 Vgl. Lavrinc2012.

10 Vgl. Speranza, Rocco et al. 2020.

11 Vgl. Speranza 2020.

12 Vgl. Olsen 2018.

13 Vgl. Rubel 2018.

14 Vgl. Crider 2019.

15 Vgl. Melton 2018.

16 Vgl. Vance 2015, S. 18 ff.

17 Vgl. Dilk 2019.

18 Unter dem „eCall“ wird ein automatisches Notrufsystem verstanden, das bei einem Unfall eine automatische Benachrichtigung an die europäisch gültige Notrufnummer 112 abgibt.

19 Vgl. European Commission (Hrsg.) 2020.

20 Vgl. Wikipedia (Hrsg.) Asurnipal et al. 2019.

21 Unter „OEMs“ oder in der Einzahl „OEM“ zu Deutsch, „Originalausrüstungshersteller“ oder „Erstausrüster“, werden im Bereich der Automobilindustrie, zum einen Fahrzeughersteller wie z.B. VW oder Mercedes, zum anderen Erstausrüster wie z.B. Bosch oder Schaeffler verstanden.

22 Der Begriff „Customer Pain“ ist im Englischen bereits weit verbreitet und wird mittlerweile auch im Deutschen vermehrt unter dem Begriff „Kundenschmerz“ verwendet. Unter anderem wird der Begriff „Kundenschmerz“ (dabei ohne Anführungszeichen) in zwei im Springer Verlag erschienenen Büchern 2017 in „Digitale Transfor­mation von Dienstleistungen im Gesundheitswesen“ und 2020 im Buch unter dem Titel „Erfolgreich im statio­nären Einzelhandel“ benutzt.

23 Vgl. Menzel 2020.

24 Vgl. Ziesemer 2020.

25 Vgl. Forsen etal. 2018, S. 25.

26 Das „Web-Development“ zu Deutsch „Webentwicklung“, bezeichnet die Softwareentwicklung von Webanwen­dungen, Webdiensten und Webseiten.

27 Netflix hat in den letzten zwei Jahren jede Woche ein neues Update im Apple App-Store veröffentlicht. Die Top 100 im App-Store, darunter Facebook und Amazon, haben jeden neunten Tag ein neues Update veröffentlicht. (Vgl. Eficode (Hrsg.) 2020).

28 Das „System-Engineering“, zu Deutsch „Softwaretechnik“ oder „Systementwicklung“, im Nachfolgenden nur noch als „Systementwicklung“ bezeichnet, hat den Anfang in der Luft- und Raumfahrtindustrie und wird dort benötigt, wo komplexe Systeme, Zusammenhänge und sicherheitsrelevante Aspekte vorherrschen und diese Menschenleben in Gefahr bringen können. Bei der Systementwicklung müssen die vorher festgelegten Anfor­derung an die Systeme und Software zum richtigen Zeitpunkt und im ersten Versuch erfüllt werden. Es darf nichts dem Zufall überlassen werden, da meistens kein Prototyp zum vorherigen Testen vorhanden ist genauer gesagt zur Verfügung steht. (Vgl. Fraunhofer IPT /Heinz Nixdorf Institut-Universität Paderborn (Hrsg.) 2013).

29 lm Englischen wird dabei auch von „Built-In Quality“ gesprochen.

30 „Quality Gates“ und „Meilensteine“ helfen dabei im Projekt den Fortschritt sicherzustellen. „Meilensteine“ über­prüfen, ob im Projekt letztendlich alle vorher definierten Ziele erfüllt und vorhanden sind. „Quality Gates“ hinge­gen überprüfen, ob die Ziele in ausreichender Qualität erfüllt wurden. Dabei wird überprüft, ob vorher bestimmte Qualitätskriterien eingehalten wurden, bevor zum nächsten Projektschritt übergegangen werden kann.

31 Bei der Embedded-Systementwicklung muss zwischen Software auf die Hardware „flashen“, zu Deutsch „ge­speicherte Daten überschreiben“, in der „Fertigung“ und dem „Feld“ unterschieden werden. In der „Fertigung“ besteht direkter Zugriff auf die Hardware. Im „Feld“ bedeutet es, dass die Hardware bereits beim Kunden respektive in der Maschine verbaut ist, wo ein direkter Zugriff meist nicht mehr möglich ist.

32 Vgl. Wolff 2016, S. 235 ff.

33 Vgl. Debois, Humble etal. 2016, Einleitung S. XXIV f.

34 Vgl. Gerstl etal. 2019.

35 Vgl. ITK Engineering GmbH (Hrsg.) 2017.

36 Vgl. ITK Engineering GmbH (Hrsg.) 2018.

37 „Saftey“, zu Deutsch „Gefahrlosigkeit“ darunter werden Maßnahmen zur Betriebssicherheit verstanden.

38 „Security“, zu Deutsch „Schutz“ darunter wird die Eingriffs- und Angriffssicherheit verstanden.

39 Vgl. ITK Engineering GmbH (Hrsg.) 2018.

40 Vgl. DevOps Research and Assessment LLC / Google Cloud (Hrsg.) 2019.

41 Vgl. Wikipedia (Hrsg.) Pseppelfricke et al. 2020.

42 „Continuous Integration / Continuous Delivery und/oder Continuous Deployment (CI/CD)“.

43 Übersetzung aus dem englischen Originalzitat von Jez Humble: „DevOps is not a goal, but a never-ending process of continual improvement.“ (Touch4IT Team (Hrsg.) 2018).

44 Vgl. Wikipedia (Hrsg.) Bobbolous et al. 2020.

45 Vgl. Kösterke 2016.

46 Übersetzung aus dem englischen Original: „Godfather of DevOps“ (Foster 2017).

47 Vgl. Paul 2014.

48 Vgl. Debois, Humble et al. 2016, Vorwort S. XIII.

49 Vgl. IEEE (Hrsg.) Debois, Patrick 2008.

50 Vgl. Debois 2008.

51 Vgl. Debois und Shafer 2008.

52 Übersetzung des englischen Originaltitels: „10+ Deploys Per Day: Dev and Ops Cooperation at Flickr“ (Allspaw 2009).

53 Vgl. Willis 2012b.

54 Vgl. Allspaw 2009.

55 Vgl. ebd.

56 Vgl. Wikipedia (Hrsg.) VÖRBY et al. 2019.

57 Vgl. Allspaw 2009.

58 Vgl. Paul 2014.

59 Vgl. Debois, Patrick (Gründer) et al. 2009a.

60 Vgl. Paul 2014.

61 lm Januar 2010 taucht der Begriff DevOps (1 von 100 Beliebheitspunkten) erstmals bei Google Trends auf. Google Trends stellt Informationen darüber bereit, wie oft ein Begriff von Nutzern bei der Google Suchmaschine eingegeben wurde. Dabei gibt es eine Bewertungsskala von 1 bis 100 Beliebheitspunkten. Ab 2013 (4 Punkte) lässt sich dann jedoch weltweit eine stetig steigende Suchanfrage bis heute (100 Punkte im Februar 2020) erkennen. (Vgl. Google (Hrsg.) 2004-2020[a]).

62 Vgl. Dawson 2016. ~

63 Vgl. ebd.

64 Vgl. Null 2017.

65 Vgl. Dawson 2016.

66 Vgl. ebd.

67 Vgl. Debois, Patrick (Gründer) et al. 2009a.

68 Vgl. Debois 2008.

69 Vgl. Wikipedia (Hrsg.) Kanbanconsult et al. 2020.

70 Quelle: Wasserfallmodell CC BY-SA 3.0 (Hoadley etal. 2013), V-Modell CC BY-SA 3.0 (Pätzold etal. 2010).

71 Vgl. Wikipedia (Hrsg.) Sebastian.Dietrich etal. 2019.

72 Vgl. Wikipedia (Hrsg.) Mdjango et al. 2020.

73 Vgl. Brandt-Pooketal. 2015, S. 24 ff.

74 Vgl. Fowler 2013b.

75 Vgl. Wikipedia (Hrsg.) Kanbanconsult et al. 2020.

76 Vgl. Beck, Kent etal. 2001.

77 Vgl. Wikipedia (Hrsg.) Kanbanconsult et al. 2020.

78 Vgl. Google (Hrsg.) 2004-2020(b).

79 Vgl. CollabNet (Hrsg.) 2019.

80 Vgl. Debois 2008.

81 Vgl. Debois 2008.

82 Vgl. Debois, Patrick (Gründer) et al. 2009b.

83 Vgl. Debois, Humble etal. 2016, S. XV.

84 Vgl. Behretal. 2013, S. 358.

85 Vgl. Steven 2018.

86 Vgl. Debois, Humble etal. 2016, Vorwort S. XI ff.

87 Vgl. Willis 2012b.

88 Vgl. Willis 2012a.

89 Vgl. Willis 2010.

90 Übersetzung des englischen Originaltitels: „Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation“ (Farley etal. 2010).

91 Vgl. Humble etal. 2014.

92 Vgl. Ries 2011.

93 Vgl. Behr etal. 2013.

94 Vgl. Debois, Humble etal. 2016, Vorwort S. XII f.

95 Vgl. Forsen etal. 2018.

96 Vgl. Kim 2019, S. 360.

97 Vgl. Behretal. 2013, S. 18 ff.

98 Vgl. ebd., S. 148 ff.

99 "Vgl. Behr etal. 2013, S. 74 ff.

100 Vgl. ebd., S. 98 ff.

101 Vgl. ebd., S. 96 ff.

102 Vgl. ebd., S. 56 ff.

103 Vgl. ebd., S. 170 ff.

104 Vgl. Hardiker 2018.

105 Vgl. Behr etal. 2013, S. 84 ff.

106 Ohno 1988.

107 Vgl. Behr etal. 2013, S. 88 ff.

108 Vgl. Wikipedia (Hrsg.) Sebastian.Dietrich et al. 2020.

109 Vgl. Behr etal. 2013, S. 294 ff.

110 Vgl. Wikipedia (Hrsg.) Sebastian.Dietrich et al. 2020.

111 Vgl. Behr etal. 2013, S. 96 ff.

112 Vgl. Wikipedia (Hrsg.) Sebastian.Dietrich et al. 2020.

113 Vgl. Howard 2016.

114 Vgl. Behr etal. 2013, S. 89 ff.

115 Vgl. Behretal. 2013, S. 74 ff.

116 Vgl. ebd., S. 89 ff.

117 Vgl. ebd., S. 161 ff.

118 Vgl. ebd., S. 161 ff.

119 Vgl. ebd., S. 225 ff.

120 Vgl. Goldratt 1984.

121 Vgl. Behretal. 2013, S. 50 ff.

122 Vgl. ebd., S. 116 ff.

123 Quelle: Auslastung einer Ressource im Verhältnis zur Wartezeit (Behr et al. 2013, S. 364).

124 Vgl. ebd., S. 356.

125 Vgl. ebd., S. 356 f.

126 Vgl. ebd., S. 357 ff.

127 Vgl. Farley etal. 2010, S. 106 f.

128 Vgl. Broy etal. 2013, S. 88 ff.

129 Vgl. Elliott 2004.

130 Quelle: Eigene Darstellung.

131 Vgl. Wikipedia (Hrsg.) Mdd et al. 2020.

132 Vgl. Broy etal. 2013, S. 61.

Fin de l'extrait de 143 pages

Résumé des informations

Titre
Kundenschmerzorientiertes Kompetenzmodell für Verbesserungen der Systementwicklung unter Verwendung von DevOps-Methoden
Université
University of Applied Sciences Kaiserslautern in Zweibrücken
Note
1,0
Auteur
Année
2020
Pages
143
N° de catalogue
V939310
ISBN (ebook)
9783346273475
ISBN (Livre)
9783346273482
Langue
allemand
Mots clés
DevOps, CI/CD, Embedded, Systems Engineering, DevOps Return on Investment (ROI) Modell, DevOps Kostenmodell, DevOps Kompetenzmodell, DevOps Capability Model
Citation du texte
Stephan Weihrauch (Auteur), 2020, Kundenschmerzorientiertes Kompetenzmodell für Verbesserungen der Systementwicklung unter Verwendung von DevOps-Methoden, Munich, GRIN Verlag, https://www.grin.com/document/939310

Commentaires

  • Pas encore de commentaires.
Lire l'ebook
Titre: Kundenschmerzorientiertes Kompetenzmodell für Verbesserungen der Systementwicklung unter Verwendung von DevOps-Methoden



Télécharger textes

Votre devoir / mémoire:

- Publication en tant qu'eBook et livre
- Honoraires élevés sur les ventes
- Pour vous complètement gratuit - avec ISBN
- Cela dure que 5 minutes
- Chaque œuvre trouve des lecteurs

Devenir un auteur