In einer agilen Umgebung, die für die Softwarearchitektur verantwortlich ist


19

Wer ist in einem agilen Team dafür verantwortlich, übergeordnete Architektur- und Designentscheidungen zu treffen, die sich auf das gesamte System auswirken und nicht nur auf die Arbeit im aktuellen Sprint?

Vielleicht Product Owner, Scrum Master, das Scrum Team oder jemand anderes?

Bildbeschreibung hier eingeben


10
Das ... macht keinen Sinn ...
Telastyn

3
Das Vorhandensein von Product- und Sprint-Backlogs hat keinen Einfluss darauf, wer für die Softwarearchitektur verantwortlich ist. Eine bessere Frage könnte sein: Wer ist in einer agilen Umgebung für die Softwarearchitektur verantwortlich?
ChargerIIC

Ich habe versucht, die Frage zu aktualisieren, damit sie zumindest verstanden werden kann. Nicht 100% sicher, ob ich es richtig verstanden habe ...
FrustratedWithFormsDesigner

Antworten:


24

"Die Softwarearchitektur wird vom gesamten Team durchgeführt. Diese Praxis beseitigt nicht die Notwendigkeit eines Softwarearchitekten, sondern bedeutet lediglich, dass der Architekt mit einer breiteren und wahrscheinlich erfahreneren Perspektive zur Diskussion beiträgt, zu der jedoch alle Mitglieder des Teams beitragen die Architektur der Software. "


5
Pure Agile tendiert dazu, traditionelle Top-Down-Rollen wie "Projektmanager" und "Systemarchitekt" abzulehnen, anstatt diese Rollen umzugestalten und ihre traditionellen Verantwortlichkeiten auf das gesamte Team zu verteilen.
Jonathan Eunice

6
@ JonathanEunice: Wie kann das praktisch machbar sein? Nicht jeder Entwickler ist auch ein guter Architekt.
Giorgio

2
@ JonathanEunice: Also die Frage, die DWD gestellt hat, macht doch Sinn. Ich verstehe nicht alle Abstimmungen.
Giorgio

3
@ DaveHillier: Vielleicht sind diese Projekte groß, aber die Architektur ist einfach genug: Die Entwickler müssen die Teile nur in einem recht einfachen, sich wiederholenden Schema ausfüllen (z. B. Hunderte ähnlicher Formulare in einer webbasierten Anwendung mit einem vorhandenen Domänenmodell schreiben). . Andererseits weiß ich, dass Sie, sobald eine Anwendung ausreichend komplex ist, jemanden brauchen, der sich um die Architektur kümmert (oft im Voraus), andernfalls wird es zu einem großen Durcheinander kommen.
Giorgio

6
"Big Upfront Design" ist das typische agile Argument, um den Schluss zu ziehen, dass es überhaupt kein Upfront Design geben sollte: Es wird extrem vorgegangen, das Extreme als falsch erwiesen und das Gegenteil als Lösung vorgeschlagen. Ich bin damit einverstanden, dass ein großes Vorab-Design selten ein guter Ansatz ist, aber einige grundlegende architektonische Entscheidungen müssen im Voraus getroffen werden, um eine umfangreiche Umgestaltung oder eine spätere vollständige Umschreibung zu vermeiden. Dies ist keine Aktivität, die improvisiert werden kann, "wenn man das Gefühl hat, dass der Code zu unübersichtlich wird und umgestaltet werden muss". Erfahrung hilft, eine gute Balance zu finden.
Giorgio

19

Architekten natürlich, aber vielleicht nicht die traditionellen Architekten.

Ich meine damit nicht den leitenden Chirurgen, der alles nachdenkt und dann die Affen das ganze Tippen überlässt. Ich meine einen erfahrenen Programmierer, der die Kosten-Nutzen-Kompromisse von schwer umkehrbaren Entscheidungen versteht und Teams berät, was zu tun ist.

Effektive Architekten sind schwer zu finden, aber es kann eine fantastische Position sein, und deshalb haben Sie wahrscheinlich mindestens einen erfahrenen, nachdenklichen Programmierer, der es gut kann. Eine solche Person muss

  • Treffen Sie natürlich gute Architekturentscheidungen, aber auch
  • Wissen, wie man effektiv Ratschläge gibt, damit sich andere wohl fühlen, und auch
  • Delegieren Sie langsam Architekturentscheidungen an die Teams

