Agile Entwicklung: Gutes Schätzen geht auch remote

Für das Schätzen von Aufwänden setzt man sich im agilen Umfeld an einen Tisch. Der Artikel gibt Entwicklern Methoden für Schätzungen im Homeoffice an die Hand.

In Pocket speichern vorlesen Druckansicht 40 Kommentare lesen

(Bild: Pheelings media / Shutterstock.com)

Lesezeit: 12 Min.
Von
  • Annegret Junker
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.

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 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.