Agile Entwicklung: Gutes Schätzen geht auch remote

Inhaltsverzeichnis

Wer Schätzungen zu Aufwänden abgeben will, setzt sich in einem Raum zusammen und diskutiert die anstehenden Aufgaben. Aber wie soll das in Zeiten von Corona und Homeoffice funktionieren? Diskussionen von Angesicht zu Angesicht, bei denen man Metaplankarten hin und herschiebt, sind dann nicht möglich. Der vorliegende Artikel zeigt, wie man auch remote – also über das Internet – gute Schätzungen abgeben kann und miteinander zu gemeinsamen Festlegungen kommt.

Schätzungen werden immer wieder von Entwicklern, Testern, Product-Ownern und anderen Beteiligten am Softwareentwicklungsprozess verlangt. Aber wie kann man etwas beziffern, was nicht da ist? Etwas, das in der Zukunft liegt? Man kann nicht einfach messen, wie eine Uhr die Zeit misst oder wie ein Maßband eine Strecke. Man muss sich auf eine Schätzung verlassen. Schätzungen sind in ihrer Natur unsicher, und je weiter man in die Zukunft schaut, desto unsicherer werden sie.

Fiktives Projekt – eine Fahrradausleihe

Der Artikel beschreibt im Folgenden die Entwicklungsphasen und die damit anfallenden Schätzungsanforderungen anhand eines fiktiven Projekts. Die einzelnen Phasen und entsprechenden Vor-Ort-Schätzmethoden wurden bereits im Beitrag "Gib mir eine Zahl" allgemein beschrieben. Diesen gilt es nun zu folgen und auf das fiktive Projekt anzuwenden.

Als Beispiel für ein fiktives Projekt dient eine Fahrradausleihe. Der Dienstleister stellt an verschiedenen Orten wie Bahnhöfen oder Hotels Fahrräder zur Verfügung. Mitglieder sowie Gelegenheitsnutzer können die Räder gegen Gebühr ausleihen. Eine Reservierung sowie die Freischaltung der Räder an den Fahrradständern ist über eine App möglich. Nutzer können die Fahrräder an den Stationen zurückgeben. Sie stehen dort wieder zur Ausleihe zur Verfügung, dabei muss die Ausleihstation nicht der Rückgabestation entsprechen.

Schätzungen zur Projektinitialisierung

Schätzungen zur Projektinitialisierung sind in der Regel notwendig, um eine prinzipielle Aussage zur Machbarkeit treffen zu können. Man weiß noch sehr wenig vom eigentlichen Projekt. Es sind erste Ideen, die noch nicht weiter ausgearbeitet sind.

Für die Fahrradausleihe ergeben sich die folgenden Blöcke:

• Login: Mitglieder und Angestellte können sich in das System einloggen.
• Ausleihstation-Management: Ausleihstationen lassen sich mit entsprechenden Fahrradständern anlegen, sodass sie in der App angezeigt werden können.
• Fahrradausleihe: Fahrräder lassen sich ausleihen und zurückgeben.
• Fahrrad-Management: Fahrräder können für die Ausleihe angeschafft und registriert, Beschädigungen gemeldet und repariert werden, Verluste von Fahrrädern können behandelt werden.
• Benutzer-Management: Ein Mitglied kann sich mit seiner E-Mail-Adresse registrieren, ein Administrator einen Angestellten registrieren.

Nun kann man die Komplexität der einzelnen Blöcke abschätzen. Dies lässt sich beispielsweise durch eine Einteilung in T-Shirt-Größen erreichen. Dabei werden aber den einzelnen Größen keine wirklichen Aufwände zugeordnet. Man weiß nur, dass ein Block wesentlich größer als der andere ist.

Online-Schätzwerkzeuge für T-Shirt-Größen

Im Internet sind viele Online-Schätzwerkzeuge zu finden (s. Abb. 1). In der Regel bieten sie die im klassischen Planning-Poker angewendete angepasste Fibonacci-Folge an, aber auch die Einteilung in T-Shirt-Größen ist wählbar.

Man schätzt im Team User Story für User Story – in diesem Fall also Block für Block. Wenn alle Teammitglieder geschätzt haben, kann das Ergebnis bewertet werden. Sind die Resultate zu unterschiedlich, diskutiert man sie, sind sie gleich, kann man den nächsten Block schätzen. Solche Tools bieten beispielsweise Scrumpoker Online, PlanIT Poker, Planning Poker oder auch Scrumvee an.

Mit Ausnahme von Scrumpoker Online ist bei allen Tools eine Registrierung notwendig (entweder via E-Mail-Adresse oder über soziale Medien). Zusätzlich müssen Nutzer eine Beschreibung der Blöcke oder User Stories hinterlegen, die man im Team schätzen will. Ob dies erlaubt ist, hängt vom Auftraggeber oder Arbeitgeber und der Art des Projekts ab.

Schätzen mit Excel

