als ich vor ein paar tagen auf der bonner runde einen vortrag zum thema “aufwandsschätzungen” präsentiert habe war das interesse groß. für viele schien es sich um ein kritisches und akutes thema zu handeln.
dabei sind einige prinzipien guter schätzungen nicht besonders kompliziert und gut zu erlernen. trotzdem konnten sie sich anscheinend in den letzten jahren nicht besonders gut durchsetzen bzw. verbreiten.
mit unter mag das daran liegen, dass zentrale eigenschaften einer “schätzung” gerne mißinterpretiert oder mit verwandten konzepten und disziplinen in der software-entwicklung vermischt werden. philipp armour hat in diesem zusammenhang in einem netten essay zusammengefasst, was eine schätzung alles NICHT ausmacht. natürlich wird dort auch beschrieben, wie man diesen dort genannten fehlinterpretationen von schätzungen begegnen kann.
neben den typischen problemen und risiken, mit denen man bei der erstellung einer aufwandsschätzung zu kämpfen hat, existieren auch einige fallstricke in bezug auf deren präsentation, kommunikation oder diskussion. festgefahrene oder stark emotionsgeladene gespräche sind keine seltenheit, wenn es darum geht das ergebnis einer schätzung zu besprechen. einige zuhörer konnten bestätigen, dass es nicht selten dazu kommt, dass ein besonderer druck auf denjenigen ausgeübt wird, der die schätzung erstellt hat. dieser druck kann u.a. deshalb entstehen, weil die geschäftlichen ziele, die der auftraggeber einer schätzung verfolgt, nicht mit dem ergebnis der schätzung in übereinstimmung gebracht werden können. häufig werden in diesen zu verhandlungen neigenden gesprächen falsche zugeständnisse gemacht, um den erwartungen entgegenzukommen.
in solchen situationen hilft es manchmal die grundsätze der “art of principled negotiation” zu befolgen.
hiermit lassen sich viele problematische gesprächssituationen entschärfen.
ein teilnehmer machte auch darauf aufmerksam, dass bestimmte dinge bei aufwandsschätzungen häufig nicht berücksichtigt werden. dabei sind es nicht unbedingt nur entwickler, die diese typischerweise häufig fehlenden aktivitäten oder aufgaben übersehen. auch projektleiter tendieren dazu folgende wichtige aspekte auszublenden (s. steve mcconnel, 2006):
- erstellung von setup- oder installations-programmen
- entwicklung von tools zur daten-konvertierung
- programmierung von infrastruktur-code zur einbindung von third-party- oder open-source-software
- einarbeitungs- und betreuungsaufwand für neue projekt-mitarbeiter
- deployment und installation auf entwicklungs-, test- oder live-systemen
- klärung von ungenauen anforderungen
- revisionsverwaltung
- automatisierte tests
- erzeugung von testdaten
- berücksichtigung / aufnahme von change-requests
- projekt-meetings (change-board, daily stand-up, weekly jourfixe…)
- technische unterstützung bei der wartung von systemen
- bugfixing und deren administrative aufwände (bugtracking)
- performance tuning
- einarbeitung in neue entwicklungstools
- koordinationsaufwände (innerhalb entwicklung, entwicklung zu test, test zu betrieb…)
- anfertigung von benutzerdokumentationen, technischen konzeptpapieren, management-präsentationen oder deren review
- präsentation von releases beim (end-)kunden, auf messen, für das management etc.
- erstellung oder überarbeitung von (projekt-)plänen und schätzungen
- urlaub
- krankheitstage
- fortbildung
- betriebsausflüge
- aufbau neuer arbeitsplätze
- installation neuer software-versionen auf den arbeitsstationen
- behebung von soft- und hardware-problemen auf den arbeitsrechnen
viele weitere fragen und probleme habe ich während meines vortrags angesprochen und versucht lösungen dafür zu empfehlen. die folien zum vortrag habe ich weiter unten zum download zur verfügung gestellt.
Aufwandsschätzung-Egger-2006 (1751 downloads)