Dieser letzte Punkt bringt viele Menschen um den Verstand. Wenn gut gemeinte Agilisten Dinge wie "Das Team besitzt die Architektur" sagen, haben sie das "Recht", aber ich finde den Ratschlag in seiner Anwendung fast völlig bedeutungslos. Wenn Sie sich darauf verlassen würden, dass Teams die Verantwortung für ihre eigene Architektur übernehmen, würden Sie die Frage nicht gleich stellen, oder ?! Ich gehe daher davon aus, dass Sie die Frage stellen, weil es auch diesbezüglich Bedenken gibt

  • Niemand wird Verantwortung übernehmen und wir werden eine schlechte Architektur haben, oder
  • Die falschen Leute werden Verantwortung übernehmen und wir werden eine schlechte Architektur haben, oder
  • Wer Verantwortung übernimmt, wird zum Sündenbock, und das wollen Sie vermeiden

Wenn Sie jemanden brauchen , der Verantwortung übernimmt, geben Sie sie jedem, der sie annehmen möchte. Ernst. Wenigstens diese Person kümmert es. Geben Sie dieser Person die Ressourcen, die sie für die Arbeit benötigt, und helfen Sie ihnen, wenn sie sie benötigen. Es ist wahrscheinlich egal, wie kompetent die Person ist, denn wenn es sie interessiert, werden sie versuchen zu lernen, was sie lernen müssen. Natürlich braucht eine solche Person Unterstützung in Form von guten Büchern und einer Gemeinschaft von Gleichaltrigen und Mentoren, die sie um Hilfe und Rat bitten kann.

Wenn Sie befürchten, dass die falsche Person die Verantwortung übernimmt, dann hoffe ich, dass Sie wissen, wer "die richtige Person" ist, und kämpfen werden, um sie als Architekten einzusetzen. Ein Buch wie The New Strategic Selling wird Ihnen helfen, die Verkaufstechniken zu erlernen, die dies ermöglichen.

Wenn Sie nur einen Sündenbock brauchen, stupsen Sie ruhig andere an, um die Verantwortung für die Karriere zu übernehmen, die Sie am liebsten zerstören oder beeinträchtigen möchten. Sei wenigstens ehrlich.

Wenn sie zu ihrer Arbeit als Architekt zurückkehren, können sie sich ihre Arbeit als Führungsposition und nicht als bloße Entscheidungsposition vorstellen. Wenn sie nicht mindestens die routinemäßigsten Entscheidungen an die Teams delegieren, werden sie zu einem Engpass und verlangsamen die gesamte Organisation . Das Hinzufügen von mehr Architekten an der Spitze beschleunigt dies nicht. Bessere Architekturentscheidungen von Grund auf kultivieren. Die Technik der Delegationstafel hilft Ihrem Architekten, im Laufe der Zeit mehr und mehr Entscheidungen an die Teams zu delegieren, da diese Teams Vertrauen gewinnen, indem sie Kompetenz beweisen.

Ich stelle mir einen großartigen Architekten als jemanden vor, der mir hilft, meine Systeme besser zu entwerfen, der mich geduldig berät, wenn ich danach frage, und der mich gelegentlich davon abhält, eine sehr schlechte Entscheidung zu treffen. Ein solcher Architekt verhält sich im wahrsten Sinne des Wortes wie ein Führer: jemand, dem andere freiwillig folgen .

Ich weiß, dass das viel war.

Verweise

Miller, The New Strategic Selling . Dieses Buch enthält ein Modell, anhand dessen Sie nachvollziehen können, warum Sie einen bestimmten Verkauf nicht abgeschlossen haben. Ich finde das von unschätzbarem Wert, wenn ich verstehe, warum Mitarbeiter nicht das offensichtlich Wunderbare tun, was ich vorschlage.

Weinberg wird technischer Vorreiter . Dieses Buch hat mir geholfen zu lernen, wie man den Nicht-Architekten-Teil der effektiven Architektenarbeit erledigt.

Appelo, Delegation Boards und Delegation Poker . Unterschätzen Sie nicht, wie hart die Delegation ist und wie sehr wir daran leiden. Lernen Sie es effektiver und komfortabler zu machen.


1
Ist dein 'h' Schlüssel zwielichtig? ;)
Dave Hillier

3
Nein, Dave. Ich habe Spivak-Pronomen (geschlechtsneutral) verwendet.
JB Rainsberger

Aufgrund der Fragen, die @ DaveHillier stellt, neige ich dazu, "s / he" zu verwenden. Klischees)
Marjan Venema


1
@Walfrat Nach längerer Überlegung habe ich mich entschlossen, diesen Punkt noch etwas näher zu erläutern. Eine Person, die sich darum kümmert, wird versuchen zu lernen, was sie lernen muss, benötigt aber wahrscheinlich Unterstützung, wie beispielsweise einen Mentor.
JB Rainsberger

10

