User-Centered Design in agilen Entwicklungsprozessen

Veröffentlicht am:

Agile Entwicklungsprozesse und User-Centered Design sind zwei iterative Vorgehensmodelle, die ihre Anwendung in der Softwareentwicklung finden. User-Centered Design ist eine Designphilosophie, die menschliche Bedürfnisse, Fähigkeiten und Verhaltensweisen in den Fokus rückt und dann das Design an diese Bedürfnisse, Fähigkeiten und Verhaltensweisen anpasst (Norman 2013).
Agile Entwicklungsprozesse wie Scrum, gewinnen immer mehr an Popularität. Ihre grundsätzlichen Werte sind Interaktion, Kollaboration und Flexibilität. Agile Modelle verzichten auf umfangreiche Dokumentationen und bevorzugen informative und häufige Kommunikation vor festen Abläufen (Nebe & Baloni 2016). Die iterative Vorgehensweise der agilen Entwicklung hilft dabei zeitgleich an kleineren Features zu arbeiten, die nach und nach ein größeres System bilden. Große Projekte werden so meist, in mehreren kleinen Projekten implementiert, ausgeliefert und getestet (Nebe & Baloni 2016).
Das große Risiko bei agilen Methoden ist, dass sie von Programmierern und Entwicklern entworfen worden und sich hauptsächlich auf die Implementierung fokussieren, weniger jedoch auf Usabilityaspekte (Nebe & Baloni 2016). Dieser Faktor soll durch die Integration von User-Centered Design in den Entwicklungsprozess aufgefangen werden. Die vorliegende Arbeit legt Recherchen zu durchgeführten Studien und Praxisbeispielen dar und zeigt Probleme, sowie Integrationsmöglichkeiten auf.

User-Centered Design

Die Integration von User-Centered Design (UCD) in agile Entwicklungsprozesse kann problematisch sein.
Als Software Engineering in den 70er Jahren entwickelt wurde, wurde sich an anderen Engineering Prozessen orientiert. Daraus entstand die Wasserfall-Methode, die auf einer festen Abfolge von Entwicklungsphasen beruht, z.B. Problemanalyse, Anforderungsspezifikation, Design, Implementierung, Verifikation, Installation und Operation (Gram & Cockton 1996).
User-Centered Design wurde ursprünglich entwickelt, um die Usability von Softwareprodukten zu verbessern. Als die Kosten für Hardware in den 80er Jahren fielen, hatten immer mehr Menschen Zugang zu Computern, aber nicht zu der nötigen Ausbildung, die Computerexperten durchliefen. Nachdem während der 90er Jahre effektive Usability Methoden entwickelt wurden, stieg die Qualität der Benutzbarkeit von Software deutlich an. Für User-Centered Design wurden die Attribute Befriedigung, Effektivität und Kontextangemessenheit, neben Geschwindigkeit, "ease of use" und Lernfähigkeit als Schwerpunkte im Designprozess implementiert. In den 2000er Jahren kamen zu diesen Eigenschaften noch der Fokus auf eine positive User Experience (UX), die Qualität der Benutzbarkeit. Mit jeder dieser Erweiterungen des UCD's strebte man höhere Softwarequalität an, sowohl indem ein besseres Erlebnis für den Nutzer entwickelt wird, indem stärker auf die Bedürfnisse des Endnutzers eingegangen wird, als auch darauf, dass Kosten und Risiken während des Entwicklungsprozesses reduziert werden. User-Centered Design beinhaltet heute ein breites Spektrum von Werten wie Effektivität, Effizienz, Befriedigung, Wohlfühlen am Arbeitsplatz, Markenloyalität, Gesundheit und Sicherheit, Mitarbeiterbindung, Menschenwürde und Wettbewerbsfähigkeit. Daran gemessen sollte User-Centered Design, zumindest in der Theorie, ein interessanter Aspekt für die Softwareentwicklung sein (Cockton et al. 2016).
Erste Versuche User-Centered Design in den Softwareentwicklungsprozess zu integrieren fanden in den 80er Jahren statt. Die größte Herausforderung dabei war die Akzeptanz von UCD-Praktiken durch alle Phasen des Entwicklungsprozesses. UCD-Praktiken, wie kontextuelle Recherche, passten in die Problemanalyse-Phase des Wasserfallprozesses und Nutzertests in die Verfikationsphase, allerdings sieht UCD eine iterative Vorgehensweise vor, so lange bis alle Nutzeranforderungen erfüllt sind, sowohl aus funktionaler Sicht, als auch aus Usability Sicht. Dazu musste Zeit für Kommunikation und Entscheidungsfindung zwischen den Stakeholdern geschaffen werden (Gram & Cockton 1996).

