EXPERT TALK: Vom Tretroller zum Auto?

EXPERT TALK: Vom Tretroller zum Auto?

2018-11-28T08:55:56+00:00November 26th, 2018|Expert Talk|

Wie kommt man zu einem guten MVP?

Autorin: Dr. Annegret Junker, Software-Entwicklerin

Neue Reihe:

EXPERT TALK

In der Reihe „Expert Talk“ auf dem iSQI Blog schreiben Experten in regelmäßigen Abständen über Fachthemen aus dem Bereich Softwaretesting und Co.

Minimal Viable Products (MVPs) gelten neben Microservices und Domain Driven Design als heiliger Gral der agilen Software-Entwicklung. Sie versprechen frühzeitiges Feedback vom Kunden bei minimalen Aufwänden. Minimal Viable Product (MVP) bedeutet wörtlich übersetzt „minimal überlebensfähiges Produkt“. Es ist die allererste Minimal-Version eines Produkts, das schnell und einfach entwickelt und nur mit den nötigsten Kernfunktionen ausgestattet wird. Über das MVP soll mit so wenig Aufwand wie möglich Feedback von potenziellen Kunden eingeholt werden. Oft werden MVPs mit Bildern beschrieben. Der Tretroller steht stellvertretend für Fahrrad, Motorroller, Motorrad und Auto. Das Bild greift zwar die Mobilitätsanforderung des Kunden auf. Und sicher können viele Dinge während der Entwicklung des Tretrollers auch für seine großen und komplizierten Kollgen im Verkehr geklärt werden. Doch viele Wege und die Hürden werden weniger diskutiert.

Zwar folgt aus dem Bild, dass die Mobilitätsbedürfnisse des Kunden immer besser befriedigt werden, aber aus einem Tretroller wird nie ein zufriedenstellendes Fahrrad werden. Aus einem Motorrad wird nie ein Auto. Aber die Zwischenergebnisse können im nächsten Schritt nicht wiederverwendet werden. Der Beitrag diskutiert anhand eines Beispiels aus dem IoT-Bereich, wie man MVPs bauen kann, ohne zu viel „für die Tonne“ zu arbeiten und auf welche Fragestellungen man am Anfang nicht verzichten kann.

Als Modell wird ein mittelalterlicher Bau für kleine Hütten und Wohnhäuser verwendet. Als erstes errichtet man ein Gestell aus Holz und deckt es mit Stroh ab. So entsteht ein Dach, das schon einen ersten Schutz vor Regen und Wind bietet, auch wenn man darin nicht wirklich wohnen kann. In einem zweiten Schritt wird das Dach mit Holzstützen angehoben und darunter Mauern gebaut. Nun hat man schon ein Haus mit Tür, wenn auch ohne Fenster. Die Fenster können nachträglich eingefügt werden und auch ein Schornstein mit Feuerstelle kann gebaut werden.

 

Im Gegensatz zu dem gängigen Skateboard – Auto -Modell erreicht der Kunde in diesem Modell eine bessere Befriedigung seiner Bedürfnisse – ohne dass das vorher Erreichte wie zum Beispiel eine Hütte ohne Fenster weggeworfen wird.

Problemstellung für das Finden eines MVPs in einem IoT-Projekt

Bauern in ländlichen Gebieten suchen nach zusätzlichen Verdienstmöglichkeiten im Winter. Eine solche Möglichkeit ist ein Schneeräumdienst zum Beispiel für Supermärkte. Da nicht jeder Bauer mit jedem Supermarkt selbst Verträge machen kann, können hier Vermittler der Verträge und der Aufträge auftreten. Dieser Vermittler übergibt nicht nur die Aufträge an die Landwirte, sondern stellt die Dienstleistungen auch zentral in Rechnung – wodurch der Gesamtprozess einfacher und übersichtlicher wird. Man braucht einen Nachweis, dass die Dienstleistung erbracht wurde. Hierzu können Sensoren eingesetzt werden, die sowohl die GPS-Daten des Traktors, als auch die Arbeitszustände des Schneepfluges und der Streumaschine aufnehmen und an eine zentrale Stelle senden. Das Gesamtsystem ist ein IoT-Projekt mit Sensoren in den Fahrzeugen bis hin zu den Daten-Auswertungen für Rechnungen.

 

