Bei agilen Projekten arbeitet man in Teams und wird nicht von einer Anforderungsdokumentation geführt, sondern von generellen Ziel¬en, also nicht am „Wie“ sondern am „Was“. Solche Zielsetzungen sind länger gültig als in Lastenheften festgelegte Anforderungen, denn sie reden nicht von Methoden und Technik, sondern von Geschäftszielen, Umsatzzielen und strategischen Positionen.
Es ist jedoch viel schwieriger geworden, den zu erwartenden Aufwand zuverlässig zu schätzen. Dies im Unterschied zu einer Aufwandschätzung auf Basis einer herkömmlichen Anforderungsdokumentation mit gängigen Zählmethoden. Die Schätzung hängt natürlich von wesentlich mehr Faktoren ab als von Funktionalität. Kostenrelevante Anforderungen sind beispielsweise Sicherheit, Vertraulichkeit, Schnelligkeit, Verfügbarkeit.
Sequenzdiagram für die Authentifizierung einer SIM-Karte (Quelle: Swiss ICT Magazin)
Beispiel einer Buglione-Trudel Matrix (Aufwandschätzung) (Quelle: Swiss ICT Magazin)
Zuverlässige Aufwandschätzung
Ein Software-Entwicklungsprojekt ohne zuverlässige Aufwandschätzung zu starten, ist riskant. Selbst wenn man das Risiko auf den Auftragnehmer abwälzt, bleibt es doch beim Nutzer der Software: Was hilft eine halbfertige Software, weil das Budget zu früh ausgegangen ist? Auch agiles Vorgehen mit Timeboxen hilft nicht wirklich über das Problem hinweg, dass zuverlässig geschätzt werden muss, wie viele Iterationen oder Sprints nötig sind, um ein Projektbudget bereit zu stellen und Fragen wie Time-to-Market und Return on Investment zu beantworten.
Wie schätzt man also agile Projekte ab? Zwar sind die qualitativen Anforderungen gerade dadurch, dass agile Projekte über Zielsetzungen geführt werden, eher besser bekannt als in traditionellen Entwicklungsprojekten, aber es fehlen wichtige Elemente für die Kostenschätzung: der zu implementierende funktionale Umfang und die aus den qualitativen Anforderungen abzuleitenden Eigenschaften der Software („nicht-funktionale“ Anforderungen). Und beide sind oft sehr wohl kostenrelevant.
Den funktionalen Umfang früh richtig abschätzen
Am einfachsten erstellt man früh ein Sequenzdiagramm, um den funktionalen Umfang abzuschätzen. Dabei werden involvierte Aktoren und Business-Objekte identifiziert und es wird abgeschätzt, wie viele Datenbewegungen zwischen diesen stattfinden. Daraus lässt sich ein stark vereinfachtes Architekturmodell der Software erstellen und die Funktionalität mühelos messen.
Solche Sequenzdiagramme können zudem als Kommunikationsinstrument für die Entwickler dienen und sind technisch weniger versierten Sponsoren leicht verständlich.
Die Sequenzdiagramme brauchen nicht genau nach Modell implementiert zu werden, als Referenz dienen sie auch dann, wenn die Business-Objekte in technisch bedingte detaillierte Java- oder Scala-Objekte aufgelöst sind.
Frühe Abschätzung der nicht-funktionalen Anforderungen
Ebenso leicht ist die Abschätzung der nicht-funktionalen Anforderungen: Man nutzt die Buglione-Trudel Matrix. Diese besteht aus zwei Teilen, die man sich als Haus vorstellen kann: im Keller sind die funktionalen Anforderungen als Sequenzdiagramme untergebracht, hinzu kommen Stockwerke, die einem strategischen Projektziel entsprechen.
Jede User Story bekommt ein solches Haus zugewiesen. Falls die im Keller vorhandenen Funktionalitäten zu aufwandwirksamen Massnahmen im Projekt führen, welche der Zielerreichung dienen – etwa besonders sorgfältiges Engineering für eine attraktive Nutzeroberfläche – so erhält das Zimmer in diesem Stockwerk eine entsprechende Wirkungszahl zwischen 0 und 9 zugewiesen. Diese Skala muss mit der Anzahl der voraussichtlich benötigten Datenbewegungen abgestimmt sein2) und muss mit dem zu schätzenden Projekt abgestimmt werden.
So stellt man sicher, dass die nötigen nicht-funktionalen Aufgaben einberechnet werden und dass die Aufwendungen auf die wichtigsten strategischen Projektziele konzentriert werden. Darüber hinaus definiert die Matrix, wie die Ziele erreicht werden sollen. Somit kann man mit statistischen Methoden errechnen, welchen Grad der Zielerreichung man erwarten darf.
Faustregeln und Schätzungen mit der ISBSG-Datenbank
Nun zählt man Funktionspunkte und Wirkungspunkte zusammen. Die ergibt eine Summe pro User Story, welche in etwa dem benötigen Aufwand für die Implementierung von Anforderungen entsprechen. Eine spezielle Datenbank liefert Antworten, wie viel Funktionalität pro Arbeitstag realisiert werden kann. Diese Datenbank der unabhängigen Organisation ISBSG nutzt Daten aus 6‘000 analysierten IT-Projekten.
Eine Faustregel: Ein Funktionspunkt braucht ein bis zwei Arbeitstage (inkl. Design, Implementierung, Test und Build Integration, exkl. Projektmanagement, Administration etc.). Bei weiteren Kostentreibern wie Teamgrösse, verteilte Entwicklung, Skalierbarkeit, Wartbarkeit etc. liefert die ISBSG–Datenbank Referenzwerte.
Story Points: Änderungen schätzen und Korrekturen einleiten
Dieselbe Matrix hilft in der Umsetzung, die initiale Schätzung laufend zu überprüfen und anzupassen. Die Wirkungszahlen werden nun ersetzt durch Aufgaben für Entwickler und andere Beteiligte, deren Wirkung auf die strategischen Projektziele mittels einer Skala Stark – Mittel – Schwach ebenfalls bewertet werden.
Solche Bewertungen sind sich agile Teams gewohnt: Sie heissen «Story Points» und helfen beim Planen von Sprints oder Iterationen. Der Wirkung entsprechend zeigt sich auch: Welche Aufgaben sind tatsächlich relevant? Welche kann man streichen? Fehlentwicklungen und Änderungen sind ebenso schnell ersichtlich wie Korrekturmassnahmen eingeleitet.
Aufwandschätzung für Agile Projekte in der Praxis
Eine frühe Aufwandschätzung zu erstellen, ist kein grosser Aufwand. Man rechnet typisch drei Tage für ein mittelgrosses Projekt von wenigstens 300 Manntagen. Erstellt werden muss das Sequenzdiagramm, was die Mitarbeit eines Experten des Kunden bedeutet, und immer sollte ein externer, unabhängiger Experte die Aufwandschätzung verantworten. Die Nutzung der ISBSG-Datenbank in der Schweiz koordiniert SwissICT (DASMA in Deutschland); die SwissICT-Fachgruppe SwiSMA steht für die Software Metrics zur Verfügung.
Fazit: Objektive, reproduzierbare und quantifizierbare Aufwandschätzungen sind auch in agilen Projekten nicht nur möglich, sondern in allen Projektphasen hilfreich.
Internationale Normen für Functional Size Measurement (FSM)
-COSMIC-FFP Functional size measurement method 3.0.1 (ISO/IEC 19761:2009) – am besten geeignet für agile Projekte
-IFPUG Counting Practice Manual 4.3 (ISO/IEC 20926:2009) – die am weitesten verbreitete Norm
-Mk II Function Point Analysis 1.3.1 Unadjusted (ISO/IEC 20968:2002) – Anwendungsrichtlinie für Real-Time Systeme (UK)
-NESMA FPA Method 2.1 Unadjusted (ISO/IEC 24570:2005) – die Anwendungs-richtlinie für Holland
-FiSMA FSM 1.1 (ISO/IEC 29881:2008) – umfassende
Anwendungsrichtlinie für Finnland
Daneben gibt es Dutzende nicht-normierter Zählmethoden wie Object Points, Use Case Point, oder konsensbasierte Verfahren wie Story Points.
Gängige Zählmethoden und die Datenbank der ISBSG
Man misst die verlangte Funktionalität mit gängigen Zählmethoden gemäss den ISO/IEC Normen 20926 (IFPUG) oder 19761 (COSMIC). SwissICT stellt die ISBSG-Datenbank zur Verfügung, sie bietet eine branchenspezifische Abschätzung, basierend auf über 6‘000 Referenzprojekten. Sie ist als SaaS–Lösung zugänglich.
Die ISBSG ist eine Nonprofit-Organisation, die drei Datenbestände (Repositories) mit historischen IT Daten (Soft¬waremetriken) etabliert hat. Sie erweitert, pflegt und nutzt diese, um die Verbesserung des Managements von IT weltweit zu unterstützen. Die aktuellen Mitglieder der ISBSG repräsentieren IT- und Metrikverbände aus zwölf Ländern.
