Wie wird architektonisches Design in einer agilen Umgebung durchgeführt?

Ich habe Grundsätze für den agilen Architekten gelesen , in denen die nächsten Grundsätze definiert wurden:

Prinzip 1 Die Teams, die das System codieren, entwerfen das System.
Prinzip Nr. 2 Erstellen Sie die einfachste Architektur, die möglicherweise funktionieren kann.
Prinzip 3 Wenn Sie Zweifel haben, codieren Sie es aus.
Prinzip # 4 Sie bauen es, sie testen es.
Prinzip Nr. 5 Je größer das System, desto länger die Landebahn.
Prinzip Nr. 6 Die Systemarchitektur ist eine Rollenzusammenarbeit.
Prinzip Nr. 7: Es gibt kein Innovationsmonopol.

Das Papier besagt, dass der größte Teil des Architekturentwurfs während der Codierungsphase erfolgt und nur der Systementwurf davor. Das ist gut.

Wie wird das Systemdesign durchgeführt? Verwenden Sie UML? Oder ein Dokument, das Schnittstellen und Hauptblöcke definiert? Vielleicht etwas anderes?

Haftungsausschluss: Ich bin Architekt in einem agilen Umfeld, aber wie Helmuth von Moltke der Ältere sagt: "Kein Schlachtplan überlebt den Kontakt mit dem Feind". Mit anderen Worten, Praktiken bedeuten, dass der genaue Buchstabe der Richtlinien nicht immer befolgt werden kann.

Die meisten der oben angesprochenen Punkte werden nach bestem Wissen des Teams befolgt. Allerdings Prinzip 1 (Die Teams , die Code das System das System Design) ist wirklich schwer zu folgen , wenn das Team von zehn (oder Hunderte) besteht aus Entwicklern auf verschiedenen Kontinenten und Zeitzonen aufgeteilt . Dies hat nichts mit den Fähigkeiten oder Einstellungen der Entwickler zu tun, sondern vielmehr mit dem logistischen Problem, dass alle vorhanden sind, um die Anforderungen der Kunden zu erfassen und vorhandene komplexe Systeme zu verstehen.

Wie wird das Systemdesign durchgeführt? Verwenden Sie UML? Oder ein Dokument, das Schnittstellen und Hauptblöcke definiert? Vielleicht etwas anderes?

Oft identifiziert der Architekt die Hauptkomponenten, definiert dann die Schnittstellen zwischen ihnen (einschließlich nicht funktionierender Anforderungen wie Sicherheit, Geschwindigkeit und Zuverlässigkeit) und delegiert das interne Design der Komponenten an einzelne Teams . Dies ist ein guter Kompromiss zwischen dem Ermöglichen, dass die Teams ihre eigenen Komponenten entwerfen, ohne dass jeder alles über das System wissen muss.

Jede Organisation hat ihre eigenen Standards für architektonische Entwürfe und diese variieren manchmal von Projekt zu Projekt innerhalb der Organisation. Dieses Design wurde erstellt, bevor das Team mit dem Codieren beginnt oder so früh wie möglich und enthält normalerweise (und ist keine vollständige Liste):

1. Erweiterte Definition von Anforderungen und Umfang. Dazu gehören Use Cases oder User Stories, die die übergeordneten Geschäftsanforderungen konkretisieren. Ich persönlich verwende gerne RFC 2119 für nicht-funktionale Anforderungen. Das Design basiert darauf und geht auf diese zurück. Obwohl es möglicherweise nicht zur allgemeinen Definition von Design passt, sind diese oft genauso wichtig.
2. Eine Übersicht bestehend aus einem übergeordneten Netzwerk- oder Komponentendiagramm und einer Textseite. Dies ist für ein sehr breites Publikum, vom oberen Management bis hin zu Entwicklern und Qualitätssicherern. Aufgrund des breiten Publikums wird hier nur selten UML oder eine definierte Notation verwendet.
3. Details für einzelne Komponenten, wobei häufig die Schnittstellen oder APIs zwischen ihnen im Mittelpunkt stehen, wie oben erwähnt. Schnittstellen können als Methodensignaturen in der Zielsprache mit Vor- und Nachbedingungsdetails angegeben werden. Komponenten können Netzwerkdiagramme enthalten, z. B. das Layout von VMs in einer Cloud oder einem Rechenzentrum und deren Netzwerkanordnungen. Relationale Datenbanken haben normalerweise Entity-Relationship-Diagramme.
4. Eine Liste der architektonischen Risiken und ihrer Minderung, falls bekannt. Diese zeigen, wie auch die Anforderungen, Entwurfsentscheidungen und Kompromisse.

