Wie steuern Sie Architektur in einem agilen Projekt?

Question

Wie stellen Sie sicher, dass das Projekt mit "guten" Designentscheidungen gebaut wird, die eine flexible Softwarearchitektur ermöglichen?

Wie balancieren Sie zwischen dem vollständigen Überlassen der Architektur an die Teams auf der einen Seite und der Kontrolle der gesamten Architektur durch einige wenige Personen auf der anderen Seite?

Haben Sie eine "Architekturgruppe", ein "Architekturlabel" oder ähnliches?

Answer 1

Ein Voraussetzung für Agile Ansätze ist eine Architektur, die Sie bereits kennen, wie man sie verwendet.

Wenn die Architektur nicht klar definiert und vollständig verstanden ist, können Sie keinen wirklich agilen Ansatz verfolgen.

Sie müssen einige technische Spikes haben, die zeigen, wie die Architektur funktioniert und wie die verschiedenen Teile zusammenpassen werden. Diese können als vorläufige Sprints durchgeführt werden, führen jedoch nicht direkt zu einer Veröffentlichung für die Benutzer. Sie sind ein Sonderfall, der erforderlich ist, um zu einer Architektur zu gelangen, die Sie nutzen können.

Nach dem Abschluss dieser Anstrengung, um die Architektur zu verstehen, können Sie dann mit der Durchführung von Sprints beginnen, die direkt zu Veröffentlichungen für die Benutzer führen.

Answer 2

Ich könnte erklären, wie ich es machen würde, aber dieser sagt es besser als ich könnte.

Answer 3

Ich würde auch empfehlen, Fowlers Dokument Ist Design Dead zu lesen, soweit ich seine Argumente verstehe, wenn Sie alle agilen Praktiken als Ganzes betrachten, dann gewinnen Sie die Freiheit, große Änderungen vorzunehmen und so eine Architektur weiterzuentwickeln.

Refactoring funktioniert am effektivsten mit kontinuierlicher Iteration, Testing wird durch TDD und kontinuierliche Integration verbessert... Ich könnte weitermachen. 'Architekturen' entwickeln sich nur begrenzt, wenn Sie nicht in der Lage sind, die großen Änderungen vorzunehmen, die zur Korrektur von 'Fehlern' erforderlich sind.

Zusätzlich denke ich, dass Sie einen Architekten als Stakeholder im Projekt haben, sie tragen Benutzerstories bei, die wiederum an den Architekten zurückgeliefert werden.

Dies ist auch eine gute Möglichkeit, Pair Programming mit dem Architekten als Teil des Paares zu nutzen. In diesem Kontext ist der Architekt nicht so sehr eine dedizierte Person, sondern mehr eine Rolle, die ein Mitglied des Entwicklungsteams während des Pair-Programmings einnimmt.

Ich glaube, dass XP die Rolle des Architekten (und der Architektur) nicht schmälert, sondern die Verantwortung auf alle Teammitglieder für die Lieferung über die Lebensdauer des Projekts verteilt.

[bearbeiten]

Gemäß anderer Kommentare keine Angst vor einigen planerischen Vorüberlegungen, Iteration Null ist eine gute Zeit, um zu versuchen, einen Plan zu skizzieren, seien Sie einfach nicht zu strikt, ihn innerhalb eines bestimmten Zeitrahmens zu liefern.

Answer 4

In meiner Erfahrung ist der beste Weg, dies zu tun, erfahrene Entwickler / Architekten einzusetzen, die an den Projekten arbeiten, die die Architekturvision tagtäglich vorantreiben.

Ich würde vorschlagen, dass es Aufgabe des Entwicklungsleiters im Projekt ist, die Architektur zu kontrollieren und sicherzustellen, dass alle neuen Arbeiten damit übereinstimmen.

Answer 5

Ich gehe damit um, indem ich zu Beginn etwas Planung mache - im Allgemeinen habe ich bereits einige Erfahrungen mit einer ähnlichen Anwendung, die mir dabei helfen. Wenn nicht, werde ich etwas Erkundung im Bereich betreiben, um eine Vorstellung zu bekommen. Sobald eine grundlegende Architektur festgelegt ist, werde ich mit der Entwicklung beginnen und dabei meine priorisierten Stories berücksichtigen. Anschließend werde ich während des Prozesses Refactoring durchführen, um Mängel oder Fehler in der Architektur zu beheben.