Immer schön beweglich bleiben (16 Sep 2013)

Gerade komme ich von einem Vortrag zurück, den JUGS und andrena gemeinsam organisiert haben: "Agilität und Softwarearchitektur - Freunde oder Feinde".

Im allgemeinen meide ich Diskussionen über agile Softwareentwicklung - aus der leidvollen Erfahrung heraus, daß man sich dabei entweder in Allgemeinplätzen verliert oder aber längst bekannte Standpunkte zum zweiundvierzigsten Male austauscht. Bei diesem Vortrag habe ich eine Ausnahme gemacht, weil ich mir Hilfe erhoffte, um meine Position als Softwarearchitekt in einem neuen Scrum-Team zu bestimmen.

Braucht ein Scrum-Team überhaupt einen ausgewiesenen Architekten? Wenn ja, von welchen schlechten Angewohnheiten sollte er dringend ablassen? Welche Aufgaben sollte der Architekt im Team übernehmen? Und wie entsteht dieses wolkige Etwas namens Architektur, wenn man immer nur die nächsten ein oder zwei Monate detailliert plant?

Der Vortrag von Johannes Stammel lieferte dazu Hinweise. Leider aber driftete die folgende Diskussion wie befürchtet ab - zum Beispiel ging es um die Frage, wie man einem Kunden ein agiles Projekt "verkauft". Das ist ein veritables Problem in der Praxis, hat aber mit der Architektenrolle eher wenig zu tun.

Aber der Vortrag lieferte Verweise auf weitere Quellen und die Inspiration, sich mit ihnen zu beschäftigen:

Erst jüngst hatte ich außerdem den Artikel Der agile Architekt von Nils Arndt gelesen, dessen Schlussfolgerungen für die Architektenrolle mir durchaus sympathisch waren:

  • So wie es in einem Scrum-Team einen Spezialisten fürs UI geben kann, so darf es auch jemanden geben, der sich mit Vorliebe oder besonderer Begabung mit Architekturthemen beschäftigt.
  • Die Architektur wird von Sprint zu Sprint weiterentwickelt. Entscheidungen werden im "letzten Moment" gefällt - also dann, wenn man die Anforderungen gut kennt und man sich etwas vergeben würde, wenn man keine Entscheidung fällt.
  • Abstraktionswut hat in agilen Projekten keinen Platz.
  • Der Architekt faßt selbst in der Entwicklung mit an.
  • Architekturdokumentation gibt es weiterhin, fällt aber schmaler aus als bei anderen Ansätzen. (Nils Arndt schlägt arc42 als Schablone für die Architekturdokumentation vor, was ich aber noch mit Skepsis sehe.)
  • Architektur wird schon kommuniziert, während an ihr gearbeitet wird, um Feedback einzuholen.
  • Der Architekt trägt Architekturwissen ins Team (Schulungen, Entwurfsbesprechungen, Dokumentation), denn: "Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams."
  • Der Architekt ist Kommunikator - er vermittelt zwischen Entwicklern, product owner, Management.
  • Bei divergierenden Auffassungen im Team ist es Aufgabe des Architekten, eine Entscheidung herbeizuführen.

Mal sehen, was mein Team dazu sagen wird...



When asked for a TWiki account, use your own or the default TWikiGuest account.



to top

You are here: Blog > DefinePrivatePublic20130916AgilerArchitekt

r1.3 - 17 Sep 2013 - 06:56 - ClausBrod to top

Blog
This site
RSS

  2017: 12 - 11 - 10
  2016: 10 - 7 - 3
  2015: 11 - 10 - 9 - 4 - 1
  2014: 5
  2013: 9 - 8 - 7 - 6 - 5
  2012: 2 - 10
  2011: 1 - 8 - 9 - 10 - 12
  2010: 11 - 10 - 9 - 4
  2009: 11 - 9 - 8 - 7 -
     6 - 5 - 4 - 3
  2008: 5 - 4 - 3 - 1
  2007: 12 - 8 - 7 - 6 -
     5 - 4 - 3 - 1
  2006: 4 - 3 - 2 - 1
  2005: 12 - 6 - 5 - 4
  2004: 12 - 11 - 10
  C++
  CoCreate Modeling
  COM & .NET
  Java
  Mac
  Lisp
  OpenSource
  Scripting
  Windows
  Stuff
Changes
Index
Search
Maintenance
Impressum
Datenschutzerklärung
Home



Jump:

Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback