Krautkanal.com

Veröffentlicht am 2015-03-26 19:42:08 in /prog/

/prog/ 6870: Aufwandsschätzung

naupintos Avatar
naupintos:#6870

Nicht sicher ob /prog/, aber ich denke jeder der schon mal für Geld programmiert hat wird das Elend kennen. Ich habe jetzt schon etwas Erfahrung im Schätzen von Aufwänden, habe aber nicht wirklich den Eindruck, dass meine Schätzungen über die Zeit genauer geworden sind. Das mag auf der einen Seite daran liegen, dass ich immer mit unterschiedlichen Systemen arbeite und selten Erfahrungen aus dem einen Bereich in einen anderen Übertragen kann. Auf der anderen Seite mache ich es vielleicht auch einfach falsch, weil meine Methodik zu naiv ist.

Ich sehe mir die Anforderungen an und gehe grob im Kopf durch, was ich zu tun habe. Da kommt dann ein Puffer oben drauf (z.B. +20%) und fertig. Manchmal benutze ich PERT, wenn es meinen Projektmanager glücklich macht, wobei ich ehrlich nicht verstehe was daran so toll sein soll. Im Grunde tut der Min- und Max-Wert dabei ziemlich wenig zur Sache, auch wenn ich das x-fache als Max-Wert eintrage ist das Ergebnis immer sehr nahe am Mittelwert. Im Studium habe ich auch ein paar Sachen zu hören bekommen, z.B. anhand der benötigten Code-Zeilen zu schätzen (ich brauche ca. 200 Zeilen Code für die Anforderung, eine Zeile Code dauert im Schnitt 3 Min --> 600 Min.) aber das hat sich für mich als völlig unpraktikabel erwiesen.

Bernd, erzähl doch mal wie du das machst. Irgendwelche besonderen Methoden um den Aufwand zu ermitteln?

mauriolg Avatar
mauriolg:#6871

Hallo Berndi,
du solltest dir zunächst mal über den Unterschied zwischen Schätzung und Kalkulation Gedanken machen.

guischmitt Avatar
guischmitt:#6873

Also wenn es rein um Schätzungen geht, dann gehe ich so vor: Feature A benötigt einen Tag, dann rechne ich für die Implementierung 2. Weil immer Fuckmist irgendwo dabei ist. Dann nochmal die gleiche Anzahl fürs Testen. Das muss auch nicht sofort davor oder danach erfolgen, manchmal kommt ein Bugreport halt erst nach 2 Monaten rein. Die Zeit will man mit abdecken + die sofortigen automatischen und manuellen Tests. Und dann würde in dieser Woche noch ein Tag überbleiben, damit kann man jetzt machen was mag - oder als Puffer draufzählen.

Bisher bin ich mit geschätzten 1-3 Wochen (gesamt) ganz gut hingekommen, waren aber auch überschaubare Features.

armcivor Avatar
armcivor:#6882

>>6870
Ich finde das wichtigste ist eine Schätzung nicht mal eben auf dem Flur oder am Telefon zu machen, sondern sich eine schriftliche Auflistung zu machen und die Aufgabe aufzubrechen. Dazu kommt dann natürlich Test, Support, Deployment, Doku, Puffer usw. Es ist manchmal sinnvoll dem Kunden deutlich zu machen wo die Tücken liegen und warum (natürlich in einer Sprache die der Kunde versteht). Wenn der Kunde am Ende nur eine tolle neue Grafik sieht, versteht er nicht warum das so viel Aufwand ist. Das Ganze gilt natürlich auch dann wenn man ein ähnliches Problem schonmal gelöst hat - man sollte seine Arbeit nicht verschenken.

mwarkentin Avatar
mwarkentin:#6883

Aufwände zum streichen einer Wand kann man gut schätzen, da die Anforderung für jede Wand ähnlich ist und nur die Wandgröße variiert. In der Informatik ist die Problemstellung + Lösunsgweg stehts verschieden und muss völlig neu gefunden werden.

Den Lösungsweg in kleine Pakete teilen um diese zu schätzen fällt oft einfacher als ein großes Arbeitskapet PI * Daumen zu bewerten. Kleine Pakete zu beschätzen hilft auch dabei, wenn sich Anforderungen ändern und man die Schätzung nachträglich ändern muss. Vieleicht muss man nur ein Arbietspaket streichen anstatt sich eine neue Aufwandszahl für das Gesamtprojekt zu überlegen.

Bernd Avatar
Bernd:#6884

>>6870
Tadadada: http://de.wikipedia.org/wiki/Function-Point-Verfahren

Neuste Fäden in diesem Brett: