Verwendung von Aufzeichnungen über architektonische Entscheidungen zur Optimierung der technischen Entscheidungsfindung für ein Softwareentwicklungsprojekt - AWS Präskriptive Leitlinien

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verwendung von Aufzeichnungen über architektonische Entscheidungen zur Optimierung der technischen Entscheidungsfindung für ein Softwareentwicklungsprojekt

Darius Kunce und Dominik Goby, Amazon Web Services (AWS)

März 2022 (Dokumentverlauf)

In diesem Leitfaden wird der ADR-Prozess (Architectural Decision Records) für Softwareentwicklungsprojekte vorgestellt. ADRs unterstützen die Teamausrichtung, dokumentieren strategische Leitlinien für ein Projekt oder Produkt und reduzieren den wiederkehrenden und zeitaufwändigen Entscheidungsaufwand.

Während der Projekt- und Produktentwicklung müssen Softwareentwicklungsteams architektonische Entscheidungen treffen, um ihre Ziele zu erreichen. Diese Entscheidungen können technischer Art sein, z. B. die Entscheidung, das CQRS-Muster (Command Query Responsibility Segregation) zu verwenden, oder prozessbezogen sein, z. B. die Entscheidung, den GitFlow-Workflow zur Verwaltung des Quellcodes zu verwenden. Diese Entscheidungen zu treffen ist ein zeitaufwändiger und schwieriger Prozess. Die Teams müssen diese Entscheidungen begründen, dokumentieren und den relevanten Stakeholdern mitteilen.

Bei architektonischen Entscheidungen treten häufig drei wichtige Anti-Muster zutage:

  • Aus Angst, die falsche Wahl zu treffen, wird überhaupt keine Entscheidung getroffen.

  • Eine Entscheidung wird ohne jegliche Begründung getroffen, und die Leute verstehen nicht, warum sie getroffen wurde. Dies führt dazu, dass dasselbe Thema mehrfach erörtert wird.

  • Die Entscheidung wird nicht in einem Archiv für architektonische Entscheidungen gespeichert, sodass die Teammitglieder vergessen oder nicht wissen, dass die Entscheidung getroffen wurde.

Es ist besonders wichtig, diese Antimuster während des Entwicklungsprozesses eines Produkts oder Projekts zu beseitigen.

Die Erfassung der Entscheidung, des Kontextes und der Überlegungen, die zu der Entscheidung geführt haben, in Form einer alternativen Streitbeilegung ermöglicht es aktuellen und zukünftigen Stakeholdern, Informationen über die getroffenen Entscheidungen und den Denkprozess hinter jeder Entscheidung zu sammeln. Dies reduziert die Zeit für die Softwareentwicklung und bietet eine bessere Dokumentation für zukünftige Teams.

Gezielte Geschäftsergebnisse

ADRs zielen auf drei Geschäftsergebnisse ab:

  • Sie bringen aktuelle und zukünftige Teammitglieder zusammen.

  • Sie legen eine strategische Ausrichtung für das Projekt oder Produkt fest.

  • Sie vermeiden Entscheidungsmuster, indem sie einen Prozess definieren, mit dem architektonische Entscheidungen ordnungsgemäß dokumentiert und kommuniziert werden.

ADRs erfassen den Kontext der Entscheidung, um zukünftige Stakeholder zu informieren. Eine Sammlung von ADRs bietet eine Übergabeerfahrung und eine Referenzdokumentation. Team- oder Projektmitglieder verwenden die ADR-Sammlung für Folgeprojekte und die Planung von Produktfeatures. Die Möglichkeit, auf ADRs zu verweisen, reduziert den Zeitaufwand für Entwicklung, Überprüfung und architektonische Entscheidungen. ADRs ermöglichen es anderen Teams auch, aus den Überlegungen anderer Projekt- und Produktentwicklungsteams zu lernen und Einblicke in diese zu gewinnen.