Friday, March 4, 2011

Emerging Architecture in Scrum Projekten

Immer wieder werde ich gefragt wie denn nu Architektur in Scrum Projekten entsteht.
Eigentlich ist das gar nicht so unterschiedlich, wie in klassischen Projekten:
  • Gute Architekten im Team sind bestimmt ein guter Ausgangspunkt
  • Das Architekturdesign wird wesentlich von den nicht funktionalen (ich sage lieber Qualitätsanforderungen) getrieben
  • Die Architekturpattern und Designpattern, die wir in unserem Produkt verwenden, sollten immer über Beispiele implementiert und über Tests nachgewiesen werden.
  • So bauen wir nach und nach eine Architektur auf, in dem wir unsere Überlegungen nach und nach durch lauffähigen Code implementieren und verfizieren.
So weit so gut, aber wie mache ich das nu konkret in einem Scrum Projekt" werde ich häufig gefragt. Nun, anhand einer Frageliste von Studenten von mir, möchte ich einen Vorschlag dazu unterbreiten.

Frage: Woher werden die Anforderungen an die Architektur abgeleitet (Vision)?
Antwort: Das kann eine Quelle sein, aber nicht die einzige. Grundsätzlich sind die Qualitätsanforderungen (oder Nicht Funktionale Anforderungen) die Treiber der Architektur. Nun gibt es nur ganz wenige Qualitätsanforderungen, die unabhängig von einer Funktionalität sind. Meistens sind sie im Zusammenhang einer Funktionalität wichtig und wesentliche. Beispiel:

  • Performance: nicht jede Funktionalität muss performant sein. Ein Admin-Dialog z.B. kann durchaus auch einmal langsam sein. Dafür muss etwas der Bestelldialog in einer Anwendung schnell gehen. Dann muss die Qualitätsanforderung bezüglich Performance in der User Story des Bestelldialoges als Akzeptanzkriterium formuliert werden und mit Performancetests getestet werden.
Gilt so eine Qualitätsanforderungen für mehrere User Stories identisch, dann macht es Sinn diese Qualitätsanforderung auf ein Kärtchen schreiben und auf dem Scrum Board in einer Sektion "Qualitätsanforderungen " hinzuhängen.
  • Sicherheit: Wenn alle Zugriffe in einem System unter einer bestimmten Authorisierung/Authentifizierung zu laufen haben, dann ist dies eine unabhängige Qualitätsanforderungen. Diese würde ich dann auf ein Kärtchen schreiben und auf dem Scrum Board in einer Sektion "Qualitätsanforderungen " hinhängen.
Typisch gibt es nur sehr wenige Qualitätsanforderungen, die in dieser Form "unabhängig" von Funktionalität - also von Einträgen im Backlog - sind.
In einem Backlog werden dann die User Stories markiert (Vorschlag), bei denen eine unabhängige Qualitätsanforderung gilt. Eventuell hat jedes Qualitätsanforderungen (die in der Sektion der Qualitätsanforderungen im Backlog hängen) eine eigene Farbe. Die User Story wird mit dieser Farbmarkierung markiert, wenn diese mit einer Qualitätsanforderungen in Verbindung gebracht werden soll(Vorschlag eines simplen Tracking). Ein weiterer Vorschlag (in einem elektronischen Backlog, z.B. Excel)  wäre pro unabhängiger Qualitätsanforderung eine Spalte zu etablieren und in den Zeilen ein Kreus bei den User Stories einzutragen, bei denen diese Q-Anfordeung zutrifft. Der nächste Schritt wäre dann die Akzeptanzkriterien zu diesen Qualitätsanforderungen zu schreiben für diese User Story...usw.

Frage: Wie und wann werden Architektur und Design in einem agilen Projekt (Scrum) durchgeführt?
Antwort: Mit der Antwort der obigen Frage kann dies nun ganz einfach durchgeführt werden. Um Architektur zu bauen, sind die Qualitätsanforderungen die wichtigen Treiber. Wenn die obigen Überlegungen im Scrum Board abgebildet wurden, nun, dann kann ich meine User Stories neu priorisieren unter dem Aspekt, welche Qualitätsanforderung(en) will ich im nächsten Sprint als Software umsetzen. "Zufälligerweise" verwende ich dazu meine User Story als Beispielimplementierung (Spike) dazu. Intelligener Weise sehe ich über die kommenden User Stories und die darin geforderten Qualitätsanforderungen (und Akzeptanzkriterien) und denke mit meinem Team über Architektur und Design Pattern nach.
Das führt dann dazu, dass am Anfang eines Greenfield- oder Migrationsprojekts (noch keine Architektur da oder die vorhandene ist zu überarbeiten) weniger Businessvalue, dafür aber mehr "Architektur-Value" erzeugt wird.

 
Emerging Architecture in einem Scrum Projekt
  
Frage: Wie wird die Architektur dokumentiert?
Antwort: Am Besten wie bisher: Ein Architekturdokument schreiben. Wer verbietet es denn, dass in Scrum ein Dokument geschrieben werden darf. Das wichtige: Das Dokument sollte so geschrieben werden, dass es dem Team (und eventuell Chicken, oder in einem grösseren Projektvorhaben mit mehrere Scrum Teams auch den anderen Teams - besser ein gemeinsames Dokument mit den anderen Teams...) einen Nutzen bringt.
Das sind typisch Dokumentation der genommenen Arhcitekturprinzipien und Beispiele einer Umsetzung typisch über Klassen, Componenten, Sequenz, logische System Structure und Deplyoment Diagramme (wäre ein Vorschlag von mir) Ich würde kein Software-Design dokumentieren, nur die Architektur.

Frage: Wo wird die Architektur dokumentiert?
Antwort: Siehe oben, Architekturdokument und siehe Code, die implementierten Tests für die Akzeptanzkriterien zu den Qualitätsanforderungen der betroffenen User Stories.

Frage: Ist die Erstellung der Architektur ein Punkt im Product-Backlog?
Antwort: Nein, siehe oben, Architektur entsteht während die User Stories in Software umgesetzt werden. Dies unter Erfüllung der geforderten den Qualitätsanforderungen, gemessen über die Einhaltung der als automatisierte Test geschriebenen Akzeptanzkriterien zu den Qualitätsanforderungen.
In den Done Kriterien steht aber eventuell "das Architekturdokument ist auf dem aktuellen Stand".

Frage: Welche Artefakte bezüglich Architektur müssen erstellt werden?
Antwort: Siehe oben.

OOP Keynote now on YouTube

I put my OOP Keynote about impediments of organizations to implement agility into YouTube in 2 parts under http://www.youtube.com/watch?v=z972yW2lYSo (Part I) and http://www.youtube.com/watch?v=OGnEOHqbrXc (Part II).