In diesem Video erkläre ich, worum es beim SAFe for DevOps Training geht. Im Gegensatz zu klassischen Schulungen ist dieses Training ein praxisnaher Workshop, in dem echte Teams an ihren eigenen Value Streams arbeiten und mit einem konkreten, priorisierten Aktionsplan nach Hause gehen.
Was genau ist TDD oder Test-Driven Development, und warum schwören so viele erfahrene Entwickler darauf? In diesem kurzen Video erkläre ich, woher TDD kommt, wie der Red-Green-Refactor-Zyklus funktioniert, und ich zeige an einem einfachen Calculator-Beispiel in C#, wie der Prozess in der Praxis aussieht. TDD ist nicht nur eine Entwicklungstechnik, sondern ein Mindset, das prägt, wie man an jede Zeile Code herangeht.
Was wird DevOps 2021 wirklich bewegen? Nach einem Jahr, das fast jede Organisation gezwungen hat, Digital Delivery zu beschleunigen, sind die Trends für 2021 weniger glänzende neue Tools, sondern Disziplin: DevOps im grossen Stil zum Funktionieren bringen, Security nach links verschieben, Continuous Delivery ernst nehmen, weiter in die Cloud gehen — und die ersten Signale von AIOps beobachten.
Waterfall und Agile sind nicht einfach zwei Geschmacksrichtungen von Projektmanagement. Es sind zwei grundlegend verschiedene Arten, mit Unsicherheit umzugehen. Wer das versteht, versteht den Rest fast von selbst.
Waterfall: Linear und sequenziell # Waterfall ist ein linearer, sequenzieller Lebenszyklus. Das Team geht erst in die nächste Phase, wenn die vorherige erfolgreich abgeschlossen ist. Zuerst Anforderungen, dann Design, dann Implementierung, dann Test, dann Deployment, dann Betrieb. Jede Phase hat eine Übergabe und eine Freigabe. Jede Phase erzeugt ein Dokument, das die nächste Phase konsumiert.
Der dritte Weg, DevOps einzuführen, besteht darin, eine Vertrauenskultur zu schaffen, die Experimente und Risikobereitschaft trägt. Das ist der Third Way im Three-Ways-Framework von Gene Kim — und er bringt das Team auf eine Lernkurve, die steil genug ist, um die Konkurrenz hinter sich zu lassen.
Der zweite Weg, DevOps einzuführen, ist ein starker Feedback-Fluss in die Gegenrichtung des Value Flows — vom Kunden und aus der Produktion zurück ins Business und ins Development. Das ist der Second Way im Three-Ways-Framework von Gene Kim, und er verhindert, dass der First Way im Blindflug optimiert.
Der erste Weg, DevOps einzuführen, besteht darin, den Value Flow von Development über Operations bis zum Kunden zu optimieren. Das ist der First Way im Three-Ways-Framework von Gene Kim — und genau dort sollte jede Transformation starten.
Continuous Deployment ist der finale, aggressivste Schritt in der CI/CD-Progression. CI beweist, dass der Code baut und die Unit Tests grün sind. Continuous Delivery beweist, dass das Artefakt in einer produktionsähnlichen Umgebung funktioniert. Continuous Deployment entfernt den letzten manuellen Checkpoint: Wenn alle Tests auf dem Weg grün sind, geht die Änderung direkt in Produktion. Kein “Deploy”-Button, kein Freitagnachmittag-Release-Fenster, kein Mensch im Loop für den letzten Schritt.
Continuous Integration endet mit einem getesteten Artefakt. Das klingt gut, aber ein grüner Build heisst nicht, dass die Software in einer realistischen Umgebung tatsächlich funktioniert. Unit Tests laufen isoliert. Integrationstests laufen gegen Mocks. Solange man die Software nicht irgendwo hinstellt, das aussieht wie Produktion, und sie unter echten Bedingungen ausführt, hat man eigentlich noch nichts bewiesen. Continuous Delivery ist der Schritt, der diese Lücke schliesst.
In der traditionellen Softwareentwicklung wird Software von allen Entwicklern in einem grossen einzigen Integrationsschritt zusammengeführt und getestet, der in der Regel Wochen oder gar Monate dauert. Da dies nur alle paar Monate passiert, ist dieser Schritt sehr zeitaufwändig.
In der klassischen Softwareentwicklung war Integration ein einziges, schmerzhaftes Ereignis. Jeder Entwickler arbeitete wochen- oder monatelang isoliert, und am Ende wurde alles in einem grossen Big Bang zusammengeführt. Dieser Integrationsschritt dauerte Wochen, manchmal Monate. Konflikte häuften sich an, Bugs versteckten sich in den Nahtstellen zwischen Modulen, und niemand konnte mit Sicherheit sagen, ob das System tatsächlich funktionierte. Continuous Integration wurde erfunden, um genau diesen Schmerz aufzulösen.
Ein Wertstrom ist der Weg, den Wert von der ersten Idee bis in die Produktion zurücklegt. Er ist die Summe aller Schritte, Übergaben und Wartezeiten dazwischen. In diesem Video zeige ich ein einfaches Vorgehen in sieben Schritten: einen Wertstrom identifizieren, ehrlich messen, ein Zielbild entwerfen und dann Schritt für Schritt dorthin arbeiten. Die Zahlen im Beispiel sind bewusst vereinfacht, damit die Methode im Vordergrund steht und nicht ein einzelnes Ergebnis.
