Kapitel 6. Zukünftige Arbeit aufteilen
Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com
Teil II des Buches befasst sich damit, wie der gesamte Software-Lebenszyklus von Continuous Deployment beeinflusst wird. Dieses Kapitel beginnt am Anfang dieses Lebenszyklus und konzentriert sich auf das, was vor der Programmierarbeit passiert: die Erstellung und Pflege eines Product Backlogs, das mit Continuous Deployment zusammenarbeitet und nicht dagegen.
Der Product Backlog sollte die Quelle der Wahrheit für alle anstehenden Arbeiten an einem Produkt sein, einschließlich der gewünschten Funktionen, Erweiterungen und Korrekturen. Ein gut strukturierter Backlog erleichtert nicht nur häufige Einsätze und ermöglicht aussagekräftige und frühzeitige Tests in der Produktion, sondern nutzt auch die Geschwindigkeit und Granularität der kontinuierlichen Bereitstellung, um häufige Experimente zu unterstützen.
Die Aufteilung der Arbeit in einem Product Backlog ist wichtig, wenn es um Initiativen (Epos) geht, die zu lang sind, um in eine einzige Iteration zu passen. Die Unterteilung von Epen in kleinere, gut durchdachte Teile ermöglicht eine bessere Sichtbarkeit des Fortschritts und eine schrittweise Umsetzung. In diesem Kapitel gehe ich auf zwei verschiedene Möglichkeiten ein, Epos zu unterteilen, wobei ich besonders diejenige hervorhebe, die in Kombination mit kontinuierlicher Bereitstellung effektiver ist. Dann stelle ...
Get Kontinuierliche Bereitstellung now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
