Projektmanagement Softwareentwicklung

Softwareentwicklung für Projektleiter, Manager und Entwickler

IT-Projektmanagement RSS
  • Aufwandschätzung: Schätzprobleme

    Jörg Hinrichs

    Das Problem ist nicht dass wir uns verschätzen – das Problem ist, dass wir uns immer in dieselbe Richtung verschätzen!
    - Henning Wolf, it-agile GmbH

    Der Projektleiter hat für unser IT-Projekt ein Meeting angesetzt. Es geht um unsere Aufwandschätzungen. Zu behaupten sie sind nicht gut wäre ziemlich geschmeichelt. Um die Wahrheit zu sagen: Sie liegen irgendwo zwischen katastrophal und unterirdisch. Das wir für Tasks von 1-2 Wochen 100% daneben liegen ist keine Seltenheit. Dabei sind wir größtenteils erfahrene Entwickler. Und wir stehen auch längst nicht mehr am Beginn des Projektes, wo man solche Abweichungen vielleicht noch durch mangelhaftes Verständnis der Materie erhalten könnte.

    Unser Projektleiter ist auch etwas genervt, weil er sich auf keine Schätzung verlassen kann. Das bringt sein Projektmanagement durcheinander und er muss immer wieder Verzögerungen rechtfertigen. Er weiß aber auch, dass es ihn nicht weiter bringt, wenn er seinen Ärger am Team auslässt. Außerdem versuchen wirklich alle, so gut wie möglich zu arbeiten. Also schluckt er seinen Ärger herunter und fragt in die Runde:
    “Hat irgendjemand eine Idee, wieso wir solche Probleme beim Schätzen haben?”.

    Wir sind relativ ratlos. “Ein Grund für die Verspätungen liegt sicherlich darin, dass wir keine stabilen Anforderungen haben.”, sagt einer.
    Das stimmt, im Verlauf der Entwicklung ergeben sich immer mal wieder Änderungen durch fachliche Aspekte, die im Vorhinein nicht geklärt wurden. 10 oder 20 Prozent Abweichung könnte man damit sicherlich erklären, aber 100% und mehr? Nein, das kann nicht die zentrale Ursache sein. Außerdem sind wir mit unserer Aufwandschätzung schon ziemlich großzügig.

    “Wir haben grundlegende Änderungen in der Architektur durchgeführt. Das kostet Zeit und führt zu vielen neuen Fehlern.”
    Auch das ist richtig. Aber dann müssten unsere Probleme eigentlich zeitlich begrenzt sein – das sind sie aber nicht. Wir sind schon über ein Jahr dabei und diese Abweichungen beim Schätzen gab es von Anfang an. Außerdem haben wir Unit-Tests, mit denen wir so etwas ganz gut abfangen können.

    “Die Materie ist einfach sehr komplex.”, sagt ein anderer.
    Stimmt ebenfalls. Allerdings sind unsere Aufwandschätzungen für alle Tasks schlecht, auch bei denen, die keine große Komplexität beinhalten.

    “Wir verbringen viel Zeit damit Fehler zu beseitigen, die mit unserer aktuellen Aufgabe nichts zu tun haben. Die Anwendung ist insgesamt einfach nicht stabil genug.”
    Alles berechtigte Einwände. Aber Abweichungen von 100% und mehr? Das sollte trotz allem eigentlich nicht passieren. Wir sind ratlos, uns will keine vernünftige Erklärung einfallen.

    Wer viel misst, misst nicht immer viel Mist!

    Schließlich beschließen wir zu analysieren, wo genau unsere Zeit eigentlich bleibt. In der nächsten Woche werden wir alle unsere Tätigkeiten detailliert protokollieren, von der Implementierung bis zum Klönschnack in der Küche. Mit einer Auflösung von 10 Minuten. Und wir werden Klassifizierungen vornehmen: Zeitaufwände für Codierung, Test, Refactoring, Bugfixing, Beseitigung von fremden Fehlern. Wir wollen jetzt definitiv wissen, was los ist!

    Eine Woche später machen wir die Auswertung. Das Ergebnis ist unerwartet: Die Hälfte der Zeit geht mit projektfremden Tätigkeiten verloren, vor allem mit Tagesgeschäft! Das überrascht uns dann doch. Hätte man uns vorher gefragt, wären das “gefühlt” etwa 15% gewesen, maximal 20%. So kann man sich irren.

    Trotzdem hat uns diese Untersuchung eines vor Augen geführt, was wir während der gesamten Zeit nicht berücksichtigt haben: Der Aufwand, den ein Entwickler für einen Task angibt, ist in der Regel ein Nettoaufwand. Der wird sich jedoch nie 1:1 realisieren lassen. Selbst wenn Sie einen Mitarbeiter haben, der zu 100% dem Projekt zugeordnet ist, dann wird er im Durchschnitt kaum mehr als 80% zur Verfügung stehen. Das müssen Sie in Ihrem Terminplan berücksichtigen, sonst werden Sie keinen einzigen Termin halten können.

    So schlecht waren unsere Aufwandschätzungen also gar nicht, was den Nettoaufwand anging. Nachdem wir das im Projektmanagement berücksichtigt hatten, wurden unsere Schätzungen auch wesentlich zuverlässiger.

    Vertrauen ist gut, Kontrolle ist besser

    Wenn sich die Projektsituation gravierend verändert, dann sollten Sie Ihre Messungen wiederholen. Hier muss man ein bisschen Feingefühl entwickeln, denn natürlich werden die Entwickler schnell genervt sein, wenn sie jede 4. Woche minutengenau ihre Aufwände protokollieren müssen. Für den Entwickler ist das eine artfremde Tätigkeit, die ihn in seiner Arbeit nur behindert.

    Ihre Messungen sollten Sie also nicht in zu kleinen Abständen wiederholen und nur dann, wenn ein konkreter Anlass vorliegt. Das könnte zum Beispiel eine der folgenden Situationen sein:

    • Neue Mitarbeiter kommen ins Team oder verlassen es.
      Hier wird es immer zu Reibungsverlusten kommen. Neue Mitarbeiter müssen eingearbeitet werden und das Team muss sich neu finden, seine Rollenverteilung neu festlegen. Rechnen Sie hier für eine Übergangszeit mit neuen Arten von Tätigkeiten (Einarbeitung, Konfliktlösung) und dadurch verursachte geringere Produktivität.
    • Technologiesprünge
      Sie steigen auf eine neue Entwicklungsumgebung um oder setzen neue Komponenten von Drittanbietern ein. Auch hier entstehen neue Arten von Tätigkeiten, wie beispielsweise die Ausarbeitung von Standardproblemlösungen und es ist mit einer Verringerung der Produktivität zu rechnen, bevor (hoffentlich) eine Verbesserung eintritt.

    Wenn Sie über einen begrenzten Zeitraum alle Aktivitäten genau messen und auch klassifizieren, dann hat das noch einen sehr aufschlussreichen Nebeneffekt: Sie erhalten Informationen darüber, in welchem Verhältnis beispielsweise Codierung, Bugfixing und Test zueinander stehen. Das ist sehr wertvoll für ihr Projektmanagement: Es unterstützt weitere Analysen im Rahmen der Qualitätssicherung oder zukünftige Aufwandsschätzungen (auch in anderen IT-Projekten). Wenn Sie Ihre Messungen mehrmals durchführen können Sie erkennen, ob diese Relationen stabil sind – oder ob z.B. der Aufwand für die Fehlerbeseitigung steigt. In diesem Fall haben Sie vielleicht ein Qualitätsproblem.

    Zusammenfassung

    1. Nettoaufwand bei Schätzungen
      Definieren Sie als Projektleiter zusammen mit den Entwicklern, dass bei Aufwandschätzungen der Nettoaufwand angegeben wird. Definieren Sie außerdem, welche Tätigkeiten dazu gehören (siehe Artikel Fertig! – Fertig?).
    2. Messen Sie den Bruttoaufwand!
      Verlassen Sie sich nicht auf “gefühlte” Angaben sondern prüfen Sie sie nach. Je nach Projektsituation vielleicht auch mehrmals.
    3. Netto ist nicht gleich Brutto!
      Seien Sie sich immer der Tatsache bewusst, dass Netto- und Bruttoaufwand voneinander abweichen. Das klingt trivial, wird aber im Eifer des Gefechts schnell mal übersehen. Am besten protokollieren Sie immer beide Angaben parallel.

     

    2 Comments

2 Responses to “Aufwandschätzung: Schätzprobleme”

  1. I really like and appreciate your article.Really thank you! Really Cool.

  2. [...] Aufwandschätzung: Schätzprobleme [...]

Leave a Reply