Die Industrie, Architekten und Ingenieure machen es uns schon lange vor. Durch den Einsatz von Prototypen optimieren sie ihre Entwicklungsprozesse und schaffen ein gemeinsames Verständnis vom “Produkt” und seiner Nutzung.  In der Softwareentwicklung wird diese Methodik immer noch viel zu selten eingesetzt.

 

Prototypen

Prototypen sind vereinfachte, unvollständige Modelle eines Designs (visuell oder technisch). Sie werden eingesetzt um Ideen zu überprüfen, Anforderungen zu optimieren, Spezifikationen zu verfeinern und um Funktionalität zu testen.

 

3 Arten von Prototypen

In der Praxis unterscheidet man zwischen 3 verschiedenen Arten von Prototypen:

  1. Konzeptprototypen: Nutzt man um in einem frühen Stadium Varianten eines Konzepts oder einer Idee zu überprüfen und zu vergleichen.
  2. Wegwerfprotoypen: Eigenen sich  für die einmalige Überprüfung einer Funktionalität und dem Sammeln von Informationen zu einem bestimmten Systemaspekt (z.B. Windkanalmodelle in der Autoindustrie). Die Prototypen werden danach “entsorgt”.
  3. Evolutionsprototypen: Die für die Softwareentwicklung wohl wichtigste Art. Sie wird dann eingesetzt,  wenn ein System und seine Designspezifikation ständiger Wandlung und Weiterentwicklung unterworfen ist. Ein solcher Prototyp wird iterativ weiterentwickelt, evaluiert, und getestet. Es “wächst” mit dem Projekt.

 

Prototypen und User Centered Design

In der Solution Architektur kennt man seit längerem vertikale Prototypen (Durchstich einer prototypischen Funktionalität durch alle Systemebenen). Im User Centered Design Lifecycle nutzen wir horizontale Prototypen – die den aktuellen Funktionsumfang in seiner Breite nicht aber in seiner Detailtiefe zeigen – in Form von Wireframes, HTML Prototypen oder gar Scribbles. Sie sind für den Requirements Engineering Prozess aus folgenden Gründen enorm wichtig:

  • Sie  visualisieren die Interaktion Nutzer-System und die damit verbundenen Anforderungen.
  • Sie zeigen ein konsistentes aber dennoch vereinfachtes Gesamtbild des Produktes.
  • Sie  ermöglichen das Validieren von Anforderungen (u.a. Usability Tests) in jeder Phase des Projektes.
  • Sie helfen dadurch frühzeitig Risiken zu identifizieren.
  • Sie helfen im Projektteam ein gemeinsames Verständnis der Funktionalität zu verankern.
  • Sie sind Teil der Spezifikation und Dokumentation.

Besonders hervorheben möchte ich die beiden letzten Aspekte. Im aktuellen Projekt, an dem ich arbeite, nutzen wir seit dem zweiten Sprint einen Wireframe-Prototyp, der sich über die letzten 14 Sprints laufend verändert und mitwächst. Zu Beginn des Projektes waren die Entwickler ziemlich skeptisch gegenüber “den Zeichnungen” und wollten deren Sinn nicht recht verstehen. Doch im Laufe der ersten Sprints wandelte sich ihre  Meinung. Die Wireframes hingen im Projektraum an der Wand gegenüber der SCRUM-Storymap (2-Wand Prinzip) und wurden innerhalb kürzester Zeit zur Kommunikationsgrundlage zwischen Businessvertretern, den Entwicklern, den Stakeholdern (diverse Fachbereiche im Konzern) und dem sogar dem Top-Management. Jeder hat nun die gleiche visuelle Vorstellung von dem, was wir umsetzen wollen. Die Wireframes sind zu einer lebendigen Kommunikationsplattform geworden. Heute sagen mir die Entwickler: “Gib mir die Story, die entsprechenden Wireframes und das Visual-Design. Mehr Spezifikation brauche ich nicht!” In einem Unternehmen, dessen Prozesse Dokumentberge für die Spezifikation generieren und fordern, ein absoluter Tabubruch.

 

Mögliche Probleme bei der Arbeit mit Prototypen

Natürlich ist der Einsatz von Prototypen nicht gänzlich unproblematisch. Bei der Entwicklung von Evolutionsprototypen läuft der Designer Gefahr – durch die Fokussierung auf die kontinuierliche Verbesserung des bestehenden Prototypen – ein Scheuklappendenken zu entwickeln und Lösungsalternativen ausser acht zu lassen. Es ist daher umso wichtiger, dass das gesamte Entwicklungsteam die Evolution des Prototypen mitverfolgt und dadurch neue Perspektiven einnehmen kann.

Ein weiterer Knackpunkt kann das Problem der “künstlichen Realität” darstellen. Ein Prototyp ist ein mehr oder weniger abstarktes Abbild einer zukünftigen Realität. Beim einem Architekturmodell ist diese Tatsache jedem Beteiligten bewusst. Bei Wireframes oder gar HTML Prototypen kann die Grenze zwischen Modell und realem Produkt erheblich unscharf werden. Es ist daher wichtig, dass Prototypen als solche klar und deutlich erkannbar sind und auch so deklariert werden, ganz besonders im Umgang mit Kunden und Stakeholdern. 

 

Fazit

Setzt Prototypen ein! Verwendet Konzeptprototypen zur Entwicklung und Evaluierung vorbereitender Ideen und Evolutionsprototypen zur Ausarbeitung von Anforderungen, zum Evaluieren von Annahmen und zur Schaffung eines gemeinsamen Produktbildes bei allen Beteiligten. Achtet aber auf die Problematiken der künstlichen Realität  der Übertragbarkeit und Integration und kalkuliert genügend Zeit für die Evaluierung der Prototypen. Ihr werdet es nicht bereuen und feststellen, dass die Vorteile und deren Impact auf das Projekt enorm sind. Viel Spass dabei!