Architektur [Technik]

5 Übungsfragen mit Lösung und Erklärung.

☝️ SingleWas bedeutet "emergente Architektur" im agilen Kontext?
❌Auf Architekturentscheidungen wird grundsätzlich verzichtet
❌Jeder Developer entscheidet Architekturfragen für sich allein
✅Die Architektur entwickelt sich mit dem wachsenden Verständnis weiter, statt vollständig im Voraus festgelegt zu werden
❌Die Architektur wird von einem zentralen Gremium vorgegeben
Emergent heißt nicht planlos. Entscheidungen mit hoher Änderungskosten werden weiterhin bewusst getroffen – nur eben zum spätestmöglichen verantwortbaren Zeitpunkt.
☝️ SingleWas besagt das Prinzip "Last Responsible Moment"?
❌Der Product Owner entscheidet erst im Sprint Review
✅Eine Entscheidung wird so spät wie verantwortbar getroffen, solange das Aufschieben mehr Information als Risiko bringt
❌Entscheidungen werden grundsätzlich so lange wie möglich vermieden
❌Architekturentscheidungen fallen ausschließlich im ersten Sprint
Die Betonung liegt auf "responsible": Wird der Punkt überschritten, an dem die Entscheidung noch günstig umsetzbar ist, wird aus Flexibilität Zögern.
☝️ SingleWelchen Zusammenhang beschreibt Conways Gesetz?
❌Jedes System enthält mindestens einen unentdeckten Fehler
✅Systeme spiegeln die Kommunikationsstrukturen der Organisationen wider, die sie entwerfen
❌Die Dauer eines Projekts verdoppelt sich mit jeder Verzögerung
❌Die Komplexität eines Systems wächst quadratisch mit der Teamgröße
Die praktische Umkehrung heißt "Inverse Conway Maneuver": Wer eine bestimmte Systemarchitektur will, schneidet zuerst die Teams entsprechend zu.
☝️ SingleWas unterscheidet ein Feature-Team von einem Komponenten-Team?
❌Ein Komponenten-Team hat keinen Product Owner
✅Ein Feature-Team liefert durchgängig nutzbare Funktionalität über alle technischen Schichten, ein Komponenten-Team verantwortet nur einen technischen Ausschnitt
❌Ein Feature-Team arbeitet agil, ein Komponenten-Team klassisch
❌Ein Feature-Team ist größer als ein Komponenten-Team
Komponenten-Teams erzeugen zwangsläufig Abhängigkeiten: Kein einzelnes Team kann allein ein Increment liefern, weshalb Planung und Integration zum Engpass werden.
✍️ OffenEin Stakeholder fordert, vor dem ersten Sprint die vollständige Architektur festzulegen. Beziehen Sie begründet Stellung.
Musterantwort: Der Wunsch ist nachvollziehbar, weil Architekturfehler teuer sind und spät sichtbar werden. Vollständig vorab festzulegen löst das Problem jedoch nicht, sondern verschiebt es: Die Entscheidungen fallen zu dem Zeitpunkt, an dem das Wissen über das Produkt am geringsten ist. In der komplexen Produktentwicklung entsteht ein erheblicher Teil der Anforderungen erst durch die Nutzung erster Ergebnisse, weshalb eine vorab vollständige Architektur häufig auf Annahmen beruht, die sich als falsch erweisen – und dann aufwendig zurückgebaut werden müssen. Angemessen ist stattdessen eine bewusste Abstufung. Entscheidungen mit hohen Änderungskosten und weitreichenden Folgen, etwa grundlegende Technologieauswahl, Datenhaltung oder Sicherheitsarchitektur, werden früh und sorgfältig getroffen, weil ihr späterer Wechsel unverhältnismäßig teuer ist. Entscheidungen mit geringen Änderungskosten werden dagegen zum spätestmöglichen verantwortbaren Zeitpunkt getroffen, wenn mehr Information vorliegt. Für die frühen Sprints bedeutet das, die Architektur an echter Funktionalität zu erproben statt auf dem Papier: Ein durchgängiger, schmaler Anwendungsfall über alle Schichten belegt die Tragfähigkeit besser als jedes Dokument. Wichtig ist außerdem, Architekturentscheidungen samt Begründung und Alternativen festzuhalten, damit sie später überprüfbar bleiben. Gegenüber dem Stakeholder würde ich das Anliegen anerkennen, nämlich Risiko zu begrenzen, und aufzeigen, dass frühe Erprobung dieses Risiko wirksamer senkt als frühe Festlegung.
← Alle ThemenIm Quiz üben