Auch wenn es vermutlich etwas altbacken und nicht agil wirkt, kann man Excel verwenden, um in T-Shirt-Größen eine Schätzung vorzunehmen. In der Vorbereitung wird eine Excel-Tabelle mit den entsprechenden Blöcken als Zeilen und den Meeting-Teilnehmern als Spalten angelegt. Im Meeting bespricht man die einzelnen Blöcke und schätzt sie. Auf Aufforderung des Meeting-Moderators tragen die Teilnehmer ihre Schätzungen in die Tabelle ein. Sind die Ergebnisse zu unterschiedlich, wird erneut diskutiert und noch mal gemeinsam geschätzt. Das Ergebnis wird vom Team in der Tabelle festgehalten.

Man kann – unter bestimmten Bedingungen – gemeinsam an einer Excel-Tabelle arbeiten (s. Abb. 2). Sind diese Bedingungen nicht gegeben, muss der Moderator die Ergebnisse der Schätzung abfragen und eintragen. Um die gegenseitige Beeinflussung der Teammitglieder gering zu halten, lässt sich beispielsweise die initiale Schätzung vor dem Meeting bei den Teilnehmern einzeln abfragen. Sicherlich klingt dies alles ein wenig umständlich, aber so lässt sich remote schätzen, ohne auf die oben genannten Werkzeuge und ihre Einschränkungen angewiesen zu sein.

Schätzungen für die Wirtschaftsplanung

Für eine detailliertere Planung sind Kosten und damit Aufwände notwendig. Sicherlich kann man in einer solch frühen Phase keine detaillierten Schätzungen und damit einen Aufwand abgeben. Daher muss man eine Vergleichsbasis schaffen, um doch zu in bestimmten Rahmen verlässlichen Aufwänden zu kommen.

Hierfür kann man Bucket- (oder auch Eimer-)Schätzungen anwenden. Bei dieser Methode werden die einzelnen Blöcke aus dem vorherigen Abschnitt in funktionale Blöcke zerlegt. Ein Beispiel, wie sich die Blöcke der Fahrradausleihe zerlegen lassen, zeigt Abbildung 3.

In einer Bucket-Schätzung werden die einzelnen Funktionsblöcke in "Eimer" einsortiert. Der erste Spieler nimmt eine Karte und legt sie auf den Tisch vor sich. Der nächste nimmt die darauf folgende Karte und sortiert sie in Bezug auf die schon liegenden Karten ein. Ist die Komplexität des Funktionsblocks auf der Karte größer, legt er sie rechts daneben, ist sie kleiner, links. Denkt der jeweilige Spieler, die Komplexität des aktuellen Funktionsblocks ist ungefähr gleich, legt er sie unter der vorherigen Karte ab.

Bucket-Schätzung mit Online-Tools

Die im vorherigen Abschnitt beschriebene Kartenlogik setzt eigentlich einen Tisch und Karten – also Meeting-Teilnehmer in einem Raum – voraus. Online lässt sich diese Methode beispielsweise mit Whiteboard-Software simulieren.

Die erste Karte ist schon gesetzt. Die nächsten werden Schritt für Schritt hinzugefügt. Sie sind dann das Online-Äquivalent von Haftnotizen, die man auf eine Metaplanwand oder einen Tisch kleben kann. Das Ergebnis kann wie in Abbildung 4 aussehen:

Für solche Schätzungen kann man im Grunde jede Online-Whiteboard-Software verwenden. Miro, Mural und Ziteboard seien hier nur als Beispiele genannt.

Alternative MS PowerPoint

Wieder muss man sich fragen, ob man die Informationen über sein Projekt online speichern möchte. Auch in den Whiteboard-Werkzeugen muss man sich mit einer E-Mail-Adresse anmelden. Wenn man allerdings PowerPoint ein wenig anders gebraucht als beabsichtigt, kann es für eine solche Schätzung verwenden (s. Abb. 5).

Man legt für jeden funktionalen Block eine Folie mit möglichst großer Schrift an. Dafür bieten sich die Vorlagen für Titelfolien an. In der Ansicht „Folien sortieren“ lassen sich Folien in kleinen sogenannten Thumbnails anzeigen. Zusätzlich ist es möglich, Abschnitte zu definieren, die wie bei den Online-Whiteboards Gleichheit oder Größenbeziehungen anzeigen.

Sicherlich ist ein solcher Gebrauch von PowerPoint nur ein extremes Hilfsmittel für eine Bucket-Schätzung. Ähnliches kann man auch mit Excel erreichen, wenn man in der Diskussion einzelne Zellen kopiert, die für die Funktionsblöcke stehen, um sie gemäß ihrer Komplexität zu sortieren. Es zeigt, dass man auch remote gute Unterstützung für Schätzungen finden kann, ohne Online-Tools verwenden zu müssen, die der Auftraggeber oder Arbeitgeber nicht zulässt.

