Venture at the Center

by Raphael Haase

Vom 7.04. – 10.04. habe ich zum ersten Mal ein besonderes Format der Produktentwicklung mitgemacht. Das so genannte CenterVenture. Am CDTM.

In nur 6 Tagen wollten wir ein intelligentes Steckdosen-Strommessgerät bauen,

  • das mit dem Internet spricht
  • die Messdaten visualisiert
  • Ein-/Ausschalten der Steckdose per Internet ermöglicht,
  • das gerade angesteckte Gerät über einen RFID-Tag am Gerät selbst identifiziert.

Und weil wir am Center of Digital Technology and Management sind, durften auch

  • eine Marke mit Logo und Botschaft,
  • Finanzplan
  • und Zielgruppenanalyse

nicht fehlen.

Vergleich mit Managing Product Development (anderer Kurs)

Über den “normalen” Produktentwicklungskurs im Semester davor hatte ich stets so meine Zweifel. Da sich hier viele Parallelen zum Arbeitsleben und anderen Uni-Kursen an ähnlichen Institutionen ergeben dürften, will ich meine Erfahrungen damit im Detail erklären:

Jeder im Team hat parallel sein normales Studium gemacht und alles hing stets etwas in der Luft:

  • Zu wenig Fokus.
  • Kontext-Wechsel im Hirn ist beanspruchend: Wenn man viele Projekte gleichzeitig abwickelt, merkt man, wie schwierig es eigentlich ist, einen Zustand im Gehirn da einzufrieren, wo man gerade ist. Jedes Betriebssystem kriegt das gut hin, wenn Anwendungen im Hibernation-Mode einfach per Abbild persistiert werden. Das menschliche Gehirn ist nicht nativ dafür ausgelegt. Man will eigentlich bei einem Projekten nach 7 Tagen wieder genau da weiter machen, wo man war. Geht aber nicht so einfach. Die beste Approximation in diese Richtung ist meiner Erfahrung nach aber eine riesige Mindmap mit allem drin: Fakten, Links zu Artefakten, Aufgaben, Zuständigkeiten, Deadlines. Der Theorie nach entspricht diese Struktur dem Hirn, dh. wenn man es so visualisiert, merkt man es sich besser und beim ersten Blick auf die Struktur hat mal viel schneller wieder alles da.
  • Eskalierende Einstellung zur Mittelmäßigkeit: Ich hatte Glück und Pech mit meinem Team. Wir waren zu Fünft. Zwei außer mir haben richtig kräftig gezogen. Und ich nehme kein Blatt vor den Mund: Von den anderen Zweien war ich nicht gerade begeistert. Ich hatte das Gefühl, als müssten wir nun die zwei mitschleppen, obwohl sie von den Fähigkeiten her gar nicht ins Team passten. Man sollte sein Team also lieber selbst auswählen können.

CenterVenture ist das bessere Format

Beim CenterVenture-Format war das besser:

  • Dauer: Statt einem ganzen Semester, dauerte das ganze nur 6 Tage. 2 Tage Konzept, 4 Tage Machen.
  • Team: Für so ein Espresso-Format melden sich naturgemäß bessere und motiviertere Leute. Denn leider gilt das mit dem Zentralen Grenzwertsatz überall. Nachdem jedoch der Erwartungswert im CenterVenture besser war und meine menschliche Wahrnehmung nicht auf die Normalverteilung kalibriert ist, war ich mit dem Team hier deutlich zufriedener.
  • Echte Bereitschaft zur Exzellenz:
    • Marathon vs. Sprint: Mein Gefühl ist, dass die Leute eher bereit sind, über 4 Tage sehr viel Leistung zu geben, als im richtigen Moment einer langen Strecke. Zu wissen, wann man beim Marathon (ein ganzes Semester) wie schnell laufen sollte, ist offensichtlich doch den meisten nicht intuitiv klar. Die 4 Tage der Entwicklungs-Session, in der wir den Prototypen gebaut haben und den Business Plan geschrieben, sieht dagegen übersichtlicher.
    • Amplitude zählt: 2. Beobachtung: Häufig zählt die maximale Leistung. In 4 Tagen alles zu geben kann also besser sein, als über 3 Monate ein bisschen.

