Einsparungen bei der plattformübergreifenden mobilen Entwicklung: Skyeng-Fallstudie

Hallo, ich bin Andrey Kucherenko, Teamleiter der mobilen Entwicklung von Skyeng. Wir machen mobile Anwendungen für iOS und Android. Sie haben die gleiche Funktionalität und die gleiche Oberfläche, die dem Stil entspricht. Aufgrund unterschiedlicher Plattformen ist die Entwicklung einer scheinbar einzigen Anwendung jedoch recht teuer. Auf der Suche nach Einsparungsmöglichkeiten bei der mobilen plattformübergreifenden Entwicklung haben wir vier Lösungen ausprobiert:

• Kombination von iOS- und Android-Entwicklern in einem Team
• Schaffung von Arbeitsgruppen zur Lösung komplexer Probleme
• Dokumentation sparen
• Gemeinsamen Code schreiben

Ich hatte die Gelegenheit, mehrere Berichte darüber zu machen, was daraus wurde. In diesem Artikel habe ich die wichtigsten Beobachtungen und Ergebnisse gesammelt.

Kombination von iOS- und Android-Entwicklern in einem Team

Vor zwei Jahren hatten wir zwei separate mobile Anwendungen und zwei Entwicklungsteams, die nur durch einen gemeinsamen Produktmanager verbunden waren. Daraus entstand eine Reihe von Problemen: Die Anwendungen ähnelten sich äußerlich nur aus der Ferne, sie arbeiteten in vielerlei Hinsicht, die Entwickler hatten keine Ahnung, wie die benachbarte Anwendung angeordnet war, sie löschten regelmäßig alle möglichen Fehler und Irrtümer in der Logik aus. Ab einem bestimmten Punkt wurde klar, dass es unmöglich war, diesen Weg fortzusetzen, und das erste, was wir in dieser Hinsicht taten, war, die Entwickler von iOS und Android in einem Produktteam zusammenzufassen, wodurch eine Reihe von Prozessen gemeinsam wurden.

Einer dieser Prozesse ist zu einer technischen Überprüfung geworden.

Bevor Sie zum Entwickler gelangen, geht die Aufgabe einen bestimmten Weg. Zunächst wird es im User Story-Format formuliert, Skizzen oder Layouts werden darauf gezeichnet, woraufhin ein Epos gestartet wird, in dem das Benutzerproblem und seine Lösung beschrieben werden. In dieser Form fällt die Geschichte in Teamführung, wenn es sich um ein teamübergreifendes Epos handelt, oder in eine Teamführung, wenn sie sich im selben Team befindet. Dort wird alles auf die Ebene der einzelnen Aufgaben zerlegt. In jeder dieser Aufgaben wird gegebenenfalls eine mögliche Lösung beschrieben, wobei die Aufgaben innerhalb von Epic miteinander verbunden sind und verschiedene Blocker angebracht sind, wodurch viele unnötige Kommunikationen beseitigt werden. Danach findet direkt eine technische Überprüfung statt, über die die endgültige Entscheidung festgelegt und die Schätzung vorgenommen wird. Auch in diesem Stadium kann die Aufgabe weiter zerlegt werden, wenn die Schätzung länger als zwei Tage erhalten wird.

So sparen wir bei der gemeinsamen technischen Überprüfung:

