Truck Number
Kennzahl im Risikomanagement
From Wikipedia, the free encyclopedia
Die Truck Number (teils auch Bus-Faktor oder Lotto-Faktor) ist eine Kennzahl aus dem Risikomanagement zur Abschätzung von Projektrisiken. Die Truck Number ist jene Zahl an Personen, die mindestens ausfallen (im übertragenen Sinne „vom Bus/Lkw überfahren werden“) müssen, damit ein Projekt scheitert oder zumindest nicht mehr vorangebracht werden kann.[1][2]
Eine niedrige Truck Number zeigt an, dass die Informationen, Fähigkeiten etc. innerhalb eines Projektes auf wenige Personen konzentriert sind. In so einem Projekt kann bereits der Ausfall weniger Personen, im schlimmsten Fall der Ausfall einer einzigen Person das Vorankommen eines Projekts gefährden. Eine hohe Truck Number hingegen zeigt an, dass die Informationen, Fähigkeiten etc. innerhalb eines Projektes breit gestreut sind. Der Ausfall einzelner Personen gefährdet das Vorankommen eines Projekts nicht.
Die Kernfrage zur Bestimmung der Kennzahl lautet:
“How many or few would have to be hit by a truck (or quit) before the project is incapacitated?”
„Wie viele oder wenige müssten von einem Lastwagen überfahren werden (oder kündigen), ehe das Projekt lahmgelegt ist?“
Analog ist der Begriff Bus-Faktor zu verstehen. Die Bezeichnung als Lotto-Faktor geht davon aus, dass ein Mitarbeiter nach einem (sehr hohen) Lottogewinn spontan kündigt und nicht mehr am Projekt mitarbeitet.
Zu beachten ist, dass in Abhängigkeit davon, welche konkrete Information, Fähigkeit etc. man untersucht, verschiedene Werte ermittelt werden können (zum Beispiel 3 Personen mit Fähigkeit A, aber nur 2 mit Fähigkeit B). Für das Gesamtprojekt zählt nur die niedrigste der über alle Informationen und Fähigkeiten ermittelten Zahlen. Das ergibt sich aus der Feststellung, dass im ungünstigen Fall eben der Ausfall genau dieser wenigen Personen reicht, um das Projekt lahmzulegen; die Tatsache, dass für andere Informationen und Fähigkeiten eine bessere Redundanz existiert hätte, wäre in diesem Fall irrelevant.
Aussagekraft
Für kleine Projekte kann die Truck Number als Indikator für das Risiko einer Blockade bis hin zum Scheitern des Projektes dienen, insbesondere wenn die Gesamtzahl der Personen gering ist.
In großen und hinreichend komplexen Projekten kommt die Aussagekraft der Truck Number jedoch schnell an ihre Grenzen. Je mehr Fähigkeiten und Informationen ein Projekt benötigt, desto schwieriger wird es, die Truck Number hoch zu halten. Bei einer großen Anzahl von benötigten Fähigkeiten kann die Truck Number sehr schnell 1 werden, auch wenn insgesamt tausende Personen in einem grundsätzlich sehr redundant ausgelegten Projekt arbeiten.
Ebenso macht die Zahl keine Aussage darüber, wie schwierig es ist, ein durch den Ausfall von Personen zum Stillstand gekommenes Projekt durch die Ergänzung neuer Mitglieder wieder zu entblocken. In Bezug auf Informationen kann eine sorgfältige Projekt-Dokumentation das Risiko des Scheiterns minimieren. In Bezug auf die Fähigkeiten muss berücksichtigt werden, wie einfach oder schwierig es ist, neue Teammitglieder mit denselben Fähigkeiten zu finden.
Bei der Ermittlung der Truck Number können zwar die konkreten Risikobereiche gut identifiziert werden, eine Aussage über die Wahrscheinlichkeit und Konsequenzen eines Ausfalls lässt sich jedoch mit zunehmender Projektgröße immer schlechter treffen.
Der Beantwortung dieser Frage versucht sich der Truck Factor zu nähern. Er ist ein von Kent Beck vorgeschlagener Wert, der die Wahrscheinlichkeit des Scheiterns eines Projektes bei Ausfall eines Mitarbeiters beschreibt, und ist eine reelle Zahl zwischen 0 und 1. Der schlechteste Wert ist 1, denn er besagt, dass jedes Teammitglied ein unverzichtbarer Spezialist ist und damit der Ausfall eines (beliebigen) Teammitglieds das Projekt zum Scheitern bringt. Eine nur vereinzelt geringe aber allgemein hohe Redundanz spiegelt sich in einem kleineren Truck Factor wieder. In einem großen Projekt mit grundsätzlich viel Redundanz und einer einzigen nicht-redundanten Fähigkeit ist der Truck Factor sehr niedrig, obwohl die Truck Number 1 ist.
Um das Risiko zu umgehen oder abzuschwächen, werden in der agilen Softwareentwicklung Techniken wie Paarprogrammierung, Mobprogrammierung oder Collective Code Ownership verwendet, mit Hilfe derer das Wissen über jeden Teil des Quellcodes breit im Team verteilt wird.
Literatur
- Michele Marchesi, Giancarlo Succi, Don Wells, James Donovan Wells, Laurie Williams: Extreme Programming Perspectives. Addison-Wesley, Boston u. a. 2003, ISBN 0-201-77005-9.
- Laurie Williams, Robert Kessler: Pair Programming Illuminated. Addison-Wesley, Boston u. a. 2002, ISBN 0-201-74576-3.
- Kent Beck: Extreme Programming. Das Manifest. Addison-Wesley, s. l. 2000, ISBN 3-8273-2139-5.