Ein Storyboard zum Anfassen:
Rapid Prototyping in der Softwareentwicklung

MVP. PoC und Prototyp – welche Unterschiede gibt es und worauf ist beim Rapid Prototyping zu achten?

Was haben das Storyboard für einen Zeichentrickfilm und ein Software-Prototyp gemeinsam?

Beides sind Visualisierung einer Idee und häufig auch der „rote Faden“ für die Umsetzung in einem Team.

Ein Grundkonzept des Design Thinking liegt u.a. darin alle Projektbeteiligen durch geeignete Visualisierungen in die Lage zu versetzen, „die gleiche Sprache zu sprechen“ und mögliche Lösungen für ein gegebenes Problem mithilfe verschiedener Techniken zu finden und zu bewerten.
Während dies bei einem Animationsfilm recht einfach dadurch gelingen kann, dass man z.B. einige Bilder des Storyboards zu einem Daumenkino kombiniert, um so z.B. die Bewegung von Personen und Objekten darstellen zu können, ist dies bei Software meist etwas aufwändiger.

Häufig werden im Rahmen der Weiterentwicklung bestehender Softwareprodukte (interaktive) Mockups oder Wireframes verwendet, um z.B. Übergänge von einem View auf einen anderen zu simulieren. Im Grunde ist dies aber auch nichts anderes als eine reine Visualisierungstechnik – und z.B. bei sogenannte Greenfield-Projekten nur bedingt hilfreich. Im Laufe der Zeit haben sich deshalb auch eine ganze Palette verschiedener Versionen des Prototypings entwickelt, die eines gemeinsam haben:

Durch einen überschaubaren Aufwand and (personellen) Ressourcen, Zeit oder Budget soll entweder

  • die Machbarkeit eines Ansatzes überprüft,
  • der zu erwartende Aufwand für die komplette Implementierung eines Projekts abgeschätzt oder
  • schnellstmöglich eine erste Version gebaut werden, mit der man sich Feedback (von Nutzern, Steakholdern, Projektbeteiligten) einholen kann.

Häufig werden die Begriffe Prototyp, Minimum Viable Product (MVP) und Proof of Concept (PoC) synonym verwendet, unterscheiden sich jedoch im Vergleich von einander:

  • Im Rahmen eines Proof of Concept wird in der Regel ein Teilbereich eines kompletten Produkts betrachtet. Dies kann bei einer datenbankgetriebenen Anwendung z.B. die Beispielimplementierung für die Verwendung einer bestimmten Datenbank sein oder für eine Webanwendung der Vergleich zwischen einem LAMP- und einem MEAN-Stack sein.
  • Ein klassicher Prototyp wird meistens dann entwickelt, wenn das Zusammenspiel verschiedener Technologien, Lösungsansätze etc. in einem kontrollierten Umfeld (z.B. einer Testumgebung) – in der Regel ohne echte Testnutzer – demonstriert werden soll.
  • Ein Minimum Viable Product ist einem Prototypen sehr ähnlich, im Regelfall jedoch so weit ausgereift, dass es – in begrenztem Rahmen, ohne dass bereits alle geplanten Funktionen zur Verfügung stehen – auch in einem produktiven Umfeld getestet werden kann.

Wie wird nun aber aus Prototyping Rapid Prototyping?

Die kurze Antwort: Indem man die Entwicklungszeit (für jede Iteration) des Prototypen möglichst kurz hält. Etwas ausführlicher bedeutet dies:

Viel hilft nicht unbedingt viel
Im Regelfall ist die Rechnung dass ein Job in der Hälfte der Zeit erledigt wird, wenn ich doppelt so viel Ressourcen zur Verfügung habe, falsch. Je größer das Team wird, umso mehr Overhead entsteht durch Absprachen und Selbstorganisation. Zudem besteht das Risiko, dass durch ein unterschiedliches Verständnis der Aufgaben-/ Fragestellung sich widersprechende Ansätze verwendet werden.

Wiederverwendbarkeit
In der Regel wird – weder beim Prototyping, noch der Entwicklung einer Softwarelösung – ausschließlich selbstentwickelter Code verwendet. Häufig kommen externe Bibliotheken, Tools und Frameworks zum Einsatz. Dabei sollte bedacht werden, dass

  • Sehr umfangreiche und große Frameworks meist auch eine längere Einarbeitungszeit benötigen. D.h. selbst wenn man schnell einen entsprechend qualifizierten Entwickler findet, ist es meist nicht ohne Weiteres möglich das Framework oder den Entwickler/ Dienstleister in einer späteren Projektphase zu wechseln.
  • Die verwendeten Frameworks und Bibliotheken sollten nicht nur möglichst viele schnell einsetzbare und Standardkomponenten enthalten, sondern die Komponenten sollten auch so gestaltet sein, dass ein Entwickler diese ohne viel Aufwand/ Code entsprechend der aktuellen Bedürfnisse modifizieren kann.
  • Low Code-Systeme erfreuen sich aktuell immer größerer Beliebtheit, da sie versprechen, dass im Grunde jeder Anwender – auch ohne Erfahrung in der Programmierung – seine eigenen Anwendungen entwickeln kann. Unabhängig davon, dass die meisten derartigen Systeme häufig nur Bausteine für von Ihnen selbst unterstützte Funktionen und Drittanwendungen bereitstellen, sollte man sich vor dem Einsatz dieser Systeme aber überlegen ob der Produktiveinsatz der damit einhergehenden Infrastrukturen überhaupt gewünscht oder sinnvoll ist. Ein typisches Beispiel dafür ist Power Automate der Firma Microsoft, das zwar sehr mächtig sein kann, jedoch auch die Nutzung der Azure-Cloudinfrastruktur voraussetzt.

Nichts überstürzen!
Auch wenn die reine Entwicklungszeit eines Prototypen, MVP oder PoC unter Optimalbedingungen recht zügig erfolgen kann, ist es gerade im Agilen Umfeld wichtig, dass damit nicht das Ende der Reise erreicht ist, sondern nicht nur Feedback eingeholt werden sollte, sondern dieses auch entsprechend in die Planung nächster Schritte oder weiterer Prototyping-Zyklen einfließen einfließen muss. Häufig dauert es mindestens genauso lange bis alle am Projekt beteiligten Mitglieder, Testnutzer, Mitglieder von Fokusgruppen die Möglichkeit hatten die entsprechenden Funktionen zu testen, ihre Rückmeldung dazu zu geben und diese auch entsprechend aufzuarbeiten.