Pragmatische Aufwandsschätzung

Größe: px

Ab Seite anzeigen:

Download "Pragmatische Aufwandsschätzung"

Thomas Bernt Steinmann
vor 7 Jahren
Abrufe

1 Pragmatische Aufwandsschätzung Holger Bohlmann Henning Wolf

2 Agenda Einleitung Story 1: Hochrechnung Story 2: Teamschätzung Story 3: Unklare Anforderungen Story 4: Relativ schätzen Story 5: Abstrakte Schätzmaße Story 6: Schätzfreundliche Anforderungen Story 7: Hierarchische Dekomposition Abschluss

3 Einleitung Winston Churchill: Prognosen sind schwierig, insbesondere wenn sie die Zukunft betreffen. Das stimmt, wir müssen trotzdem Prognosen/Schätzungen machen: Wir können aber lernen, besser rückzukoppeln Wir können besser erkennen, welche Faktoren falsch oder richtig waren

4 1.Story: Die Hochrechnung Geschwindigkeit unbekannt einfach mal anfangen und messen!

5 1. Story: Hochrechnung mit Prototyp? Sehr hilfreich zur Klärung von Anforderungen, aber Prototyp Fertiges System Entwicklungsgeschwindigkeit ist unterschiedlich zur späteren Entwicklung

6 2. Story: Team-Schätzung Binsenweisheit: Je mehr Leute schätzen desto genauer wird das Ergebnis. Beispiel: 40 Personen schätzen Anzahl Gummibären Ergebnis: wird geschätzt Mittelwert entspricht der Anzahl ± 10 % Investition in die Schätzung lohnt sich!

2. Story: Team-Schätzung Die es entwickeln,

Schätz-Expertise sollen Entwickler haben,

7 2. Story: Team-Schätzung Die es entwickeln, sollen es auch schätzen Commitment vom Entwicklungsteam Der Entwickler ist der Experte, er/sie muss es realisieren Schätz-Expertise sollen Entwickler haben, kann man auch lernen. Bekannte agile Technik: oder bekannter

8 3. Story: Unklare Anforderung Unklare Anforderungen ergeben unklare Schätzungen! Deshalb: Nicht würfeln, sondern klären. Schätzfreundliche Anforderungen können dabei helfen (siehe Story 6) Leider schwer zu bekommen: Der fachliche Ansprechpartner

9 4. Story: Relativ-Schätzen I I III II I I II I I IIIIIIIII II I I III III I III III II I III

10 4. Story: Relativ-Schätzen Grenzen Absoluter Zahlenbestimmung Frühe römische Antike: I, II, III, IIII, V, VI, VII, VIII Maya in Mittelamerika: *, **, ***, ****, I, *I, **I, ***I. Menschen sind schlecht im Schätzen konkreter Größenangaben.

11 4. Story: Relativ-Schätzen Ma Dalton will einen Pullover stricken...

12 5. Story: Abstrakte Schätzmaße

13 5. Story: Abstrakte Schätzmaße - Function Points Größenmaß zur Beschreibung des funktionalen Umfangs Perspektivenwechsel: Anwendersicht Geschätzt werden: Elementarprozesse Eingabe Ausgabe Abfrage Daten Interne Datenbestände Externe Datenbestände Funktionaler Gesamtumfang: ufp = Prozesspunkte + Datenbestandspunkte

14 5. Story: Function Points - Elementarprozesse Eingabe >= 16 Anzahl Datenbestände >= Ausgabe Abfrage >= >= 20 Anzahl Datenbestände >= Anzahl Datenbestände >=

15 5. Story: Function Points - Datenbestände Interner Datenbestand Externer Datenbestand >= >= 51 Anzahl Feldgruppen Anzahl Feldgruppen >= >=

5. Story: Function Points Vereinfachte Prognose Eingabe 1-4 5-15 >= 16 Anzahl Datenbestände 0-1 3 3 3 2 3 4 6 >=3 4 6 6 Ausgabe Anzahl Daten-bestände 1-5 6-19 >= 20 0-1 4 4 5 2-3 4 5 7 >=4 5 7 7

16 5. Story: Function Points Vereinfachte Prognose Eingabe >= 16 Anzahl Datenbestände >= Ausgabe Anzahl Daten-bestände >= >= Abfrage Anzahl Daten-bestände >= >= Interner Datenbestand Anzahl Feldgruppen >= >= Externer Datenbestand Anzahl Feldgruppen >= >= %

