SCRUMTISCH meets UX Stammtisch: Requirements Management
Beim connect.IT Scrumtisch treffen sich vierwöchentlich Interessierte an Scrum, agilen Methoden/Einstellungen und Projektmanagement. Der Teilnehmerkreis setzt sich aus engagierten Menschen von unterschiedlichen Branchen und Tätigkeitsfeldern zusammen. Meistens wird in einer offenen Themenrunde diskutiert, bei der auch neue Teilnehmer einen schnellen Einstieg finden und individuelle Fragen zum Erfahrungsaustausch einbringen können.
Requirements Management
Den 26. Scrumtisch moderierte Dr. Andreas Birk, Gründer und Principal Consultant bei Software.Process.Management (SWPM). Wir beschäftigten uns mit der Frage, wie sich ein gutes Anforderungsmanagement gestaltet.
Zum Hintergrund: Das gute alte Lastenheft vs. User Stories
Im klassischen Projektmanagement nach DIN 69901-5 werden Anforderungen anhand eines Lastenhefts beschrieben, welches die Wünsche des Kunden repräsentieren (das „Was und wofür?“). Ergänzt wird dieses Dokument durch ein Pflichtenheft, das eine Lösungsumsetzung als Fachkonzept des Auftragnehmers beschreibt (das „Wie und womit?“). Sobald der Auftraggeber das Pflichtenheft abnimmt, wird im klassischen Vorgehen mit der Umsetzung begonnen. Was einmal als Spezifikation festgelegt wurde, ist nach dieser Vorgehensweise bindend. Nachträgliche Änderungswünsche werden als Abweichungen von der Basiskonfiguration über ein Änderungsmanagement abgebildet.
Mit der zunehmenden Geschwindigkeit, wie sich Technologien heutzutage weiterentwickeln, sind auch technische Produktentwicklungen einer höheren Dynamik ausgesetzt. Kaum hat sich ein Standard etabliert, folgt in einigen Branchen bereits der nächste. Der Kunde akzeptiert keine veraltete Technologie, zur Not kauft er bei der Konkurrenz. Produktentwicklungen müssen heutzutage nicht nur schnell gehen; Entwicklerteams setzen sich mehr und mehr mit unbekannten Technologien auseinander, deren Sinnstiftung aufgrund der Neuartigkeit selbst vom Auftraggeber nicht treffend beschrieben werden kann. Wie geht man nun damit um? Schreibt man dann einfach ein unvollständiges Lasten- und Pflichtenheft?
Agiles Anforderungsmanagement nähert sich diesem Problem mit User Stories. Ein Produkt wird hier nicht vorab mittels Lasten- und Pflichtenheft beschrieben. Vielmehr wird begleitend zum Entwicklungsprozess anhand von kurzen Erzählungen (Stories) spezifiziert, welche bestimmte Kundenrollen (Personas), welches Ziel mit einem Produkt(-teil) verfolgen. User Stories sind deshalb typischerweise im Stil „Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>“ als Karten (User Cards) verfasst. Es können laufend Kundenanforderungen hinzukommen oder geändert werden, das Entwicklungsteam arbeitet diese in fest definierten Zeitabschnitten (Time-boxing) ab. Wer noch mehr darüber erfahren möchte, ich empfehle das Buch „Scrum mit User Stories“ von Ralf Wirdemann.
Ein kleiner Auszug aus unseren Diskussion
Agile Anforderungen & Technische Detailverliebtheit
Die erste Frage ging in die Richtung, wie agiles Anforderungsmanagement in regulierten Umgebungen für technische Systeme aussehen kann. Wenn zum Beispiel ein Zug gebaut werden soll, wie geht man mit einer harten Spezifikation wie zum Beispiel „Bremsen“ vor? Eine denkbare Lösung ist hier die Aufnahme der Bremsleistung in die Akzeptanzkriterien (Definitions of Done) einer User Story. Bei solchen wichtigen Produktmerkmale liegt es auch auf der Hand, dass Details beschrieben werden. Allerdings sollte man im agilen Anforderungsmanagement eher den Anspruch haben, das „Big Picture“ sinnvoll zu beschreiben, anstatt sich in Kleinteiligkeit zu verlieren und somit unflexibel zu werden. Ob der Entwicklungsprozess dann in sequentiellen Abfolgen (Wasserfall) oder Iterationen verläuft – entscheidend sind die Feedbackschleifen zum Kunden.
Es lebe die Empirie!
Für das Lasten- und Pflichtenheft gibt es Standards (zum Beispiel vom VDI und der IEEE), wie schreibt man aber eine richtige User Story? Hier merkte ein Teilnehmer des Treffens an, dass in der agilen Entwicklung Empirie enorm wichtig sei: Erlaubt ist alles, was zweckmäßig ist. Und man soll sein Vorgehen regelmäßig prüfen und weiter verbessern.
Andreas Birk stimmte dem vorbehaltlos zu. Er betonte, dass User Stories keine Requirements-Spezifikationen seien. Man solle sie als möglichst leichtgewichtige Repräsentation von Requirements-Information betrachten, und besonders als Anlass zur Kommunikation und Klärung unter den Projektbeteiligten nutzen. Das Template „Role – Feature – Reason“ schaffe da eine sehr gute Balance zwischen Kürze und Klarheit. Er berichtete aber auch von Teams, die nur mit stichwortartigen User Stories sehr gut arbeiten konnten, weil sie so gut eingespielt waren und ein breites gemeinsames Verständnis von System und Anwendungsbereich hatten. Ein anderes nützliches Schema für Use Cases sei „Given – When – Then“, mit dem sich insbesondere bei reaktiven Systemen ein sehr guter Übergang von User Stories zu Akzeptanztests erzielen lässt.
Sind wir nicht alle ein bisschen DAU?
Personas sind ein zentrales Element im Requirements Engineering, um die Nutzerzentrierung zu verankern und das Problemverständnis zu fördern. Wer sich damit schwer tut, kann den Einstieg in Personas über den in der Software Entwicklung scherzhaft genannten „Dümmsten Anzunehmenden User“ schaffen – ein komplett uninformierter Nutzer, der aber dennoch bestimmte Bedürfnisse und Anforderungen dem System gegenüberstellt. Und auch hier lebt die Empirie – es wäre falsch Personas aufzustellen und als gegeben hinzunehmen. Personas sind zunächst nur Hypothesen, die es im Feld zu verifizieren gilt.
An dieser Stelle nochmals herzlichen Dank an Dr. Andreas Birk und alle Diskussionsteilnehmer. Außerdem hat uns die Schwarz IT Infrastructure & Operations Services (SITIOS) einen Raum und Getränke zur Verfügung gestellt – vielen Dank!
Nächster Scrumtisch: 29.05.2017 ab 18:30 Uhr bei SolidIT
Die Eventorganisation läuft über Xing, wir bitten um Anmeldung, die Plätze sind begrenzt: https://www.xing.com/events/28-connect-it-scrumtisch-1817422