• In den meisten Fällen stellt sich die gleiche technische Lösung für iOS und Android heraus. Es sind auch unterschiedliche Lösungen möglich, dies kann auf die unterschiedliche Architektur der Plattformen zurückzuführen sein, aber im Kontext der Aufgabe ist der Unterschied meistens minimal.
• synchronisiert die Architektur und Struktur der beiden Anwendungen. Dadurch wird die Situation beseitigt, in der das Produkt mit einer anderen Funktion ausgestattet ist. Wir bewerten die iOS-Aufgabe nach zwei Stunden und Android nach zwei Stunden, da dort alles neu geschrieben werden muss.
• Meistens bekommen wir eine gute Note. Wenn unsere Bewertungen für Plattformen sehr unterschiedlich sind, kann dies entweder darauf hinweisen, dass die Entwickler die Aufgabe nicht verstanden haben, oder auf einige Plattformprobleme, die behoben werden müssen.
• Mit dieser Überprüfung findet ein Erfahrungsaustausch zwischen iOS- und Android-Entwicklern statt, und ich glaube, dass sie eine Vorstellung davon haben sollten, wie die benachbarte Plattform funktioniert. Es stellt sich oft heraus, dass eine Lösung von einer Plattform für eine andere erfolgreich ist.
• Vereinfachung der manuellen Prüfung. Funktionen werden auf der Grundlage einer technischen Lösung implementiert. Wenn die Qualitätssicherung Fehler feststellt, ist dies eine Gelegenheit, dieselben Schritte auf einer anderen Plattform zu wiederholen. Meistens gibt es auch dieselben Fehler.
• Universalsoldaten, die für beide Plattformen schreiben können: Wenn dies der Fall ist, können Sie sie zwischen Projekten wechseln, was den Busfaktor erhöht und das Übertragen von Urlaub und Abwesenheit erleichtert. Es gibt keine Situationen, in denen eine Plattform in den Ferien weit voraus läuft.

Busfaktor: Die Anzahl der Personen im Team, die der Bus herunterfahren muss, damit das Projekt nicht fortgesetzt werden kann.

Arbeitsgruppen zur Lösung komplexer Probleme

Um ein Problem zu lösen, müssen wir sehr oft zusätzlich zum direkten Schreiben des Codes einige Nachforschungen anstellen, das Design durchführen und, wenn die Aufgabe die Interaktion zwischen Teams umfasst, viel Zeit für die Kommunikation aufwenden. Im Kontext der mobilen Entwicklung sind alle Aufgaben, die dies alles nicht erfordern, trivial und erfordern keine Arbeit vom Backend aus. Ich nenne sie "einfach" und alles andere "komplex".

Ich analysierte Worklogs hinsichtlich der Verteilung der Zeit, die für das Schreiben, die Kommunikation, das Design und die Recherche von Code aufgewendet wurde. Folgendes passiert bei einfachen Aufgaben:

Hier ist alles klar, im Grunde schreiben wir den Code, die Kosten dafür betragen bis zu 80% der Zeit.

Sehr oft erfordern Aufgaben eine Verfeinerung des Backends, wodurch es automatisch zwischen den Befehlen erfolgt. Hier wird mehr Zeit für Design und Kommunikation aufgewendet. Der Anteil des Codeschreibens wird reduziert:

Oft werden Produkte mit Aufgaben geliefert, die nicht gut zur aktuellen Architektur der Anwendung passen, und wir müssen Zeit aufwenden, um eine gute Lösung zu finden: Planen Sie möglicherweise ein Refactoring, führen Sie es sofort als Teil der Aufgabe aus usw. In diesem Fall wird viel Zeit für das Entwerfen aufgewendet:

Schließlich die Aufgaben, bei denen es im Allgemeinen nicht klar ist, wie man vorgeht, wo man zuerst recherchieren und entwerfen muss:

Wenn die Arbeit an komplexen Aufgaben in keiner Weise koordiniert werden kann, werden alle Arbeiten, die nicht direkt mit dem Schreiben von Code zusammenhängen, zweimal ausgeführt. Bei komplexen Aufgaben sind dies 50% der Lösungszeit, oft sogar mehr.

Ich habe einen Ausweg gefunden: Ich habe all diese Aufgaben einfach selbst übernommen und abgeschlossen. Es gelang mir, Zeit zu sparen, aber ich wurde ständig überlastet, ich hatte nicht genug Zeit, um auf Aufgaben mit niedriger Priorität zu achten, die Entwickler mussten auf mich warten, alles war schlecht. Das Problem trat erneut auf und wir haben es bereits durch die Schaffung von Arbeitsgruppen gelöst.

