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.

Warum? Was?

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.

Wie myCloud Desktop von Swisscom agil entwickelt wurde.

Was ist daran herausfordernd?

Aufgabe von myCloud Desktop ist es somit, Dateien auf jeweils allen Computern des Benutzers 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 der Benutzer arbeitet auf potentiell veralteten Daten.
  • Wenn der Benutzer z.B. eine Datei mit Word bearbeitet, 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?

Wir sind 2016 mit der Idee gestartet, dass myCloud Desktop in kurzen Abständen prüft, 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 weiter von einem fertigen Produkt entfernt.

Die Rahmenbedingungen standen jedoch fest, wir benötigen 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 bis März und damit der Releaseplan von myCloud Desktop eingehalten werden konnte.

Wie funktioniert myCloud-Desktop?

myCloud-Desktop setzt konsequent moderne und plattformunabhängige Technologien ein, um auf der gleichen Code-Basis unterschiedliche Betriebssysteme wie Windows und Mac zu unterstützen:

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.