Das Wellen Modell – Skalierbare Anforderungen in Scrum

  • Yves Bertrand

Liip benutzt Scrum zum Entwickeln von Websites. Nach der reinen Lehre m├╝sste damit eine Anforderung von A-Z fertiggestellt werden, damit sie freigegeben werden kann. Dem stehen gewisse Hindernisse entgegen, wie ich als Product Owner feststellen musste. Dazu geh├Ârt, dass das Visual Design beim Sprintstart unter Umst├Ąnden noch gar nicht vorhanden ist, oder nur teilweise. Dazu geh├Ârt auch, dass etliche unserer Kunden von einem Relaunch profitieren, um den Inhalt zu ├╝berarbeiten und deshalb den Content nicht automatisch migrieren lassen, sondern ihn manuell neu erfassen. Das braucht Vorlaufzeit, damit beim Go Live alles bereit ist. Und schliesslich ist es so, dass beim Entwickeln einer neuen Website oder bei einem Relaunch nicht nach jedem Sprint tats├Ąchlich auch f├╝r die ├ľffentlichkeit releast werden kann, sondern halt eben erst beim Go live.

Das Druids-Team bei Liip wendet deshalb f├╝r seine Drupal-Webprojekte das Wellen-Modell an. Wir haben es an unsere Bed├╝rfnisse angepasst und arbeiten mit drei unterschiedlich hohen Wellen:

  1. Prototyp
  2. Minimum Viable Product (MVP)
  3. Overachievement

F├╝r jede Anforderung m├╝ssen mindestens die ersten zwei Punkte umgesetzt werden.

Ein Beispiel-Epic k├Ânnte so aussehen:

Als Websitebesucher

m├Âchte ich alles ├╝ber die Hausratversicherung der Versicherung X wissen

um entscheiden zu k├Ânnen, ob ich eine solche Versicherung brauche.

Flexibilit├Ąt dank Wellen

Der Prototyp w├Ąre in diesem Fall der Drupal-Contenttyp ÔÇ×VersicherungsproduktÔÇť mit all seinen ben├Âtigten Feldern, das MVP der fertig gestylte Contenttyp und das Overachievement k├Ânnte sein, dass automatisch Infos von Konkurrenten eingeblendet werden, damit auch wirklich verglichen werden kann (nat├╝rlich im Wissen, dass die Versicherung X ein besseres Angebot hat als die Konkurrenz).

F├╝r jede Wellenstufe gibt es eine eigene User-Story, wobei nat├╝rlich auch die ersten zwei Stufen in ein und dem selben Sprint durchgef├╝hrt werden k├Ânnen, wenn beide Stories ready sind. Innerhalb eines Sprints sind somit Stories f├╝r Drupal-Backender und Frontender vorhanden, die parallel bearbeitet werden k├Ânnen, ohne dass eine Rolle auf eine andere warten muss.

In der unten stehenden Beispielgrafik w├╝rden w├Ąhrend des Sprints 1 vom Epic A 2 Stories entwickelt (Prototyp und MVP), von Epic B und D nur je 1 (Prototyp) und Epic C w├╝rde bis zum Overachievement gebracht. Im Sprint 2 k├Ânnten dann beispielsweise die Epics B und D mindestens auf MVP-Stufe gebracht werden.

Liip Drupal Wellen-Modell

Dank dem Wellen-Modell kann bereits mit der Entwicklung begonnen werden, auch wenn das Visual Design noch nicht komplett fertig ist, da der Prototyp meist nur aus dem Contenttyp besteht. Der Kunde kann somit rasch mit dem Erfassen von Content in Drupal beginnen, da mit dem Prototyp bereits alles dazu vorhanden ist. Nat├╝rlich bedingt dann die noch nicht optimale Darstellung des Contents ein gewisses Vorstellungsverm├Âgen, aber das hat sich gem├Ąss meiner Erfahrungen noch nie als Blocker erwiesen.


Tell us what you think