Agile Entwicklung

Das Agile Manifesto entwickelte sich als Gegenbewegung zum Wasserfall-Softwarentwicklungsprozess. Einige der Charakteristika der agilen Vorgehensweise waren kompatibel mit UCD-Praktiken: Anforderungen werden kontinuierlich über eine Abfolge von Iterationen definiert, inkrementelle Entwicklung, um das frühe Ausliefern einer lauffähigen Software zu ermöglichen, und die enge Zusammenarbeit, sowie Einbeziehung des Kunden in den Entwicklungsprozess. Andere Charakteristika passen weniger in den UCD-Ansatz, zum Beispiel weniger Möglichkeiten für User-Tests und weniger Planungszeit im Vorfeld der Implementierung. Diese negativen Aspekte schließen UCD aus manchen der populärsten agilen Prozessen aus oder übergeben die UCD-Verantwortlichkeiten an einen Business-Analysten (Boehm 2003 & Meyer 2014).
Da es verschiedene agile Methoden gibt, ist es wichtig, nicht zu verallgemeinern. Die Entwicklungsmethoden sind darüber hinaus bewusst unterspezifiziert, damit sie in der Praxis im richtigen Kontext eingesetzt und vervollständigt werden können (Cockton et al. 2016). Diese Punkte werden bei Anwendung der Methoden unweigerlich offen gelegt. Projektteams müssen deswegen immer gegen eventuell negative Aspekte und für positive Aspekte in dem bestimmten Anwendungsfall arbeiten. Was während des Entwicklungsprozesses passiert, hat einen höheren Stellenwert, als das was die Methodik vorgibt. Deswegen ist es wichtig, zu verstehen, wie agile Methoden gemanagt werden und wie eine Modifikation der Methodik sich auf die Integration des User-Centered Design auswirkt (Cockton et al. 2016).

Scrum

Die agile Entwicklungsmethode Scrum hat innerhalb der letzten Jahre immer mehr an Aufmerksamkeit und Bedeutung gewonnen, meist wegen der Agilität und des Spielraums für Flexibilität, sowie der Fokussierung auf die Fähigkeiten und die Motivation der Teammitglieder. Einer der Grundsätze von Scrum ist Schnelligkeit und Kommunikation (Beck 2001). Anforderungen an die User Experience, Usability und anderer für den Nutzer wichtigen Aspekte sind nicht explizit im Scrum-Prozess enthalten (Kotzé 2013).
Viele in der Branche sehen Scrum als einen nutzerzentrierten Prozess, unter anderem, weil User Stories Bestandteil des Prozesses sind und durch die iterative und kommunikative Vorgehensweise (Schwaber 1995). Diese Aspekte stimmen mit den Werten des UCD Ansatzes überein und könnten wiederum erklären, warum Scrum so erfolgreich ist (Kotzé 2013). Die Nutzerperspektive ist allerdings nicht zwingend Teil des Prozesses und etwas was vorausgesetzt werden kann, wenn man in einem Scrum Prozess arbeitet. Obwohl viele Organisationen von einem großen Erfolg durch agile Prozesse berichten, schreibt keiner dieser Prozesse vor, dass Aktivitäten des Usability Engineering integriert werden sollen (Sohaib & Khan 2010). Eine der Schwierigkeiten, die immer wieder genannt wird, ist der zeitliche Aspekt: Es ist schwer im Prozess noch Zeit für Usability Aktivitäten wie Nutzertests zu finden (Larusdottir 2011). Hinzu kommt, dass es schwierig ist, den Überblick über die gesamte User Experience des Produktes innerhalb eines Scrum Projektes zu behalten. Um dieses zu gewährleisten wird empfohlen einen Usability Spezialisten in jedem Team zu installieren oder zumindest mehr face-to-face Kommunikation zwischen den Mitgliedern des Scrumteams und den Usability Spezialisten stattfinden zu lassen (Kuusinen et al. 2012).
Studien haben gezeigt, dass viele Informanten informales Feedback bezüglich ihres Designs durch qualitative Evaluation generieren, allerdings nur wenige quantitatives Feedback von mehr als 10 Nutzern einholen. In der Regel wird Usability Evaluation nur selten einberufen – zwei mal im Jahr und häufig durch einen externen Usability Experten (Larusdottir et al. 2010). Als häufigster Grund für die seltene Usability Evaluation wird der Zeitfaktor genannt. Allerdings werden manche Usability Maßnahmen wie Workshops regelmäßig in Scrum Projekten genutzt (Jia et al. 2012). Diese Aktivitäten sind meistens formlos, d.h. sie beinhalten keine Messungen oder gründliche Usability Evaluationen und passen daher besser zu den Scrum-Grundsätzen Schnelligkeit und Kommunikation. Zusätzlich ist das Produzieren von inkrementellen Auslieferungen in kurzen zeitlichen Projektabschnitten ein weiteres beliebtes und wichtiges Merkmal von Scrum. Dieses Merkmal führte bei den Befragten jedoch zu dem Problem, dass es schwer ist, die Gesamtvision für die Nutzerperspektive auf alle Projektteile anzuwenden, obwohl das Projekt in Scrum in kleine Abschnitte unterteilt wird.

