Leseproben
Dirk Dorsch Heidelberg Mobil International GmbH

Eine leichtgewichtig in den Prozess integrierte Schätzkultur bietet die vermisste Nachverfolgbarkeit ohne zu viel den Agilen verhassten Prozessoverhead einzuführen.

Schätzen hatte noch nie einen allzu guten Ruf. Die eine Seite fürchtet den hohen Aufwand und die damit verbundenen Kosten, die andere Seite ein daraus entstehendes Commitment, das einzuhalten insbesondere dann ein Ding der Unmöglichkeit ist, wenn man nicht ausreichend Zeit und Informationen hat. Trotz eines ambivalenten Verhältnisses bieten Schätzungen allen Stakeholdern einen großen Nutzwert. Richtig verankert erhalten alle Beteiligten ein gemeinsames Verständnis des Projekts und Stellschrauben für Optimierungen – alles im Sinne der Anwender.

Schätzen ist eine Frage der Übung. Das steht ebensowenig außer Frage wie die Tatsache, dass jede Schätzung mit hoher Wahrscheinlichkeit falsch sein wird. Auch in einem klassischen Set-up mit intensivem Austausch von Lasten- und Pflichtenheft lassen die Anforderungen Freiheitsgrade und Interpretationsspielraum. Bietet die Lastenheftphase genügend Zeit, kann man sie eventuell auf ein Minimum reduzieren. Gepaart mit großer Erfahrung und bester Kenntnis über die in der geplanten Durchführung einzusetzenden Technologien und Menschen lässt sich so womöglich eine annähernd verlässliche Schätzung abgeben. Also Schluss mit Agile, zurück zum Wasserfall? Vermutlich nicht, sind da doch noch die Proargumente agiler Entwicklung. Im Allgemeinen ist es – in Hinblick auf ein für den Kunden oder Anwender optimiertes Ergebnis – nicht ratsam, die Handlungsfähigkeit bei sich ändernden Anforderungen zugunsten einer optimierten initialen Schätzung aufzugeben. Also Schluss mit Schätzen, hin zu „Es ist halt fertig, wenn es fertig ist“ und „Es dauert so lange, wie es dauert“? Außerhalb Utopias ist das schwer vorstellbar. Gibt es da ja noch den allseits geliebten Festpreis und auch die Releasetermine. Was bleibt, ist zu erkennen, dass Schätzungen Teil der Software und ebenso agil zu behandeln sind. Schätzen ist keine einseitige Aufgabe der Entwickler, die dann an den Pranger gestellt werden, wenn sie die Schätzung in der Umsetzungsphase nicht einhalten. Schätzen ist, wie die gesamte Entwicklung, ein kollaborativer Prozess, der alle Beteiligten zusammenbringt und ein gemeinsames Verständnis und Verantwortungsgefühl schafft.

Der Softwareentwicklungsprozess bindet die einzelnen Stakeholder in den unterschiedlichen Projektphasen unterschiedlich intensiv ein. Innerhalb der jeweiligen Peergroups und Projektphasen entstehen schnell ein abweichender Terminus und eine damit einhergehende Varianz in der Sicht auf die Anforderungen. Zwangsläufig ist es deswegen ab einem gewissen Zeitraum immer aufwendiger, einen nachvollziehbaren Projektstatus zu bekommen. Der Managementoverhead steigt also mit fortschreitendem Projektverlauf rapide an. Die Antwort nach dem Stand im Budget zu bestimmen, erfordert teilweise schon forensische Detailarbeit.

Vertrieb und Management benötigen einen einfachen Zugang zum Projektstatus, um eine rollierende Kontrolle des Budgets zu erreichen, die im Risikofall ein zielgerichtetes Eingreifen ermöglicht. Auftraggeber wollen bezüglich Lieferterminen und Budget stets auf dem aktuellen Stand sein, insbesondere, sobald Abweichungen zu erkennen sind. Der Projektleiter will ebendiese vermeiden und benötigt einen Echtzeitblick auf die KPIs des Projekts. Die Entwicklung selbst ist häufig nur nebensächlich an den Aufwänden interessiert, hier liegt der Fokus verstärkt auf der qualitativ hochwertigen Umsetzung. Aber gerade diese erfordert auch eine entsprechende Sensibilität für die Aufwände, um zu erkennen, wann und in welchem Umfang beispielsweise nicht zwingend erforderliche Optimierungen an der Infrastruktur vorgenommen werden können.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Business Technology 4.17 - "Teams spielen heute anders"

Alle Infos zum Heft
579819720Wie schätzen sinnvoll ist
X
- Gib Deinen Standort ein -
- or -