Hat man seine Buckets gefunden, kann man ihnen Zahlen zuordnen. Wiederum bietet es sich an, eine angepasste Fibonacci-Folge zu verwenden. Aber auch Zahlenfolgen mit Verdoppelungen oder anderen Faktoren können durchaus zum Einsatz kommen. Ausprobieren führt hier zum Ziel. Für die Buckets in Abbildung 4 bieten sich die Zahlen 3, 5, 8, 13, und 20 an. Sie können verschiedene Aufwände repräsentieren – Personenwochen oder auch Sprints. Aus der eigenen Erfahrung heraus empfiehlt es sich, in Personenwochen zu schätzen. Das Schätzen in Teamsprints kann sich schwierig gestalten, wenn sich das Projekt wie im Beispiel des Artikels noch am Anfang befindet, man noch kein Team und keine zugehörige Team-Velocity hat. In wirklich großen Projekten mit vielen Teams bietet sich aber ein Schätzen in Teamsprints eher an als eines in Personenwochen.

Während der Diskussion sollte man auch Risiken festhalten und dokumentieren. Ähnlich wie die User-Stories kann man sie auf virtuellen Haftnotizen festhalten. Man sollte gleich bewerten, ob das Risiko hoch, mittel oder niedrig ist. In der Diskussion ergeben sich dann entsprechende Aufschläge auf die Schätzung, zum Beispiel 30 Prozent für ein niedriges, 50 Prozent für ein mittleres und 100 Prozent für ein hohes Risiko. Das Ergebnis eines solchen Vorgehens zeigt Abbildung 6.

Auftragsklärung, Team-Einarbeitung, Projekt-Kick-off

Ist das Budget bewilligt, können die Beteiligten in die detaillierte Planung einsteigen. Abgrenzungen des Projekts und Domänendefinitionen sind hierfür notwendig. Die groben funktionalen Blöcke müssen in Epics herunter gebrochen werden. Es bietet sich an, dies schon durch erste Teammitglieder durchführen zu lassen. Idealerweise stehen schon die sogenannten 3 Amigos zur Verfügung: Product Owner, Entwickler und Tester. Bei größeren Projekten mit mehreren Teams sollten auch übergreifende Rollen wie Architektur- und UX-Experten in den Schätzungs- und Planungsprozess einbezogen werden.

Die Teamvertreter brechen die funktionalen Blöcke in Epics herunter und markieren wiederum Risiken, aber insbesondere Abhängigkeiten zu anderen Teams oder auch Projekten. Die Epics lassen sich im Bucket-Verfahren gemäß ihrer Komplexität bewerten. Abhängigkeiten gehen als Risiko in die Bewertung ein. Auch andere Risiken – wie Nichtverfügbarkeit von Entwicklungs- und Testumgebungen, Lernaufwände für unbekannte Technologien – fließen in die Bewertung ein. Wieder kann man virtuelle Haftnotizen für die Schätzung verwenden. Lässt sich für die Teamschätzungen nur Excel oder auch PowerPoint verwenden, kann man die Notizfunktionen nutzen, um solche Risiken festzuhalten.

Implementierung der Schätzmethoden

Während der Implementierung kommen die klassischen Schätzmethoden während des Sprint-Plannings bei Scrum oder auch vergleichbare Meetings in einem Kanban-Ansatz zum Einsatz. Ohne die Online-Tools, wie sie im ersten Abschnitt vorgestellt wurden, fallen solche Meetings nicht leicht. Kreativität in der Nutzung von Excel und PowerPoint hilft aber auch hier.

Ist der gemeinsame Zugriff auf eine Excel-Tabelle mit Office365 möglich, können die Schätzungen in die einzelnen Zellen eingetragen werden (wie schon in Abbildung 2 vorgestellt). Aber auch die Nutzung der Webcam und das Hochhalten der entsprechenden Planning-Poker-Karten hat sich bewährt.

Fazit

Agile Schätzmethoden setzen eine enge Zusammenarbeit aller Beteiligten voraus. In Zeiten von Homeoffice muss das auch remote funktionieren. Online-Tools können helfen, die Schätzungen trotz allem verlässlich und mit einer guten Vertrauensbasis abzugeben. Auch die Ungenauigkeit in frühen Phasen eines Entwicklungsprojekts können Online-Tools beispielsweise durch eine Einteilung in T-Shirt-Größen abfangen. Doch nicht immer ist der Einsatz solcher Werkzeuge möglich. Ein kreativer Einsatz von Standard-Office-Tools hilft auch hier, damit Projektbeteiligte zusammenarbeiten und vertrauenswürdige Schätzungen abgeben können.

Dr. Annegret Junkerist Principal Software Architect bei adesso SE. Sie arbeitet seit mehr als 25 Jahren in der Softwareentwicklung in unterschiedlichen Rollen und unterschiedlichen Domänen wie Automotive, Versicherungen und Finanzdienstleistungen. Besonders interessiert sie sich für DDD, Microservices und alles, was damit zusammenhängt.

(mdo)