Oh, da gibts so einiges. Übers Schätzen gibts ganze Bücher und in den Projektmanagement-Vorlesungen an der Uni gibts immer mindestens eine, wenn nicht sogar mehr Vorlesungseinheiten dazu. Wenn du ein bisschen suchst, findest du da viel.
Leider hab ich momentan kaum Zeit, kann hier also nicht viel schreiben. Außerdem muss ich sagen, dass ich auf dem Gebiet hauptsächlich theoretische Kenntnisse hab. Meine eigenen Erfahrungen bezüglich Schätzen, sind überschaubar, also sei vorsichtig mit dem, was hich heir sage:
- Zum Schätzen eignet sich das
Delphi-Verfahren. Das heißt tatsächlich so, hat aber mit Delphi nichts zu tun. Wie hier schon vorgeschlagen wurde, stützt sich das auf das systematische runterbrechen in Teilaufgaben und getrennte Schätzungen. Am Ende fällt ein Wert in Personentagen raus.
- Es gibt FunctionPoint-Verfahre + diverse Abwandlungen. Die Vergeben für bestimmte Anforderungen Punkte, die dann über einen erfahrungsbasierten, organisationsabhängigen Schlüssel in Personentage umgerechnet werden. Kanst du nur machen, wenn du da viel Erfahrung drin hast oder externe Experten kommen lässt. Ist also wohl eher weniger relevant.
- Eines der Lieblingsverfahren meines Profs sei auch noch erwähnt.
CoCoMo. Hier basiert die Schätzung auf basis der ebenfalls geschätzten Größe LOC. Kannst du nur machen, wenn du bereits eine große Datenbasis hast. Also eher weniger interessant.
- Es gibt Datenbanken mit tausenden von Projektdaten drin. Von ganz kleinen bis ganz große. Du gibtst deine Daten ein (Projektgröße, Anzahl und Erfahrung der Entwickler, etc.) und am Schluss kriegst du ne statistische Auswertung, wie lange andere gebraucht haben. Zugang zu solchen Datenbanken ist aber IIRC kostenpflichtig und ich müsste auch erst nachgucken, wie die Dinger heißen.
- Man sagt als Daumenregel gilt: die Quadratwurzel des Projektaufwands in Personenmonaten ergibt in etwa die maximal sinnvolle Teamgröße. Der Name der Regel ist mir grad entfallen.
- Auch wichtig:
Hofstadter's law
mfg
Christian