Die Arbeitsgruppe besteht aus einigen iOS- und Android-Entwicklern, die direkt an der Implementierung dieser Funktion beteiligt sind. Einer wird zum Leiter ernannt, er wird für Design, Forschung und Interaktion mit anderen Teams verantwortlich sein. Das Ergebnis seiner Arbeit wird eine Dokumentation sein, in der alles festgelegt ist; Diese Docks werden dann von der Arbeitsgruppe und dem Teamleiter überprüft, und das Team fährt mit der Implementierung fort.

Als Ergebnis erhielten wir:

• Die Belastung des Timlids hat abgenommen, während er nicht die Kontrolle über den Fortschritt der Aufgabe verliert. Ich nehme an allen wichtigen Besprechungen teil, überprüfe die technische Lösung und kontrolliere die Aufgabe, bevor sie direkt in die Entwicklung geht.
• Die Entwickler waren sehr motiviert. Als wir diese Praxis getestet haben, kamen alle und sagten: "Cool, lass es uns noch einmal versuchen." Es gab keine Leute, die dies nicht wollten und es vorziehen würden, „nur zu codieren“. Die Menschen haben mehr Entwicklungsmöglichkeiten;
• Der Busfaktor nahm zu, das Team wurde unabhängiger und diejenigen, die zu Teamleitern weiterentwickelt werden können, sind bei solchen Aufgaben deutlich sichtbar. Das Problem, Timlida im Urlaub zu lassen, wird gelöst.

Speichern Sie die Dokumentation

Wir haben uns entschlossen, die Dokumentation im Marketdown zu belassen und im Github-Repository zu speichern. Die Dokumentation wird zusammen mit dem Code und der Pull-Anforderung überarbeitet, sodass wir Situationen ausschließen, in denen etwas geschrieben wird, aber niemand es liest und wenn es erforderlich ist, niemand etwas versteht. Die Dokumentation mit einem Code ermöglicht es Ihnen, in den Kontext einzutauchen und zu verstehen, worum es bei Pull-Rikvest ging.

Wir bearbeiten die Dokumentation direkt in der IDE. Die meisten von ihnen können Markdowns rendern. Sie unterbrechen das Schreiben von Code nicht. Sie müssen nicht irgendwo zusammenfließen. Das Risiko wird verringert, dass der Entwickler einfach vergisst, ihn zu aktualisieren. Für diejenigen, die das Repository lokal heruntergeladen haben, werfen wir Links zu Github, sie können auch alles lesen.

Schließlich hilft diese Art des Andockens beim Onboarding eines neuen Entwicklers: Zusammen mit dem Code erhält er alle möglichen Codestile, Konventionen, Anweisungen zum Zusammenstellen von Anwendungen, und die Eingabe in das Team ist viel einfacher.

Gemeinsamer Code

Die Idee, gemeinsamen Code zu schreiben, ist nicht die neueste, es gibt eine Reihe von Tools, um dies zu tun. Wir haben versucht, mit C ++ eine Vokabularbibliothek zu schreiben, und wir haben eine kleine Anwendung, die vollständig in Kotlin Multiplatform geschrieben ist. Theoretisch sollten bei Verwendung eines plattformübergreifenden Entwicklungstools unsere Kosten für das Schreiben von Code halbiert werden. Es erscheinen jedoch weitere:

• Startkosten. Es muss viel Zeit aufgewendet werden, um Hypothesen zu sammeln, zu starten, zu testen, zu testen und ein Team zu schulen. In einigen Fällen sind diese Kosten so hoch, dass der Gewinn überhaupt nicht sichtbar ist.

  
  

