#define private public - Claus Brod on stuff (16 Sep 2013)

topic end
<!--
   * Set TOPICTITLE = #define private public - Claus Brod on stuff (16 Sep 2013)
-->

<style type="text/css">
pre {background-color:#ffeecc;}
</style>

%STARTINCLUDE%
<a name="16"></a>

---+++ [[DefinePrivatePublic20130916AgilerArchitekt][Immer schön beweglich bleiben]] (16 Sep 2013)

<summary>
Gerade komme ich von einem Vortrag zurück, den <a href="http://jugs.org/2013-09-16.html">JUGS</a>
und <a href="http://www.andrena.de/veranstaltungen/agilitaet-und-softwarearchitektur-freunde-oder-feinde-0">andrena</a>
gemeinsam organisiert haben: "Agilität und Softwarearchitektur - Freunde oder Feinde".
</summary>

Im allgemeinen meide ich Diskussionen über agile Softwareentwicklung - zu oft
verliert man sich dabei in Allgemeinplätzen oder tauscht 
längst bekannte Standpunkte zum zweiundvierzigsten Male aus. 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 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 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 in der Tat ein veritables Problem, hat aber mit der Architektenrolle 
eher wenig zu tun.

Aber der Vortrag inspirierte mich auch, weitere Quellen zu bemühen:
   * http://www.slideshare.net/sybit/softwarearchitektur-in-agilen-teams
   * [[http://vimeo.com/19394558][Interview mit Stefan Roock: Spannungsfeld Architektur und Agilität]]
   * http://www.agilearchitect.org/agile/role.htm

Erst jüngst hatte ich außerdem den Artikel [[http://entwickler.de/artikel/Der-agile-Architekt][Der agile Architekt]]
von [[http://m.nils-arndt.de][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.
   * Der Architekt trägt durch Schulungen, Entwurfsbesprechungen, aktive Mitarbeit und Dokumentation
     Architekturwissen ins Team.
     Denn: "Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams."
     (Womit dann auch das Team für die Architektur verantwortlich ist und nicht nur der
     Architekt.)
   * Die Architektur wird von Sprint zu Sprint gemeinsam 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 [[http://www.arc42.de/template/template.html][arc42]] als Schablone
     für die Architekturdokumentation vor, was ich aber noch mit Skepsis sehe.)
   * 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...

PS: Ein Kollege verwies mich als Kommentar gleich auf Martin Fowlers [[http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf][Who Needs An Architect?]].

---

%STOPINCLUDE%

%COMMENT{type="below" nonotify="on"}%

---
to top
End of topic
Skip to action links | Back to top
You are here: Blog > DefinePrivatePublic20130916AgilerArchitekt

r1.4 - 17 Sep 2013 - 08:35 - ClausBrod to top
Blog