Greifen wir die Antwort gleich vorweg: Je größer das Software-Projekt, desto eher führen agile Prozesse zum gewünschten Ergebnis. Doch was gibt es dabei als UX-Designer zu beachten? Werfen wir heute einen Blick darauf.
Je weiter wir in der Vergangenheit der Software-Entwicklung zurückreisen, desto mehr stellen wir fest, dass in den damaligen 70ern selbst komplex erscheinende Betriebssysteme von nur wenigen tüchtigen Entwicklern geschrieben werden konnten, Zeile für Zeile – man denke nur an die Geburtsstunde und den späteren kometenhaften Aufstieg von Microsoft durch Paul Allen und Bill Gates. Erst mit zunehmender Komplexität wurde mehr Entwickler-Power erforderlich, die auch über längere Strecken hinweg ein möglichst klar visualisiertes Projekt umzusetzen gedachte.
Die Wasserfall-Methode – eine kurze Geschichte
Der Grundgedanke lautete damals schon: Gute Planung führt zu guten Ergebnissen. Je minuziöser die Vorausplanung, desto besser also auch das Resultat. Man ahnt schon, dass dies nicht der Weisheit letzter Schluss sein konnte … Doch das kam erst später. So führte man einen Schritt nach dem anderen hintereinander aus bis er abgeschlossen war. Ist das passiert ging es weiter zum nächsten und dann zum darauffolgenden. Dieses Vorgehen trägt den sinnbildlichen Namen Wasserfall-Modell und funktionierte zuweilen auch gut.
Das Problem entstand, als die Größe in alle Dimensionen zunahm: Mehr Entwickler, mehr Funktionen, mehr Code, mehr Abhängigkeiten, mehr Komplexität usw. Was über Jahre hinweg erarbeitet wurde musste nun kurz vor Abgabe zusammengebaut werden, woraus sich ganz neue Fragestellungen ergaben. Denn erst in dieser Phase kamen Gedanken und Probleme zu Vorschein, an die vorher niemand auch nur dachte. Fehler und Ungereimtheiten offenbarten sich, unterschiedliche Standards und Inkompatibilitäten erschwerten die Arbeit – die Folge: Man musste Fehler akzeptieren, auf Features verzichten oder schlicht länger daran arbeiten, als eigentlich gewollt (und geplant).
Agile Projektentwicklung – altes Ziel, neues Konzept
Der Wunsch nach guten Resultaten war nach wie vor gegeben, doch versuchte man, anders als in den 70ern, in den 90ern den Herausforderungen mit Agilität entgegenzutreten – dem lateinischen Wort für Beweglichkeit und Flinkheit. Anstelle stur das Ziel vor Augen zu haben und Stein für Stein aufeinanderzusetzen, drehte man den Ansatz um und legte so wenig Zwischenziele wie möglich vorher fest: Das Try-and-Error-Prinzip leistete gute Dienst, Code wurde in wiederkehrenden Zyklen erarbeitet und somit in iterativer Weise, was im Grunde einen wiederholenden Vorgang beschreibt, so lange angepasst, wie es eben notwendig war. Man werkelte fleißig vor sich hin und baute in sich geschlossene Teilsysteme. So fand auch die agile Scrum-Methodik viel Zuspruch und Beliebtheit, da sie sich im Vorgehen an Sprints orientiert und ein äußerst flexibles Projektmanagement zulässt. Idealerweise konnte Menschen mit vollkommen unterschiedlichen Skills dadurch am Ende ein potenziell lieferbares Ergebnis, Produkt, Feature oder Service präsentieren.
In der Praxis: Teilprojekte als Teamarbeit
Derartige Sprints werden zum Beispiel über Kanban-Boards organisiert (wie der erstellte User Interface-Prototyp oben zu Beginn des Artikels exemplarisch visualisiert) und sind Phasen, die zwischen 1 und 4 Wochen dauern können – üblich sind hingegen zwei, mit dem Ziel, eine lauffähige Software als Teil eines großen Ganzen zu entwickeln, das am Ende des Sprints zusammengesetzt wird. Tests und Erprobungen werden durchgeführt und der Funktionsumfang anschließend auf den Prüfstand gestellt. Für die Testphase bietet es sich an, eine kleine Stammgruppe aufzubauen, die sich für etwaige Vorhaben kurzerhand rekrutieren lassen. Das lässt sich dann auch gut an fixen Tagen in wiederkehrenden Rhythmen im Kalender einplanen.
Stimmt alles kann das Neue implementiert werden. Treten hingegen Fehler auf, entdeckt man diese glücklicherweise zeitnah und kann frühzeitig entsprechend Korrekturen einleiten. Das Ergebnis ist schnell(er) sichtbar, kurzfristige Ziele können somit zügig erreicht werden und all diese Glücksmomente führen überdies dazu, dass man gerne am Ball bleiben möchte. Erkennbar ist, bei dieser Technik und vor allem auch entscheidend, dass es sich hierbei um eine Team-Arbeit handelt – keinen Soloauftritt.
Bei der Erstellung neuer Features für unser E-Learning-Portal TutKit.com erarbeiteten wir im UX-Team, parallel und zusammen mit den Developern auf diese Weise neue Funktionen, die zu Release noch nicht vorhanden waren, wie:
- Ermäßigte und barrierefreie Zugänge für Anwender, die über Partnerschaften zu uns kommen
- Newsletter-System mit Berücksichtigung persönlicher Nutzer-Präferenzen
- Newsletter-Funnel als Schleife, in die Nutzer je nach Interessenschwerpunkt aufgenommen werden
- Die Optimierung des Kündigungsprozess mit dem Ziel, die Quote der Abo-Kündigungen durch attraktive Gegenangebote zu reduzieren
- Neue Backend-Funktionen, zum Beispiel zur statistischen Auswertung
- Prozesse, um mehr Besucher in den Call to Action zu führen (kostenlose 3-tägige Testphase)
- usw.
Zusammenfassung
Ist die Hauptaufgabe und Kernfunktion also verständlich definiert, werden die Arme hochgekrämpelt und man beginnt mit der Umsetzung. Für die anschließende Konzeption arbeiten Devs und UXler konzeptionell zusammen. So wird sichergestellt, dass die Umsetzung erfolgreich ist und das Ergebnis umgekehrt auch unter Usability-Aspekten geprüft werden kann. Erkenntnisse können iterativ in die nächste Runde einbezogen werden. Besonders umfangreiche Software, Web-Apps, native Apps und Online-Dienste werden bevorzugt agil erarbeitet und auch auf diese Weise mit neuen Funktionen up2date gebracht. Je größer das Projekt, umso wertvoller offenbart sich die Entscheidung in der Vorgehensweise auf agile Projektentwicklung zu setzen – womit sie auch das breite Feld durchdringt: Von kleinen Agenturen bis hin zu großen Firmen findet sich in der Praxis dafür reichlich Zustimmung. Doch auch der umgekehrte Fall tritt auf und Ablehnung (auch in großen Firmen) ist keine Seltenheit, denn Transparenz und Kontrolle rutschen erstmal bei dieser Methodik zur Seite.
Agiles Vorgehen verlangt einem neue Sichtweisen ab. Ebenso die Fähigkeit, etablierte Gewohnheiten getrost unterlassen zu können: zum Beispiel das Anfertigen umfangreiche Dokumentationen – simple Notizen reichen oftmals. Fokussiertes und lösungsorientiertes Denken hilft mehr, anstelle links und rechts am Wegesrand jeden Gedanken den geistigen Rucksack zu laden. Und schnelles Umsetzen mit Praxistests erspart oftmals langes theoretisches Grübeln. Doch einen Gedanken sollte man bei all dem Glanz und Gloria im Kopf behalten: Nicht immer ist agile Projektentwicklung der heilige Gral bei der Projektarbeit – manchmal tut es auch schlicht die gute Wasserfall-Methodik.