Starten Sie Ihre Softwareprojekte mit den richtigen Methoden

Eine Soft­ware ist nur dann rich­tig gut, wenn die Anwen­der sie gerne nutzen. Ihre Anfor­de­run­gen müssen zu Beginn des Projek­tes so genau wie möglich erfasst werden. So werden Planungs­feh­ler vermie­den, die später teuer zu stehen kämen. Im Projekt­ver­lauf soll­ten sich Ände­run­gen inte­grie­ren lassen. Und schließ­lich müssen alle Maßnah­men auch ins Budget passen.

Wir haben ein struk­tu­rier­tes Vorge­hen entwi­ckelt, mit dem wir große Soft­wa­re­pro­jekte zeit- und kosten­ef­fi­zi­ent umset­zen können. Wich­tig für das Anfor­de­rungs­ma­na­ge­ment sind aus unse­rer Sicht eine gute Kommu­ni­ka­tion und ein enges Zusam­men­spiel zwischen Kund:innen und Entwick­ler:innen. Und so gehen wir an diese Aufgabe:

Welche Funk­ti­o­nen soll die Soft­ware bieten? Mit Hilfe der Story Map visu­a­li­sie­ren wir den ange­streb­ten Funk­ti­ons­um­fang. Hierzu erzäh­len wir Stories aus Sicht der Benut­zer bzw. der Perso­nas.

Story Mapping ist eine Tech­nik, mit der alle Anfor­de­run­gen an das neue Soft­wa­re­pro­dukt aufge­nom­men und über­sicht­lich darge­stellt werden. Und zwar immer ausge­hend vom gewünsch­ten Nutze­rer­leb­nis (User Expe­ri­ence, UX).

Wir star­ten mit einer Samm­lung der Aufga­ben, die aus Sicht der Benut­zer:innen zu erle­di­gen sind (User Tasks). Sie werden aufge­schrie­ben und so neben­ein­an­der ange­ord­net, dass sie eine nach­voll­zieh­bare Geschichte (User Story) erge­ben. Hier­bei geht es nicht um einen festen Ablauf, denn manche Tasks führt der Nutzer sicher­lich auch mal in einer ande­ren Reihen­folge aus.

Die Wörter und Bilder, die wir dazu verwen­den, sorgen dafür, ein gemein­sa­mes Verständ­nis aufzu­bauen. So können wir uns besser auf die Nutzer:innen und ihre Erfah­run­gen konzen­trie­ren. Das Ergeb­nis ist eine bessere Kommu­ni­ka­tion unter­ein­an­der und schlus­s­end­lich ein besse­res Produkt.

Wenn wir die Story Map erstel­len, orien­tie­ren wir uns am Arbeits­fluss unse­rer Perso­nas. In Form von Anwen­der­auf­ga­ben (User Tasks) doku­men­tie­ren wir pass­ge­nau die Anfor­de­run­gen an das System. Diese werden im nächs­ten Schritt prio­ri­siert und entspre­chen­den Releases zuge­wie­sen.

Bevor wir anfan­gen zu entwi­ckeln, erstel­len wir einen Themen­spei­cher, das Product Back­log. Es verzeich­net und prio­ri­siert die zu entwi­ckeln­den Funk­ti­o­nen (Product Back­log Items). Die einzel­nen Back­log Items erge­ben sich aus den User Tasks der Story Map.

Ein Product Back­log ist eine dyna­mi­sche Liste und nie ganz fertig, denn wir lernen während der gesam­ten Projekt­lauf­zeit dazu. Um auf Verän­de­run­gen reagie­ren zu können, müssen wir die Inhalte und Reihen­folge jeder­zeit ändern können.

Den Über­blick über den Inhalt des Product Back­logs hat der Product Owner (PO). Beim Aufbau unter­stüt­zen ihn übli­cher­weise Scrum Master und Mitglie­der des Entwick­lungs­teams. Bei jeder User Task muss sich der PO über­le­gen, ob das Element ausrei­chend beschrie­ben und klein genug ist, um in die Entwick­lung zu gehen. Wenn dies nicht der Fall ist, wird das Element weiter verfei­nert und „geschnit­ten“.

Der PO kann das Product Back­log jeder­zeit verän­dern, wenn sich im Laufe des Entwick­lungs­pro­zes­ses Ände­run­gen erge­ben. Übli­cher­weise enthält es Aufga­ben für die nächs­ten vier bis sechs Wochen. So kann der PO flexi­bel auf Verän­de­run­gen reagie­ren, während das Team weiter­a­r­bei­tet.