Vergleich zwischen agiler Entwicklung und UCD

Agile Entwicklung und UCD haben beide zum Ziel, ein qualitativ hochwertiges Produkt zu entwickeln, sind aber aus unterschiedlichen Perspektiven formuliert, was die Integration beider Prozesse schwierig gestaltet (Nebe & Baloni 2016).
Agile Entwicklungsmethoden iterieren über Code oder kleine Sets von Features und UCD iteriert über User Requirements und Interaction Design. Man müsse beim Integrieren beider Prozesse darauf achten, UCD ebenfalls inkrementell zu gestalten, d.h. das Sammeln der User Requirements und die Entwicklung von Designalternativen iterativ für ein kleines Set von Features entwickeln. Beide Prozesse sind Human- bzw. User-centered. Der Unterschied: Bei UCD ist mit dem Endnutzer, derjenige gemeint, der das Produkt am Ende verwendet, während in agilen Prozessen nicht zwischen Endnutzer und Kunde unterschieden wird. In agilen Prozessen ist per Definition kein Endnutzer-Feedback involviert. Beide Ansätze setzen den Schwerpunkt auf effektives Teamwork und Kommunikation, durch Selbstorganisation und face-to-face Kommunikation. Eine weitere Charakteristik von UCD ist, dass das ganze Team sowohl beim Design, als auch bei der Entwicklung an den Endnutzer denkt. Agile Methoden sind besonders effektiv, wenn die Anforderungen bei Projektstart nicht eindeutig sind, aber definieren nicht, wie die Anforderungen gesammelt werden. Agile Teams, sind auf die Anforderungen des Kunden angewiesen. Der UCD Prozess startet früher, indem im voraus Analysen, Sammeln von Anforderungen und Design stattfinden. In agilen Prozessen wird täglich von Entwicklern getestet, Testing der Userakzeptanz bzw. Kundenakzeptanz kann nach jeder Iteration oder nach jedem Sprint (Scrum) stattfinden, aber es findet kein explizites Usability-Testing mit dem Endnutzer statt. In agilen Methoden bedeutet Akzeptanz, der Kunde sieht die Anforderungen erfüllt und implementiert, in UCD wird das System mit echten Nutzern getestet, was sowohl Usability Probleme, als auch technische Probleme aufdeckt (Larusdottir 2011).

Integrationsmethoden