17 5. Story: Function Points Vereinfachte Prognose Eingabe >= 16 Anzahl Datenbestände >= Ausgabe Abfrage >= >= 20 Anzahl Datenbestände Anzahl Datenbestände >= >= Fehler des Gesamtergebnisses: 5% (Poensgen / Bock, Function Point Analyse)

18 5. Story: CoCoMo Von der Größenbestimmung zur Schätzung: Aufwand = K * (Größe) ^ S K = 17 Kostentreiberfaktoren Reliability Database size S = 5 Skalenfaktoren Precedentedness (Vorerfahrung) Development Flexibility (Flexibilität des Entwicklungsprozesses) Risk Resolution (Wird Risikomanangement betrieben?) Team Cohesion (Wie ist die Zusammenarbeit im Team?) Process Maturity (Prozessreife: Welcher CMM-Level?)

19 5. Story: Abstrakte Schätzmaße Velocity Dauer = Größe / Velocity Schätzungen sind selbstkorrigierend durch Geschwindigkeitsfaktor Geschwindigkeitssteigerung messbar Größen-Schätzungen altern nicht Objektivität: Von den Individuen getrennt. Meine Stunden sind nicht deine Stunden Vergleichende/ abstrakte Schätzungen sind schneller

20 6. Story: Schätzfreundliche Anforderungen Anforderungen feingranularer aufschreiben Z.B. Epics, MMF (Minimal Marketable Features) Darunter User-Storys Fachliche Ausbaustufen einführen Umfassen dann eine Menge an Epics/MMFs Vorteile: Erleichtert die Schätzung (je kleiner das Teil, um so leichter zu schätzen) Teile können untereinander gewichtet werden Simple Preisberechnung, wenn Teile herausgenommen werden Geschwindigkeit durch Rückkopplung: Schaffe ich diesen Teil in X PT?

21 7. Story: Gesamtschätzung: Grobgranulare Dekomposition Vollständigkeit kann man immer herstellen. Ist nur eine Frage der Granularität. Mind. eine vollständige Liste der Epics lässt sich auch in größeren Projekten erstellen. Customer Production Accounting Order

22 7. Story: Gesamtschätzung: Hierarchische Dekomposition Customer Search Customer Print Customer List Edit Customer Delete Customer Show Customer Save Customer Check Plausibility Production Order Accounting System Epics Stories Tasks

23 7. Story: Gesamtschätzung: Tiefenbohrung Customer 2 EP Search Customer 5 SP Print Customer List 5 SP Order 5 EP Edit Customer 3 SP Delete Customer 1 SP Accounting 2 EP Show Customer Dialog 1 PT Show Customer Content 1 PT Save Customer 0,5 PT Check Plausibility 0,5 PT Production 3 EP Check Unsaved Data 0,5 PT Σ 9 PT 3 SP = 9 PT 1 SP = 3 PT 2 EP = 14 SP 1 EP = 7 SP 1 EP = 21 PT System = 12 EP System = 84 EP System = PT

Abschluss Schätzen bleibt eine Herausforderung. Es gibt Mittel, um Schätzungen zu vereinfachen und zu verbessern. Agile Sichtweise: Wir schätzen nur kleinere Häppchen genauer.

24 Abschluss Schätzen bleibt eine Herausforderung. Es gibt Mittel, um Schätzungen zu vereinfachen und zu verbessern. Agile Sichtweise: Wir schätzen nur kleinere Häppchen genauer. Agile Sichtweise: Schätzen von Festpreisen kostet Geld. einfach loslegen und schrittweise Anforderungen realisieren könnte für den Kunden günstiger sein insbesondere wenn unterwegs Anforderungen getauscht werden können oder entfallen dürfen: Money for nothing, change for free.

ObjektForum Nord zu testgetriebener Entwicklung Magazin-Kino 09.02.

25 ObjektForum Nord zu testgetriebener Entwicklung Magazin-Kino :30-18:30: Live-Demo 19:00: Vortrag Info und Anmeldung:

Ähnliche Dokumente

Pragmatische Aufwandsschätzung und Agile Methoden

Pragmatische Aufwandsschätzung und Agile Methoden Dipl.-Informatiker Stefan Roock, Henning Wolf Senior IT-Berater, Geschäftsführer stefan.roock@it-agile.de, henning.wolf@it-agile.de http://www.it-agile.de