Selbst Großunternehmen, die viel Geld in die Applikationsentwicklung investieren, können die Ergebnisse ihrer IT-Projekte häufig nicht exakt messen und bewerten. Das jedenfalls behaupten Michael Huskins, James Kaplan und Krish Krishnakanthan vom Beratungsunternehmen McKinsey. Der Grund: Firmen verlassen sich weitgehend auf Input-orientierte Messgrößen. Dazu zählen die Stundensätze der IT-Entwickler, Abweichungen vom veranschlagten Budget oder der Prozentsatz an Entwicklungsleistung, die zu bestimmten Lieferterminen erbracht ist. Diese Kenngrößen seien zwar nützlich, weil sie die Leistung der Applikationsentwicklung anzeigen.
Wenn es jedoch darum geht, die von einem Entwicklerteam innerhalb eines bestimmten Zeitraums an einen Fachbereich gelieferte Funktionalität zu bestimmen oder die Produktivität der Entwicklertruppe zu messen, tappen IT-Organisationen meist im Dunklen. Um die Effektivität bei der Anwendungsentwicklung zu erhöhen, raten die McKinsey-Autoren, eine Kombination der Output-basierten Kenngrößen "Use Case" (UC) und "Use Case Points" (UCS) einzusetzen.
Anwendungsentwicklung produktiver machen
Ein Use Case oder Anwendungsfall ist eine logische Methode, um funktionale und technische Anforderungen für Entwicklungsprojekte strukturiert zu sammeln. In Use Case Points wird dagegen die Anzahl der ausgelieferten Softwarefunktionalitäten erfasst. Ein UC beschreibe dabei ein Szenario, in dem ein Endanwender oder ein anderes IT-System mit einer Applikation interagiert sowie die Transaktionen, welche die Anwendung ausführt. Ein UC besteht zum Beispiel aus den Einzelschritten, die ein Bankkunde durchführt, um sich an einer Online-Banking-Anwendung anzumelden und einer Transaktion wie einer Überweisung, wofür die Applikation auf Informationen zugreift, die in einer Datenbank gespeichert sind. Rund um einen UC lassen sich dann technische Anforderungen und Design-Entscheidungen für eine Anwendung gruppieren.
Diese Struktur beschleunigt innerhalb des Lebenszyklus der Softwareentwicklung die Phase "Sammeln von Anforderungen", gleichzeitig wird das Risiko reduziert, dem Business falsche Funktionalität zu liefern. Dadurch würden den Autoren zufolge zeit- und kostenintensive Change Requests sowie Nacharbeiten während der Design- und Build-Phase vermieden. Zugleich lassen sich mit Use Cases funktionale Testfälle einfacher schreiben und durchführen.
Dagegen werden die Use Case Points aus den Informationen abgeleitet, die in den Use Cases gesammelt sind. UCP-Kalkulationen setzen sich zusammen aus der Anzahl der Transaktionen, die eine Applikation ausführt, und der Zahl der Personen oder IT-Systeme, die mit dieser Anwendung interagieren. Die Rohzahlen werden dann aufbereitet, indem darin auch die technische Komplexität einer Anwendung oder der Prozentsatz des zu modifizierenden Codes einbezogen werden. Für die Berechnungen sind die Daten zudem mit den Top-Down-Anforderungen aus dem Management und den Fachbereichen abzugleichen. Auf dieser Grundlage lässt sich dann in drei Schritten eine effiziente Applikationsentwicklung umsetzen.
Schritt 1: Score an Funktionalitäten definieren
Für jedes einzelne Entwicklungsprojekt ist in Form eines "Score" die relative Zahl der Softwarefunktionalitäten festzulegen, die ausgeliefert werden sollen. Eine hohe Übereinstimmung zwischen UCP-Kalkulation und dem vorgegebenem Score legt nahe, dass sich mit der UCP-Methode der Output und damit auch die Produktivität verschiedener Entwicklungs-Teams verlässlich messen und somit auch vergleichen lassen. Die Berechnungen können im Entwicklungs-Lebenszyklus einer Applikation bereits zu einem frühen Zeitpunkt durchgeführt und dann sukzessive verfeinert sowie angepasst werden.
Dabei lassen sich UCP-Kalkulationen sowohl in Verbindung mit der klassischen Wasserfall- als auch mit agilen Entwicklungsmethoden wie Scrum einsetzen und durchführen.
Schritt 2: Piloten aufsetzen, Prozesse definieren, IT-Tool auswählen
Unternehmen, die UCs und UCPs erfolgreich übernommen haben, beginnen in der Regel mit einem Piloten, in den verschiedene Teams und neue Entwicklungsprojekte eingebunden sind, um den Ansatz zu testen. Damit das Ganze im operativen Geschäft funktioniert, sind die entsprechenden Prozesse zu definieren und zugleich ein IT-Tool auszuwählen, in dem sich UCs erfassen, UCPs kalkulieren und die Prozesse von allen Beteiligten standardisiert durchführen lassen. Ist das Design des Piloten komplett, werden die Teams damit vertraut gemacht und dieser in einem aktuellen Projekt eingesetzt, damit die Prozesse und Tools nachjustiert werden können.
Schritt 3: Rollout mit Change Management durchführen
Danach erfolgt unternehmensweit der Rollout in mehreren Wellen. Erfolgskritisch ist, über den gesamten Prozess vom Pilot bis hin zum Rollout, dass auch das Change Management beachtet und die Vorzüge der neuen Methoden gegenüber den Geschäftsbereichen kommuniziert werden. Letztere reagieren in der Regel sehr sensibel darauf, wenn sich die Art und Weise ändert wie Anforderungen an eine Applikation gesammelt werden. Auch die Führungskräfte müssen das neue Verfahren unbedingt nutzen, damit es intern allgemein akzeptiert wird. Außerdem muss der Anschein vermieden werden, dass UCP-Kalkulationen dazu benutzt werden, um anhand der Ergebnisse Applikationsentwickler zu belohnen oder zu bestrafen. Wäre dies der Fall, würden diese die neuen Methoden ablehnen.