Was die agile Entwicklung von der Softwarepsychologie für eine empfehlenswerte User Experience lernen kann.
Agile Entwicklung erfreut sich einer zunehmenden Verbreitung. Entwickelten Ende 2005 nur 14 Prozent der Unternehmen in Nordamerika und Europa ihre Software mit agilen Prozessen, waren es 2013 bereits 84 Prozent aller Unternehmen [1].
Viele IT-Hersteller wissen das und zählen sich zu den Befürwortern der agilen Entwicklung. Doch nur wenige schenken einem Problem der agilen Entwicklung Aufmerksamkeit, das erst durch die empirische Denkweise der Softwarepsychologie sichtbar wird.
Sowohl für die Softwarepsychologie als auch für die agile Entwicklung steht die Kundenzufriedenheit im Mittelpunkt der iterativen Arbeitsweise. Durch die Einbindung der Kunden und User in die Entwicklung werden im agilen Vorgehen und der Softwarepsychologie wertvolle Informationen zur Gestaltung einer faszinierenden User Experience gewonnen. Die erhobenen Daten werden in Form von Szenarien in der Entwicklung kommuniziert.
Grenzen der agilen Entwicklung
Ab hier beginnen sich die Wege der agilen Entwicklung und der Softwarepsychologie zu trennen.
In der agilen Entwicklung werden passend zur Vision verschiedene User Storys formuliert. Daraus werden in jedem Sprint die Funktionen für das neue (Teil-) Produkt abgeleitet.
Die Softwarepsychologie berücksichtigt an diesem Punkt zusätzlich, dass die Entscheidungen der Menschen stark von der Beschreibung der Wirklichkeit – also nicht von der Wirklichkeit selbst – abhängen. Der Grund liegt darin, dass eine bestimmte Beschreibung einen Bezugsrahmen für unsere Entscheidungen suggeriert. Schauen wir uns das an einem Beispiel an.
Bezugsrahmen prägen Entscheidungen
Bezugsrahmen (engl. Frame) umfassen alle Informationen, die einer Entscheidung zugeordnet sind. Im Folgenden lesen Sie zwei konkurrierende Entscheidungsoptionen aus der Arbeit von Daniel Kahneman und Amos Tversky, für die 2002 der Nobelpreis verliehen wurde.
Bitte lesen Sie sich erst alle vier Optionen durch bevor Sie aus den beiden folgenden Entscheidungen ihren Favoriten auswählen.
Entscheidung 1 – Wählen Sie zwischen:
A) Sicherer Gewinn von 240 Dollar
B) 25-prozentige Chance, 1.000 Dollar zu gewinnen, und eine 75-prozentige Chance, nichts zu gewinnen.
Entscheidung 2 – Wählen Sie zwischen:
C) Sicherer Verlust von 750 Dollar.
D) 75-prozentige Chance, 1.000 Dollar zu verlieren, und 25-prozentige Chance, nichts zu verlieren.
Wie haben Sie sich entschieden? Bei Entscheidung 1 sprachen sich 84 Prozent der Probanden für A) und 16 Prozent für B) aus. Bei Entscheidung 2 wählten 13 Prozent C) und 87 Prozent D). Haben Sie genauso entschieden, wie die Mehrheit der 150 Probanden, denen diese Aufgabe gestellt wurde?
Und für welche der beiden folgenden Optionen würden Sie sich jetzt entscheiden?
Entscheidung 3 – Wählen Sie zwischen:
E) 25-prozentige Chance, 240 Dollar zu gewinnen, und 75-prozentige Chance, 760 Dollar zu verlieren.
F) 25-prozentige Chance, 250 Dollar zu gewinnen und 75-prozentige Chance, 750 Dollar zu verlieren.
Haben Sie sich dieses Mal genauso entschieden, wie die Testteilnehmer? 100 Prozent der Befragten bevorzugten F, also die in den Entscheidungen 1 und 2 von der Mehrheit abgelehnten Optionen B) und C).
Enge Bezugsrahmen mindern Rationalität
Der einzige Unterschied zwischen F) und den beiden Optionen B) und C) ist die Beschreibung bzw. der Bezugsrahmen einer jeden Entscheidung. Inhaltlich ist die Option F) identisch mit den Optionen B) und C). Dasselbe gilt für E) im Vergleich zu A) und D).
Die Ergebnisse dieser und anderer Untersuchungen zeigen, dass Entscheidungen auf Basis enger Bezugsrahmen (Entscheidung 1, Entscheidung 2) weniger rational sind als Entscheidungen auf Basis komplexerer Bezugsrahmen (Entscheidung 3).
Bezugsrahmen in der agilen Entwicklung
In der agilen Entwicklung bilden die ausgewählten User Storys den Bezugsrahmen. Sie geben während eines Sprints vor über welche Anforderungen in der Entwicklung nachgedacht wird.
Aufgrund der festen Dauer jedes Sprints ist die agile Entwicklung gezwungen den Bezugsrahmen für die Umsetzung und die mit ihr verbundenen Entscheidungen klein zu halten. Stellen sich die Entscheidungen zur Realisierung von Anforderungen im weiteren Kontext als nicht optimal heraus, sind Nacharbeiten nötig.
Das Ausmaß der Nacharbeiten aufgrund zu enger Bezugsrahmen richtet sich nach dem Stadium der Entwicklung, in der die Entscheidungen für bestimmte Anforderungen getroffen werden. Zur Verdeutlichung dieses Punktes möchte ich zwei Situationen unterscheiden, wie sie in Ihrer agilen Entwicklung auftreten können:
1. Ein Navigationskonzept ist nicht vorhanden
Im ersten Fall liegt kein abgesichertes Navigationskonzept für das User Interface Design vor. Dieses soll aus der Betrachtung der User Storys im ersten Sprint kreiert werden.
Wie bereits oben ausgeführt, wirken zu kleine Bezugsrahmen rationalen Entscheidungen und damit der User Experience und Kundenzufriedenheit entgegen. Aus der Betrachtung einer handvoll User Storys im aktuellen Sprint lässt sich kein Navigationskonzept kreieren, dass auch für bisher unbekannte Probleme und User Storys geeignet ist.
Wachsende Unzufriedenheit der User mit der Usability des Produktes, mangelnde User Experience und eine Überarbeitung des Navigationskonzeptes sind die Folge.
2. Ein Navigationskonzept ist vorhanden
Im zweiten Fall verfügen Sie in Ihrer agilen Entwicklung über ein abgesichertes Navigationskonzept. Mit ihm visualisieren Sie bereits einen weiten Bezugsrahmen. In der Umsetzung differenzieren Sie anhand der User Storys lediglich das Interaktionsdesign aus.
Natürlich kann das Feedback der User am Ende eines Sprints auch hier zu Anpassungen führen. Doch die damit verbundenen Aufwände zur Korrektur des Interaktionsdesigns sind im Vergleich zu einer erneuten Überarbeitung des bereits programmierten Navigationskonzeptes sehr viel geringer.
Konsequenzen für die agile Entwicklung
Wie gezeigt, setzen die zeitlich befristeten Sprints enge Bezugsrahmen für die Entscheidungen zum User Experience Design. Teure Nacharbeiten zugunsten einer steigenden User Experience resultieren also aus einer rein agilen Entwicklung für komplexe Software.
Sie vermeiden diese Nacharbeiten, indem Sie die Stärke der agilen Entwicklung eher in der Umsetzung sehen. Diesem Gedanken folgend ist vor der agilen Entwicklung eine kreative Phase nötig, in der Sie
- mittels agilem User Researchs den komplexen Bezugsrahmen ausleuchten und den umsatzversprechenden Teil abstecken.
- für den erfolgsversprechenden Bezugsrahmen ein tragfähiges Navigationskonzept für Ihr einfaches User Interface Design und eine exzellente User Experience entwickeln.
Nach diesen Schritten steht Ihrer agilen Entwicklung nicht nur eine Vision, sondern auch ein zu ihr passendes User Interface Konzept zur Verfügung, dem das Spielfeld für die angestrebte Konkretisierung des Interaktionsdesigns innewohnt.
Dieses Navigationskonzept schließt die Lücke zwischen dem weiten Bezugsrahmen der Vision und den engen Bezugsrahmen der User Storys. So fördern Sie bessere Entscheidungen hinsichtlich des User Experience Designs und die agile Entwicklung kann ihre Stärken voll ausspielen.
UX Konzeption ist nicht Umsetzung 
Jede Methode hat ihren Einsatzbereich. So ist das Vorgehen der Softwarepsychologie für User Experience Design besonders geeignet um die Kernwerte zu demaskieren und das Navigationskonzept abzusichern. Die Stärke der agilen Entwicklung ist die zügige Umsetzung der Anforderungen samt Interaktionsdesign.
Quellen
[1] http://www.versionone.com/pdf/7th-Annual-State-of-Agile-Development-Survey.pdf Stand 04.09.2014
apliki.wordpress.com 