Softwareprojekte starten

Von der Produktvision zum Scrum-Projekt

Chat

Hallo

Ich bin der Chatbot der HEC GmbH. Ich beantworte Ihnen Fragen zum Unternehmen, zur Bewerbung, zu Parkmöglichkeiten und ähnlichem!

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:

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 Projekt­ziele. Aber Kommu­ni­ka­tion kann trick­reich sein und das Projekt­team mitun­ter etwas ganz ande­res darun­ter verste­hen.

Wich­tig ist deshalb, von Anfang an ein gemein­sa­mes Verständ­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, Produkt­ma­na­ger:innen, Projekt­lei­tende, Nutzer:innen, Ideen­ge­bende, Stake­hol­der, tech­ni­sche Ansprech­part­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 bestimm­tes Nutzungs­ver­hal­ten kann ihnen zuge­schrie­ben werden. Sie verfü­gen über Ziele und Bedürf­nisse, haben Vorlie­ben und Erwar­tun­gen. Die Perso­nas beglei­ten das Team während der gesam­ten Projekt­lauf­zeit.

Produktvision

Das Produkt vor Augen führen

Das Soft­wa­re­pro­dukt wird plas­tisch – und zwar mit der Produkt­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 [Link] 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.

Auf einen Blick: 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­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.

Product Backlog

Der Speicher für alle Aufgaben

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.

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 NoEsti­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

Starten Sie jetzt Ihr Projekt

Anforderungs­management