14

IMPLEMENTIERUNG // AGILE METHODEN

ELEKTRONIKPRAXIS Embedded Software Engineering November 2016

User Experience Designin der agilen EntwicklungIn der Software User Experience kommen iterative Prozesse zum Ein-

satz: Dieser Artikel beleuchtet Möglichkeiten, Software User Experiencemit dem agilen Vorgehensmodell Scrum zu kombinieren.

DANIEL FRANK *

* Daniel Frank... arbeitet seit 2006 für Method Park.Seine Schwerpunkte liegen in denBereichen Qualitätssicherung, Pro-zessoptimierung und User Experience.

Scrum ist heute das agileVorgehensmo-dell mit der weitesten Verbreitung. EskommtmitwenigenRollen,Aktivitäten

undArtefakten aus. Ein sogenannter ProductOwner übernimmt die Position des Kunden.Er bestimmt die Richtung der Entwicklungund macht auch die Vorgaben zur Beschaf-fenheit des Endproduktes. Der ScrumMasterkümmert sich darum, dass sein Team in Ru-he arbeiten kann. Er überwacht die Einhal-tung der Regeln, plant und moderiert Mee-tings und dient dem Team als Coach, ohnein die Arbeitsweise einzugreifen. Das Teamkonzentriert sich auf die Entwicklung.DieVorgabendesProductOwnerswerden

in Form kurzer User-Stories notiert. Eine

User-Story ist ein Satz, der eine Handlungdes Users mit dem Produkt beschreibt. JedeStory enthält die Nutzergruppe, die Hand-lungunddasZielderHandlung.Beispiel:„AlsReisender will ich eine Fahrkarte kaufen,damit ich den Bus nutzen darf.“ Die Samm-lung allerUser-Stories eines Projektes nenntman Product Backlog. Der Product Ownerdarf die User-Stories priorisieren.Das Team schätzt die nötigen Aufwände,

um die einzelnen Stories umzusetzen. EsübernimmtStories aus demProduct Backlogin einen Sprint Backlog. Dieser enthält dieStories, die das Team in einem festgelegtenZeitraum (Sprint) umsetzen wird. Die Dauereines Sprints liegt in einem festen Intervallvon zwei bis vier Wochen. Während desSprints kommtdas Team täglich zusammen;jedes Teammitglied berichtet vomStand sei-ner aktuellen Tätigkeit. Am Ende jedesSprints erfolgt ein Sprint Review. Das Team– der Product Owner, sowie eventuell Kun-

dendesProductOwners –bewertenhier daslauffähige Ergebnis des Sprints.Das Feedbackder Stakeholderwird gesam-

melt und fließt in das Product Backlog ein.Um seine Effizienz zu steigern, nimmt dasTeameineRetrospektive vor.Hierbei sinddasTeam und der Scrum Master anwesend. Esgeht darum, Probleme zu identifizieren, diewährend des letzten Sprints aufgetauchtsind. Diese werden diskutiert, damit dernächste Sprint effizienter verläuft. Anschlie-ßend plant das Team den folgenden Sprint.

Grundlagen der Software UserExperienceAlle Software User Experience (kurz: UX)

Designer haben ein Schema, nachdemsie inProjekten vorgehen. Sie entwickeln diesesSchema in ihrerAusbildungoder spätestenswährend ihrer Praktika inder Industrie. Vie-le Designer machen sich formal wenig Ge-danken über Prozesse. Einen formalisiertenAnsatz liefert dieNorm ISO9241:210 "Humancentered design for interactive systems" [1].Sie beschreibt einen Prozess, in dessen Mit-telpunkt der Nutzer steht. Die Entwicklungder Mensch-Maschine-Schnittstellen orien-tiert sich also an den Bedürfnissen der User.Das Produkt muss diesen Bedürfnissen ent-sprechen. Daher wird der Nutzer in die Ent-wicklung einbezogen.Ein Projekt beginntmit der Planungspha-

