Schätzungen von keiner Sachkenntnis getrübt

Dieser Post diskutiert, wie Schätzungen in extrem frühen Phase eines Projekts abgegeben werden können. Eine spezifische Form des Planungs-Pokers wird vorgeschlagen, der auch eine Form der Risiko-Abschätzung enthält.

Ich denke, jeder der in irgendeiner Rolle in der Software-Industrie arbeitet, hat schon irgendwelche Schätzungen abgegeben. Wenn Du auf der glücklichen Seite warst, hast Du sie via Planungs-Poker in einem Team abgegeben. Solche Schätzungen sind üblicherweise mehr oder weniger verlässlich. Aber das kannst Du nur machen, wenn Du ein Team hast. Am Beginn eines Projekts – insbesondere in großen, strategischen Projekten – hast Du kein Team. Du bist voll in der Planungs-Phase. Vielleicht sind erste Team-Mitglieder schon an Board, aber üblicherweise sind die Teams noch nicht aufgesetzt.

Aber jedermann, beginnend beim Vorstand bis hin zu den zukünftigen Programm- und Projektmanagern, fragen nach den Kosten. So bist Du als ein Architekt gedrängt, Abschätzungen abzugeben – mehr noch basierend darauf, die Manager sind gedrängt darauf basierend, Personalpläne vorzulegen. Als ein Architekt wirst Du nach Kostenplänen für Soft- und Hardware inklusive Cloud-Kosten gefragt. Zu diesem Zeitpunkt weiß noch niemand irgend etwas. Aber die Planung muss gemacht werden, andererseits kann das Projekt nicht vorgesetzt werden.

Um herauszufinden, welche Technologie benutzt werden kann und welche System benötigt werden, kannst Du Dich mehr oder weniger auf Deine Erfahrung verlassen. Aber verlässliche Schätzungen abzugeben, ist eine komplett andere Geschichte.

Es sind sehr gute, unterschiedliche Schätztechniken bekannt (siehe auch die ausgewählten Literaturstellen am Ende dieses Posts), aber nach meinem Gefühl kann keine von ihnen in dieser spezifischen Situation angewendet werden. Meistens versuchen diese Techniken mehr und mehr Daten in die Schätzungen einzubeziehen, aber in diesem frühen Stadium eines Projekts wie während dem strategischen Planung, sind diese Daten einfach nicht bekannt. Es bleibt nur, das aktuelle Projekt mit Projekten, die schon durchgeführt wurden, zu vergleichen (mit allen Risiken, die ein solcher Vergleich beinhaltet).

Aber, aber, aber …

Stell die Situation, die ich hier beschrieben habe, noch einmal vor. Es ist der Startpunkt einer langen Reise. Wir benötigen keine Schätzungen basieren auf Stunden oder sogar Tagen. Wir benötigen Schätzungen auf einer größeren Skala. Mehr noch: zu einem solchen frühem Stadium eines Projekts sind keine oder nur wenige Anforderungen bekannt, das ganze Projekt ist nur mehr oder weniger eine Sammlung von Ideen. Alles wie ein Work-Break-Down oder sogar Risiko-Vermeidung sind nicht bekannt. Daher benutze eine grobe funktionale Zerlegung.

1. Weise jeder Business-Funktion einen Service zu.
2. Versuche festzulegen, welche unterstützenden Services, wie z.B. ein Authentication-Service oder ein Geo-Location-Service, benötigt werden.
3. Spiele einen Planungs-Poker für jeden identifizierten Service

Hä? – Planungs-Poker? Erst habe ich gesagt, wir haben keine Anforderungen, ich habe noch nicht einmal ein Team. Und jetzt sage ich „Spiele Planungs-Planungs-Poker?“ Wie soll das gehen?

Wir müssen nach Stakeholdern suchen, vielleicht erste Team-Mitglieder, Programm-Manager, usw. Mit diesem können wir Planungs-Poker spielen, vertrauend auf die Erfahrung dieser Stakeholder. Obwohl sie vielleicht keine eigene Implementierungs-Erfahrung haben. Sie haben definitiv Erfahrungen mit Softwareentwicklung – wenn auch von außen. Aber wenn wir größere Teile der Applikation schätzen, haben wir nicht solche handhabbaren Teile wie in einem klassischen Work-Break-Down. Daher können wir nicht in Tagen oder Stunden schätzen. Auch User-Story Points machen keinen Sinn, da wir kein Team und vergleichbare Arbeitsteile haben.

Ich empfehle, in Sprints zu schätzen. Normalerweise hast Du ein gutes Gefühl, was in einem Sprint getan werden kann. Benutze die bekannte Fibonacci-Reihe für das Schätzen mit 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100. So ein Planungs-Poker folgt den gleichen Regeln wie ein Planungs-Poker in einer Spring-Planung. Erste Runde – Diskussion – Zweite Runde – Ergebnis.

OK, Manager fragen nicht nach Anzahl von Sprints. Sie fragen Dich nach Kosten. Du weißt wahrscheinlich den Tagessatz von Entwicklern und Testern. Die Kosten für einen Sprint können wie folgt abgeschätzt werden: ein Team besteht aus 7 Personen: ein Product-Owner, 4 Entwickler, und 2 Tester. Der Product-Owner wird nicht in die Implementierungskosten einbezogen (wenigstens in meinem Beispiel J). Ein Sprint besteht aus zwei Wochen (in meiner Erfahrung eine gute Länge, aber Du denkst vielleicht anders). So haben wir 6 mal 10 Tage – macht 60 Tage brutto. Wenn wir 0,5 Tage pro Teammitglied für die Sprintplanung, 0,5 Tage für den Sprintabschluss, 20‘ pro Tag für das Standup und 2% für alles andere rechnen, haben wir ungefähr 50 Personentage pro Sprint.

Aber das ist nicht die alleinige Wahrheit. Natürlich müssen wir auch das Risiko abschätzen. Nochmal: Wir haben keine Information darüber. Wir müssen wiederum unserem Gefühl vertrauen. Lass einfach die Teilnehmer des Planungs-Pokers auch das Risiko abschätzen. Ich empfehle drei Stufen – hoch, mittel und klein. Du kannst definieren, was diese Stufen meinen: hoch heißt 80%, mittel 50% und klein 20%. Diese Risikoabschätzung erlaubt es dir, Dinge hinzuzufügen, von denen Du nicht weißt, dass sie existieren.

Mit einer solchen groben Schätzung bekommst Du mehr oder weniger verlässliche Abschätzungen, obwohl Du Dich in einem sehr frühen Zeitpunkt des Projekts befindest. Natürlich müssen solche Schätzungen während des Projekts verfeinert werden. Aber ich denke, eine solche Schätzung ist immer noch besser als gar keine Schätzung.

Laqrichi, S., Gourc, D., Marmier, F.: Toward an effort estimation model for software projects integration risk, Université de Toulouse, Mines Albi, Centre Génie Industriel, Toulouse 2015, https://arxiv.org/pdf/1509.00602.pdf

NN: Effort Estimation for Software Development, http://open-works.org/?e=effort-estimation-for-software-development

Madsen, S.: 10 guidelines for estimating project effort, Bergen, Netherlands 2011, https://www.susannemadsen.co.uk/blog/10-guidelines-for-estimating-project-effort