Sie kennen die Situation: der letzte Review kurz vor Release. Der PO sitzt gespannt wie ein Flitzebogen vor dem Team und lässt sich die neuesten Features zeigen. Dann plötzlich: BAM! Ein unbedienbares Feature jagt das Nächste. Den Entwicklern gehen in den Ladepausen die Witze aus. OMG! Das ist sowas von nicht releasefähig. Fragezeichen in den Gesichtern der Entwickler. Tut doch alles, oder?

Ist doch gar nicht so schlimm

„Tut doch alles“ ist die Frage nach der Priorität von Usability und Performance. Ein MVP Feature muss nicht super bedienbar sein. Auf der anderen Seite bekommt man nur einmal die Chance einen ersten Eindruck zu hinterlassen. Davon ausgehend, dass es immer einen Konkurrenten gibt, gewinnt am Markt nicht die beste Funktion, sondern die am besten bedienbare.

Das Pfund Fleisch des Benutzers

Trotzdem werden Usability und Performance gerne in den Bereich der technischen Schulden verschoben: fixen wir später. Eine gute Regel in der Softwareentwicklung lautet: Performanceoptimierungen immer erst ganz am Ende. Im Grunde ist Usability die Performanceoptimierung der Bedienbarkeit. Andererseits hat alles was der Kunde bedient und anfasst eine starke Signalwirkung. Dazu kommt: man hat nur eine Chance einen ersten Eindruck zu hinterlassen.

Warum Usability auch Performance ist

Ich definiere Performance hier nicht nur als nackte 100.000-Datensätze-in-30-Sekunden-Metrik, sondern auch in Bezug auf die Fähigkeit eines Benutzers bestimmte Anwendungsfälle nicht nur überhaupt, vollständig und korrekt, sondern auch in angemessenen Zeit zu erledigen. Weil das aber meistens zu Verwirrung führt, benutze ich weiter beide Begriffe.

Ich muss nur wissen, wo es steht

Eventuell haben Sie Performance und Usability als nichtfunktionalen Anforderungen sogar dokumentiert und als Entwicklerrichtlinie bekannt gemacht. Ich meine, das ist doch Best-Practice, oder? Die Akzeptanzkriterien sollen ja auch nicht seitenlang werden. Ich bewundere Ihren Optimismus, aber solche Guidelines sind wie Handbücher.

Ticket Disclaimer sind für den Popo

Selbst wenn sie die beiden Standardsätze „die Anwendung muss sich gut bedienen lassen“ und „die Anwendung muss performant sein“ bei jeder Story als Akzeptanzkriterien aufnehmen, erreichen Sie leider nichts. Diese weichen, nicht messbaren Kriterien werden einfach ignoriert. Wenn sie in jedem Ticket stehen schon gleich dreimal bzw. n-mal

Bauen heißt nicht benutzen

OK, und was ist mit gesundem Menschenverstand? Manch ein PO mag da sagen: aber das sieht doch ein Blinder mit Krückstock, dass das so Bockmist ist. Wirklich? Im Gegensatz zum PO stellen sich Entwickler selten vor, wie sie konkret mit einem Feature arbeiten. Entwickler zerlegen jedes Feature automatisch in einzelne Verarbeitungsschritte. Während für den PO die Story Teil eines Workflows ist, liegt bei Entwicklern der Fokus stets auf dem konkreten nächsten Schritt. Dazu kommt auch noch: viele Entwickler benutzen tatsächlich ihre eigene Software nie.

Das steht so nicht in der Story

Aber unsere Testabteilung, die muss das doch sehen. Naja, wenn die Zeit haben für exploratives Testen, sicher. Im Allgemeinen richten sich die Tester aber nach den Tickets und den Akzeptanzkriterien. Das führt unter anderem dazu, dass auch ein Tester jeden Schritt einzeln prüfen, anstelle zielgerichtet eine Aufgabe mit der neuen Funktion zu erledigen. Das ist ganz natürlich, weil die meisten Storys eben gerade nicht den Workflow beschreiben. Dieser größere Zusammenhang geht beim Splitten üblicherweise verloren. Dazu kommt das agile Tester neben Clubmate unglaublich auf automatisiertes Testen stehen. Usability ist aber unmöglich durch automatisiertes Testen überprüfbar. Deshalb fällt schlechte UX durch das Testraster.

Performance ist eine Reifensorte

