i

Das Bauklotzspiel

Wozu das Bauklotzspiel?

Im Bauklotzspiel erfährst du die üblichen Kommunikationsprobleme in der Softwareentwicklung. Auf der Seite "Alltag einer Softwareentwicklerin" wurde die Kommunikation zwischen verschiedenen Stakeholdern bereits angesprochen. In der traditionellen Softwareentwicklung löst man diese Kommunikation in der Regel über Dokumente. Da diese Kommunikation in Scrum häufig nur über eine statt viele Personen, den Product Owner läuft, können viele Dokumente entfallen. Die gute Vermittlungsfähigkeit des Product Owner ist daher sehr wichtig.

Bevor es losgeht

Beispieltuerme[1]
BeispielSkizzen[2]
  • Hinweis: Bei Kursen über 9 Personen empfiehlt es sich, das Spiel zu parallelisieren, also vor der Gruppeneinteilung den Kurs in zwei oder mehr gleich große Teile zu splitten, die untereinander die beiden Gruppen bilden, um das Spiel durchzuführen.
  • Teilt euren Kurs in zwei gleich große Gruppen auf. Definiert außerdem eine Person als Product Owner.
  • Eine Gruppe begibt sich als Kundenfirma in einen anderen Raum (Kundenraum), die andere Gruppe bleibt als Entwicklerteam im Raum (Entwicklerraum).
  • Die Gruppe im Entwicklerraum bekommt einen Stapel Bauklötze zur Entwicklung des Produkts. Wichtig: Das Kundenteam sollte die verfügbaren Bauklötze nicht kennen, in der Softwareentwicklung kennen sich Kunden in der Regel ja auch nicht mit der späteren Implementierung aus.
Hinweis

Die Türme auf den Bildern stellen lediglich Beispiele dar. Eure Skizzen oder Türme können natürlich gänzlich anders aussehen.

Ablauf

  • Die Kundenfirma überlegt sich zunächst gemeinsam ein Objekt, welches das Entwicklerteam aufbauen soll. Beispiele für ein solches Objekt könnten z.B. eine Brücke oder ein Turm sein.
  • Die Kundenfirma skizziert das Objekt möglichst präzise. (Bei einem Turm also zum Beispiel Höhe, Breite, Fenster, Positionen von Fenstern und Türen, die Form der Spitze, uvm.)
  • Die Kundenfirma bittet den Product Owner herein und nennt diesem die Anforderungen, welche das gebaute Objekt erfüllen muss. Jedoch darf es die Skizze nicht dem Product Owner zeigen. Der Product Owner darf beliebige Rückfragen stellen, jedoch keine Notizen oder Skizzen anfertigen.
  • Der Product Owner verlässt den Kundenraum und betritt den Entwicklerraum. Er benennt dem Entwicklerteam die Anforderungen der Kundenfirma.
  • Das Entwicklerteam versucht die Anforderungen der Kundenfirma mit den vorhandenen Bauklötzen umzusetzen. Es ist dabei maximal eine Rückfrage an die Kundenfirma möglich.
  • Nach Abschluss der Entwicklungsphase wird die Kundenfirma zur Präsentation wieder in den Entwicklerraum geholt. Die Kundenfirma muss jetzt entscheiden, ob das Objekt dem auf der Skizze notierten Objekt ausreichend präzise ähnelt, um akzeptiert (und in der echten Welt bezahlt) zu werden.

Aufgabe

Haltet einmal selbst in der Entwicklergruppe, sowie der Kundenfirmagruppe ein Retroperspective Meeting zum Bauklotzspiel ab.

Recap

Aufklappen

Besprecht gemeinsam das Ergebnis. War das Bauklotzobjekt dem skizzierten Objekt ähnlich? Hat der Product Owner vielleicht nicht alle Anforderungen des Kunden verstanden? Hat der Product Owner seine Anforderungen ausreichend eindeutig für das Entwicklerteam formuliert? Der Product Owner muss zwar selbst nicht das Produkt entwickeln, hat jedoch in Scrum keine leichte Aufgabe. Er muss die Anforderungen des Kunden verstehen und dem Entwicklerteam daraus konkrete Anforderungen ableiten. Anschließend muss er das fertige Produkt dem Kunden gegenüber vertreten.

Quellen

Suche

v
9.3.3.5
dev.inf-schule.de/software/scrum/kommunikation/bauklotzspiel
dev.inf-schule.de/9.3.3.5
dev.inf-schule.de/@/page/iKlHUWIlRAc0DzkI

Rückmeldung geben