Das ist eine erfundene Geschichte, aber mit durchaus realen Problemen. Es geht darum, wie ein Unternehmen durch sein führendes Management versucht, sich selbst zu retten. Das Projekt „Phönix“ ist ein Produkt dieses Unternehmens, das nicht mehr auf die herkömmliche Weise existieren kann. Die Wettbewerber bringen ihre neuen Funktionen schnell heraus, während das aktuelle Team sehr lange braucht, um Releases zu veröffentlichen. Nach solchen Releases kommt es bei vielen Nutzern oft zu Ausfällen, bedingt durch schlechte Produktqualität und unzureichende Integrationstests.
Die Manager des Unternehmens verstehen das Problem und versuchen auf verschiedene Weise, die Situation zu verbessern, aber anfangs gelingt ihnen nichts und alles wird nur noch schlimmer. Es gibt eine große Abhängigkeit von einigen leitenden Ingenieuren, deren Abwesenheit die Wartung der Projekte sowie die Veröffentlichung neuer Versionen erschwert. Ein weiteres großes Problem sind technische Schulden, die mit der Zeit nur wachsen.
Im Laufe der Zeit beginnen die Teams, neue Ansätze für Entwicklung, insbesondere für Tests und Deployment, einzuführen, was zu positiven Ergebnissen führt. Jetzt haben sie keine technischen Schulden mehr und können Releases sogar täglich durchführen. Um weitere Spoiler zu vermeiden, halte ich mich hier mit einer sehr kurzen Zusammenfassung zurück und konzentriere mich auf einige andere Kernaussagen des Buches.
Die reine Einführung von DevOps-Technologien mit vollwertigen CI/CD-Lösungen ist sehr gut. Aber nur die Einführung von Tools bringt dem Projekt oft nicht viel Nutzen. Ja, es ermöglicht eine schnelle Entwicklung, Tests und Auslieferung des Codes an die Nutzer. Doch damit das Produkt gefragt ist und der gesamte Entwicklungszyklus möglichst effizient läuft, müssen die Kommunikationswege und die Prozessverbesserungen zwischen den Abteilungen grundlegend geändert werden. Dieses Problem wird im Buch immer wieder unterschwellig (manchmal auch explizit) thematisiert. Der Aufbau der DevOps-Prozesse wird zusammen mit Motivation, Bürokratie und anderen Feinheiten diskutiert. Einige dieser Feinheiten sind äußerst unerwünscht und schädlich. Im gesamten Buch lässt sich beobachten, wie sich mit den aufgebauten Entwicklungs- und Auslieferungsprozessen auch die Zusammenarbeit zwischen den Teams verändert.
Insgesamt ist es ein interessantes und leicht lesbares Buch. Es ist nützlich für diejenigen, die sich ein wenig von der Arbeit ablenken möchten, aber nicht zu weit vom IT-Thema entfernen wollen. Außerdem wäre es für viele Manager und Führungskräfte hilfreich, um zu verstehen, welche Probleme bei falschem Vorgehen und schlechter Prozessorganisation auftreten können und wie man all das ändern kann und sollte.
