Agile Methoden User Experience Design in der agilen Entwicklung

Anbieter zum Thema

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Method Park Software AG

In der Software User Experience kommen iterative Prozesse zum Einsatz: Dieser Artikel beleuchtet Möglichkeiten, Software User Experience mit dem agilen Vorgehensmodell Scrum zu kombinieren.

Scrum ist heute das agile Vorgehensmodell mit der weitesten Verbreitung. Es kommt mit wenigen Rollen, Aktivitäten und Artefakten aus. Ein sogenannter Product Owner übernimmt die Position des Kunden. Er bestimmt die Richtung der Entwicklung und macht auch die Vorgaben zur Beschaffenheit des Endproduktes. Der Scrum Master kümmert sich darum, dass sein Team in Ruhe arbeiten kann. Er überwacht die Einhaltung der Regeln, plant und moderiert Meetings und dient dem Team als Coach, ohne in die Arbeitsweise einzugreifen. Das Team konzentriert sich auf die Entwicklung.

Die Vorgaben des Product Owners werden in Form kurzer User-Stories notiert. Eine User-Story ist ein Satz, der eine Handlung des Users mit dem Produkt beschreibt. Jede Story enthält die Nutzergruppe, die Handlung und das Ziel der Handlung. Beispiel:„Als Reisender will ich eine Fahrkarte kaufen, damit ich den Bus nutzen darf.“ Die Sammlung aller User-Stories eines Projektes nennt man Product Backlog. Der Product Owner darf die User-Stories priorisieren.

Das Team schätzt die nötigen Aufwände, um die einzelnen Stories umzusetzen. Es übernimmt Stories aus dem Product Backlog in einen Sprint Backlog. Dieser enthält die Stories, die das Team in einem festgelegten Zeitraum (Sprint) umsetzen wird. Die Dauer eines Sprints liegt in einem festen Intervall von zwei bis vier Wochen.

Während des Sprints kommt das Team täglich zusammen; jedes Teammitglied berichtet vom Stand seiner aktuellen Tätigkeit. Am Ende jedes Sprints erfolgt ein Sprint Review. Das Team – der Product Owner, sowie eventuell Kunden des Product Owners – bewerten hier das lauffähige Ergebnis des Sprints.

Das Feedback der Stakeholder wird gesammelt und fließt in das Product Backlog ein. Um seine Effizienz zu steigern, nimmt das Team eine Retrospektive vor. Hierbei sind das Team und der Scrum Master anwesend. Es geht darum, Probleme zu identifizieren, die während des letzten Sprints aufgetaucht sind. Diese werden diskutiert, damit der nächste Sprint effizienter verläuft. Anschließend plant das Team den folgenden Sprint.

Grundlagen der Software User Experience

Alle Software User Experience (kurz: UX) Designer haben ein Schema, nach dem sie in Projekten vorgehen. Sie entwickeln dieses Schema in ihrer Ausbildung oder spätestens während ihrer Praktika in der Industrie. Viele Designer machen sich formal wenig Gedanken über Prozesse. Einen formalisierten Ansatz liefert die Norm ISO 9241:210 "Human centered design for interactive systems" [1]. Sie beschreibt einen Prozess, in dessen Mittelpunkt der Nutzer steht. Die Entwicklung der Mensch-Maschine-Schnittstellen orientiert sich also an den Bedürfnissen der User. Das Produkt muss diesen Bedürfnissen entsprechen. Daher wird der Nutzer in die Entwicklung einbezogen.

Ein Projekt beginnt mit der Planungsphase. Hier wird der Grundstein für das weitere Vorgehen gelegt. Man wählt geeignete Methoden aus, sucht passende Nutzer und legt Termine fest. Darauf folgen die Analyse und die Beschreibung des Nutzungskontextes. Dieser umfasst die Benutzer, deren Ziele, Arbeitsmittel, Umgebung sowie das soziale Umfeld.

