• Facebook
  • Google+
  • Twitter
  • XING
16.11.2008

Agile-Entwicklungsprojekte und Usability

Agile-Methoden zielen darauf ab, Usability-Barrieren im traditionellen Entwicklungsprozess zu überwinden, aber sie führen zu neuen Bedrohungen der Qualität des Nutzererlebnisses. Durch Modifikationen der Agile-Ansätze haben viele Unternehmen den Nutzen realisiert und den Schaden vermieden.

 

by Jakob Nielsen (deutsche Übersetzung) - 17.11.2008

 

Je nachdem, wie sie gehandhabt werden, können Rapid-Application-Development-(RAD)-Prozesse wie Agile oder Scrum die Qualität des Nutzererlebnisses steigern oder bedrohen.

Die Vorteile von Agile-Methoden

Agile-Methoden sprechen drei Themen an, die Usability-Experten schon seit langem ärgern:

  • Schon seit 50 Jahren zeigt fast die gesamte Erfahrung, dass die traditionellen Wasserfall-Entwicklungsmethoden zu einem schlechten Nutzererlebnis führen. Der Grund ist einfach: die Beschreibung der Erfordernisse ist immer falsch.

    • Im besten Fall, wenn sie sorgfältig erhoben wurden, spiegeln die Erfordernisse wider, was die Nutzer wollen. Häufiger allerdings spiegeln sie die Wünsche von "repräsentativen" Nutzern wider, die von den Verhältnissen vor Ort zu weit entfernt sind, um die Details am wirklichen Arbeitsplatz zu kennen. In jedem Fall sind das, was die Nutzer wollen, und das, was die Nutzer brauchen, zwei verschiedene Dinge und deshalb ist es seit langem eine primäre Usability-Richtlinie zu beobachten, was die Nutzer tun, und nicht darauf zu hören, was sie sagen.
    • Wenn zwischen der Abfassung der Erfordernisse und der Auslieferung des Produktes Jahre vergangen sind, haben sich die Nutzerbedürfnisse wahrscheinlich verändert, wodurch sich die Distanz zwischen den Erfordernissen und den Bedürfnissen noch weiter vergrössert hat.
    • In den vergangenen 25 Jahren hat die Usability-Arbeit gezeigt, dass es einer der besten Wege ist, die Qualität eines Designs zu evaluieren, indem man beobachtet, wie die Nutzer mit ihr interagieren (sei es durch einen funktionalen oder durch einen nachgemachten Bildschirm). Auch hier gilt: Wenn Jahre vergehen, bevor die Entwickler dies tun, haben sie ihre meisten Entwicklungsanstrengungen in die falschen Designs hineingesteckt.

  • Dokumentationen weiter unten am Wasserfall verursachen ebenfalls Probleme. Es gibt nur eines, was schlimmer ist als Designer, die von Design-Spezifikationen abweichen: Designer, die Design-Spezifikationen buchstäblich umsetzen. Viele Probleme kommen erst während der detaillierten Umsetzung eines Interaktions-Designs hoch; die Entwickler können solche Probleme nicht auf eine Weise lösen, die die Usability verbessert, wenn die Design-Arbeit schon vor langer Zeit abgeschlossen wurde und die Experten für Nutzererlebnis das Haus schon lange verlassen haben.
  • Seit 1989 hat die Discount-Usability-Bewegung demonstriert, dass schnelle und billige Usability-Methoden der beste Weg sind, die Qualität des Nutzererlebnisses zu steigern, weil die Entwickler sie während des gesamten Entwicklungsprozesses wiederholt verwenden können. Das ist aber nicht möglich, wenn es nur einen Meilenstein im Prozess gibt, der nach Usability-Input verlangt.

Agile-Methoden versprechen, an den vielen Stellen anzusetzen, an denen traditionelle Entwicklungsmethoden systematisch Barrieren gegen eine gute Usability-Praxis errichten.

Die Gefahren von Agile-Methoden

Die grösste Gefahr von Agile für die Systemqualität rührt aus der Tatsache, dass diese Methode von Programmierern vorgeschlagen wurde und hauptsächlich auf die Implementierungsseite der Systementwicklung abhebt. Das führt dazu, dass sie oft das Interaktions-Design vernachlässigt und als Nebeneffekt des Kodierens betrachtet. Dies widerspricht natürlich der gesamten Erfahrung der letzten 30 Jahre, in der die Bedeutung des Nutzererlebnisses in der Systementwicklung ständig gewachsen ist, während wir uns von Zentralrechnern über PCs bis hin zum Internet entwickelt haben. In dem Masse, in dem sich die Nutzerbasis und die Anwendungsfälle ausgedehnt haben, ist der Bedarf nach erstklassiger Usability gewachsen.

Um ein hochwertiges Nutzererlebnis zu konstruieren, brauchen die Entwicklungs-Teams Methoden für Interaktionsdesign und Usability. Kleinere Teams brauchen nicht unbedingt ausgewiesene Designer und Usability-Profis. Es reicht völlig aus, wenn die Entwickler sich mit Interaktions-Design und Usability beschäftigen. Aber das Team muss diese beiden Bereiche ausdrücklich als Komponenten der Entwicklungsmethodik anerkennen, gleichgültig ob die Leute Design oder Usability als Hauptjob machen oder nur als eine der zahlreichen Rollen, die sie besetzen.

Ein Projekt, das Interaktions-Design und Usability ernst nimmt, muss ihnen ähnlich viel "Spielgeld" zuweisen (das heisst Ressourcen) wie dem Kodieren.