se. Hier wird der Grundstein für das weitereVorgehen gelegt. Man wählt geeignete Me-thoden aus, sucht passende Nutzer und legtTermine fest. Darauf folgen die Analyse unddie Beschreibung des Nutzungskontextes.Dieser umfasst die Benutzer, deren Ziele,Arbeitsmittel, Umgebung sowie das sozialeUmfeld. Die UX-Designer verwenden etwaBeobachtungenoder kontextuelle Interviews[2], um den Nutzungskontext zu ermitteln.Untersucht man lediglich die vorhandenenSystemeoder greift auf ErfahrungendesPro-duktmanagers zurück, erhält man ein lü-ckenhaftes Gesamtbild. Auf Basis des Nut-

Bild 1: Einfache Integration der Prozesse

Bild:M

etho

dPark

document6393342606692518392.indd 14 16.11.2016 10:19:41

ELEKTRONIKPRAXIS Embedded Software Engineering November 2016 15

IMPLEMENTIERUNG // AGILE METHODEN

zungskontextes spezifizieren die DesignerNutzungsanforderungen. Dabei gehen sievon sogenannten Erfordernissen aus. Dieseberuhenauf der Frage:Wasbraucht derNut-zer? Die daraus resultierendenNutzungsan-forderungen beantworten die Frage: Waskann der Nutzer mit dem System tun?Nun müssen die Gestalter Lösungen ent-

wickeln, die alle Nutzungsanforderungenabdecken sollen. Der erste Grobentwurf ent-hält zumBeispiel eine Informationsarchitek-tur, die alle nötigen UI-Komponenten unddieNavigation festlegt. Dieser erste Entwurfwird dann imweiterenProjektverlauf bis insletzte Detail verfeinert. Allerdings ist jederSchritt zu evaluieren.HierfürmüssenProto-typen erstelltwerden. Zunächst bedientmansich einfacher Prototypen aus Papier. DasTeam entwickelt diese Prototypen immerweiter, um die Gestaltungslösung für denBenutzer erlebbar zumachen. Sowird sicher-gestellt, dass das Ergebnis optimal auf dieNutzer abgestimmt ist. Stellen die GestalterProbleme fest, danngehen sie dazuüber, denNutzungskontext anzupassen oder die An-forderungen zu überarbeiten. Der Prozessendet, sobald eine Gestaltungslösung alleNutzungsanforderungen erfüllt.Liefergegenstände legt die ISO 9241 nicht

explizit fest. DieArbeitsergebnisse vonDesi-gnern sind normalerweise gut durchdachtund visuell gut aufbereitet. Außenstehendeerwarten genau dies. Allerdings ist der Zeit-bedarf für eine derartige Arbeitsweise hoch.Diese Zeit ist innerhalb einer agilenEntwick-lung nicht verfügbar. Damit die Zusammen-arbeit mit der Entwicklung funktioniert,müssen Designer im agilen Umfeld umden-ken. Diese Denkweise ist auch fester Be-standteil von Lean UX [3].

Strategien: Mit Iterationen dieideale Lösung findenDie beschriebenenVorgehensmodelle ha-

ben viel gemeinsam. Zum einen verfolgenbeide einen iterativenAnsatz. In Scrumbautjedes Inkrement auf dem vorhergehenden,aus dem letzten Sprint auf. Im UX-ProzesswerdenPrototypen erstellt. DieDesigner eva-luierendiesemitUsernund lassendie Ergeb-nissewieder in denProzess einfließen.Auchhinsichtlich der engen Zusammenarbeit derStakeholder undder entstehendenTranspa-renz stimmen die Modelle überein.Ein großer Unterschied liegt allerdings in

der Zielgruppe. Bei Scrum ist der ProductOwner der Ansprechpartner für das Team,wenn es um die User-Stories geht. Bei derErstellung eines UX-Konzeptes hingegen er-hebendieGestalter dieAnforderungendirektmit Nutzern. Ein weiterer Unterschied sind

die Interessen der Stakeholder: Entwicklersind oft nicht an Design interessiert, Desig-ner nicht an Fragen der Implementierung.Die größte Differenz besteht in der Zielset-zungderModelle. UX-Design lotetmöglichstviele Ideen aus, um eine für den Nutzer ide-ale Lösung zu finden. Scrumdagegen ist einInstrument, ummittels von Iterationen einetechnisch optimale Lösung umzusetzen.

Einfache Integration der UX-Aktivitäten in ScrumEine erste Möglichkeit, beide Modelle zu