Um die „user-centeredness“ eines agilen Prozesses zu messen, haben Nebe & Baloni eine Checkliste, basierend auf ISO 9241-210 mit dem „agile manifesto“ abgeglichen. Das heißt, jeder der 103 Punkte der ISO-Norm wurde auf Kompatibilität mit einem agilen Prozess überprüft. Alle 103 Punkte, waren anwendbar auf einen agilen Prozess, in 90 Fällen musste jedoch eine Anpassung des agilen Prozesses stattfinden. Das Ergebnis ist eine leicht angepasste Checkliste der ISO 9241-210, die auf agile Methoden angewandt werden kann (Nebe & Baloni 2016). Es ist also grundsätzlich möglich HCD in agile Prozesse zu integrieren.

Es gibt laut Nebe & Baloni 2016 drei Ansätze, den UCD Prozess in einen agilen Prozess zu integrieren:

  1. Den Spezialisten Ansatz: Es gibt drei Teams: UCD Spezialisten, Entwicklungsteam und die Nutzer/Kunden.
  2. Der Generalisten Ansatz: Es gibt zwei Teams: Die Nutzer/Kunden und die Entwickler, die gleichzeitig als UCD Spezialisten agieren. Bei diesem Ansatz müssen die Entwickler, ausgebildete oder selbsterlernte UCD Fähigkeiten besitzen.
  3. Der Generalisten Spezialisten Ansatz: Bei diesem Ansatz ist ein Mitglied des Teams ein ausgebildeter UCD Spezialist, und hat außerdem Erfahrung in Softwareentwicklung. Dieses Mitglied ist sowohl Generalist, als auch Spezialist (Nebe & Baloni 2016).

Probleme bei der Integration

Eine wichtige Aufgabe besteht also darin, die Verantwortlichkeiten während eines Projektes klar zu definieren. Diffuse Verantwortlichkeiten sind ein soziales Phänomen, welches in größeren Gruppen auftritt. Wenn eine Aufgabe an eine Gruppe von Personen übergeben wird, ist es die Tendenz jedes Einzelnen, anzunehmen, dass jemand anderes die Verantwortung für den Task übernehmen wird und sich am Ende niemand verantwortlich fühlt. Dieses Phänomen tritt häufig in Gruppen auf, in denen Aufgaben nicht eindeutig verteilt sind. Forschungen in diesem Bereich haben ergeben, dass diffuse Verantwortlichkeiten einen negativen Effekt auf den Entwicklungsprozess haben (Gotterbarn 2001).
Ziele für Usability oder User Experience zu formulieren ist ein Weg, die Betonung auf die Wichtigkeit dieser Faktoren zu lenken und gibt den Mitarbeitern die Motivation die Nutzerperspektive in ihrer Arbeit zu berücksichtigen (Kotzé 2013). Diese Methode wurde von IT-Fachkräften sehr gut bewertet, um Usability in den Softwareentwicklungsprozess zu integrieren (Gulliksen 2004). Usability Anforderungen an ein System innerhalb eines agilen Prozesses zu definieren, wird als großes Problem wahrgenommen, da agile Prozesse eher den Kunden einbinden, anstatt den Endnutzer (Sohaib & Khan 2010). Eine weitere Studie zeigt, dass das Definieren von Usability Zielen eine hohe Bewertung bei den Teilnehmern hatte, aber über die Hälfte der Teilnehmer keine expliziten Usability Ziele formulieren (Jia et al. 2012). Als Lösung schlagen die Forschenden vor, Usability Ziele oder Probleme mit bestehender Dokumentation aus dem Scrum Prozess zu kombinieren, z.B. die Beschreibung von Zielen als Akzeptanzkriterien von User Stories (Singh 2008) und das Sammeln von Usability Zielen in User Stories oder im Backlog (Düchting 2007).
Aktuelle Ergebnisse zeigen, dass viele IT-Fachkräfte Usability Maßnahmen in Scrum Projekten durchführen und diese als sinnvoll bewerten (Jia et al. 2012). Die am höchsten bewerteten Maßnahmen laut dieser Studie sind Workshops, formlose Usability Tests mit Nutzern und Meetings mit Nutzern. Alle dieser Aktivitäten sind eher formlos. Ähnliche Ergebnisse lieferte auch eine Studie, die gezeigt hat, dass alle Formen von Prototypen häufiger in Scrum Prozessen benutzt werden als in anderen agilen Prozessen (Larusdottir et al. 2009). Die meistgenutze Form von Prototypen in der agilen Entwicklung sind Low-Fidelity Prototypen und User-Tests, die genutzt werden um die Prototypen in der nächsten Iteration weiter zu entwickeln (Silva da Silva et al. 2011).
Als erheblicher Erfolgsfaktor für die Integration der Nutzerperspektive in Scrum wird in mehreren Studien eine enge Zusammenarbeit zwischen Entwicklern und Usability-Experten genannt (Kuusinen et al. 2012 & Silva da Silva et al. 2011). Zwei weitere wichtige Erfolgsfaktoren sind das Verständnis des Usability Spezialisten für seine Rolle und die Etablierung, der Schutz und die Kommunkation einer gemeinsamen Vision (Kollmann et al. 2009). User Experience Themen sind meistens sowohl auf der operativen, als auch auf der strategischen Ebene wichtig, aber die aktuellen Arbeitsprozesse und Führungsstile können den Einfluss eines Usability Spezialisten einschränken (Kuusinen & Väänänen-Vainio-Mattila 2012).

