Sind gute Schätzungen vor guten Anforderungen möglich? | Knowledge Department
 
Sie befinden sich hier: Blog  

Gute Schätzungen vor guten Anforderungen?

Sind gute Schätzungen vor guten Anforderungen möglich? Eine Schätzung ist ein Versuch, begründet Vermutungen über den zukünftigen Verbrauch einer Ressource anzustellen. Die Informationsgrundlage zum Zeitpunkt der Schätzung ist entscheidend für die Qualität einer Schätzung. In der Praxis liegen bei IT-Projekten die tatsächlichen Werte um bis zu 400% über oder unter den initialen Schätzwerten. Eine Abweichung, die  lax formuliert der  “GIGO”-Regel folgt, denn eine frühe Schätzung hat schlichtweg oft keine zufriedenstellende Informationsgrundlage.

Doch je früher die Schätzung vorliegt, desto angemessener kann auf eine gegebene Angebotslage reagiert werden. Wir alle kennen Projekte, in denen noch vor guten Anforderungen an das System Schätzungen (am Besten in 10 Minuten) abgegeben werden sollen. Skizzen, wage Ideen, bessere Konzepte und Phrasen wie “sollte halt so aussehen wie” sind typische Indikatoren für diesen Zeitpunkt. Die vom System verlangte Qualität lautet oft bestechend einfach: “Hauptsache es läuft bis zum Datum X.“

Jede Schätzung – und sei sie noch so ungenau – ist zu diesem Zeitpunkt besser als keine Schätzung. Dass zu einem frühen Termin die Informationsgrundlage (Anforderungen) oft nicht vorhanden bzw. sehr instabil sind, die Qualität der Schätzung somit ein hohes Risiko birgt, muss als Risiko betrachtet werden. Oft gilt fürs Management an dieser Stelle: geschätzter Abgabetermin in frühestens X Tagen = Abgabetermin in X Tagen („date driven estimates“). Das ist einfach, das ist positiv, aber leider auch eher unwahrscheinlich. Ausbaden muss dann diesen Trugschluss oftmals der Projektleiter.

Geben Sie zu jeder Schätzung deren Wahrscheinlichkeit an. Auch mit schlechten Anforderungen an das neue Projekt empfehlen wir als ersten Schritt “grobe Cluster” über den zu migrierenden/zu konvertierenden Daten und den neu zu entwickelnden Teilen in der Software zu bilden. Die identifizierten Cluster müssen für eine erste Schätzung getrennt betrachtet werden. So kann Migrationsaufwand etwa auf Stundenbasis bestimmt werden. Neu zu entwickelnde Bereiche hingegen können durch das “One File Model” der Funktionspunkt-Analyse geschätzt werden, indem identifizierte Software-Einheiten mit empirisch gewonnenen Werten multipliziert werden (erstaunlicherweise bringen uns diese Werte sehr nahe an die Projektwahrheit heran). In Bereichen, in denen die Funktionspunkt-Analyse nicht sinnvoll verwendet werden kann, könnten historische Werte, z.B. aus ISBSG (International Software Benchmarking Standard Group), einer Datenbank mit über 5000 Referenzdaten aus Softwareprojekten, herangezogen werden, um über einen Abgleich mit den bereits jetzt vorliegenden Indikatoren ein ähnliches Referenzprojekt mit belastbaren Werten zu finden. Aufwände hingegen für noch unklare “Nichtfunktionale Anforderungen” sollten über die vergangenen Jahre herangezogen werden können (ebenfalls etwa in Form von Funktionspunkten). Hier gilt außerdem: die Komplexität, die man auch hinter noch unklaren Nichtfunktionalen Anforderungen vermutet, kann kaum überschätzt werden (auf ein “Oh mein Gott, das ist ja viel einfacher als ich vermutet habe!” stoßen wir hier eher selten). Auch technische Besonderheiten sollten mit in die Schätzung einfließen, um gegenüber unerwarteten Überraschungen gewappnet zu sein.

Wir empfehlen (nachhaltig!) Annahmen, die über die kommenden und laufenden Projekte getroffen werden, zu dokumentieren. Wie gesagt: aus der vorhandenen Informationsgrundlage resultiert die Qualität einer Schätzung. Oftmals scheitert das Verfahren sonst bzw. verliert an seiner Qualität. Frühzeitige Schulungen zu Workshops über “Schätzverfahren mit Funktionspunkt-Analyse” bei Knowledge Department können die Qualität ihrer Schätzverfahren weiterhin deutlich verbessern. Außerdem möchten wir es an dieser Stelle nicht versäumen, auf die Ergebnisse zu Schätzungen in Software-Projekten von “Carol Dekkers” hinzuweisen.

Ihr Wissen können Sie auch ausbauen in den ISTQB Certified Tester-Tester- und in den Requirements Engineering-Kursen von Knowledge Department.

Tags: , , , , ,

Hinterlassen Sie eine Antwort