Einladung: 11. V-ARC Treffen: Bring your own user story am 17.6. bei A1

Eines der Werte aus dem Agilen Manifesto lautet: „Funktionierende Software ist wichtiger als umfassende Dokumentation“. Wir wissen aber, die Zusammenarbeit im Projekt ist auch von der lebenden Dokumentation geprägt.

In diesem Termin sehen wir uns die konkreten Analyse-Artefakte aus den echten, optimaler weise agilen Projekten an, und diskutieren anschließend über diese.

Wann und Wo

Montag, 17.06.  15:00-18:00,

A1 Telekom Lassallestrasse 9 1020 Wien Österreich

Bitte melde Dich im XING hier an.

Impulsreferat(e)

In diesem Teil sehen wir uns die konkreten Beispiele aus Deinem Projekt an – hier einige Fragen auf welche Du in Deinem Referate eingehen solltest:

  • Wie sieht Deine Story aus? Wie entsteht sie (im Team oder gemeinsam mit dem PO)?
  • Hat sie einen komplexen Lebenszyklus (z.B. in Analyse, Geschätzt, In Implementierung,  Abgenommen)?
  • Welche Tools zur Dokumentation setzt Du ein? Post-It, JIRA, Confluence, Word oder was Drittes?
  • Hast Du Epic’s, wie sehen Diese aus?
  • Welche Dokumentationsformen verwendest Du zusätzlich zu User Stories/Epics?  Use Cases, Geschäftsobjektmodelle, Mockups, Features, Testfälle als Spezifikation?

Sei auch Du ein Vortragender! Melde Dich dafür bitte bis 13. Juni bei vnisevic@gmail.com

Podiumsdiskussion

Anschließend versuchen wir in der Podiumsdiskussion folgende Fragen gemeinsam zu beantworten:

  • Wie viel Dokumentation in Deinem agilen Projekt ist genug?
  • Gibt es sowas wie „Ideale User Story*“

Wir freuen uns, wenn Du bei diesem Treffen dabei bist!

Vienna Agile Requirements Circle

Advertisements

Checkliste des Agilen Anforderungsmanagements

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.