Agile Minds

Scrum und die Rolle des Architekten

Die Grundidee von Scrum ist leicht zu vermitteln. Die wichtigsten Rituale lassen sich schnell erlernen. Ein Team kann schnell agil werden. Doch wie skaliert Scrum? Gibt es bei all dem iterativen und inkrementellen Herangehen noch Platz für langfristige Pläne und Ziele und eben auch für die Architektur? Das iterative Entwickeln hilft schnell auf Änderungen von außen reagieren zu können. Es spart Zeit bei der Planung, die, wenn sie bis ins letzte Detail passieren soll, sehr lange dauert; ganz abgesehen davon, dass Fehler bei der Planung leider keine Ausnahme sind. Der Berliner Flughafen lässt grüßen! Dennoch soll der inkrementelle Ansatz natürlich nachhaltig sein und Schritt für Schritt auf eine Vision zusteuern und diese auch erreichen. Ist die Gesamtaufgabe nur gross genug, sind mehrere Scrum Teams nötig, um sie zu bewältigen, und diese müssen natürlich Ecksteine geplant und abgestimmt haben, sonst werden die Bausteine nicht zueinander passen. Andererseits haben Scrum Teams klare Einzelziele vor Augen, die schon für sich alleine genommen einen Mehrwert für den Endbenutzer darstellen. Ansonsten würden die User Stories ihren Namen nicht verdienen. Ist nun okay, wenn jedes Scrum Team einzeln und für sich entscheidet, wie sie User Stories realisiert und ist es völlig egal, wie die anderen Teams, die an demselben gemeinsamen Projekt arbeiten, ihre Aufgaben realisieren? Das Gesamtprodukt sollte doch auch technisch stimmig sein und nicht nur was z.B. user experience und user workflow angeht, oder? Zumindest widerspricht es jeder Softwareentwicklerethik und Gepflogenheit, wenn verschiedene Teile einer Gesamtapplikation, z.B. verschiedene Bibliotheken benutzen, um dasselbe Problem zu lösen. Natürlich würde man erwarten, dass es zu einer Absprache kommt, um einheitliche Lösungen zu benutzen. Doch wer initiiert solche Absprachen? Der Architekt? Und wann und auf welchem Wege passiert dies? Ein Scrum Team entscheidet schliesslich selbst, wie eine Anforderung umgesetzt wird. Muss es ein Konzept oder Design von einem Architekten abnehmen lassen? Muss ein Architekt oder gar ein ganzes Architekturteam zunächst zumindest einen Grobplan erstellen?

Wenn es einen Grund in der Vergangenheit gab, weshalb es heute agile Methoden wie Scrum gibt, dann doch der, dass sich ein System eben nicht komplett am Reißbrett durchdenken lässt. Die Metaphern des Engineerings und der Architektur und des Designs sind schlicht nicht gut, da die Analogien nur selten auf die Softwareentwicklung zutreffen. Interessanterweise sind die Metaphern auch nicht mal nötig, denn die Randbedingungen sind anders: Natürlich muss beim Bau eines großen Gebäudes aus Beton zunächst ein guter Plan existieren, denn bei einem Bauwerk tauscht man eben nicht einfach das Fundament nochmal aus nachdem bereits das 100. Stockwerk entstanden ist. Bei Software ist dies wesentlich einfacher und sollte nicht per se ausgeschlossen werden. Gerade bei Softwareentwicklung hat man eben den Vorteil einen guten Plan, den man zunächst hatte, weiterentwickeln zu können, während das Gesamtsystem entsteht. Die ursprünglichen Blaupausen für das Design sind nützlich und zum Einstieg hilfreich. Letztlich kennt jeder Entwickler aber aus Erfahrung den Effekt, dass er während des Programmierens neue Erkenntnisse hat, die schließlich mit einem kleinen Umbau einer API enden können. Das Resultat ist im Allgemeinen besser als vorher – sonst hätte die Änderung wohl keinen Einzug gehalten – auch wenn dies so zunächst nicht geplant war und deshalb auch nicht in den ursprünglichen Designdokumenten vorgesehen war. Letztlich ist das tatsächliche Design und die Architektur das, was als Sourcecode realisiert ist. Design und Architektur entwickeln sich stetig weiter! Und das ist gut so. Die persönlichen Skills eines jeden Entwicklers, der auf gutes Design achtet, sind wichtig, um ein gutes Gesamtsystem zu entwickeln. Jeder Entwickler sollte sich stets weiterentwickeln und sein Handwerkszeug sehr gut beherrschen. Und jeder Entwickler sollte motiviert sein so zu denken und zu handeln. Jeder Entwickler ist ein Architekt! So entstehen gute Designs durch Zusammenarbeit erfahrener Entwickler, die gemeinsam die Entwicklung des Produktes vorantreiben. Gute Ideen und Erkenntnisse werden ganz im agilen Sinne durch Kommunikation ausgetauscht. Alle Entwickler nehmen Teil am Gesamtdesign. Die Entscheidungen der Entwickler basieren auf tagesaktueller Erfahrung. Kein Elfenbeinturm-Architekt kann dies leisten. Gutes Design und Architektur kommen nicht von oben. Wie der sprichwörtliche Trampelpfad, der zeigt, wo Personen langlaufen möchten, und es auch tun, zeigt sich der optimale Codepfad durch die andauernde Verwendung von alleine. Und dieser Pfad ist eine gute Lösung und sie überlebt, weil sie gut ist.

Kategorien:Agile Minds