HEC Blog: Technik & Methoden
Verfasst von Annekathrin Gut am 28. Oktober 2021
Von der Produktvision zum Scrum-Projekt

Softwareprojekte erfolgreich starten

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 Projek­t­­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­­e­f­­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:

Projektstart

Anforderungen richtig verstehen

Was soll die Soft­­ware leis­ten, wenn sie fertig ist? Kund:innen nennen zu Beginn ihre Anfor­­de­run­­gen und Projek­t­­ziele. Aber Kommu­­ni­­ka­tion kann trick­reich sein und das Projek­t­team mitun­ter etwas ganz ande­res darun­ter vers­te­hen.

Wich­tig ist deshalb, von Anfang an ein gemein­sa­­mes Verstän­d­­nis von Zielen und Anfor­­de­run­­gen zu entwi­­ckeln. Um das zu errei­chen, star­ten wir übli­cher­­weise mit einem gemein­sa­­men Work­­shop, in dem wir zunächst die Personas und die Produktvision erstellen. Darauf bauen wir später eine Story Map und ein Produkt Backlog auf.

Am Work­­shop soll­ten möglichst alle an der Planung oder der späte­ren Nutzung betei­­lig­ten Perso­­nen teil­­neh­­men. Dazu gehö­ren Product Owner, Produk­t­­ma­na­­ger:innen, Projek­t­lei­tende, Nutzer:innen, Ideen­­­ge­­bende, Stake­hol­­der, tech­­ni­­sche Ansprech­par­t­­ner:innen und Spon­­sor:innen.

Personas

Kreativ in Nutzer hineinversetzen

Wir stel­len uns die Perso­­nen vor, die später mit dem Soft­wa­re­pro­­dukt arbei­ten sollen. Die soge­­nann­ten Perso­nas, die wir im Work­­shop entwi­­ckeln, sind fiktive Reprä­­sen­tan­ten mit den wesent­­li­chen charak­te­ris­ti­­schen Merk­­ma­len der späte­ren Benut­­zer.

Perso­nas sind ein krea­ti­­ves Hilfs­­­mit­tel, das den Work­­shop­­be­tei­­lig­ten hilft, sich in die künf­ti­­gen Nutzer hinein­­zu­­ver­­­set­­zen. Sie sind genauer als Ziel­­grup­­pen und werden mit einem Namen, einem Gesicht, einer Funk­tion und einem Werde­­gang verse­hen. Auch Privat­le­­ben und ein bestim­m­tes Nutzungs­­­ver­­ha­l­ten kann ihnen zuge­­schrie­­ben werden. Sie verfü­­gen über Ziele und Bedür­f­­nisse, haben Vorlie­­ben und Erwa­r­tun­­gen. Die Perso­nas beglei­ten das Team während der gesam­ten Projek­t­lauf­­zeit.

Produktvision

Das Produkt vor Augen führen

Das Soft­wa­re­pro­­dukt wird plas­tisch – und zwar mit der Produk­t­vi­­sion. Sie soll dem Projekt Orien­tie­rung geben und die Work­­shop­­teil­­neh­­men­­den dazu inspi­rie­ren, die Vision verwirk­­li­chen zu wollen. Gemein­­sam beant­wor­ten wir folgende Fragen:

Sie kennen viel­leicht das Prin­­­zip des Busi­­­ness Model Canvas. Mit solchen Vorla­­­gen wird ein Geschäfts­­­­­mo­­­dell auf einen Blick sicht­­­bar gemacht. Extra für unsere Soft­wa­re­pro­jekte haben wir ein Poster entwi­ckelt, damit die Produkt­vi­sion wirk­lich plas­tisch wird. Es gibt auch andere Möglich­kei­ten, zum Beispiel einen Zeitungs­ar­ti­kel über das fertige Produkt zu schrei­ben oder einen Produkt­kar­ton zu bauen.

Nutzen Sie unsere Arbeitshilfen:

