Suche

Performancemanagement in agilen Unternehmen

Die Goldenen Regeln

Agiles Performancemanagement basiert auf einigen wenigen, aber notwendigen Regeln, die gewährleisten, dass wir obige Fragen beantworten können. Sollten Sie keine Regeln mögen, nennen Sie sie einfach Prinzipien. Wichtig ist allerdings, dass alle befolgt werden:

  • Kontinuität im Umgang mit der Performance ist der erste unserer Bausteine. Schneller reagieren zu können, bedeutet, jederzeit die Information zur Verfügung zu haben, die man braucht. Performancemanagement ist in allen Phasen des Anwendungslebenszyklus präsent.
  • Der Mensch zuerst. Das hört sich jetzt sehr altruistisch an, wird aber sehr oft vergessen. Viele Unternehmen haben sich stark darauf fokussiert, den aufwendigen – und oft teuren – Prozess des Performancemanagements zu Tode zu optimieren. Dies führt zu Testcentern, die weder mit der Entwicklung noch mit der Produktion Kontakt haben und rein auf Durchsatzoptimierung ausgelegt sind. Hier leidet der Informationsfluss oft so stark, dass vielen Beteiligten die nötige Information für ihre Arbeit fehlt.
  • Offenheit ist ein weiterer wichtiger Baustein. Offenheit bedeutet, dass jeder Mitarbeiter Zugang zu den Informationen besitzt, die für ihn wirklich wichtig sind – und zwar unmittelbar. Die Praxis zeigt, dass es oft sehr schwierig für Architekten ist, Informationen aus der Produktion zu bekommen. Gerade diese Informationen aber ermöglichen es aber erst, bessere Architekturentscheidungen treffen zu können.
  • Im gleichen Atemzug ist auch Feedback wichtig. Je unmittelbarer in der Entwicklung die Auswirkungen von Designentscheidungen und Codeänderungen auch aus Performancesicht erkennbar sind, desto schneller kann gegengesteuert werden. Passiert dies aber erst sehr viel später, bleibt oft nur mehr Schadensbegrenzung übrig. Passieren die ersten Performancetests erst wenn die Entwicklung beendet ist, ist es eigentlich schon zu spät.
  • Stellen Sie einen Bezug zwischen dem geschäftlichen Nutzen und der Performance Ihrer Anwendung her. Sehr oft wird im Umfeld von Performance von technischen Metriken gesprochen. Dies ist auch natürlich, da es nun einmal um technische Aspekte einer Anwendung geht. Letztendlich geht es aber um den geschäftlichen Mehrwert einer Anwendung. Dieser und auch dessen Zusammenhang mit Performance sollten allen Beteiligten bewusst sein. Welchem Argument wären Sie mehr zugänglich: a) unsere Produktwebsite muss 300 Millisekunden schneller laden oder b) unsere Produktseiten sind um 20 Prozent langsamer, als die unseres Mitbewerbers, und wir sehen, dass die durchschnittliche Anzahl der Seitenaufrufe nach unten geht.
Wohin soll die Reise gehen?

Wie Sie schon zwischen den Zeilen lesen können, geht es bei agilem Performancemanagement darum, dass alle Beteiligten über alle Phasen hinweg zusammenarbeiten. Wie sieht das allerdings in der Praxis aus? In agilen Projekten ist immer mehr zu sehen, dass Testabteilungen in die Entwicklung integriert werden. Die Rolle des eigentlichen Testers tritt dabei immer stärker in den Hintergrund. Stattdessen entwickeln sich die Tester mehr und mehr zu Experten im Bereich der Testautomatisierung. Sie unterstützen also die Entwicklung dabei, besser und schneller automatisiert Testen zu können.

Bei immer häufigeren Produktions-Deployments ist es auch notwendig, den Betrieb näher zur Entwicklung zu bringen. Der operative Betrieb wird somit ein natürlicher Bestandteil der agilen Entwicklung. Dies ist vor allem im Bereich von Performance wesentlich, da nur der Betrieb über Echtdaten verfügt. Zudem ist dieser dann auch besser auf Änderungen vorbereitet und wird nicht erst im tatsächlichen Betrieb davon überrascht.

Aus Product-Owner-Sicht muss einem bewusst werden, dass Performance nicht etwas ist, das man später hinzufügt. Die Definition von „Done“ muss in diesen Anforderungen bereits enthalten sein. Das ist in der Praxis oft schwer abzuschätzen – vor allem bei neuen Anwendungen. Speziell für Webanwendungen gibt es hier aber zahlreiche Benchmarks, auf die zurückgegriffen werden kann. Im Zweifelsfall soll sich die Performance zumindest nicht verschlechtern, und wenn, dann sollte schon ein massiver geschäftlicher Mehrwert gegeben sein. Dies widerspricht sich in der Praxis allerdings meistens.

Übrigens sind User Stories à la „Performance der Anwendung verbessern“ etwa gleich sinnvoll wie „Usability erhöhen“. Diese nichtfunktionalen Anforderungen müssen klar definiert werden und sind Teil der einzelnen Use Cases und nicht getrennt davon zu sehen.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.