Praxisbeispiel: Autoscout24

Susanne Hanst beschreibt in ihrem Paper "Agil und kundenorientiert?" die Vorgehensweise im Scrum-Prozess bei Autoscout24. Die interdisziplinären Scrum-Teams bestehen bei AutoScout24 aus:

  1. Product Owner (PO): Er ist zuständig für die strategische Ausrichtung des Produkts und für das Festlegen was und mit welcher Priorität etwas umgesetzt wird. Diese Produktausrichtungen werden in das sogenannte Product Backlog einsortiert und an das Management kommuniziert.
  2. Product Manager (PM): Er ist dafür zuständig festzulegen, wie etwas umgesetzt werden soll, auf Basis von Analyse- und Konzeptarbeit in enger Zusammenarbeit mit dem restlichen Team.
  3. UX Manager (UX): Entspricht den Mitgliedern des Usability Teams. Sie sind dafür zuständig, das was zu verstehen, Hintergründe über die Nutzersicht (Kundenkontakt, Nutzeranforderungen) zu liefern und den Product Manager in der Umsetzung des wies zu unterstützen.
  4. Entwicklerteam mit dem Systemarchitekten (Devs): Sie sind zuständig für die finale Implementierung und die Code-Qualität. Weiterhin sind sie wichtiger Feedbackgeber für die Konzeptarbeit.
  5. Qualitätsmanager (QA): Er ist zuständig für die Qualitätsabsicherung der einzelnen Produktausrichtungen im Zusammenspiel der Gesamtplattform.
  6. Scrum-Master (SM): Er unterstützt das restliche Team in der Durchführung der Scrum-Methodik. Er schützt vor oder behebt externe Störungen, verbessert die Produktivität und die Kommunikation im Team durch durchgängiges transparent machen und reflektieren des Sprintgeschehens und der Teamdynamik.
    (Hanst 2012)

Dabei sind in der Einführungsphase folgende Probleme aufgetreten:

  1. Erschwerte Zusammenarbeit des Usability-Teams durch räumliche Trennung.
  2. Zu viele Meetings für die UX Manager, die nicht in allen Meetings etwas beitragen können und dadurch in Zeitdruck geraten, was zu Druck und Fehlern führt. Nicht ganz durchdachte Konzepte und keine Zeit zum Testen sind die Folgen.
  3. Anforderungsanalyse wird vernachlässigt. Stärkere Kontrolle der Anforderungen ist nötig, es wird mehr direktes Kundenfeedback und die Berücksichtigung konkreter Kundenbedürfnisse gefordert. Es wird jedoch wenig Zeit für Research und Usability-Test eingeplant.
  4. Qualität leidet, da nach Sprints Live gegangen wird und keine Zeit zum "nachziehen" eingeplant ist, es folgt direkt der nächste Sprint.
  5. Das Usability-Team wird vernachlässigt, was zu Problemen in der Konsistenz und Usability führt.
    (Hanst 2012)

Wie lässt sich die Usability-Arbeit in Sprints integrieren

Jeder kann alles

Entwickler sollen aktiv an der Konzeption des User Interfaces teilhaben, damit abgestimmte Konzepte auch umsetzbar sind. Dieser Ansatz führte jedoch nicht zu zufrieden stellenden Ergebnissen, da ein UX Manager meistens gegen 5 Entwickler und einen Produktmanager und einen Scrummaster stand und die Diskussionen verlor (Hanst 2012).

Frühe Aufwandsschätzung

Eine weitere Strategie ist es, so früh wie möglich in eine Aufwandschätzung mit dem ganzen Team zu gehen. Die Stärke des Interdisziplinären Know-Hows konnte jedoch nur abgerufen werden, wenn zuvor eine Vorbereitung des Usability Teams eingeplant war, um eine Diskussionsgrundlage zu haben (Hanst 2012).

Evaluationssprint

Anstatt alle Tätigkeiten des Teams in einem Sprint zu planen, laufen zwei Sprints parallel. Es gibt einen Evaluations- und einen Implementierungssprint. Dadurch wird sicher gestellt, dass der UX Manager jeweils für den nächsten Implementierungssprint vorbereiten und neue Features testen und evaluieren kann. So können Produktverbesserungen frühzeitig identifiziert werden (Hanst 2012).

Versetzte Sprints in Scrum mit UX Team

Nach 2 Jahren Zeit wurden bei Autoscout ein Zwischenfazit gezogen:

  1. UX Manager bleiben Teil des Scrum-Teams neben aber nicht mehr an allen Meetings teil.
  2. Das Usability-Team ist messerbar erfolgreich. Durch das direkte Kundenfeedback werden Lob und Probleme direkt an das Scrum-Team weiter gegeben, was zu einer höheren Motivation führte. Produktmanagement und IT sind deutlich interessierter an User-Tests und Studienergebnissen. Das Usability Team wird außerdem durch ein Design-Team verstärkt und Texteraufgaben werden von externen Anbietern eingekauft.
  3. Die User Stories müssen definiert sein. Durch die Einführung der Evaluationssprints hat das Usability Team und Produktmanagement Zeit, die Produktanforderungen klarer zu durchdenken.
  4. Sprints müssen vorbereitet werden. Sobald ein grober Plan steht, wird das Scrum-Team zur Estimation für Lösungsansätze oder zu technischen und umsetzungsrelevanten Rahmenbedingungen hinzugegzogen. Jeder bringt dabei seine fachlichen Stärken ein und es wird eine breite gemeinsamen Wissensbasis geschaffen.
  5. Ein Styleguide wurde etabliert, um gemeinsame Qualitätsstandards zu etablieren. Design und Entwicklung arbeiten zusammen an CSS Standards.
  6. Peer Reviews und 3-stündige Workshops wurden eingeführt, um sich innerhalb des Usability Teams auszutauschen und gemeinsame Standards zu schaffen.
    (Hanst 2012)

Handlungsempfehlungen

