Methoden und Wissen
Starten Sie Ihre Softwareprojekte mit den richtigen Methoden
28. Oktober 2021 / Annekathrin Gut
Eine Software ist nur dann richtig gut, wenn die Anwender sie gerne nutzen. Ihre Anforderungen müssen zu Beginn des Projektes so genau wie möglich erfasst werden. So werden Planungsfehler vermieden, die später teuer zu stehen kämen. Im Projektverlauf sollten sich Änderungen integrieren lassen. Und schließlich müssen alle Maßnahmen auch ins Budget passen.
Wir haben ein strukturiertes Vorgehen entwickelt, mit dem wir große Softwareprojekte zeit- und kosteneffizient umsetzen können. Wichtig für das Anforderungsmanagement sind aus unserer Sicht eine gute Kommunikation und ein enges Zusammenspiel zwischen Kund:innen und Entwickler:innen. Und so gehen wir an diese Aufgabe:
Projektstart
Anforderungen richtig verstehen
Was soll die Software leisten, wenn sie fertig ist? Kund:innen nennen zu Beginn ihre Anforderungen und Projektziele. Aber Kommunikation kann trickreich sein und das Projektteam mitunter etwas ganz anderes darunter verstehen.
Wichtig ist deshalb, von Anfang an ein gemeinsames Verständnis von Zielen und Anforderungen zu entwickeln. Um das zu erreichen, starten wir üblicherweise mit einem gemeinsamen Workshop, 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 Workshop sollten möglichst alle an der Planung oder der späteren Nutzung beteiligten Personen teilnehmen. Dazu gehören Product Owner, Produktmanager:innen, Projektleitende, Nutzer:innen, Ideengebende, Stakeholder, technische Ansprechpartner:innen und Sponsor:innen.
Personas
Kreativ in Nutzer hineinversetzen
Wir stellen uns die Personen vor, die später mit dem Softwareprodukt arbeiten sollen. Die sogenannten Personas, die wir im Workshop entwickeln, sind fiktive Repräsentanten mit den wesentlichen charakteristischen Merkmalen der späteren Benutzer.
Personas sind ein kreatives Hilfsmittel, das den Workshopbeteiligten hilft, sich in die künftigen Nutzer hineinzuversetzen. Sie sind genauer als Zielgruppen und werden mit einem Namen, einem Gesicht, einer Funktion und einem Werdegang versehen. Auch Privatleben und ein bestimmtes Nutzungsverhalten kann ihnen zugeschrieben werden. Sie verfügen über Ziele und Bedürfnisse, haben Vorlieben und Erwartungen. Die Personas begleiten das Team während der gesamten Projektlaufzeit.
Produktvision
Das Produkt vor Augen führen
Das Softwareprodukt wird plastisch – und zwar mit der Produktvision. Sie soll dem Projekt Orientierung geben und die Workshopteilnehmenden dazu inspirieren, die Vision verwirklichen zu wollen. Gemeinsam beantworten wir folgende Fragen:
- Wie nennen wir das Produkt?
- Was soll mit dem Produkt erreicht werden?
- Was können wir besser (als andere), wenn das Produkt fertig ist?
- Wer möchte was und wozu?
- Woran erkennen wir, dass das Projekt erfolgreich ist?
- Wer hat Einfluss auf den Erfolg des Projektes?
- Welche Risiken und Chancen gehen mit dem Projekt einher?
Sie kennen vielleicht das Prinzip des Business Model Canvas. Mit solchen Vorlagen wird ein Geschäftsmodell auf einen Blick sichtbar gemacht. Extra für unsere Softwareprojekte haben wir ein Poster entwickelt, damit die Produktvision wirklich plastisch wird. Es gibt auch andere Möglichkeiten, zum Beispiel einen Zeitungsartikel über das fertige Produkt zu schreiben oder einen Produktkarton zu bauen.
Personas
Das HEC Personas-Poster hilft dabei, die künftigen Nutzer:innen besser zu verstehen.
Business Story Template
Die Business Story-Vorlage bietet Hilfestellung auf dem Weg zur Produkt-Vision.
Produktvision
Das HEC Produktvision-Poster zeigt auf einen Blick, wie das fertige Softwareprodukt aussehen soll.
Nutzen Sie unsere Arbeitshilfen
Story Map
Das große Bild der Anforderungen
Welche Funktionen soll die Software bieten? Mit Hilfe der Story Map visualisieren wir den angestrebten Funktionsumfang. Hierzu erzählen wir Stories aus Sicht der Benutzer bzw. der Personas.
Story Mapping ist eine Technik, mit der alle Anforderungen an das neue Softwareprodukt aufgenommen und übersichtlich dargestellt werden. Und zwar immer ausgehend vom gewünschten Nutzererlebnis (User Experience, UX).
Wir starten mit einer Sammlung der Aufgaben, die aus Sicht der Benutzer:innen zu erledigen sind (User Tasks). Sie werden aufgeschrieben und so nebeneinander angeordnet, dass sie eine nachvollziehbare Geschichte (User Story) ergeben. Hierbei geht es nicht um einen festen Ablauf, denn manche Tasks führt der Nutzer sicherlich auch mal in einer anderen Reihenfolge aus.
Die Wörter und Bilder, die wir dazu verwenden, sorgen dafür, ein gemeinsames Verständnis aufzubauen. So können wir uns besser auf die Nutzer:innen und ihre Erfahrungen konzentrieren. Das Ergebnis ist eine bessere Kommunikation untereinander und schlussendlich ein besseres Produkt.
Wenn wir die Story Map erstellen, orientieren wir uns am Arbeitsfluss unserer Personas. In Form von Anwenderaufgaben (User Tasks) dokumentieren wir passgenau die Anforderungen an das System. Diese werden im nächsten Schritt priorisiert und entsprechenden Releases zugewiesen.
Business Stories
Die Wirkung für Stakeholder fokussieren
Wie hängen User Tasks oder Stories und Produktvision nun genau zusammen? Die Produktvision gibt uns eine große Orientierung (meist für die nächsten Jahre) und die User Stories beschreiben meist einzelne Funktionalitäten. Dazwischen gerät häufig der Zusammenhang und damit die Wirkung aus den Augen.
Um diese Lücke zu schließen, arbeiten wir mit Business 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 anfangen zu entwickeln, erstellen wir einen Themenspeicher, das Product Backlog. Es verzeichnet und priorisiert die zu entwickelnden Funktionen (Product Backlog Items). Die einzelnen Backlog Items ergeben sich aus den User Tasks der Story Map.
Ein Product Backlog ist eine dynamische Liste und nie ganz fertig, denn wir lernen während der gesamten Projektlaufzeit dazu. Um auf Veränderungen reagieren zu können, müssen wir die Inhalte und Reihenfolge jederzeit ändern können.
Den Überblick über den Inhalt des Product Backlogs hat der Product Owner (PO). Beim Aufbau unterstützen ihn üblicherweise Scrum Master und Mitglieder des Entwicklungsteams. Bei jeder User Task muss sich der PO überlegen, ob das Element ausreichend beschrieben und klein genug ist, um in die Entwicklung zu gehen. Wenn dies nicht der Fall ist, wird das Element weiter verfeinert und „geschnitten“.
Der PO kann das Product Backlog jederzeit verändern, wenn sich im Laufe des Entwicklungsprozesses Änderungen ergeben. Üblicherweise enthält es Aufgaben für die nächsten vier bis sechs Wochen. So kann der PO flexibel auf Veränderungen reagieren, während das Team weiterarbeitet.
Schätzen
Das Budget im Blick haben
Bevor Sie ein Projekt starten, müssen Sie abschätzen können, wieviel Sie innerhalb Ihres Budgetrahmens umsetzen können. Wie schaffen Sie es, nicht zu detailliert zu werden und dennoch Ihr Budget möglichst genau planen zu können?
Bevor also einzelne Backlog Items umgesetzt werden, werden diese geschätzt. Hierfür gibt es verschiedene Techniken und Methoden: Story Points und Shirt-Sizes, Team Estimation Game, Planning Poker oder Magic Estimates. Nicht immer sind solche Schätzungen zielführend. In Projekten mit langer Laufzeit und konstantem Wertfluss können auch andere Betrachtungen wie NoEstimates zum Einsatz kommen.
Scrum Projekt
Die Softwarentwicklung beginnen
Jetzt kann es losgehen. In der Regel entwickelt die HEC Software mit Hilfe des Scrum-Rahmenwerks, das mittlerweile international state-of-the-art für die moderne Softwareentwicklung ist. Wir haben festgestellt, dass wir nur gemeinsam erfolgreich sind: Eine enge Zusammenarbeit mit den Kund:innen ist wichtig. Scrum fördert die dafür notwendige Transparenz und Offenheit.
Für die Umsetzung des Projektes stellt die HEC ein Entwicklungsteam sowie den Scrum Master. Der Kunde stellt den PO, den unsere Expert:innen unterstützen. Um selbst Know-how aufzubauen ist es auch möglich, dass der Kunde eigene Entwickler:innen in das HEC-Team einbringt. Diese können auch vor Ort in der HEC arbeiten.
Kennen Sie den HEC Newsletter?
