Im Rahmen von v-arc haben wir uns gefragt, wäre die Agile Anforderungsmanagement-Methode (agiles RE) für jene Projekte in welchen wir gerade arbeiten, geeignet. Die Antwort was sofort „Es kommt darauf an…“, also es gibt keine allgemeingültige.

Wir haben schnell festgestellt, daß es von vielen Faktoren abhängt: von der Organisation in welcher man arbeitet, vom Umfeld, von der Projektart usw.  Projektart selbst kann viele Dimensionen haben, und diese benötigen unterschiedliche Herangehensweise an die methodische Einführung des agilen RE.

In diesem Artikel, suchen wir aus unserer Sicht die geeigneten Schritte für die Einführung des agilen RE, sowie die notwendigen Rahmenbedingungen, damit die Anwendung der Methode ein Erfolg wird.

Wir wollen dabei eine Art Checkliste erstellen, welche man durchlaufen muß, und in den einzelnen Schritten die relevanten  Einflußfaktoren berücksichtigen sollte.

Was ist das Ziel?

Was ist das minimale Zielzustand, welches wir erreicht haben wenn wir meinen „wir praktizieren Agiles Anforderungsmanagement“? Was ist eigentlich unser Ziel?

Ziel ist eigentlich nicht agiles RE selbst zu praktizieren, sondern die Zielgenauigkeit der IT Lösungen zu erhöhen, wobei diese die angedachten Geschäftsziele unterstützen.

Dieses Ziel zu erfüllen, hilft die agiles RE in dem sie die Ergebnisse eines wiederholten (iterativen) Anforderungsprozesses in ein genauso wiederholbares Entwicklungsprozeß  mündet, und die Ergebnisse – die Softwareinkremente den Benutzern, Anforderen, Analytikern, und dem Team präsentiert. Durch die Präsentation der Ergebnisse, entsteht ein wertvolles Feedback, welches in die nächste Analyse-Iteration einfließt.

Somit sind wir überzeugt, daß agiles RE als „Insel-Praktika“ ohne dahinterliegender Entwicklung keinen Sinn ergibt.

Also, hier kommt eine – bestimmt unvollständige Liste der Schritte, welche zu dem erfolgreichen agilen RE in einem Projekt führen.

Check #1: „Analyse Jour Fixe etablieren“

Etabliere ein regelmäßiges Analysetermin mit Anforderern/Kunden und der Entwicklung um Slots zu haben, wo die agile Praktiken gelebt werden: Backlog – Priorisierung, Präsentation der Zwischenergebnisse, Aufwandsschätzung-Kommunikation.

In der iterativen Vorgehensweise ist es essentiell eine Kultur der immer wiederkehrenden Tätigkeiten zu etablieren. Dazu ist es sinnvoll sog. „Analyse-Serie“ zu etablieren.

Plane die „Analyse-Serie“ in 1-2 Monaten in der Zukunft, definiere  zu besprechenden Themen, damit Kunde (Anforderer-Team) die richtigen Ansprechpartner holen kann.

Definiere die Praktiken in dem Analysetermin und klare Ergebnisse:
–    Präsentation der Zwischenergebnisse geht immer auf der Grundlage der definierten Akzeptanzkriterien.
–    Aufwandsschätzung ist immer die Schätzung des Entwicklers(Teams) ohne Puffer
–    Feedback mündet nur in das Backlog

Check #2: „Analyse Backlog etablieren“

Erarbeitung des Analyse Backlogs ist einer Grundlage für den iterativen Analyseprozess.

Die Fähigkeit, die kommunizierten Anforderungen so zu „schneiden“ damit sie klein aber zugleich sinnvoll sind, ist ein Paradigmenwechsel und benötigt einen Umdenkprozeß – ähnlich dem Umstieg eines Entwicklers von einer prozeduralen auf eine objektorientierte Programmiersprache.

Ein Beispiel in Scrum ist z.B. Anspruch daß die User Stories Charakteristiken erfüllen sollen, welche unter dem Akronym „INVEST“ zusammengefaßt sind (siehe z.B. http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/)

Check #3: „Dokumentation der Analyseergebnisse – Kollaboration über die Inhalte statt Review- und Freigabeprozesse “

Ausgehend von den Punkten aus dem Agilen Manifesto:

–    Funktionierende Software mehr als umfassende Dokumentation
–    Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

ist es essentiell daß man in Projekten, in welchen sich starre Review- und Freigabeprozesse der großen Dokumente etabliert haben, versucht aufzuweichen.

Die Kultur des Einfrierens der Dokumente (Spezifikationen) muß aufgebrochen werden, und Team dazu bewogen, daß man die Dokumente jederzeit ändern kann.

Dokumentation ist da, den aktuell korrekten Stand der geplanten Entwicklung abzubilden, und als Träger für die Entwicklung bzw. QA zu dienen.

Dabei sollte man jene Dokumentationswerkzeuge auswählen, wo die Veränderung automatisch nachvollziehbar ist, und somit jegliche Diskussionen darüber auf die Seite legt.

Check #4: „Timeboxing Kultur etablieren“

Der wahre Enabler der Agilen Umsetzung ist eine Kultur des Timeboxings in der Analyse und der Umsetzung zu etablieren.

Wenn man schafft, die einzelnen Iterationen (Timeboxing) als die fixe Konstante zu etablieren, und Inhalt als Variable zu akzeptieren, dann bekommt man ein wichtiges Management-Werkzeug in die Hände: Die Möglichkeit daß man die Mitarbeiter ohne wenn und aber, zu festgelegten Zeitpunkten immer wieder neu ausrichten kann.