Pläne sind nichts; Planung ist alles.
Dieses Zitat geht auf Dwight D. Eisenhower zurück. Es bringt gut auf den Punkt, wie wichtig und wandelbar die Planung in einem Softwareprojekt ist.
Pläne sind nichts; Planung ist alles.
Dieses Zitat geht auf Dwight D. Eisenhower zurück. Es bringt gut auf den Punkt, wie wichtig und wandelbar die Planung in einem Softwareprojekt ist.
Als erstes sollten die Eckdaten des Projekts geklärt werden. Dazu nutzen wir die W-Fragen:
Welchen Nutzen soll die Webapp haben?
An wen richtet sich die Webapp?
Warum will ich diese Webapp entwickeln?
Wann soll die erste Version fertig sein?
Wie viel Budget steht für die Entwicklung zur Verfügung?
Von wem (Konkurrenten) will ich mich abheben?
Bei allen W-Fragen ist auch die Negation besonders interessant, zum Beispiel: An wen soll sich die Webapp nicht richten, welche Nutzergruppe können wir bewusst ignorieren?
Sobald die Anforderungen erfasst wurden, müssen die Kernfunktionen für den MVP identifiziert werden. Der MVP, das Minimum Viable Product, ist die Basisversion der Software, die alle wesentlichen Funktionen und Merkmale enthält, die für die Lösung des Problems der Benutzer unbedingt erforderlich sind.
Wenn es mal schwierig ist, die Grenze zu ziehen ...
Dann hilft es, die Features die man sich wünscht, in 4 Kategorien zu unterteilen:
Must have
Should have
Could have
Won't have
Diese Art der Unterteilung nennt man MoSCoW-Priorisierung. Im besten Fall, besteht der MVP nur aus den Must-haves und verzichtet weitestgehend auf die Should's und Could's.
Sobald die Kernfunktionen für den MVP identifiziert wurden, müssen die Funktionen für nachfolgende Versionen identifiziert werden. Diese Funktionen können nach und nach hinzugefügt werden, um die Softwarelösung zu verbessern und weitere Bedürfnisse der Benutzer zu erfüllen.
Um sicherzustellen, dass die Software den Anforderungen der Benutzer entspricht, müssen Anforderungsdokumente und Userstories erstellt werden. Diese Dokumente beschreiben, wie die Software funktionieren soll und was die Benutzer von ihr erwarten können. Hierbei wird mit den Kernfunktionen des MVP begonnen und später auf die Funktionen für nachfolgende Versionen erweitert.
Eine User Story ist eine kurze, prägnante Beschreibung einer Funktion aus der Perspektive (Rolle, Szenario) des Benutzers. Sie beschreibt, was der Benutzer tun möchte und warum. User Stories werden in der agilen Softwareentwicklung verwendet, um Anforderungen zu sammeln und das Entwicklerteam darüber zu informieren, wie sich die App verhalten soll.
Beispiele für Userstories:
Als Benutzer möchte ich in der Lage sein, mich mit meinem Benutzernamen und Passwort anzumelden, um auf meine Kontoinformationen zugreifen zu können.
Als Administrator möchte ich in der Lage sein, Benachrichtigungen an Benutzer zu senden, um wichtige Informationen weiterzugeben.
Sobald die Anforderungsdokumentation und die Userstories erstellt wurden, kann mit der Entwicklung des MVPs begonnen werden. Hierbei werden die Kernfunktionen umgesetzt, um die Basisversion der Softwarelösung zu erstellen.
Ein MVP schreibt sich auf die Fahne, schnell umgesetzt zu sein weil er sich nur auf das wichtigste konzentriert.
Worauf verzichtet man also?
Moderne MVPs die mit Laravel und Nova entwickelt werden, bieten viele UI-Funktionen wie Filter, Sortierfunktionen, Dark-Mode, uvm und natürlich individuelle Business-Logik. Nicht selten wird Nova insbesondere für interne Tools bei denen kein spezielles Design benötigt wird, von Beginn an mit dem langfristigen Einsatz von Nova geplant.
Nach der Entwicklung des MVPs sollten erste Benutzertests durchgeführt werden, um zu überprüfen, ob die Software den Anforderungen der Benutzer entspricht. Hierbei wird Feedback gesammelt, um die Planung auf der Grundlage der Nutzerbedürfnisse zu verbessern.
Es ist wichtig, frühzeitig mit echten Benutzern zu testen, da dies dazu beiträgt, Feedback zu sammeln und sicherzustellen, dass die Software den Bedürfnissen der Benutzer entspricht. Durch frühzeitiges Testen können Probleme frühzeitig erkannt und behoben werden, bevor die Software veröffentlicht wird.
Die Planung basierend auf Nutzerfeedback verändert sich, da Feedback dazu verwendet wird, die Software zu verbessern. Die Rückmeldungen der Benutzer helfen dabei, Schwachstellen und Verbesserungsmöglichkeiten zu identifizieren und Änderungen vorzunehmen, um die Bedürfnisse der Benutzer