Ein anderes Problem besteht darin, dass bei Agile die Entwicklung eines Produktes in kleinere Abschnitte zersplittert wird, von denen immer nur einer fertig gestellt wird. Ein solcher Ansatz birgt das Risiko, dass er das Konzept eines integrierten Nutzer-Gesamterlebnisses unterminiert, bei dem die verschiedenen Funktionen konsistent zusammenarbeiten und den Nutzern dabei helfen, ein zusammenhängendes konzeptuelles Modell des Systems zu entwickeln. Schlimmstenfalls sieht die Nutzeroberfläche am Ende wie ein Flickenteppich aus.

Um das zu vermeiden, können die Teams Storyboards und Prototypen entwickeln, die die Architektur der Nutzeroberfläche beinhalten, und diese Werkzeuge als Referenzpunkte für das Design einzelner Funktionen verwenden. Um grosse Zeitverluste zu vermeiden, können die Teams einfache Prototypen - wie zum Beispiel Papierprototypen - entwickeln, die keine Kodierung benötigen. So wie wir es immer gesagt haben.

Agile-Teams bauen ihre Funktionen normalerweise während ziemlich kurzer "Sprints" von rund drei Wochen. Bei so engen Deadlines kommen die Entwickler in Versuchung, die Usability auszulassen, weil sie annehmen, dass für Tests und Nutzerforschung zu wenig Zeit sei.

Die Lösung dafür ist eine dreifache:

  • Ziehen Sie Usability-Aktivitäten wie Nutzertests in wenigen Tagen durch. Es lohnt sich, die Tests schon dann zu planen, wenn Sie noch nicht genau wissen, was testbereit sein wird. Wöchentliche Tests reichen völlig aus und verschaffen Ihnen einen narrensicheren Weg, mehrere Nutzer-Feedback-Runden in den kürzesten Sprint zu integrieren.

    • Wir bieten einen Drei-Tages-Kurs an: wie man eine komplette Runde von Nutzertests durchzieht, bei denen wir das Team wirklich am eigenen Projekt testen. Für diese Art von schnellen Tests brauchen Sie nur einen Tag. Und Sie brauchen weniger als einen Tag, um die Tests vorzubereiten und die Ergebnisse zu analysieren.

  • Die erfolgreichsten Teams fahren einen zweigleisigen Ansatz, bei dem die Arbeit am Nutzererlebnis der Implementierungsarbeit stets einen Schritt voraus ist. Deshalb ist zu dem Zeitpunkt, wenn die Teams anfangen, eine Funktion zu entwickeln, die erste Arbeit am Nutzererlebnis bereits abgeschlossen.
  • Schliesslich brauchen wir noch grundlegende Nutzerforschung, die über die Entwicklung von Funktionen hinausgeht. Idealerweise führt eine Organisation dieser Arbeit aus, bevor ein Entwicklungsprojekt startet. Auch sollten grössere Unternehmen Grundlagenwissen über die Arbeitsabläufe der Nutzer, Personas und Usability-Richtlinien ausserhalb einzelner Projekte bereithalten, damit es jahrelang über viele Projekte hinweg wiederverwendet werden kann.

Wie man dafür sorgt, dass Agile und Usability funktionieren

Es gibt gute Gründe für die Annahme, dass Usability und Agile-Entwicklungsmethoden zusammenarbeiten und die Qualität des Nutzererlebnisses verbessern können:

  • Agile bietet viele Gelegenheiten, Probleme mit traditionellen Entwicklungsmethoden zu überwinden, die die Usability schon seit langem behindern.
  • Wenn man Agile eng auslegt, als Programmiermethode und nicht als systematische Entwicklungsmethode, könnte das den Fortschritt der letzten Dekade bei der Integrierung von Usability und Entwicklung zerstören. Doch es gibt, wie oben ausgeführt, Wege, diese Gefahren zu vermeiden. Wenn die Teams die Gefahren ausdrücklich als Probleme anerkennen, müssen sie die Produktqualität nicht schädigen.
  • Ausserdem wissen wir aus unserer Forschung, dass viele Unternehmen im kalten Wasser gelernt haben, wie es geht - wie man die Agile-Methodik übernimmt und dabei mit der qualitätsorientierten Systementwicklung im Einklang bleibt.

Diese Einschätzung der Chancen, Gefahren und empirischen Fakten basiert auf zwei Forschungsrunden:

  1. einer Umfrage bei 105 Design- und Entwicklungs-Profis
  2. tief gehenden Fallstudien mit Agile-Projekten bei 12 Unternehmen

Die Daten haben zwar viele Chancen aufgezeigt, aber wir haben auch mehrere Fälle mit schlechten Ergebnissen gefunden. Das zeigt, wie wichtig es ist, dass die Unternehmen sich ausdrücklich mit der Integration von Agile und Usability auseinandersetzen.

Für Nutzererlebnis-Praktiker, die Agile-Teams unterstützen, liegt der grösste Wechsel in der Denkweise. Mit guten, allgemeinen Kenntnissen zum Nutzererlebnis verstehen Sie, wie Sie traditionelle Design- und Evaluationsmethoden abwandeln müssen, um den verschobenen Fokus Ihres Agile-Teams zu treffen. Letztendlich aber müssen Sie, um Erfolg zu haben, an sich selbst glauben und zugleich Agile-Entwicklungskonzepte einbeziehen.

Wenn Sie bereit sind, Ihre Praktiken zu ändern und die Verantwortung zu übernehmen, gibt es grossartige Gelegenheiten, Ihre Effektivität und Ihre Wirkung auf die Teams, die Sie unterstützen, zu steigern.

 

© Deutsche Version von Jakob Nielsens Alertbox. Institut für Software-Ergonomie und Usability AG. Alle Rechte vorbehalten.

Kommentare auf diesen Beitrag

    Keine Kommentare

Kommentar hinzufügen

Die mit * gekenzeichneten Felder sind zwingend auszufüllen