Die besten Architekturen , Anforderungen und Designs ergeben sich aus sich selbst organisierenden Teams

- Agiles Manifest

Das Team organisiert sich also selbst, um Architekturentscheidungen nach eigenem Ermessen zu treffen. Es gibt keine feste Regel, sie kann vom Konsens über einen "Rat" der höchsten Mitglieder bis hin zur Ernennung eines bestimmten Mitglieds zur Architekturbehörde und der Entscheidung des Architekten, ob es ein Mitglied mit einer solchen Berufsbezeichnung gibt, reichen. .


9
Ich mag Agile, aber das ist eine große Schwäche - die Architektur wird oft vernachlässigt oder zusammengeschustert.
user949300

1
@ user949300 "Agile" sagt wie im Manifest sehr wenig über Architektur aus. Auf welche genauen Methoden ziehen Sie diese Schlussfolgerung? XP würde Sie ermutigen, gnadenlos umzugestalten. Sind Sie für BUFD?
Dave Hillier

"XP würde Sie dazu ermutigen, gnadenlos umzugestalten": Bis Sie mehr Zeit mit dem Umgestalten verbringen als mit dem Schreiben von neuem Code. Ich denke, die beste Lösung besteht darin, ein Gleichgewicht zwischen grundlegenden Architekturentscheidungen zu finden, die Sie nach einer sorgfältigen Analyse treffen, und kleineren Entwurfsentscheidungen, die Sie auf dem Weg zum Refactoring treffen.
Giorgio

@ user949300 Das liegt daran, dass sich das Team nicht selbst organisiert. Wenn dies der Fall wäre, würden sie häufig mit dem Rest des Teams kommunizieren, wenn eine Architekturentscheidung getroffen und diese Ideen ordnungsgemäß dokumentiert / argumentiert / diskutiert werden müssen.
Rudolf Olah

3

Ich bin der Meinung, dass die Antwort auf die Frage, wer für die Entscheidungen über Architektur und Design auf hoher Ebene verantwortlich ist, von der Größe und Anzahl der Teams abhängt.

Für ein oder zwei Teams mit 3-7 in jedem Team kann das selbstorganisierte Team die Führung der Senior-Mitglieder übernehmen.

Bei 3 oder mehr Teams führt die erhöhte Komplexität dazu, dass ein Architekturteam benötigt wird, das sieht, ob die verschiedenen Subteams Arbeiten ausführen, die mit den anderen Teams zusammenarbeiten. Meiner Erfahrung nach ist dieser Punkt erreicht, wenn ungefähr 8 Teams oder ungefähr 50 Personen anwesend sind.


1

Das Team von Scaled Agile Framework (SAFe) hat auf seiner Website einige hervorragende Ressourcen bereitgestellt.

Es hilft Ihnen im Wesentlichen dabei, die Agilität in Ihrem gesamten Unternehmen zu skalieren und über eine einzelne Version hinaus in die Portfolio- und Programmplanung einzusteigen. Die Dokumentation enthält Vorschläge, wie Sie Ihre Unternehmens- und Systemarchitekten in den Prozess einbeziehen können, um Architekturepos in den Release-Zug einzuführen.

Bearbeiten Sie zur besseren Übersicht, um die Frage direkter zu beantworten:

In einer skalierten, agilen Umgebung gibt es mehrere Eigentümerstufen für die Architektur. Das agile Implementierungsteam wird Eigentümer der aufstrebenden Low-Level-Architektur sein, indem es nach Bedarf umgestaltet, um die Implementierung der Rückstände fortzusetzen. Übergeordnete Architekturentscheidungen (unterstützte Betriebssysteme, Browser, Plattformen, Bibliotheken) liegen in der Verantwortung Ihrer System- und Unternehmensarchitekten. Sie erstellen die Business Cases für den Zeitpunkt, zu dem diese Änderungen vorgenommen werden müssen, und empfehlen, diese Architekturänderungen dem Release-Zug für die Implementierungsteams hinzuzufügen.

In Bezug auf die Architekturentscheidungen auf hoher Ebene, die über den Sprint hinausgehen, müssen Sie diese normalerweise auf einer Ebene über dem Team treffen. Diese Fachleute haben traditionell bereits eine Architektenrolle innerhalb des Unternehmens.


2
Wie wird die Frage beantwortet, wer für die Entscheidungen über Architektur und Design auf höchster Ebene verantwortlich ist?
gnat

1
Danke Mücke, ich habe versucht, es zu bearbeiten, um klarer zu machen, was meine Absicht war, auf die Frage zu antworten. Ich machte ein paar Sprünge in meinem Kopf, vergaß aber, sie aufzuschreiben :)
Jay S