Die UX-Designer verwenden etwa Beobachtungen oder kontextuelle Interviews [2], um den Nutzungskontext zu ermitteln. Untersucht man lediglich die vorhandenen Systeme oder greift auf Erfahrungen des Produktmanagers zurück, erhält man ein lückenhaftes Gesamtbild. Auf Basis des Nutzungskontextes spezifizieren die Designer Nutzungsanforderungen. Dabei gehen sie von sogenannten Erfordernissen aus. Diese beruhen auf der Frage: Was braucht der Nutzer? Die daraus resultierenden Nutzungsanforderungen beantworten die Frage: Was kann der Nutzer mit dem System tun?

Nun müssen die Gestalter Lösungen entwickeln, die alle Nutzungsanforderungen abdecken sollen. Der erste Grobentwurf enthält zum Beispiel eine Informationsarchitektur, die alle nötigen UI-Komponenten und die Navigation festlegt. Dieser erste Entwurf wird dann im weiteren Projektverlauf bis ins letzte Detail verfeinert. Allerdings ist jeder Schritt zu evaluieren. Hierfür müssen Prototypen erstellt werden.

Zunächst bedient man sich einfacher Prototypen aus Papier. Das Team entwickelt diese Prototypen immer weiter, um die Gestaltungslösung für den Benutzer erlebbar zu machen. So wird sichergestellt, dass das Ergebnis optimal auf die Nutzer abgestimmt ist. Stellen die Gestalter Probleme fest, dann gehen sie dazu über, den Nutzungskontext anzupassen oder die Anforderungen zu überarbeiten. Der Prozess endet, sobald eine Gestaltungslösung alle Nutzungsanforderungen erfüllt.

Liefergegenstände legt die ISO 9241 nicht explizit fest. Die Arbeitsergebnisse von Designern sind normalerweise gut durchdacht und visuell gut aufbereitet. Außenstehende erwarten genau dies. Allerdings ist der Zeitbedarf für eine derartige Arbeitsweise hoch. Diese Zeit ist innerhalb einer agilen Entwicklung nicht verfügbar. Damit die Zusammenarbeit mit der Entwicklung funktioniert, müssen Designer im agilen Umfeld umdenken. Diese Denkweise ist auch fester Bestandteil von Lean UX [3].

Strategien: Mit Iterationen die ideale Lösung finden

Die beschriebenen Vorgehensmodelle haben viel gemeinsam. Zum einen verfolgen beide einen iterativen Ansatz. In Scrum baut jedes Inkrement auf dem vorhergehenden, aus dem letzten Sprint auf. Im UX-Prozess werden Prototypen erstellt. Die Designer evaluieren diese mit Usern und lassen die Ergebnisse wieder in den Prozess einfließen. Auch hinsichtlich der engen Zusammenarbeit der Stakeholder und der entstehenden Transparenz stimmen die Modelle überein.

Ein großer Unterschied liegt allerdings in der Zielgruppe. Bei Scrum ist der Product Owner der Ansprechpartner für das Team, wenn es um die User-Stories geht. Bei der Erstellung eines UX-Konzeptes hingegen erheben die Gestalter die Anforderungen direkt mit Nutzern. Ein weiterer Unterschied sind die Interessen der Stakeholder: Entwickler sind oft nicht an Design interessiert, Designer nicht an Fragen der Implementierung. Die größte Differenz besteht in der Zielsetzung der Modelle. UX-Design lotet möglichst viele Ideen aus, um eine für den Nutzer ideale Lösung zu finden. Scrum dagegen ist ein Instrument, um mittels von Iterationen eine technisch optimale Lösung umzusetzen.

Einfache Integration der UX-Aktivitäten in Scrum

