Cloud

Cloudy Monday I: myCloud Desktop agil entwickelt!

Der Cloud-Speicherdienst myCloud ist seit anfangs 2016 öffentlich verfügbar. Im Sinne eines Minimum Viable Products haben wir uns zunächst auf Fotos fokussiert und für dieses Feature ein gutes Kundenerlebnis geliefert.

Abdurixit Abduxukur, Cloud Solution Architect
06 marzo 2017

Warum?

Schon früh haben wir durch unsere Analyse der Kundenbedürfnisse die Datei-Synchronisation (myCloud Desktop) als eines der nächsten wichtigen Features für myCloud erkannt:

Alle Dateien sind jederzeit aktuell auf jedem Rechner und Mobilgerät verfügbar.
Neue und geänderte Dateien werden vom Rechner nach myCloud hochgeladen.
Falls eine Datei in myCloud aktueller ist als auf dem Rechner, wird diese heruntergeladen.
Dateien sind auch ‘offline’ verfügbar mit automatischem Abgleich, wenn wieder online.
Alle Daten sind sicher und unlimitiert in der Schweiz gespeichert.

Was ist daran herausfordernd?

Aufgabe von myCloud Desktop ist es somit, Dateien auf jeweils allen Computern der Benutzenden aktuell zu halten und in myCloud zu sichern. Das klingt einfach, ist es aber leider nicht:

Wenn ein Computer offline ist, können die Änderungen nicht synchronisiert werden und die Benutzenden arbeiten auf potentiell veralteten Daten.
Wenn die Benutzenden z.B. eine Datei mit Word bearbeiten, ist diese gesperrt und kann nicht aktualisiert werden.
Die Übertragung einer Datei kann mehrere Minuten dauern, währenddessen die gleiche Datei erneut verändert werden kann.
Und vieles mehr…

Wie wurde myCloud Desktop entwickelt?

Im Jahr 2016 hatten wir die Idee, dass myCloud Desktop in kurzen Abständen prüfen soll, ob auf dem Computer oder in myCloud eine Datei neu angelegt oder verändert wurde. Die Differenzen zwischen den jeweiligen Zuständen wurden dann übertragen, so dass sowohl auf den Computern als auch in myCloud jeweils die aktuellste Version jeder Datei vorliegt. Dieser Ansatz hat sich unter anderem in praktischen Tests als zu langsam erwiesen und die User-Experience stark beeinträchtigt.

Aufgrund dieser Erfahrungen haben zwei Swisscom-Kollegen mit hohem Einsatz in wenigen Wochen einen vollfunktionalen Prototyp für myCloud Desktop entwickelt. Der Prototyp arbeitete ereignisbasiert, das bedeutet, dass jede Änderung auf dem Computer des Benutzers oder in seinem myCloud-Account sofort synchronisiert wurde. Der Prototyp erreichte damit bereits sehr früh eine hohe Geschwindigkeit und versprach eine gute User-Experience.

Wir hatten nun zwei Ideen und Lösungen und mussten uns entscheiden:

Die bisherige Lösung war deutlich reifer und die Auslieferung wäre ein kleineres Risiko gewesen.
Der neue Prototyp war schnell und versprach viel, war aber noch weit von einem fertigen Produkt entfernt.

Die Rahmenbedingungen standen jedoch fest, wir benötigten myCloud-Desktop bis zum März 2017.

Wir haben uns daher für ein “Horse race” entschieden, auf dass die beste Lösung gewinnt!

Für die ersten Sprints haben wir daher harte Meilensteine definiert, die die jeweiligen Teams mit dem neuen Prototyp und mit der bisherigen Lösung erreichen mussten. Im Sinne von “fail fast” schied eine Lösung aus, wenn die Meilensteine nicht erreicht wurden.

Nach dem ersten Sprint haben beide Lösungen die Meilensteine erfüllt. Das Swisscom-Team überzeugte jedoch durch hohe Qualität und Entwicklungsgeschwindigkeit so sehr, dass der neue Prototyp als Basis für myCloud Desktop gewählt wurde.

Die gemeinsame Aufgabe hat das Team zusammengeschweisst und zu Höchstleistungen angespornt, so dass die Meilensteine von November 2016 bis März 2017 und damit der Releaseplan von myCloud Desktop eingehalten werden konnte

Wie funktioniert myCloud-Desktop?

Die Wahl von Electron für die Anwendung und von Java für die Logik hat sich bewährt, da viele plattformspezifische Funktionen wie z.B. die Status-Icons oder das automatische Update mit geringem Aufwand umgesetzt werden können.

Was haben wir gelernt?

Die Benutzerbedürfnisse müssen über die Priorisierung der Features entscheiden.
Agile Entwicklungsmethoden motivieren das Team, helfen dabei, sich auf das Wesentliche zu konzentrieren und Fehlentwicklungen schnell zu korrigieren.
Kurze 1-Wochen Sprints haben uns in den ersten Monaten durch das schnelle Feedback kurzfristige Richtungskorrekturen erlaubt. Das konsequente vertikale Teilen der User-Stories war eine wichtige Voraussetzung für den Erfolg der kurzen Sprints.
Retrospektiven und “Fail fast” sind wichtig. Wenn gesteckte Ziele nicht erreicht werden, müssen kurzfristig Gegenmassnahmen ergriffen werden.
Bei der Feature-Entwicklung hat sich bei uns Scrum bewährt, während für den Betrieb und die Wartung Kanban besser geeignet scheint.
Der konsequente aber überlegte Einsatz von existierenden Open-Source-Komponenten war für uns effizienter als diese Komponenten selbst zu entwickeln und zu warten.