Story Map

Das große Bild der Anforderungen

Welche Funk­ti­o­­nen soll die Soft­­ware bieten? Mit Hilfe der Story Map visu­a­­li­­sie­ren wir den ange­stre­b­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ün­sch­ten Nutze­­rer­le­b­­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än­d­­nis aufzu­­bauen. So können wir uns besser auf die Nutzer:innen und ihre Erfah­run­­gen konzen­trie­ren. Das Erge­b­­nis ist eine bessere Kommu­­ni­­ka­tion unter­ein­an­­der und schlus­s­en­d­­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.

Business Stories

Die Wirkung für Stakeholder fokussieren

Wie hängen User Tasks oder Stories und Produk­t­vi­­sion nun genau zusam­­men? Die Produk­t­vi­­sion gibt uns eine große Orien­tie­rung (meist für die nächs­ten Jahre) und die User Stories beschrei­­ben meist einzelne Funk­ti­o­na­­li­tä­ten. Dazwi­­schen gerät häufig der Zusam­­men­hang und damit die Wirkung aus den Augen.

Um diese Lücke zu schlie­­ßen, arbei­ten wir mit Busi­­ness Stories. Business Stories fokussieren auf die Wirkung, die wir für die verschiedenen Stakeholder erzielen möchten und sind das Bindeglied zwischen der Produktvision und den User Stories. Die Granularität ist klein genug, um sie gemeinsam mit dem Stakeholder zu priorisieren, aber auch groß genug um tatsächliche Wirkungen zu erzielen.

Product Backlog

Der Speicher für alle Aufgaben

Bevor wir anfan­­gen zu entwi­­ckeln, erstel­len wir einen Themen­­s­pei­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 Projek­t­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.

Schätzen

Das Budget im Blick haben

Bevor Sie ein Projekt star­ten, müssen Sie abschät­­zen können, wieviel Sie inner­halb Ihres Budge­t­rah­­mens umset­­zen können. Wie schaf­­fen Sie es, nicht zu detail­­liert zu werden und dennoch Ihr Budget möglichst genau planen zu können?

Bevor also einzelne Back­log Items umge­­setzt werden, werden diese geschätzt. Hier­­für gibt es verschie­­dene Tech­­ni­ken und Metho­­den: Story Points und Shirt-Sizes, Team Esti­­ma­tion Game, Plan­­ning Poker oder Magic Esti­­ma­tes. Nicht immer sind solche Schät­­zun­­gen ziel­­füh­rend. In Projek­ten mit langer Lauf­­zeit und konstan­tem Wert­fluss können auch andere Betrach­tun­­gen wie NoEs­ti­­ma­tes zum Einsatz kommen.

Scrum Projekt

Die Softwarentwicklung beginnen

Jetzt kann es losge­hen. In der Regel entwi­­­ckelt die HEC Soft­­­ware mit Hilfe des Scrum-Rahmen­­­werks, das mitt­­­ler­weile inter­na­ti­o­nal state-of-the-art für die moderne Soft­wa­re­ent­wick­­­lung ist. Wir haben fest­­­ge­­­stellt, dass wir nur gemein­­­sam erfol­g­reich sind: Eine enge Zusam­­­me­n­a­r­­­beit mit den Kund:innen ist wich­tig. Scrum fördert die dafür notwen­­­dige Trans­pa­renz und Offen­heit.

Für die Umset­­­zung des Projek­tes stellt die HEC ein Entwick­­­lungs­­­team sowie den Scrum Master. Der Kunde stellt den PO, den unsere Expert:innen unter­­­stüt­­­zen. Um selbst Know-how aufzu­­­bauen ist es auch möglich, dass der Kunde eigene Entwick­­­ler:innen in das HEC-Team einbringt. Diese können auch vor Ort in der HEC arbei­ten.

Mehr über Scrum

Fragen zum Projektstart? Wenden Sie sich an:

Anforderungs­management