Å. Cajander, M. Larusdottir, and J. Gulliksen geben aufgrund ihrer Studien und Interviews folgende Handlungsempfehlungen für das Integrieren von User-Centered Design in Scum:

  1. Es gibt kein klares Bild für die Verantwortlichkeit für Usability: Der Schwerpunkt auf die Nutzerperspektive wird gestärkt, wenn die Verantwortlichkeiten für die Usability klar und deutlich verteilt und kommuniziert werden. Dies beinhaltet die Definition, wer an der Usability arbeitet und wer für die Qualität des finalen Produktes zuständig ist. Das Problem ist: Scrum sieht keine formellen Rollen für Qualitätsaspekte wie Sicherheit, Datenschutz und Performance vor. Die Verantwortlichkeit für Usability gleichmäßig auf alle Teammitglieder zu verteilen definiert noch nicht, wie die Nutzerperspektive integriert werden soll, um gute Usability zu entwickeln. Diese Verantwortlichkeiten sollten klar an Usability Spezialisten verteilt werden. Zusätzlich benötigen die Usability Spezialisten fachliche und organisatorische Unterstützung, um die Usability Verbesserungen durchzusetzen. Einige organisatorische Beispiele sind ein ausreichendes Mandat Entscheidungen zu treffen, Unterstützung des Managements, organisatorische Kompetenz, Selbstbewusstsein und Erfahrung, sowie eine gute Position im Team (Kotzé 2013).

  2. Usability Ziele sind unklar: Bis zu welchem Grad sind messbare quantitive Ziele notwendig um Entwicklungsaufwände zu investieren und die Produktqualität zu verbessern? Die bisherigen betrachteten Studien geben darüber wenig Aufschluss. Übergeordnete Qualitätsziele performen hier meist besser, als detaillierte Usability Ziele, da sie helfen die Entwicklung und das Design in eine gemeinsame Richtung zu treiben (Kotzé 2013).

  3. Ad-Hoc Nutzereinbindung und Designfeedback: Agile Prozesse unterstützen keine Nutzereinbindung, aber verhindern diese auch nicht. Meistens geschieht die Nutzereinbindung formlos und meistens in Ad-hoc-Manier und aufgrund der Eigeninitiative eines Teammitglieds. Es wird nicht systematisch im Scum Prozess geplant. Allerdings sollte dieser Punkt systematisch in den Prozess integriert werden. Nutzereinbindung und Designfeedback sollten in den Prozess eingeplant werden (Kotzé 2013).

  4. Neue Methoden: Die agilen Anforderungen an Geschwindigkeit und Effizienz, Fokussieren auf Deliverables statt auf umfangreiche Dokumentation und die vorhandene Kritik, aufgrund der fehlenden Nutzereinbindung gibt Anreize dazu, neue Usability Methoden zu entwickeln. Die Erstellung von Nutzerforen, in denen diskutiert und Feedback gegeben wird, sind Folgen der schnellen Auslieferung von lauffähigem Code. Eine bewusste frühere Inklusion der Nutzerperspektive innerhalb der Sprint-Review-Meetings könnte ein Ansatz sein oder eine Art "Reality-Check" in der Nutzer dabei beobachtet werden, wie sie die Software im Alltag verwenden (Kotzé 2013).

Die Nutzerperspektive wird vielleicht in Scrum Projekten berücksichtigt, wenn das Team es forciert, aber es es gibt keine expliziten Forderungen danach im Prozess, wenn nicht der Project Owner oder der Entwicklungsleiter ein besonderes Interesse daran hat, eine gute Usability durchzusetzen. Da der Prozess keine Dokumentation oder Ähnliches für Usability Tätigkeiten vorsieht, geschehen diese meistens in formloser Kommunikation. Ein User-Centered Scrum Projekt muss Wege der Nutzereinbindung finden, die zu der agilen Natur des Projektes passen, sie müssen effizient und ohne großen Aufwand und aufwendige Formalien durchführbar sein. Zusammenfassend sollten Änderungen im Scrum-Prozess vorgenommen werden, um die Nutzerperspektive tiefer und eindeutiger in den Prozess zu integrieren (Kotzé 2013).

Ein User-Centered Scrum Projekt muss Wege der Nutzereinbindung finden, die zu der agilen Natur des Projektes passen!

Fazit

Die dargestellten Beispiele aus Studien und der Praxis lassen klar erkennen, dass die Integration von User-Centered Design in agile Entwicklungsprozesse möglich ist und erfolgreich sein kann. Jedoch zeigt sich auch, dass die richtige Ausführung sehr wichtig ist. Dabei stellt sich sowohl in den betrachteten Studien und dem Praxisbeispiel heraus, dass vor allem eine klare Definition von Zielen und Zuständigkeiten im Team essentiell wichtig, für ein erfolgreichen Projektverlauf sind.
Die Praxis zeigt auch, dass ein Spezialisten Ansatz, also ein dediziertes UX-Team, dass sich explizit nur um UCD-Aspekte kümmert und dafür den Rücken freigehalten bekommt, effizienter arbeiten kann. Die Einführung zeitlich versetzter Evaluations- und Implementierungssprints scheint einen guten Ansatz zu bieten, dem UX-Team den nötigen zeitlichen Vorsprung zu gewährleisten um neue Produktanforderungen zu identifizieren und zu testen. Damit der Einfluss des UX-Teams auf das gesamte Projektteam möglichst hoch ist, muss häufig und klar kommuniziert werden, dies kann allerdings auch formlos geschehen, um Dokumentationsaufwand zu sparen.

