Erstes V-ARC Treffen

1. Willkommen
2. Vorstellung V-ARC Vision
3. Vorstellungsrunde Kernteam/Alle

4. Präsentation (ca. 30’)
Dr. Wolfgang Göbl: „Die Bedeutung schriftlicher Dokumentation im agilen Requirements Management“ – Erfahrungen und Lessons Learned bei Raiffeisen Solution

5. Diskussion zum präsentierten Thema (ca. 45’) –
Die präsentierten Inhalte sollen leidenschaftlich zerpflückt, widerlegt oder gestützt und von allen Seiten betrachtet werden.

6. Themensammlung/Priorisierung für Folgemeetings (ca. 30’)

Inhalte könnten sein (beispielhaft):

– Business Object Models
– Rolle
– Wann in welchem Detaillevel
– Für Fachbereich lesbar?

– User Stories und Use Cases
– bewährte Granularität
– wann wieviele Details?

– Tooling
– Cramer- JIRA, Confluence
vs. MS Word

– Unterschied:
– Product Management vs. Anforderungsmanagement

— Soziologische/Psychologische Aspekte
– Schnittstelle Fachbereich/Analytiker/Scrum Team

– Häufige Fallen in (Scrum) Projekten

7. Networking Buffet/Social Event (open end)

Was wir tun

In klassischen Wasserfall-ähnlichen Vorgehensmodellen fokussiert sich Requirements Management auf die Erstellung und Verwaltung einer funktional vollständigen, fehlerfreien Anforderungsdokumentation. Das Gebiet hat sowohl in der Forschung als auch der Praxis weit verbreitete Methoden (Use Cases, Objektmodelle) hervorgebracht. Der Analytiker spielt eine zentrale gestaltende Rolle in der Transformation unstrukturierter Anforderungen in strukturierte Spezifikationen.

Agile Vorgehensmodelle ändern das Feld des Requirements Management radikal – die schriftliche Spezifikation tritt in den Hintergrund, möglichst direkte mündliche Kommunikation zwischen Fachbereich (z.B. „Product Owner“) und Programmierern wird zu einem zentralen Element. Verfolgt man die vielen Diskussionen der immer größer werdenden Scrum-Community, kann man leicht den Eindruck gewinnen, dass die Rolle des Analytikers obsolete wird und schriftliche Dokumentation eher ein lästiges Beiwerk als ein wertvolles Asset ist.

Auf der größten deutschsprachigen Konferenz „Requirement Days“ war 2010 eine gewisse Verunsicherung der Requirements Community spürbar. Fragen wie

  • Sind all die erprobten Methoden wie z.B. Use Cases obsolet?
  • Welche Bedeutung haben Geschäftsobjektmodelle in SCRUM?
  • Zu welchem Zeitpunkt braucht man wieviele Requirements?
  • Sollen sich Mitarbeiter weiterhin spezialisieren (z.B. Analytiker/Programmierer/Tester) oder suchen Firmen nunmehr Generalisten die alles können?
  • Wieviel schriftliche Spezifikation braucht ein Scrum Projekt?
  • Rolle Product Owner in Fachbereich/IT Bereich?
  • Kulturelle/Soziologische Aspekte an der Schnittstelle Fachbereich/IT

konnten auch von den Keynote Referenten nicht in der Tiefe beantwortet werden.