Kurz gesagt, das Design eines Systems in einem agilen Prozess entspricht genau dem eines traditionellen Wasserfallprozesses. In agilen Umgebungen wird jedoch weniger Design im Voraus erstellt und mehr an Komponententeams delegiert . Entscheidend ist, wie tief man anfänglich gehen muss, welche Entscheidungen aufgeschoben werden müssen und wann Entscheidungen getroffen werden müssen. Entscheidungen, die sich auf mehrere Entwicklungsteams auswirken, sollten früher getroffen werden, insbesondere in Bezug auf Skalierbarkeit und Sicherheit. Entscheidungen wie das Hinzufügen zusätzlicher Sprachen zu einem bereits internationalisierten Produkt können bis spät in die Nacht verschoben werden.

Nachdem der erste Entwurf erstellt wurde, arbeitet der Architekt mit jedem der Teams und überprüft deren Entwürfe. Wenn für eine Arbeitseinheit zusätzliche Konstruktions- oder Konstruktionsänderungen erforderlich sind (z. B. ein Scrum-Sprint), ist der Architekt bestrebt, sie zum Zeitpunkt des Beginns dieser Arbeitseinheit verfügbar zu haben. Der Architekt ist auch dafür verantwortlich, Änderungen an betroffene Teams oder Stakeholder weiterzuleiten.

Haftungsausschluss: Ich bin kein agiler Coach / Architekt - das habe ich in agilen Projekten gesehen, an denen ich gearbeitet habe und ich denke, dass es gut funktioniert.

Ich denke nicht, dass es durch Agile definiert ist, wie Sie Architektur machen - Agile konzentriert sich auf Entwicklungsmethoden und -praktiken. UML hingegen ist nur eine Sprache, um Ihre Architektur zu kommunizieren, die nicht agil ist (Sie verwenden sie, wenn sie zu Ihrem Projekt und Ihrem Team passt).

Eines der Prinzipien der Architektur, das wirklich gilt, ist, die Entscheidung zum letztmöglichen Zeitpunkt zu treffen. Das bedeutet, dass es in Ordnung ist, wenn Sie zu Beginn des Projekts nicht alle Entscheidungen getroffen haben, zumal Sie zu diesem Zeitpunkt über die wenigsten Informationen verfügen. Im Laufe der Zeit können Sie Entscheidungen treffen, die die Architektur "weiterentwickeln". Ja, das sieht vielleicht nach einer Überarbeitung aus, aber das liegt auch daran, dass Sie neue Erkenntnisse über die Umgebung, die Anforderungen, was möglich ist, was nicht usw. haben.

Die Hauptsache, die Sie vermeiden möchten, ist Architekturfäule, bei der der Code keiner bestimmten Architektur entspricht und nur ein Wirrwarr ist. Der Hauptunterschied zum Entwickeln einer Architektur besteht darin, dass Sie in letzterem Fall in regelmäßigen Abständen bewusste Entscheidungen treffen und diese mit eindeutigen Gründen dokumentieren und anschließend nachverfolgen, um sicherzustellen, dass Ihr Code diesen Anforderungen entspricht.

Bei der testgetriebenen Entwicklung erstellen Sie Testcode, der Ihre Module isoliert testet (= so unabhängig wie möglich von anderen Modulen).

Um die Erstellung von Testcode zu vereinfachen, führen Sie Schnittstellen zu anderen Modulen ein, die leicht verspottet werden können.

Auf diese Weise erhalten Sie als Nebeneffekt automatisch eine Architektur, bei der die Kopplung zwischen den Modulen so gering wie möglich ist.

Meiner Meinung nach ist tdd auch architektonische Arbeit.