Klare Definition von Zielen und Zuständigkeiten im Team sind essentiell wichtig für einen erfolgreichen Projektverlauf.


Quellen:

Beck, K. (2001) Extreme programming explained: embrace change. Addison-Wesley
Boehm B, Turner R (2003) Balancing agility and discipline: a guide for the perplexed. Addison-Wesley, Boston
Cockton, G. et al. (2016), Integrating User-Centred Design in Agile Development, Human–Computer Interaction Series
Düchting, M., Zimmermann, D., Nebe, K. (2007) Incorporating User Centered Requirement Engineering into Agile Software Development. In: Jacko, J.A. (ed.) HCI 2007. LNCS, vol. 4550, pp. 58–67. Springer, Heidelberg
Gotterbarn, D. (2001) Informatics and professional responsibility. Science and Engineering Ethics 7, 221–230
Gram, C., Cockton, G. (1996) Design principles for interactive software. Chapman and Hall, London
Jia, Y., Larusdottir, M.K., Cajander, Å. (2012) The Usage of Usability Techniques in Scrum Projects. In: Winckler, M., Forbrig, P., Bernhaupt, R. (eds.) HCSE 2012. LNCS, vol. 7623, pp. 331–341. Springer, Heidelberg
Kotzé, P. et al. (Eds.) (2013) INTERACT 2013, Part III, LNCS 8119, pp. 762–779
Gulliksen, J., et al. (2004) Making a difference: a survey of the usability profession in Sweden. In: Proceedings of the NordiCHI 2004 Conference, pp. 207–215. ACM Press, Tampere
Hanst, S. (2012) Agil und kundenorientiert? — Arbeiten bei AutoScout24 — Scrum und Usability in der Praxis
Kollmann, J., Sharp, H., Blandford, A. (2009) The importance of Identity and Vision to user experience designers on agile projects. In: Proceedings of the Agile 2009 Conference, pp. 11–18
Kuusinen, K., Mikkonen, T., Pakarinen, S. (2012) Agile User Experience Development in Large Software Organization: Good Expertise but Limited Impact. In: Human-Centred Software Engineering, Toulouse
Kuusinen, K., Väänänen-Vainio-Mattila, K. (2012) How to make agile UX work more efficient: management and sales perspectives. In: Proceedings of NordiCHI 2012 Coference, pp. 139–148. ACMPress, Copenhagen
Larusdottir, M.K. (2011) Usability evaluation in software development practice. In: Campos, P., Graham, N., Jorge, J., Nunes, N., Palanque, P., Winckler, M. (eds.) INTERACT 2011, Part IV. LNCS, vol. 6949, pp. 430–433. Springer, Heidelberg
Meyer B (2014) Agile! The good, the hype and the ugly. Springer, Switzerland
Larusdottir, M.K., Bjarnadottir, E.R., Gulliksen, J.(2010) The focus of usability testing in the software industry. In: World Computer Congress, Brisbane, Australia (2010)
Larusdottir, M.K., Haraldsdottir, O., Mikkelsen, B. (2009) User involvement in Icelandic Soft- ware Industry. In: Proceedings for the 2nd International Workshop on the Interplay Between Usability Evaluation and Software Development — I-Used at the INTERACT Conference 2009, Uppsala, Sweden, pp. 51–52
Nebe, K. & Baloni, S. (2016) Agile Human-Centred Design: A Conformance Checklist.
Norman, Don (2013) The Design of everyday Things — Revised and expanded Edition. Basic Books.
Schwaber, K. (1995) Scrum development process. In: Proceedings of the OOPSLA 1995 Conference, Languages and Applications — Workshop on Business Object Design and Implementation
Silva da Silva, T., et al. (2011) User-Centered Design and Agile Methods: A Systematic Review. In: Agile Conference (AGILE), 2011, pp. 77–86
Singh, M. (2008) U-SCRUM: An agile methodology for promoting usability. In: Proceedings of the AGILE 2008 Conference, pp. 555–560. IEEE
Sohaib, O., Khan, K. (2010) Integrating Usability Engineering and Agile Software Development: A Literature Review. In: Proceedings of the ICCDA 2010 Conference, pp. 32–38


Artikel teilen: Twitter Facebook
Themen:

.further txts