Aber zu langsam, das merkt doch wirklich jeder. Leider nein. Performance Messungen sind nur mit konkreten Mengengerüsten und Zielvorgaben möglich. Mein Lieblingsbeispiel aus der Praxis: der erste Kunde importiert 15.000 Produkt Datensätze. Dauert pro Produkt 6 Sekunden. Langsam, aber ausreichend, weil das über Nacht läuft. Der nächste Kunde allerdings importiert 10 Millionen Produktdatensätze. Ja, ich denke dasselbe was Sie da denken. Dem hätte ich das System so nicht verkauft. Danke, ich gebe es an den Vertrieb weiter.

Schneller, effizienter, einfacher: für 0 EURO

Sie können einen gestandenen Softwareentwickler gerne mal fragen, wie gerne er Optimierungen abschätzt. Kommt gleich hinter Bugs schätzen. Wenn sie ihr Team schätzen lassen, müssen Sie supergenaue Vorgaben für den Zielbereich geben. Das alleine ist schon manchmal richtig viel Arbeit wenn da nicht nur Wunschzahlen stehen sollen. Deswegen killen Optimierungstickets auch ihren Releasetermin. Dagegen gibt es aber ein Mittel.

Die heilige Dreifaltigkeit

Agil bietet uns eine prima Möglichkeit um mit Komplexität und Unwägbarkeiten umzugehen. In diesem Fall nutzen wir Story Splitting. Als zweites Mittel nutzen wir Timeboxing. Und als Prozess nutzen wir den kontinuierlichen Verbesserungsprozess. Dadurch können Sie alle Quickwins bei der Optimierung ziehen, und verlieren maximal die Arbeit für einen Slot in der Länge ihrer Timebox.

Praktische Optimierungsorganisation

Anstelle die Komplexität mit nichtfunktionalen Anforderungen oder Akzeptanzkriterien in den Storys zu erhöhen, reduzieren wir sie einfach. Split 1: nichtfunktionale Anforderungen. Split 2: identifizieren und erstellen von Performance Anforderungen und -Daten. Split 3: Performanceoptimierung. Split zwei und drei so oft wiederholen bis die Optimierung nichts mehr bringt innerhalb der Timebox.

Wiederholungsanzahl und Komplexität

Wie oft Sie die Optimierung wiederholen müssen, ist ein Erfahrungswert in jedem Projekt. Die Dauer der Optimierungsslots ist stark abhängig von der Komplexität der Ursprungsstorys. Ich arbeite meist einfach mit zwei Slotgrößen für einfache und schwere Tickets. Das ist nicht perfekt, aber gut genug für eine Planung im Sprint oder auf dem Kanban Board. Bei Kanban haben sie zusätzlich noch den Vorteil, dass die Optimierungstickets quasi alle gleich groß sind.

Weitere Vorteile der heiligen Dreifaltigkeit

Durch diesen Dreiersplit des Tickets ergeben sich mehrere Vorteile. Die Erstellung der Performance Anforderungen kann von jemand anders übernommen werden. Dazu gehört auch die Bereitstellung von Testdaten. Die Performance Storys sind perfekt auf das Paretoprinziep und das Erreichen von Quickwins ausgerichtet. Sie können sogar lustigerweise den Kunden via Ranking über die Qualität bestimmen lassen. Der Kunde kann selber entscheiden, ab wann ihm die weitere Optimierung zu teuer im Verhältnis zum Nutzen ist.

Sollen Performancetests automatisiert werden von Anfang an?

Optimierung und Performancetests sind erstaunlicherweise meistens mit einer Zeit oder Durchsatzmessungen verbunden. Diese Messung von Hand vorgenommen beinhaltet das Ergebnis immer eine gewisse subjektiven Spielraum. Meistens ist der erste Optimierungsansatz auch noch nicht der perfekte Wurf. Und sehr häufig kommt es vor das man versucht selbst mit nicht 100-prozentiger Optimierung beim Kunden oder beim PO damit durchzukommen. Man wird wahrscheinlich die Aufgabe deshalb noch ein paar Mal durchführen müssen.

Performanceoptimierung als wiederkehrende Tätigkeit