• Plattformcode schreiben. Aus eigener Erfahrung und basierend auf einer Reihe von Quellen kann ich sagen, dass Sie, egal für welches Tool Sie sich entscheiden, früher oder später Plattformcode schreiben müssen, wenn Sie eine ziemlich komplizierte Anwendung haben. Die Zeit zum Schreiben hängt stark von den ausgewählten Werkzeugen ab.

  
  

• Beseitigung von Mängeln. Die meisten Tools sind immer noch ziemlich roh, sie haben Fehler, Sie müssen sich mit einigen Releases befassen, die die Abwärtskompatibilität beeinträchtigen, und es wird einige Zeit dauern, bis all dies behoben ist.

  
  

• Umgehung von Beschränkungen. Plattformübergreifende Tools können architektonische oder andere Einschränkungen aufweisen, auf die Sie stoßen können, und Zeit damit verbringen, sie zu umgehen. Manchmal stellen sich solche Einschränkungen als so schwerwiegend heraus, dass man das Werkzeug ganz aufgeben muss. Zum Beispiel gab Airbnb React Native auf und kehrte zur nativen Entwicklung zurück.

  
  

• Die Komplexität der Entwicklung. Sie müssen entweder Code für zwei Plattformen gleichzeitig schreiben, was nicht jeder weiß, und es werden zusätzliche Mitteilungen angezeigt. Das Fehlen nativer IDEs vereinfacht diese Entwicklung ebenfalls nicht.

  
  

Um die Kosten der von uns getesteten plattformübergreifenden Entwicklungsmethoden zu vergleichen, habe ich vier Hauptgruppen identifiziert:

• Startkosten
• Allgemeine Kosten für das Schreiben von Code
• Kosten für das Schreiben von Plattformcode
• Infrastrukturkosten (die nicht für die ersten drei Punkte gelten)

Er mischte und verglich die Zeit, die er tatsächlich für die plattformübergreifende Entwicklung aufgewendet hatte, mit der Zeit, die wir angeblich für die native Entwicklung aufgewendet hätten.

Jede Spalte ist eine Aufgabe. Im Fall von C ++ stellte sich heraus, dass es ein ziemlich einfacher Start war, aber die Infrastrukturkosten erwiesen sich als erheblich, die Gesamteinsparungen - nur 29%. C ++ wurde ebenfalls aufgegeben, weil diese Sprache den Busfaktor senkte: Unsere mobilen Entwickler kennen C ++ nicht, sie können den Code unterstützen, aber niemand im Team hatte ernsthafte Erfahrungen.

Sehr hohe Start-ups, aber die Kosten für Plattformcode und Infrastruktur sind niedrig. Wir hatten nicht genug für eine gute Analyse der Anzahl der Aufgaben, an der aktuellen Position konnten 19% eingespart werden. Unter der Annahme, dass wir viele Aufgaben erledigen und die Startkosten verwerfen, werden wir etwa 40% Einsparungen erzielen, es sei denn, in Zukunft treten natürlich ernsthafte Probleme auf. Ein weiteres Plus ist, dass die meisten Entwickler mit Kotlin vertraut sind.

Das Minus liegt auf der Hand - die Komplexität der Prozesse. Wir schreiben entweder für beide Plattformen gleichzeitig, aber nicht alle können oder warten, bis jemand den allgemeinen Teil schreibt, dann werden wir ihn überarbeiten, dann stellt sich heraus, dass er nicht passt usw. usw. Wir müssen zusätzliche Kosten für die Entwurfsphase aufbringen, damit wahrscheinlich alles sofort abgewickelt wird.

Gesamt:

• Sie können und sollten mobile Entwicklungsprozesse und das Schreiben von Code einsparen. Richtig konstruierte Prozesse helfen nicht nur beim Speichern, sondern lösen auch eine Reihe zusätzlicher Aufgaben.
• Bei der Auswahl von Tools für die plattformübergreifende mobile Entwicklung müssen Sie die Risiken und tatsächlichen Arbeitskosten sorgfältig abwägen.