Eine erste Möglichkeit, beide Modelle zu vereinen, liegt in der Integration der UX-Aktivitäten in den Sprint. Der UX-Designer wird also Teil des Scrum-Teams. Er ist während der Sprints dafür verantwortlich, die User-Stories mit den entsprechenden Methoden in Designs zu übersetzen. Die Entwickler implementieren das User Interface nach seinen Vorgaben und das Inkrement eines Sprints wächst. Dieser Ansatz ist mit verschiedenen Problemen behaftet. Zunächst können unterschiedliche User-Stories an die gleichen Bedienelemente gebunden sein. Das Scrum-Team setzt die Stories Sprint für Sprint um, wodurch der Designer immer wieder Hand an dieselben Elemente anlegen muss. Ein konsistentes Gesamtbild kommt so nur schwer zustande; gleichzeitig erlebt der Designer bei dieser Vorgehensweise Enttäuschung und Unzufriedenheit.

Die Entwickler wollen direkt mit der Umsetzung der User-Stories beginnen. Für das User Interface benötigen sie die Vorgaben des Designers. Dieser muss zunächst ein Konzept erstellen. Durch Nutzertests mit Prototypen erhält er Klarheit darüber, ob das Konzept Erfolg verspricht. Dadurch vermeidet das Team unnötige Iterationen. Indem man die Entwickler einbezieht, stellt man zusätzlich die Machbarkeit sicher. Allerdings kann die Implementierung erst erfolgen, wenn das Konzept für eine oder mehrere User-Stories fertig ist. Soll eine Story innerhalb eines Sprints abgeschlossen werden, dann bleibt für die Implementierung folglich wenig Zeit. Dies setzt sowohl Designer als auch Entwickler unter Druck.

Gothelf und Seiden [3] beschreiben die Integration von Lean UX in Scrum. Ihr Ansatz sieht vor jedem Sprint ein Kick-off-Meeting für die Gestaltung vor. Darin sucht das Team Ideen und erstellt Skizzen. Diese zusätzliche Aktivität sorgt dafür, dass die Gestalter zu Beginn der Sprints konkrete Aufgaben bekommen. Während der Iterationsplanung leitet man nämlich aus den Skizzen User-Stories ab, die man wie üblich in das Backlog übernimmt. Im Sprint werden die Ideen validiert. Dafür reichen zwei Termine pro Sprint aus, wobei der zweite Termin noch vor dem Ende des Sprints liegen muss. So kann das Team die Ergebnisse der Validierung noch in das Ergebnis des Sprints aufnehmen.

Sprint Zero als vorgelagerte Designphase

Um die Modelle abzugleichen, kann man alternativ eine vorgelagerte Designphase einführen, also innerhalb eines sogenannten Sprint Zero [4]. Im ersten Sprint arbeitet das Team am Design. Dies geschieht, bevor die Entwicklung des Codes beginnt. Das Team des Sprint Zero kann speziell für diesen Zweck gebildet werden. Ideal ist ein interdisziplinäres Team aus UX-Experten, Produktmanagern und Entwicklern. Sie sollen ein Grobkonzept erstellen.

Im weiteren Projektverlauf verfeinert das Team dieses inkrementell. Dazu muss ein UX-Designer Mitglied im regulären Scrum-Team sein. Dieser detailliert das anfängliche Konzept und testet es mit tatsächlichen Nutzern. Ein wesentlicher Vorteil: Elemente, die über den Scope einzelner Stories hinausgehen, etwa die Informationsarchitektur und Navigation, sind schon festgelegt. So hat das Entwicklungsteam einen Rahmen, in dem es sich bewegt. Zugleich wird Konsistenz sichergestellt.

Dieses Vorgehen bildet jedoch eine Brücke zum linearen Wasserfallmodell. Wer Scrum einsetzt, will sich genau davon lösen. Die Reaktion auf Änderungen im Projektverlauf wird schwieriger, da die Anpassung des ursprünglichen Design-Konzeptes weitreichende Folgen hat. So müsste eventuell ein erneuter Design-Sprint eingeschoben werden, was den Projektverlauf verlangsamen würde.

Als dritte Variante lassen sich Design und Entwicklung parallel ausführen [5]. Dies wird als Dual Track Scrum bezeichnet. Man formt zwei Scrum-Teams mit unterschiedlichen Aufgaben. Das Discovery-Team wird interdisziplinär aufgestellt. Es kümmert sich um die Gestaltung der Software User Experience. Seine Ergebnisse erhält das Delivery-Team. Dieses zweite Team besteht aus Entwicklern, die aus dem Design neue User Stories formen und implementieren.

Bei diesem Vorgehen muss auf den Informationsfluss zwischen den Teams geachtet werden. Ein einfaches Übergeben von Dokumenten ist nicht wünschenswert. Die Teams müssen viel kommunizieren, damit hier nicht wieder Probleme der Wasserfall-Taktik auftauchen. Stories aus dem Discovery-Team müssen stets rückverfolgbar sein. Nur so kann ein Chaos bei Änderungswünschen oder notwendigen Verfeinerungen verhindert werden. Haben die Gestalter im Projekt vorübergehend nichts zu tun, so kann das Discovery-Team ohne weiteres einen oder mehrere Sprints lang pausieren.

Best Practices für die Entwicklung

Die Gestalter pflegen einen allgemeinen User Experience Styleguide. Er beinhaltet Vorgaben für Standard-Komponenten der User-Interfaces, Layouts, Icons, Farben, Responsive Design und Interaktionen. Dieser Styleguide muss für alle Mitarbeiter einsehbar sein. Änderungen werden von den Gestaltern laufend eingepflegt, so dass die aktuellste Version stets zugänglich bleibt. Anpassungen für konkrete Projekte sind zulässig, müssen allerdings in der Dokumentation festgehalten werden. Der größte Vorteil dieser Strategie besteht in der Zeitersparnis und Vermeidung von Redundanz. Alle Projekte können auf die Erfahrungen und Vorgaben aus dem Styleguide zurückgreifen.

Agile Prozesse leben vom Informationsaustausch. Dies gilt speziell bei interdisziplinären Teams. Die Verteilung von Teams über verschiedene Gebäude oder gar verschiedene Standorte schadet dem Kommunikationsfluss. Diskussionen, Ideenaustausch und schnelle Problembeseitigung funktionieren am besten durch kurze Wege. Daher sollen Gestalter und Entwickler möglichst nahe beieinander sitzen.

Die Zusammensetzung der Teams ist stabil. Ein eingespieltes Team von Gestaltern und Entwicklern sollte nicht verändert werden. Wird ein Designer temporär nicht im Projekt benötigt, sollte er später nicht durch einen Kollegen ersetzt werden. Dies stärkt den Zusammenhalt des Teams und verhindert Wissensverluste im Projekt.

Entwicklungstrends

So sieht zukunftsfähige Embedded-Softwareentwicklung aus

Softwaretechnik

Mit Secure Scrum zu mehr Softwaresicherheit im IoT

Acht Schritte für konstruktives Feedback

Scrum-Retrospektive für heterogene Teams

Agile Methoden

Warum eigentlich (immer) Scrum?

Quellenverzeichnis

[1] http://www.din.de/de/mitwirken/normenausschuesse/naerg/normen/wdc-beuth:din21:135399380

[2] http://www.usabilitybok.org/contextual-inquiry

[3] Lean UX; O'Reilly and Associates; ISBN-10: 1449311652

[4] Sprint Zero: https://www.scrumalliance.org/community/articles/2013/september/what-is-sprint-zero

[5] Adapting Usability Investigations for Agile User-centered Design; Desirée Sy; Journal of Usability Studies; Vol. 2 Issue 3; 2007

* Daniel Frank arbeitet seit 2006 für Method Park. Seine Schwerpunkte liegen in den Bereichen Qualitätssicherung, Prozessoptimierung und User Experience.

(ID:44363812)