1

Ich denke, die meisten anderen Antworten denken darüber aus der Perspektive nach, in einem Projekt zu sein.

Wenn dies die einzige Architekturstufe in einer Organisation ist, ist das Ergebnis offen gesagt ein Chaos. Ich habe dieses Chaos aus erster Hand miterlebt, leider passiert es.

Laut TOGAF erstellt die Abteilung für Unternehmensarchitektur Pläne auf hoher Ebene für und mit dem Unternehmen, um die IT-Umgebung zu erstellen und zu ersetzen. Der Enterprise Architect hat Architekturprinzipien definiert und diese auf den höchsten Ebenen der Organisation abgemeldet. Er hilft bei der Erstellung der Architektur auf hoher Ebene und der Anforderungen für jedes Projekt. Jedes Projekt wird initiiert, um einen architektonischen Baustein in dieser übergeordneten Architektur bereitzustellen.

Auf Projektebene erstellt der Solution Architect die Projektarchitektur (möglicherweise iterativ) und erhält eine Abmeldung vom Enterprise Architect.

Konzentrieren Sie sich jetzt auf ein agiles Projekt. Ein agiles Projekt hat Anforderungen. Sie haben nicht die Form eines massiven "Anforderungsdokuments", sondern sind episch und Geschichten. Diese Epen müssen noch geplant werden. Sie schicken kein Entwicklerteam auf ein paar Sprints ins Unbekannte. Sie wissen auf hohem Niveau, was das System tun muss, mit welchen anderen Systemen es interagieren muss und welche Hardware- / Betriebssystem- / Spracheinschränkungen das Unternehmen hat. Dies führt und schränkt die architektonischen Entscheidungen ein, die dem Solution Architect offenstehen. Wenn Sie sich beispielsweise für .NET und SQL Server engagieren, müssen Sie einen extremen Wert festlegenÜberzeugende Gründe für die Implementierung einer auf Magento basierenden E-Commerce-Site mit PHP und MySQL sind die Kosten für die Unterstützung von zwei Datenbanken, zwei Sprachen, zwei Webservern usw. Alternativ könnte ein Projekt eine völlig andere Bibliothek oder ein anderes Erscheinungsbild und verwenden fühlen und dies könnte Auswirkungen auf alle anderen Bordprojekte haben. Es ist wichtig, die Aufsicht eines Enterprise Architect zu haben, um zu verhindern, dass diese Art von "architektonischer Verschuldung" auftritt.


0

Hängt vom Organisationsdesign der Organisation ab und davon, ob sich das Produkt in einem Portfolio befindet. Größere, rollenorientierte Organisationen können leitende Architekten mit der Leitung dieser Art von Aktivitäten beauftragen.

Im Allgemeinen wird ein leitender Architekt Entwurfsentscheidungen erleichtern und leiten, da sie sich nicht nur auf einen Produktstau auswirken, sondern auch auf mehrere Produkte in einem Produktportfolio.

Kleinere, agile Unternehmen können sich auf Entwickler verlassen, die Systemexperten sind, die das Entwicklerteam bei der Ausrichtung auf das Architekturdesign unterstützen.

Letztendlich müssen architektonische Entscheidungen vom Lieferteam, das an dem Produkt arbeitet, vereinbart werden. Erfahrene Architekten und technische Leiter konzentrieren sich eher darauf, die Diskussion darüber zu erleichtern, wie das Design aussehen soll, als das Design zu diktieren.


0

Ich denke, die meisten Antworten heben bereits hervor, dass das Team nicht eine einzige Person diese Entscheidungen treffen sollte.

Was sie nicht berühren, ist ein anderes Agiles Prinzip:

Einfachheit - die Kunst, den Umfang der nicht geleisteten Arbeit zu maximieren - ist von entscheidender Bedeutung.

Das Nachdenken über übergeordnete Architekturen und Entwurfsentscheidungen wird oft nicht einfach getroffen, was möglicherweise zu einem erheblichen Aufwand und einer unnötigen Komplexität führen kann, die das Erweitern erschwert.

Denken Sie 'Gartenarbeit' über 'Architektur' nach - schaffen Sie eine Kultur des lebendigen, wachsenden Designs

Während Ihrer aktuellen Iteration sollten Sie Architektur- und Designentscheidungen für Ihre aktuellen Anforderungen treffen. Statt in eine Zukunft zu blicken, die niemals werden könnte, konzentrieren Sie sich nur auf das, was Sie jetzt brauchen. Wahrscheinlich ist YAGNI jetzt eine gut durchdachte Architektur. Lassen Sie das Team Stück für Stück damit umgehen.

Andere liest:

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.