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