Sobald die Kunden tatsächlich anfangen mit einer Lösung zu arbeiten erhöhen sich üblicherweise auf die Anzahl der Benutzer, die Anzahl der Transaktionen, die Datenmengen. Auch hier kann das Performance Meßszenario im Verlauf des Projektes sich verändern, leider meistens nach oben. Es bietet sich hier also direkt an bei festlegen der Performance Anforderungen und Tests und Messdaten auch gleich die Erstellung automatisierter Tests mit unterzubringen. Ich würde empfehlen beim Storys splitting diesen Ansatz einmalig zwischen Split zwei und Split drei einzufügen. Das spart auch sehr viel Zeit im Review wenn stichprobenartig die Optimierungsergebnisse demonstriert werden.

Wer hat aufgepasst? Usability lässt sich nicht automatisieren

Manchmal wünschte ich wirklich, ich hätte so ein Blitzdings. Sie haben mich erwischt. Aber ich wäre nicht ich, wenn ich hier nicht eine Lösung für sie parat hätte. Crowd Testing. Das ist nicht besonders teuer, erfordert aber etwas Beschäftigung mit dem Thema. Ich warte hier solange, während sie Google bemühen. [Zeit vergeht].

Der Test der Massen

So, jetzt wissen Sie ja was Crowd Testing ist. Ihre Aufgabe: bauen Sie Micro-Usecases auf, geben Sie ein zu kurzes Zeitlimit dafür vor und lassen Sie eine Horde komplett fremder Benutzer darauf. Eine kleine oder große Handvoll solcher Tests lässt sich in ein bis drei Tagen locker durchführen, mit etwas Übung. Ja, das kostet Geld, und auch noch externe Kosten. Aber immer noch viel weniger, als wenn sie interne Tester 100 mal solche Sachen machen lassen. Selbst wenn Sie viele Praktikanten und Azubis haben (haha)- die sind auch nicht immer so schnell oder direkt verfügbar.

In die Zukunft sehen

Bereits im Planing Poker sollte man die Frage stellen “ist das Performance kritisch?“. Wenn das der Fall ist, kann man die Storys mit einem entsprechenden Label kennzeichnen. Um jetzt nicht jedes Ticket damit zu überfrachtet ist es sinnvoll zwei oder drei Leitfragen zusätzlich zu stellen.

• Haben wir hier ungewöhnlich viele Daten im Vergleich zur Restanwendung, jetzt oder in Zukunft?
• Haben wir in ähnlichen Fällen schon einmal Performance Probleme gehabt?
• Ist das eine Hauptfunktion und wird sie vom Benutzer häufig verwendet und als kritisch eingeschätzt?
• Umkehrfrage: wäre diese Funktion total langsam, würde das den meisten Benutzern quer im Magen liegen?

Am Anfang sind diese Fragen sicher etwas mühselig, aber mit der Zeit gewöhnt sich das Team daran auch in dieser Dimension zu denken. Der PO kann auch von sich aus Storys schon mit einem entsprechenden Label während des Groomings kennzeichnen, gegebenenfalls mit einem Fragezeichen dahinter.

Wie sie mit der Aussage „das machen wir gleich richtig von Anfang an“ von Entwicklern umgehen als PO

Nein! Die meisten Storys laufen 3-5 mal durch ihr System bis sie gut sind. Wenn sie jedes Mal eine kleine Scheibe Optimierung mit dazu packen erreichen sie wesentlich mehr, als wenn sie von Anfang an direkt ein Riesending bauen. Das ist sogar eine Softwareentwickler Tugend. Aber Softwareentwickler hassen Optimierung und Quickwins Ansätze, weil das nach Pfusch aussieht. Versuchen Sie hier den Ehrgeiz und die Hecker Seite ihrer Entwickler anzusprechen: schaffte die Optimierung in der vorgegebenen Zeit, ein spielerischer Angaben. Genauso wie es Entwickler gibt die gerne Code Reviews machen, gibt es auch Entwickler die gerne diesen Optimierung Ansatz bzw. Prozess fahren.

Schnelles Lernen

Eventuell brauchen Sie diese ganzen Optimierungssachen nicht. Wenn sie Lean arbeiten, konzentrieren Sie sich darauf möglichst kleine Inkrement zu liefern und diese gleich zu validieren. Aber auch bei Lean gilt: je enger der Fokus desto weniger Zusammenhänge sieht man.

Tl;dr

Usability und Performanceoptimierung sind explizite Aufgaben. Usability und Performance ist beides Performance. Entwickler und Tester ignorieren nicht funktionale Anforderungen immer. Optimierung lässt sich durch Storys splitting in den Griff bekommen. Planen Sie Optimierung Zyklen aktiv mit ein. Markieren Sie kritische Storys im Vorfeld bereits.