So viel zum Format, nun zum Technischen:

  • Messhardware: Wir entschieden uns für Arduino als Grundlage, um die ganzen Messgeschichten, RFID zu lesen und ein- und auszuschalten. Dazu ein WiFly-Shield für WiFi-Uplink.
  • Uplink: Das Ding sollte mit dem Internet reden. Eigentlich wollte ich lieber gleich GPRS. Wir sind in Deutschland, da ist gute Netzabdeckung und GPRS ist halt am einfachsten, weil man das dem Nutzer in die Hand drückt und es läuft. Aber es sollten keine laufenden Kosten bei der Geschäftsidee dabei sein. Nachdem ZigBee doof zum Bauen war, da es keine guten Router zu IP oder HTTP gibt, blieb nur noch WLAN. Nicht gerade prädestiniert, aber fürs Bauen eine einfache Option, weil jeder mit IP und Konsorten vertraut ist. Dachte ich. Am Schluss wusste mein Kollege bei der Aufgabe doch wieder nicht, wie man einen TCP-Server in Groovy schreibt😉
  • Layer 5 aufwärts: Als erstes wollten wir den Arduino einfach einen Server per HTTP-Post-Req. über neue Messdaten informieren und diese so gleich mitschicken. Dann habe ich einen halben Tag damit verbracht, den HTTP-Get-Request richtig hin zu kriegen und hatte keine Lust mehr. Also habe ich lieber direkt nur TCP auf dem Arduino bzw. WiFly-Shield verwendet. TCP-Verbindungen kann das WiFly nämlich direkt aufbauen ohne dass man TCP implementieren müsste. Man muss lediglich die Daten für den Strom über den SPI-Bus des Arduino an das WiFly durchjagen.
  • Kommunikations-Architektur:
    • Arduino
    • “Router” TCP <-> HTTP
    • Grails-basierte Webseite
  • Server-Seite: Für die Webseite selbst wollten wir Grails einsetzen. Da wir uns lieber nicht damit beschäftigen wollten, wie man Grails mit einem TCP-Server verbindet, habe ich einen “Router” geschrieben, der nun eine persistente TCP-Verbindung mit dem Arduino offen hält und über HTTP-Requests mit Grails kommuniziert. Nachdem ich mich ohnehin seit einiger Zeit mit Python auseinandersetzen wollte, habe ich das darin geschrieben. Python war stellenweisse haariger als ich dachte. Aber es ging. Und dass bei Python die “Batterien dabei” sind, ist schon cool.

Verlauf

Am Anfang stellte ich mir alles noch recht einfach vor.

Ich dachte: Wenn das WiFly schon TCP kann und selbst WPA2-PSK mit AES, müsste doch eigentlich die Internet-Kommunikation einfach sein. Was dann jedoch seine Zeit brauchte, war die Kommunikation zwischen dem Arduino und dem WiFly. Außerdem stellte sich heraus, dass es wohl nicht so gut ist, direkt HTTP auf dem Arduino zum Laufen zu bekommen. Ich hatte zuerst GET implementiert und dann Angst vor POST, nachdem ich bei GET Stunden brauchte, um heraus zu finden, dass der Request mit einem Carriage-Return terminiert werden muss. Was natürlich nirgends steht.

Um die Kommunikation mit der Grails-basierten Webseite sicher zu stellen, kam ich auf die Idee, einen “Router” zu schreiben, der auf der einen Seite eine persistente TCP-Verbindung mit dem Arduino offen halten würde und auf der anderen Seite über HTTP in die Grails-Anwendung neue Messwerte pushen würde.

Um nicht alles zu kompliziert zu machen, haben wir den “Rückkanal” zwischen Webseite und Arduino dann einfach so implementiert, dass die Webseite in dem HTTP-Request als Antwort an den Client, in diesem Fall den “Router” zwischen Grails und Arduino, eine 1 oder 0 schickt. Die Ziffern stehen für ein an- oder aus des Stroms an der Steckdose. Mehr Rückkanal-Funktionalität brauchten wir ja auch nicht.

Am Ende der 4 Tage ging dann fast alles. … fast.

Tools

Management-Tools, die einfach unverzichtbar hilfreich waren:

  • Mindmeister: Ideal für Cloud-Mindmaps ist mindmeister. Jeder im Team ist auf der selben Seite.
  • Redmine: Als “Backend” zu mindmeister ist Redmine ein tolles Werkzeug. Es gibt Werkzeuge, die mehr Funktionen haben. Für Software-Entwicklung und überhaupt viele Dinge reicht aber Redmine IMO. So viele Features braucht man ja auch gar nicht, auch wenn viele einen versuchen das einzureden. Ich versuche in der Regel so viel wie möglich in einer einzigen Projekt-Mindmap in mindmeister zu sammeln, um den Überblick zu haben. Redmine einhält dann die noch höher aufgelösten Details, z. B. die Team-Kommunikation, technische Dokumentation im Wiki und Aufgaben. Dabei versuche ich Aufgaben so viel wie möglich in der Mindmap zu halten und nur wenns zu viel wird, in den Issue-Teil von Redmine zu verlagern.

Nachdem dieses Projekt noch nicht abgeschlossen ist, werde ich bei Gelegenheit über die weitere Entwicklung berichten.