vereinen, liegt in der Integration der UX-Aktivitäten in den Sprint. Der UX-Designerwird also Teil des Scrum-Teams. Er ist wäh-rend der Sprints dafür verantwortlich, dieUser-Storiesmit den entsprechendenMetho-den inDesigns zuübersetzen.Die Entwicklerimplementieren das User Interface nachseinen Vorgaben und das Inkrement einesSprints wächst. Dieser Ansatz ist mit ver-schiedenen Problemen behaftet. ZunächstkönnenunterschiedlicheUser-Stories andiegleichen Bedienelemente gebunden sein.Das Scrum-Team setzt die Stories Sprint fürSprint um,wodurchderDesigner immerwie-der Hand an dieselben Elemente anlegenmuss. Ein konsistentes Gesamtbild kommtso nur schwer zustande; gleichzeitig erlebtderDesigner bei dieserVorgehensweise Ent-täuschung und Unzufriedenheit.Die Entwickler wollen direkt mit der Um-

setzung der User-Stories beginnen. Für dasUser Interface benötigen sie dieVorgabendesDesigners. Diesermuss zunächst einKonzepterstellen. Durch Nutzertests mit Prototypenerhält er Klarheit darüber, ob das KonzeptErfolg verspricht. Dadurch vermeidet dasTeam unnötige Iterationen. Indem man dieEntwickler einbezieht, stellt man zusätzlichdie Machbarkeit sicher. Allerdings kann dieImplementierung erst erfolgen, wenn dasKonzept für eine oder mehrere User-Storiesfertig ist. Soll eine Story innerhalb einesSprints abgeschlossen werden, dann bleibt

Bild 2: Vorgelagerter Design-Sprint (sogenannterSprint Zero)

Bild:M

etho

dPark

document6393342606692518392.indd 15 16.11.2016 10:19:44

16

IMPLEMENTIERUNG // AGILE METHODEN

ELEKTRONIKPRAXIS Embedded Software Engineering November 2016

für die Implementierung folglichwenig Zeit.Dies setzt sowohlDesigner als auchEntwick-ler unter Druck.Gothelf und Seiden [3] beschreiben die

Integration vonLeanUX inScrum. IhrAnsatzsieht vor jedem Sprint ein Kick-off-Meetingfür dieGestaltung vor. Darin sucht das TeamIdeenunderstellt Skizzen.Diese zusätzlicheAktivität sorgt dafür, dass die Gestalter zuBeginn der Sprints konkrete Aufgaben be-kommen. Während der Iterationsplanungleitet man nämlich aus den Skizzen User-Stories ab, diemanwieüblich indasBacklogübernimmt. Im Sprint werden die Ideen va-lidiert. Dafür reichen zwei Terminepro Sprintaus, wobei der zweite Termin noch vor demEnde des Sprints liegen muss. So kann dasTeamdie Ergebnisse derValidierungnoch indas Ergebnis des Sprints aufnehmen.

Sprint Zero als vorgelagerteDesignphaseUm die Modelle abzugleichen, kann man

alternativ eine vorgelagerte Designphaseeinführen, also innerhalb eines sogenanntenSprint Zero [4]. Im ersten Sprint arbeitet dasTeam am Design. Dies geschieht, bevor dieEntwicklung des Codes beginnt. Das Teamdes Sprint Zero kann speziell für diesenZweckgebildetwerden. Ideal ist ein interdis-ziplinäres Team aus UX-Experten, Produkt-managern und Entwicklern. Sie sollen einGrobkonzept erstellen. Im weiteren Projekt-verlauf verfeinert das Teamdieses inkremen-tell. Dazumuss ein UX-DesignerMitglied imregulärenScrum-Teamsein.Dieser detailliertdas anfängliche Konzept und testet es mittatsächlichenNutzern. EinwesentlicherVor-teil: Elemente, die über den Scope einzelnerStories hinausgehen, etwadie Informations-architektur undNavigation, sind schon fest-

gelegt. So hat das Entwicklungsteam einenRahmen, in dem es sich bewegt. Zugleichwird Konsistenz sichergestellt.DiesesVorgehenbildet jedoch eineBrücke

zum linearen Wasserfallmodell. Wer Scrumeinsetzt, will sich genau davon lösen. DieReaktion auf Änderungen im Projektverlaufwird schwieriger, da die Anpassung des ur-sprünglichenDesign-Konzeptesweitreichen-deFolgenhat. Somüsste eventuell ein erneu-terDesign-Sprint eingeschobenwerden,wasden Projektverlauf verlangsamen würde.Als dritte Variante lassen sich Design und

Entwicklungparallel ausführen [5]. DieswirdalsDual Track Scrumbezeichnet.Man formtzwei Scrum-Teams mit unterschiedlichenAufgaben.DasDiscovery-Teamwird interdis-ziplinär aufgestellt. Es kümmert sich umdieGestaltung der Software User Experience.Seine Ergebnisse erhält das Delivery-Team.Dieses zweite Teambesteht aus Entwicklern,die aus demDesignneueUser Stories formenund implementieren.Bei diesem Vorgehen muss auf den Infor-

mationsfluss zwischen den Teams geachtetwerden. Ein einfachesÜbergeben vonDoku-menten ist nichtwünschenswert. Die Teams

müssen viel kommunizieren, damit hiernichtwieder ProblemederWasserfall-Taktikauftauchen. Stories ausdemDiscovery-Teammüssen stets rückverfolgbar sein. Nur sokann ein Chaos bei Änderungswünschenoder notwendigen Verfeinerungen verhin-dert werden. Haben die Gestalter im Projektvorübergehend nichts zu tun, so kann dasDiscovery-Team ohne weiteres einen odermehrere Sprints lang pausieren.

Best Practicesfür die EntwicklungDie Gestalter pflegen einen allgemeinen

User Experience Styleguide. Er beinhaltetVorgaben für Standard-Komponenten derUser-Interfaces, Layouts, Icons, Farben, Re-sponsive Design und Interaktionen. DieserStyleguide muss für alle Mitarbeiter einseh-bar sein. Änderungen werden von den Ge-staltern laufend eingepflegt, so dass die ak-tuellste Version stets zugänglich bleibt. An-passungen für konkrete Projekte sind zuläs-sig,müssenallerdings inderDokumentationfestgehalten werden. Der größte Vorteil die-ser Strategie besteht in der Zeitersparnis undVermeidung von Redundanz. Alle Projektekönnen auf die Erfahrungen und Vorgabenaus dem Styleguide zurückgreifen.Agile Prozesse leben vom Informations-

austausch. Dies gilt speziell bei interdiszip-linären Teams. Die Verteilung von Teamsüber verschiedene Gebäude oder gar ver-schiedene Standorte schadet dem Kommu-nikationsfluss. Diskussionen, Ideenaus-tausch und schnelle Problembeseitigungfunktionieren am besten durch kurzeWege.Daher sollen Gestalter und Entwickler mög-lichst nahe beieinander sitzen.Die Zusammensetzung der Teams ist sta-

bil. Ein eingespieltes Team von Gestalternund Entwicklern sollte nicht verändert wer-den. Wird ein Designer temporär nicht imProjekt benötigt, sollte er später nicht durcheinen Kollegen ersetzt werden. Dies stärktden Zusammenhalt des Teams und verhin-dert Wissensverluste im Projekt. // FG

Method Park

Bild 3: Dual Track Scrum

Bild:M

etho

dPark

PRAXISWERT

Es gibt nicht den einen KönigswegEs gibt diverse Möglichkeiten, Scrumund Software User Experience zu ver-einen. Allerdings gilt: Es gibt nicht deneinen Königsweg. Die Verbindung vonScrum und UX muss sich stets an dieGegebenheiten einer Organisation an-passen. Nur so finden die Beteiligtenam Ende einen für alle optimalen Weg.Die Mitglieder der Teams brauchen einehohe Flexibilität.

Kein Platz für HeldenDer Typus des Helden ist hier völlig fehlam Platz. Das gilt für Entwickler genau-so wie für Designer. Wichtig sind Team-geist und die Bereitschaft, sich auch anAufgaben zu beteiligen, die jenseits dereigenen Domäne liegen. Dies entsprichtwiederum den Prinzipien des agilen Ma-nifests: Kommunikation, Kollaborationund die Annahme von Veränderungen.

Quellenverzeichnis[1] http://www.din.de/de/mitwirken/normenaus-

schuesse/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 AgileUser-centered Design; Desirée Sy; Journal ofUsability Studies; Vol. 2 Issue 3; 2007

document6393342606692518392.indd 16 16.11.2016 10:19:46