Die Abbildung zeigt, wie das System funktioniert:

  1. Der Landwirt fährt zum Schneeräumen und vollzieht seinen Winterdienst. Den Auftrag bekommt er über eine mobile Applikation.
  2. Die Daten werden aus der Cloud dem Vermittler zur Verfügung gestellt.
  3. Der Vermittler erstellt Rechnungen für die Dienstleistungsnehmer auf der Basis der gesendeten Daten.

Wie können MVPs aussehen?

In einem ersten Schritt würde man die mobile Applikation implementieren. Aber macht das wirklich Sinn? Man muss die Daten in die Cloud bekommen. Das muss der erste Schritt sein. Hat man die Daten von einem Traktor mit einem Schneepflug und einer Streumaschine in der Cloud und kann die entsprechenden Daten sehen, hat man einen großen Schritt gemacht. In diesem ersten Schritt muss man die Verschiedenartigkeiten der Sensoren und der Traktoren auf eine Art von Sensoren und Fahrzeugen einschränken. Das heißt, man hat im ersten Schritt einen Traktor mit Sensoren, der Daten in die Cloud schicken kann. Das entspricht unserem einfachen Dach.

Da es für den Business-Prozess wichtiger ist, die Daten auszuwerten und Rechnungen zu schreiben, kommt als zweiter Schritt die Auswertung für die Rechnungserstellung. Die Daten werden in einem Datenteich („data lake“) gesammelt und für die Auswertung zur Verfügung gestellt. Die Auswertung erfolgt dann über entsprechende Aggregationen und Filter. Erste Load- und Performance-Tests können schon zu diesem frühen Zeitpunkt stattfinden.

Das wären die Mauern der Hütte.

Dann kann man die mobile Applikation implementieren. Mit der mobilen Applikation kann man die aktuellen Daten direkt abholen – aber auch auf die aggregierten Daten im Data Lake zugreifen. Jetzt kann unserer Kunde auch aus den Fenstern nach draußen sehen.

Um diese Hütte zu einem bewohnbaren Haus zu machen, braucht man natürlich viel mehr.

  • Zugriffsschutz inklusive Benutzerverwaltung, um die Daten zu schützen und die Datensicherheit zu gewährleisten.
  • Unterstützung von verschiedenen Fahrzeug- und Sensortypen
  • Die gesamte Applikation muss performant und skalierbar sein.

Dies führt uns von einem „MINIMAL viable product“ zu einem wirklichen verwertbaren Produkt.

Kundenbedürfnisse Schritt für Schritt befriedigen

Um MVPs zu definieren und dem Kunden vorstellen zu können, reicht es nicht, das Einfachste zuerst zu machen. Sondern man muss vielmehr den Businessprozess gesamthaft bewerten. Dazu gehört nicht nur die Geschäftsfunktion, sondern diese Funktion muss in auch qualitativen Anforderungen – wie beispielsweise Performance- oder Sicherheits-Anforderungen – eingebettet sein. Auf dieser Basis schafft man es, einen Schritt-für-Schritt-Ansatz zu ermöglichen, wo man Vor-Ergebnisse nicht (unbedingt) verwerfen muss. Nach jedem Schritt kann man das Ergebnis zusammen mit dem Kunden evaluieren. So erhält man schnell Feedback vom Kunden und kann seine weitere Vorgehensweise an den Bedürfnissen des Kunden ausrichten.

Autor

Dr. Annegret Junker ist Senior Software Architekt bei der adesso AG. Sie arbeitet seit mehr als 25 Jahren in der Software-Entwicklung in unterschiedlichen Rollen und unterschiedlichen Domänen wie Automotive und FinTech. Derzeit arbeitet sie in einem großen Migrationsprojekt bei einem deutschen Autohersteller. Kontakt: annegret.junker@adesso.de.

Literatur

[1] Kniberg, H.: Making sense of MVP, https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp