Ich habe diesen Artikel am 11. Juni 2016 in Englisch geschrieben, aber ich denke, es macht Sinn, diesen auch mal auf deutsch zu veröffentlichen und etwas zu erweitern. Das Thema ist nach wie vor aktuell.
In einem Tweet, als ich noch auf Twitter aktiv war, habe ich zugestimmt, dass ich kein Excel für meine Arbeit beim Testen verwenden möchte. Ich hasse Excel (wahrscheinlich weil ich mit Lotus 1-2-3 angefangen hatte)…
My test manager says „I don’t wanna get back to the 90s“ when talking about Excel for managing tests. No further comment.
— (((Robert Strauch))) (@shrubbytester) 10. Juni 2016
und Michael Bolton antwortete später in demselben Thread:
@osxjogi … Monte Carlo simulation. Example: https://t.co/VkYCEHAAD1 @shrubbytester @ThomasPonnet
— Michael Bolton (@michaelbolton) 10. Juni 2016
Ich schrieb also auf, wie ich mit Code-Entwickler.innen Aufwandsschätzungen durchführe, die dicht an die Realität kommen können. Wir haben da so unsere Erfahrungen mit größeren (vorrausschauend über 18 Monate Projektzeit) als auch in kleineren Projekten angewendet und die Faktoren unseren Bedürfnissen angepasst. Es ist also keine starre Regel, sondern basiert auf den Erfahrungen im jeweiligen Projekt und wurde immer mal wieder aktualisiert.
Allgemein
Es gibt zwei Aspekte in der Betrachtung:
- Schätzung der Aufwände für die Codeerstellung (Produktionscode, Klassen- und Methodentests, Dokumentation, Integrations- und Systemtest, interne Abnahmeaktivitäten) – dies ist bei der Methode vorrangig das Schätzungsziel.
- Schätzung der Aufwände für zusätzliche Arbeiten, wie Projektmanagement, Testzyklen und externe Akzeptanztests
Schätzung der reinen Codeerstellung als Grundlage
Die Methode basiert auf der Annahme, dass erfahrene Code-Entwickler.innen ihre eigene Arbeitszeit für die zu erledigenden Aufgabe sehr gut enschätzen können, also: Codierzeit, nicht aber den Rest. Die Schätzung steigt an, wenn die Einflussfaktoren größer werden, die die/der Entwickler.in nicht unter Kontrolle hat.
Die folgende Tabelle
- ist erfahrungsbasiert und keine „das ist DIE Lösung“, sondern in Summe wird das Ganze ganz gut passen, wenn man mehrere Entwicklungszyklen hat
- beschreibt den zusätzlichen Aufwand, der zur reinen Schätzung des Codierens hinzukommen muss (Schätzung = 1)
Einflussfaktoren für die Codeentwicklung
Code-Entwickler.in erstellt Code | zusätzlicher
Aufwand
zur reinen Codeschätzung | Anmerkungen und Erklärungen |
ohne Verwendung von fremden Code | 1 | Normales Verhalten in einem Entwicklungsteam |
mit der Verwendung von Open-Source-Code innerhalb des Unternehmens/Projekts | 2 | z.B. Code aus anderen Gruppen im Unternehmen verwenden - Wissen lässt sich leicht übertragen |
mit der Verwendung von Open-Source-Code von außerhalb des Projekts/Unternehmens | 3 - 5; 3 ist normal, 5 der schlimmste Fall | z.B. Verwendung eines (im Projektteam) unbekannten Open-Source-Frameworks oder extrem hohe Performance-Anforderungen |
mit der Verwendung von geschlossenem Quellcode | 3 - 5; 3 nicht oft, 5 normal | z.B. die Verwendung eines Closed-Source-Frameworks wie es ist |
mit der Notwendigkeit, Closed-Source-Software (Drittanbieter) für die Integration zu verwenden | 5 - 9 | Integrieren z.B. eines Dienstes, dessen Erreichbarkeit man nicht vom Projektteam kontrollieren kann |
Beispiele:
- Die/Der Entwickler.in schätzt 6 Arbeitstage für die reine Codeentwicklung. Die/Der Entwickler.in muss eine oder mehrere Klassen verwenden, die bereits Teil des Projekts sind.
1 x 6 Arbeitstage kommen hinzu. Zusammenfassend beträgt die Schätzung für die Erledigung der Aufgabe 12 Arbeitstage für den Code, die Unit-Tests, die Dokumentation, die Integration und die interne Abnahme. Wenn man es genauer haben muss, sollte man die Aufgabe in kleinere Stücke zuerlegen, aber das ist zumeist dann in der Schätzungsphase eine besondere Herausforderung.
- Der Entwickler schätzt 5 Arbeitstage für die reine Codeentwicklung. Der Entwickler muss ein Open-Source-Framework eines Drittanbieters verwenden. Das Wissen im Projektteam ist nahezu null. 3 x 5 bis 5 x 5 Arbeitstage kommen hinzu. Zusammenfassend erhalten Sie dann eine Schätzung von 20-30 Arbeitstagen für alle erforderlichen Arbeitsaufgaben.
Das mag für die/den eine.n oder andere.n sehr hoch gegriffen sein, aber es hat sich immer wieder und wieder gezeigt, dass die Schätzungen durch eben derartige Einflussfaktoren die Aufwände in die Höhe treiben. Product Owner, die das nicht auf dem Zettel haben, wundern sich, warum die Schätzungen immer so weit von der Realität abweichen.
Das berühmte Schätzen mit „Gummipunkten“ ist auch eine Übersetzung von derartigen Einflüssen, da die Komplexität geschätzt wird, jedoch nicht nachvollziehbar gesagt wird, wodurch diese denn beeinflusst wurde.