Stämme, Gilden, Zug und kein TDD: Wie funktioniert mobile Entwicklung in Uber, Spotify, Odnoklassniki und Avito?



    Am Vorabend der AppsConf 2018 haben wir Spezialisten aus großen Unternehmen zu den Funktionen und Prozessen großer Teams befragt, die an der Entwicklung mobiler Anwendungen beteiligt sind. Welche Arbeitsansätze werden verwendet, welche Fallgruben erwarten Ruderer, die in die riesige Galeere gelangen. Ob die ausländische Herkunft des Unternehmens den Workflow prägt - lesen Sie alles unter dem Schnitt.



    Philip Uvarov, Android-Entwickler in Spotify. Das Unternehmen arbeitet seit sechs Monaten in einem der Plattformteams, die andere Entwickler in Spotify unterstützen. Er lebt in Schweden. Vor Spotify arbeitete er in einem schwedischen Startup und noch früher in Avito.

    Artem Olkov, führender IOS-Entwickler in Odnoklassniki.  Derzeit führt er die iOS-Entwicklung eines der Produkte an. Neben der eigentlichen Entwicklung ist er für die Architektur, das Design, die Verteilung der Aufgaben, die Abstimmung mit dem Design, die Backend-API usw. verantwortlich. Insgesamt hat Odnoklassniki jetzt etwa 60 mobile Ingenieure, die in kleinere Teams unterteilt sind. Das Team Artem - 11 Personen.

    Maxim Efimov, leitender Softwareingenieur in Uber.In der Firma arbeitet zwei Jahre, ist in der Android-Entwicklung tätig. Eingeschlossen in das Team für "Fahrerzahlungen", das alles rund um Zahlungen in der Uber-Passagieranwendung erledigt. Zuvor entwickelte er für Android in anderen Unternehmen - hauptsächlich auf Bestellung und noch früher - in C ++ (Serverlösungen für SCADA-Systeme). In Uber gibt es innerhalb der Abteilung, die sich mit Zahlungen befasst, mehrere ähnliche Teams für andere Anwendungen sowie Infrastruktur-Teams - insgesamt mehrere Dutzend Teams.

    Evgeny Suvorov, Leiter der Entwicklung mobiler Einheiten bei Avito: Die Entwicklung mobiler Anwendungen gibt es seit acht Jahren. Ich probierte Spiele aus, arbeitete freiberuflich, arbeitete in Outsourcing-Unternehmen, in einem großen Unternehmen und wechselte dann zur Produktentwicklung.



    Beginnen wir mit den Funktionen. Was zeichnet die Arbeit von Teams mit einer großen Anzahl von Entwicklern im Unternehmen aus?

    Artyom Olkov (Odnoklassniki): Meiner Meinung nach hängen die Besonderheiten nicht mit der Größe des Unternehmens zusammen, sondern mit der Anordnung der Prozesse im Unternehmen und der Rolle, die das Team in diesen Prozessen spielt. Grob gesagt: Wenn Ihr Team eine mobile Plattform erstellt, auf der andere Anwendungen oder Dienste des Unternehmens basieren, werden 1000 Anfragen aus verschiedenen Ecken ankommen und ohne einen guten Produktmanager wird die Entwicklung ertrinken. Wenn das Team einen Stand-Alone-Service ohne komplexe Integrationen bereitstellt, wird der Prozess wesentlich einfacher aussehen.

    Maxim Efimov (Uber): Das charakteristischste Merkmal ist meiner Meinung nach die Arbeitsgeschwindigkeit.

    Kleine Teams arbeiten grundsätzlich viel schneller. Zur gleichen Zeit haben große Teams natürlich das endgültige Bruttoprodukt eines Entwicklers, mehr noch, weil eine ganze Gruppe von Leuten dasselbe tut. Und daraus folgt eine andere Ansicht, wie Projekte umgesetzt werden.

    In kleinen Unternehmen passen wir oft bis zu einem Tag oder einer Woche in die Bedingungen. Wir können alles im Voraus berechnen und planen. In großen Teams ist dies schwierig, da alles an eine große Anzahl von Menschen gebunden ist. Daher ist der Planungsansatz etwas anders. Projekte werden mit bestimmten Toleranzen ausgeführt, und der Fokus liegt auf der Qualität und den Features, die wir selbst machen. Und erst danach - die Notwendigkeit, in die Zeitleiste zu passen.

    Ein weiterer interessanter Punkt: Wie stimmen Teams überein? Wenn das Projekt fünf bis zehn Mitarbeiter beschäftigt, können sie leicht in einem Verhandlungsraum zusammengestellt werden und lösen nach zwei bis drei Stunden alle Probleme. Und Sie können das Projekt weiterführen. Wenn jedoch Hunderte von Menschen an dem Projekt beteiligt sind, wird dies nicht funktionieren. Wir in Uber verfügen über bestimmte Kommunikationsmechanismen, die es Teams ermöglichen, sich nicht gegenseitig zu stören, sich effektiv zu vereinen usw. In kleinen Unternehmen ist dies prinzipiell nicht möglich.

    Philip Uvarov (Spotify) : Ich denke, das Hauptmerkmal ist, dass ich nicht alle Android-Entwickler auf Anhieb kenne. Und wir haben sehr viele gemeinsame Verantwortlichkeiten. Auf diese Weise können Sie immer im Zusammenhang mit dem, was Sie tun, und schnell genug sein, um Produkte in ihre Richtung zu liefern.

    Wie synchronisiert sich Ihr Team mit anderen im Unternehmen?

    Yevgeny Suvorov (Avito): Unsere Teams sind durch eine mobile Anwendung verbunden - Avito. Alle tragen zu diesem Produkt bei, das heißt, wir haben einen Synchronisationspunkt in der Codebasis und in der Funktionalität.

    Philip Uvarov (Spotify) : Wir haben funktionsübergreifende Teams, die sich mit bestimmten Themen befassen (z. B. wir entwickeln Analysen für mobile Kunden), sind in einer großen Abteilung vereint - wir nennen es „Stamm“ (Stamm). In der Regel sind Teams innerhalb eines Stammes eng miteinander verbunden, sie haben einen regen Erfahrungsaustausch. Darüber hinaus haben wir natürlich Kunden - dies sind andere Entwickler. Daher unterstützen wir die Lösungen, die wir für sie erstellen.

    Maxim Efimov (Uber): Wir haben kleine Teams mit jeweils höchstens 20 Personen. Sie sind in bauliche Einheiten integriert, die für große Flächen zuständig sind, beispielsweise eine mobile Anwendung. Gleichzeitig sind die Teams selbst ziemlich autonom, denn wenn alles auf ein einziges Managementsystem mit direkter Unterordnung reduziert wird, werden wir ein sehr ineffizientes System erhalten.

    Die gesamte Produktidee wird von Produktmanagern oder Eigentümern an einzelne Teams geliefert. Es gibt eine separate Struktur, die diese Menschen verbindet und hilft, ein Verständnis dafür zu entwickeln, wie und wohin wir gehen. Auf einigen höheren Ebenen können strategische Ziele wie die Sorge um die Sicherheit der Passagiere definiert werden. Nun, die Details werden ein bis zwei Stufen tiefer gelöst. Zum Beispiel haben wir bestimmte Sicherheitsvorkehrungen in Ländern, in denen die Menschen zumeist bar bezahlen.

    Artem Olkov (Odnoklassniki): Wir sind in einem separaten Service tätig. Nehmen wir an, wir sind ein Startup in einer großen Firma. Verständlicherweise leben wir in derselben Infrastruktur. Ansonsten sind wir stark voneinander getrennt. Selbst als Teil der Integration verwenden wir häufig die öffentliche API unserer eigenen Tools.

    Gibt es typische Probleme für große Teams? Was musst du sehen?

    Jewgeni Suworow (Avito) : Meiner Meinung nach leiden die Prozesse in einem großen Team zuerst.

    Alle Jungs sind in der Regel erfahren, auch Junioren können technische Probleme lösen. Probleme mit Prozessen können jedoch schnell alle verlangsamen, sodass Prozesse besser automatisiert werden.

    Und das bedeutet qualitativ hochwertige Continuous Integration, Continuous Delivery, Testautomatisierung.

    Philip Uvarov (Spotify) : Ich denke, das größte Problem ist die Verbreitung von Wissen innerhalb des Unternehmens. Ich habe möglicherweise keine Vorstellung davon, was in einigen entfernten Teams passiert. Das Gleiche gilt für die entgegengesetzte Richtung: Viele Teams haben keine Ahnung, dass wir ein Analyseteam in Spotify haben. Hier spürt man die Skala.

    Der zweite Punkt ist die Geschwindigkeit, mit der innovative Entscheidungen getroffen werden können: die Anpassung desselben Kotlin und anderer neuer Technologien. Es ist eine Sache, zu kommen und den fünf Entwicklern zu sagen: „Von jetzt an schreiben wir über Kotlin“, aber es ist eine andere Sache, dies zu 100 Entwicklern zu sagen. Es gibt eine riesige Infrastruktur, die übersetzt werden muss, um diese Innovationen (CI usw.) irgendwie zu unterstützen.

    Artem Olkov (Odnoklassniki): Ja, es gibt wirklich zwei Probleme: den Wissenstransfer und die Koordinierung von Aktionen, einschließlich der Modernisierung.

    Haben große Unternehmen nachgewiesene Wege, um diese Probleme zu lösen?

    Philip Uvarov (Spotify): Um das erste Problem - das Teilen von Wissen - zu lösen, haben wir so etwas wie Gilden. Dies ist eine Kombination von Entwicklern nach Funktion, z. B. der Android-Gilde, die alle zwei Wochen einige Veranstaltungen enthält: Präsentationen, Mittagessen, bei denen Sie dringende Probleme besprechen oder etwas teilen können usw. Wir haben auch wieder Gilden sind interne Konferenzen. Plus gibt es Mailings usw. Es bleibt ein einfaches menschliches Problem: Es ist schwierig, mit all dem Schritt zu halten.

    In einer separaten Zeile möchte ich das interne Training (Fortbildung) hervorheben. Wir haben eine eigene Datenuniversität, an der Sie einen Data Engineer lernen können. Jetzt überlegen die Kollegen, dasselbe Schema für das mobile Lernen zu schaffen.

    Artem Olkov (Klassenkameraden): Wir haben keine Gilden ausgesprochen.

    Wie auch immer, die Jungs, die durch eine Aufgabe vereint sind, treffen sich bei verschiedenen Meetings - sie kennen sich, kommunizieren in einem Raucherzimmer oder beim Mittagessen. Es gibt separate Chatki, zum Beispiel rein für iOS-Nicks. Im Team wird das Problem natürlich einfacher gelöst - wir sitzen alle hinter dem gleichen Gänseblümchen.

    Wenn Sie Fragen haben, heben Sie die Hand, winken Sie der gewünschten zu - und er wird Ihnen antworten. Für den Wissenstransfer nutzen wir 15-minütige Morgenrallyes, bei denen jeder sagt, wie, was, warum und warum er es getan hat. Es gibt auch eine bestimmte Dokumentationsebene, in der die wichtigsten Punkte dargestellt werden.

    Das zweite Problem - die Koordinierung der Maßnahmen - wird durch ein kompetentes Management gelöst.

    Maxim Efimov (Uber): Tatsächlich sehe ich kein Problem im gleichen Wissensaustausch. Ich sehe, dass der Mechanismus des Teilens anders ist. In kleinen Teams geschieht dies einfach auf irgendeine Weise. Gesammelt - geredet. Und wir haben praktische Prozesse, die es uns ermöglichen, alles so zu organisieren, dass es funktioniert. Übrigens werde ich in meiner Rede darüber sprechenauf der AppsConf 2018. Die Idee ist, dass in unserem Unternehmen fast alle Entwicklungen ziemlich transparent sind. Mitarbeiter eines beliebigen Teams können sich ansehen, was andere Entwickler tun, und einige davon für sich nutzen.

    Evgeny Suvorov (Avito): Wir organisieren auch zweimal pro Woche Meetings. Wir lieben die Automatisierung, und diese Aufgabe ist auch automatisiert. Es gibt einen Prozess, wenn die Leute während der Woche Themen behandeln, über die sie auf einer Hauptversammlung von iOS- oder Android-Entwicklern sprechen möchten. Und wenn es eine Vorladung gibt, gehen wir. Während der Besprechungen berichten die Food-Teams über die Funktionen, die sie in das Produkt implementiert haben, da es sonst schwierig ist, den Überblick zu behalten.

    Wir haben uns von Anfang an getroffen, aber mit dem Wachstum des Unternehmens wurden diese Meetings am wichtigsten.

    Außerdem gibt es Chatrooms, in denen Sie spezifische Probleme besprechen können.

    Nach welchem ​​Prinzip ist es sinnvoll, viele Entwickler in einem Unternehmen aufzuteilen - nach Plattform, nach Funktionalität oder auf andere Weise?

    Artem Olkov (Klassenkameraden): Es hängt immer noch davon ab, was Sie tun und wie Sie Geld verdienen.

    Theoretisch kann ich mir die Struktur eines Outsourcing-Unternehmens vorstellen, in dem die Abteilung beispielsweise nach Plattform arbeiten wird. Aber für ein Lebensmittelunternehmen kann ich mir kaum eine andere Form der Division vorstellen, außer durch funktionelle Teams.

    Wenn Sie alle iOS-Spitznamen zusammenfassen und Aufgaben verwenden, ohne eine sehr kurze Brücke zwischen Design, Backend oder Testen zu haben, müssen Sie zu viel Zeit für die Koordination aufwenden.

    Philip Uvarov (Spotify) : Wir sind alle nach Produkten aufgeteilt. Unser Team beschäftigt sich beispielsweise mit Analysen und umfasst sowohl iOS, Backend-Entwickler und viele andere. Meiner Meinung nach ist dies eine sehr vernünftige Aufteilung der Teams, was auch zu gewissen Problemen führt, aber in einem solchen Umfang gut funktioniert.

    Maxim Efimov (Uber):Es scheint mir, dass die Idee, Teams auf Plattformen zu verteilen - iOS, Android, Backend - in großem Umfang, nicht sehr gut funktionieren wird. Es trennt die Entwickler ziemlich stark voneinander, und die Synchronisation von beispielsweise zwei mobilen Anwendungen für verschiedene Plattformen kostet daher viel mehr. Und der Vorteil davon, dass die Leute in einem Team nur Leute von ihrer Plattform aus sehen, scheint mir nicht so sehr. Ja, das Teilen von Wissen ist einfacher, aber ist es das wert? Es scheint mir nein.

    Die Idee, dass einige Befehle grundlegende Dinge ausführen, die von allen anderen verwendet werden, wie Schaltflächen, Listen und Texteingabefelder, erscheint mir interessant.

    Evgeny Suvorov (Avito): Ich stimme zu : Eine solche Struktur ist ziemlich erfolgreich und wir haben sie kürzlich in unserem Avito eingeführt, zumindest im Lebensmittelgeschäft.

    Unser Team wurde wahrscheinlich zu einem großen Team, als wir fünf Entwickler hatten, da die Selbstorganisation bei dieser Anzahl schwierig war. Es wurde schwieriger für die Jungs, ein Feature zu schneiden, sie mussten sie irgendwie trennen und in verschiedenen Ecken nach verschiedenen Features anordnen. Unstimmigkeiten begannen bei architektonischen und anderen Fragen, und die Kommunikation wurde komplizierter.

    Zu einem Zeitpunkt hatte Avito zwei große Teams - iOS und Android-Entwicklung, jeweils 15 Personen. Zu diesem Zeitpunkt begannen wir, uns in Lebensmittelgeschäftsteams aufzuteilen: "Kundenerlebnis", "Verkäufererlebnis", Messenger, Zustellung usw. wurden unterschieden. Damit wurde das Problem der Prioritäten gelöst. Zuvor waren viele Projektmanager mit Anfragen nach Funktionen zu den Teams gekommen, und für diese hatte jede dieser Funktionen Priorität Nummer eins. Als Ergebnis haben wir 20 Projekte, deren Querschnittsprioritäten nicht klar sind. Höhere Leute mussten es manuell handhaben. Nach der Zuteilung von multifunktionalen Teams, von denen jedes über eine eigene Entwicklungspipeline, eigene Prioritäten und Ressourcen verfügt, ist alles einfacher geworden.

    Gleichzeitig gibt es immer noch kleine Plattformteams, die, wie wir es nennen, „horizontale“ Lösungen schaffen, die sich auf alle Produktteams auswirken.

    Wie oft reorganisieren Teams?

    Philip Uvarov (Spotify) : Jede Woche treten einige Bewegungen auf. In unserem Unternehmen sind die Teams klein und autonom. Wenn Sie möchten, können Sie sehr leicht von einem zum anderen wechseln. Wie oft dies geschieht, hängt vom Team und der Richtung ab, in der Sie arbeiten. Wo ich arbeite, wird es nicht ausgesprochen. Spotify ist jedoch dafür bekannt, dass wir agil arbeiten und in vielerlei Hinsicht Dinge wie OKR usw. von uns stammen. Daher hat das Management des Unternehmens keine Angst, Prioritäten zu ändern, wenn es plötzlich merkt, dass etwas nicht funktioniert. Wir wechseln einfach zu etwas anderem.

    Maxim Efimov (Uber):Wir hatten umfangreiche Reformen, die sich vor allem auf das sehr schnelle Wachstum des Amsterdamer Büros bezogen. Im Laufe des Jahres hat sich die Anzahl der Mitarbeiter fast verdoppelt. Diese Teams, in denen Mitarbeiter rekrutiert wurden, wurden sehr groß und es war schwierig für einen Manager, eine solche Struktur zu verwalten. In dieser Hinsicht wurden die Teams einfach in mehrere "Unterbefehle" aufgeteilt, von denen jedes in einer engeren Sphäre tätig war. Ich denke, das ist ein natürlicher Prozess.

    Stimmen Sie der Idee zu, dass es in einem großen Team, um die Qualität des Codes nicht zu beeinträchtigen, es nicht lohnt, überqualifizierte Junioren und Senioren einzustellen?

    Philip Uvarov (Spotify): Ich denke weder das eine noch das andere. Jedes Jahr stellt Spotify im Sommer eine Reihe von Hochschulabsolventen ein (einige von ihnen erhalten eine Einladung zur Arbeit). Gleichermaßen nehmen wir leicht Leute mit mehreren Doktortitel an.

    Technische Qualifikation ist cool, aber es kann gelehrt werden. Wenn eine Person nicht weiß, wie man in einem Team arbeitet, wird es extrem schwierig. In solchen Unternehmen wird daher fast mehr auf Software-Kenntnisse geachtet.

    Und damit die Qualität nicht darunter leidet, brauchen wir gute Interviews, um Entwickler auswählen zu können, die nicht unter einem bestimmten Grundniveau liegen.

    Maxim Efimov (Uber): Wir werden durch ein etwas anderes Prinzip abgestoßen. Wir haben die wünschenswerte Mischung aus erfahrenen Entwicklern und Junioren. Nur damit es keine Situation gibt, wenn es im Juni eine Menschenmenge gibt, und es gibt niemanden, der ihnen helfen und erklären kann, wie man arbeitet. Deshalb versuchen wir, das Gleichgewicht zu halten.

    Ich sehe keinen Sinn darin, an dem Grundsatz festzuhalten, "nicht zu viele Senioren zu gewinnen". Die Suche nach dem Seigneur ist eine ziemlich schwierige Suche. Es gibt viele Unternehmen auf dem Markt und der Wettbewerb um Entwickler ist ernst. Menschen mit Erfahrung arbeiten erfolgreich an fast allen Orten. Daher ist es unrealistisch, heute qualifiziertes Personal abzulehnen und es morgen zu rekrutieren. Diese Leute werden nicht sitzen und warten, bis wir sie einladen wollen. Und wenn in meiner Praxis eine Person über gute Kompetenzen verfügt, ist es kein Problem, einen Platz im Unternehmen zu finden. Aber wir müssen auf der spezifischen Situation aufbauen. Wir müssen eine Entscheidung treffen, je nachdem, welche Ambitionen jede Person im Team hat, ob die anstehenden Projekte betrachtet werden und ob wir sie selbst herausholen können, wen wir brauchen. Das heißt, es ist notwendig, auf die Low-Level-Planung einzugehen.

    Jewgeni Suworow (Avito): Meiner Meinung nach sollten Sie bei der Anwerbung von Senioren keine Angst haben, dass sie ihren eigenen König im Kopf haben oder nicht gehorchen.
    In unserem Unternehmen bieten die Entwickler selbst Möglichkeiten an, diese oder andere Probleme zu lösen. Und Senioren haben oft diese Qualitätslösungen. Sie haben Erfahrung, daher können mit ihrer Teilnahme Probleme schneller gelöst werden. Es gibt noch ein anderes Problem - Ihre Aufgaben erscheinen den Senioren nicht interessant oder ehrgeizig.

    Auch für Junioren muss individuell angesprochen werden. Als wir noch ein Team waren, kam es regelmäßig vor, dass das Team ein weiteres Jun herausholen konnte. Und in diesem Moment war es möglich, einen schönen ehrgeizigen Mann mitzunehmen, der schnell zu einem Qualitätsingenieur wurde. In einem Team mit etablierten Prozessen ist das Lernen sehr schnell. Ja, und Juni ist anders - einige kommen nach der Highschool mit leuchtenden Augen, aber sie wissen nicht wie, während andere sieben Jahre Erfahrung im Backend haben, haben sie gerade zu mobilen Apps gewechselt.

    Das heißt, wir haben keine Angst vor Junioren, aber wir werden von den Gefühlen des Teams geleitet - ob es es braucht oder nicht.

    Planung, Synchronisation, Aufgabenverteilung


    Wie viel Aufwand erfordert das Planen und Synchronisieren von Entwicklern in einem großen Unternehmen (auch in kleinen Teams)?

    Philip Uvarov (Spotify) : Dies ist nur ein Plus der Aufteilung der Teams nach Produkt und nicht nach Funktion: Wir planen nur unser kleines Produkt innerhalb des Unternehmens und wir kümmern uns oft nicht darum, was die restlichen Millionen Entwickler dort tun.

    Artem Olkov (Odnoklassniki): Hier kann ich Ihnen nur über unser spezifisches Team berichten. Wir haben den Anfang der Entwicklung und es gibt gewisse Zugeständnisse - erlaubt Ihnen, freier zu sein. Momentan haben wir nur tägliche 15-minütige Rallyes mit dem aktuellen Status und stündlichem Schließen des vorherigen / planen den nächsten Sprint einmal pro Woche. Alles andere wird auf persönliche Weise entschieden.

    Maxim Efimov (Uber):In unserem Fall nicht sehr groß. Vielleicht in Zeiten von 1,5 - 2 mehr, als ich bei einem Outsourcing gearbeitet habe.

    Es gibt zwar einige Prozesse im Unternehmen, beispielsweise die Überprüfung von Code, die die Entwicklung behindern. Grob gesagt, bis ein Team, das für seinen Code verantwortlich ist, Ihr Commit betrachtet, kann es nur einige Zeit dauern. Ich glaube jedoch nicht, dass sich dies auf eine Synchronisierungsgebühr bezieht. Vielmehr geht es darum, wie das gesamte System auf einer niedrigen Ebene eingerichtet wird - wer überprüft wen, wie ist das Warten organisiert usw.

    Evgeny Suvorov (Avito): Wir haben das Synchronisationsproblem zunächst mit häufigen Releases gelöst. Daher dauert die Synchronisation selbst jetzt etwas. Alles ist fast automatisiert.

    Muss ich Aufgaben auf besondere Weise verteilen, damit die Qualität des Codes nicht beeinträchtigt wird?

    Philip Uvarov (Spotify) : In großen Teams ist es sinnvoll, das Produkt nach Verantwortungsbereichen zu verteilen. So gibt es bei Aufgaben immer Menschen, die sich verantwortungsbewusst an sie wenden, weil sie später auch damit leben. Sie ändern den Kontext nicht, d. H. Es gibt keine Situation, in der alle Entwickler an absolut allem beteiligt sind (Peter schrieb hier 10 Zeilen, Vasily fügte 5 weitere hinzu und als Folge gibt es ein Durcheinander, das später nicht mehr verwaltet werden kann).

    Wenn Sie außerdem in einem kleinen „Produkt innerhalb eines Produkts“ arbeiten, sollten Sie mehr oder weniger verstehen, wie das gesamte System vom Backend bis zum Client funktioniert.

    Evgeny Suvorov (Avito): In Bezug auf Qualität ist es besser, sich auf Tests und Codeüberprüfung zu verlassen. In meinem Team sägen beispielsweise die Jungs mit dem mobilen Entwicklungshintergrund Mikrodienste im Backend in drei Sprachen - Python, PHP, Go -, die der Last von Avito standhalten müssen. Aber Kommunikation, Testautomatisierung usw. sorgen am eingang des juniors und am ausgang - hochwertiges stück.

    Können Sie sich an eine oder zwei der interessantesten Aufgaben erinnern, mit denen Ihr Team in letzter Zeit konfrontiert war?

    Artem Olkov (Klassenkameraden):Wie gesagt, wir machen ein neues Produkt. Die interessanteste Aufgabe für mich persönlich, wie für die Person, die ihn leitet, ist seine Planung und Gestaltung: Architektur aufbauen, überlegen, was der Benutzer hat und was nicht und wie die Entwickler damit leben.

    Evgeny Suvorov (Avito): Das Interessanteste an mobilen Anwendungen war die Modularisierung - unsere Codebasis wurde in separate Module aufgeteilt, die sich unabhängig voneinander entwickeln können, ohne sich gegenseitig zu stören.

    So sind beispielsweise das Anzeigen von Anzeigen und der Auslieferungsbildschirm im Prinzip miteinander verknüpft. In der Codebasis wurden sie jedoch nicht getrennt, und als die Entwickler etwas unternahmen, wurden ihre Kollegen blockiert. Mein Team war gerade um diese Abteilungsaufgabe versammelt. Es dauerte etwa sechs Monate und war zunächst technisch interessant.

    Am Backend haben Microservices vor langer Zeit ihren Ursprung gefunden, und bei mobilen Anwendungen hat sich dieser Trend vor kurzem herausgebildet - vielleicht vor ein oder zwei Jahren. Und in großen ausländischen Teams gibt es in Russland so wenige.

    Technologiestapel


    Haben Sie in der letzten Zeit in Ihrem Unternehmen / Team revolutionäre Veränderungen im technologischen Bereich festgestellt? Und wie laufen solche Prozesse ab?

    Philip Uvarov (Spotify) : Wir üben das selten. Es gibt Versuche zur Einführung neuer Technologien, insbesondere mit dem Umzug von Gradle nach Bazel oder mit Teamcity in unser internes System, aber nicht mehr. Ich denke, dass solche Revolutionen bei uns unmöglich sind.

    Maxim Efimov (Uber):Vor Uber hatte ich diese Erfahrung, aber hier ist es ein kontinuierlicher Prozess. Es gibt ein paar Leute, darunter auch mich, die Kotlin bevorzugen. Es gibt bestimmte Dinge, die wir herausfinden müssen, wie man arbeitet. Aber insgesamt ist dies möglich. Wir arbeiten gerade daran. Wir müssen nicht warten und warten, bis der "wichtigste Entwickler" sagt: "Jetzt schreiben Sie auf Kotlin." Kotlin wird bereits in einem Teil unserer Codebasis verwendet, ist aber noch in Bearbeitung.

    Insgesamt finden globale Veränderungen in der Architektur statt, die auch von unserem Team stammen. Die Initiative von Menschen, die persönliche Schmerzen lösen wollen, haben wir durchaus akzeptiert. Wenn alles richtig gemacht wird, werden diese Änderungen akzeptiert.

    Evgeny Suvorov (Avito):Wir haben zwei Plattformbefehle, die Werkzeuge für den internen Gebrauch sägen. Das Unternehmenswachstum und die Modularisierung haben die Arbeitsweise dieser Teams verändert. Sie mussten viel kommunizieren, um zu verstehen, was die Endverbraucher (Entwickler) brauchen.

    In Bezug auf den technologischen Wandel haben wir Technologieradar. Entwickler sagen oft: „Lass uns dieses Ding vorstellen, anstatt das, was wir seit 5 Jahren machen, weil es ist moralisch veraltet. " Um mit diesen Vorschlägen umzugehen, haben wir Technology Radar ins Leben gerufen, bei dem derjenige, der die Initiative hat, in eine kleine Bürokratie aufsteigen, Nachforschungen anstellen und in digitalen Metriken zum Ausdruck bringen muss, dass Innovation uns beschleunigen wird, aber etwas bremst. Es bestehen Risiken hinsichtlich der neuen Technologie. Dies wird von mehreren Kollegen überprüft, und wenn alles in Ordnung ist, wird die Technologie angewendet. Richtig, mit Technologie-Radar-Angeboten werden weniger.

    Ist es schwieriger, solche Reformen mit dem Wachstum des Unternehmens durchzuführen?

    Maxim Efimov (Uber):Schwieriger, aber nicht viel. Angenommen, es gibt 10 Personen in einer kleinen Firma, und jemand allein möchte etwas ändern. Dafür muss er mit neun Leuten verhandeln. Wenn Sie 100 Entwickler haben, bedeutet dies nicht, dass Sie mit 99 eine Vereinbarung treffen müssen. Natürlich ist nicht jeder aktiv dabei, es ist nicht so schwierig, wie es sein könnte.

    Welche der neuesten Technologien finden Sie persönlich am interessantesten für die Anwendung in großen Teams (auch wenn sie in Ihrem Unternehmen nicht funktionieren)?

    Evgeny Suvorov (Avito): Die wichtigsten sind wahrscheinlich Mikrodienste , die Aufteilung nach Domänenbereichen und die Unterteilung in Teams mit eigenen Prioritäten. Technisch gesehen - überall.

    Für große Teams müssen Sie ein wenig zurückgehen und nicht in die Alpha-Beta-Versionen der Tools einsteigen, da Sie nie wissen, wozu dies führt.

    Es gibt zwar Ausnahmen. Durch die Modulpartitionierung hat das Android-Projekt gelitten - die IDE hat das Projektmodell sehr lange gedauert und nur die neuen, früher angenommenen Preview-Versionen haben geholfen. Es gab experimentelle Zecken, mit denen alles steiler wurde, um zu arbeiten.

    Philip Uvarov (Spotify) : Ich denke, Kotlin ist eines der vielversprechendsten Dinge. Es scheint mir, dass bald jeder Java über Android vergessen wird, insbesondere wenn Kotlin mit Builds ein wenig besser wird und wir es schaffen können. Soweit ich weiß, haben viele große Teams - wie Facebook - Kotlin seit langem abgelehnt, nur weil es große Projekte gibt, die seit drei Jahren ohne diese Probleme laufen, und Kotlin wird sechs Jahre zusammen haben.

    Von dem letzten scheint mir persönlich ziemlich interessantes Flattern.

    Artem Olkov (Klassenkameraden):Ich glaube, dass der beste Technologie-Stack im Rahmen der iOS-Entwicklung nativ ist, den Apple bietet. Zusätzliche Frameworks werden oft nicht benötigt. Es gibt interessante Tools, die jedoch von sehr großen Teams nur für ihre eigenen Bedürfnisse erstellt werden. Außerhalb dieser Teams fügen sie oft nur mehr Schmerzen hinzu.

    Es gibt einige sehr interessante Ansätze, die sich derzeit im Trend befinden, und einige von ihnen sind dies zu Recht. Ich möchte speziell den unidirektionalen Datenfluss erwähnen.

    Was denkst du über den schrittweisen Übergang zu Swift?

    Artem Olkov (Klassenkameraden): Dies ist ein komplexes Thema. Jetzt haben wir ein neues Projekt gestartet und sind alle auf Swift, aber es gibt 150 Zeilen auf Objective-C, weil Aus irgendeinem Grund konnten wir mit Hilfe von Swift das, was wir brauchten, nicht recht lakonisch tun.

    Wenn Sie alles in Objective-C haben und es Ihnen vollkommen entspricht, ist es dann sinnvoll, zu Swift zu wechseln? Für viele Leute, die ich kenne, ist die Übertragung der Codebasis an Swift genau die HR-PR-Geschichte, denn es gibt viele neue Entwickler auf dem Markt, die Objective-C einfach nicht kennen und nicht lernen wollen.

    Evgeny Suvorov (Avito): Dies ist unser Fall. Wir sind auf einmal in Swift eingestiegen und er hat unsere Bauzeit verlangsamt. Im Allgemeinen gab es viele Nachteile, aber für uns war einer der wichtigsten Punkte, dass es sich um einen solchen Hype handelt, für den wir viele Entwickler einstellen können. Im Allgemeinen rechtfertigte es sich zu einem gewissen Grad. Swift entwickelt sich jetzt, aber in Objective-C wäre es wahrscheinlich schneller, bequemer und weniger problematisch.

    Die Idee einer langfristigen Unterstützung könnte ein Grund für den Übergang sein (sollte es in Zukunft mehr Entwickler geben)?

    Artem Olkov (Klassenkameraden): Diese Frage ist nicht so leicht zu beantworten. Apple ist immer noch in einer Position, in der sie sagen können, dass Swift nicht mehr unterstützt wird, und es der Entwicklung von Open Source widmet. Die Wahrscheinlichkeit einer solchen Entwicklung von Ereignissen ist heute sehr gering, aber nicht Null. Objective-C wird immer noch verbessert.

    Persönlich meine Meinung (sie stimmen mit Odnoklassniki möglicherweise nicht überein) - wenn Sie nur sachliche Fakten annehmen - in fünf bis sieben Jahren werden beide Sprachen leben, und Entwickler müssen nur mit und mit diesem arbeiten können. Es ist nicht schwierig, wenn Sie die Grundbegriffe verstehen. Eines zu kennen, das andere zu lernen, ist kein so großes Problem. Bei der iOS-Entwicklung geht es heute nicht mehr um Sprachkenntnisse, sondern um die Kenntnis des Rahmens, an dem Sie arbeiten.

    Entwicklung und Test


    Wann schreibst du Tests? TDD oder nach dem Schreiben des Codes?

    Philip Uvarov (Spotify) : Um ehrlich zu sein, angesichts der Einführung von Builds für Android glaube ich nicht, dass Sie Tests effektiv vor dem Code schreiben können. Wir schreiben normalerweise Tests parallel zur Entwicklung.

    Artem Olkov (Klassenkameraden): Es hängt alles davon ab, über welche Tests wir sprechen. Unit-Tests auf dem Gewissen des Entwicklerteams.

    In unserem Team decken wir insbesondere Unit-Tests nur mit bestimmten Layern ab, bei denen wir sicher sein müssen (auf anderen Layern sehen wir Probleme sofort). Wenn es sich um Integrationstests (API, UI usw.) handelt, sind die Tester für sie verantwortlich, sobald sie verfügbar sind.

    Maxim Efimov (Uber): Ich weiß, ein Teil unseres Backends liebt TDD, aber ich kenne solche Leute nicht unter mobilen Entwicklern. Es ist uns wichtig, was am Ende passiert ist, und die Reihenfolge, in der die Person es geschrieben hat, ist sein eigenes Geschäft.

    Evgeny Suvorov (Avito): Ein Tester ist während des gesamten Lebenszyklus eines Features präsent. Ganz am Anfang hilft es bei der Formulierung des Problems, ermittelt die funktionalen Anforderungen und beschreibt die Abnahmetestfälle. UI- und Unit-Tests werden vom Entwickler selbst geschrieben. Im Prinzip kann der Tester sie auch schreiben - wir haben ein eigenes Team, das sich mit einem Tool zum Schreiben von UI-Tests befasst.

    Die Tests selbst können zu jeder Zeit unabhängig geschrieben werden. Worauf - kleine Teams entscheiden selbst. Sie können TDD verwenden oder nicht.

    Im Allgemeinen ist die TDD-Praxis nicht sehr beliebt. Wir in der Android-Community haben eine Person, die es wirklich praktiziert und versucht, Gleichgesinnte zu finden. Er spricht auf der AppsConf 2018 mit einem Vortrag über TDD.

    Meist werden jedoch Tests geschrieben, nachdem das Feature geschrieben wurde.

    Haben Sie Deckungsstandards?

    Philip Uvarov (Spotify) : Sie können je nach Aufgabe unterschiedlich sein. Eine 100% ige Abdeckung der Geschäftslogik mit Komponententests ist jedoch obligatorisch.

    Maxim Efimov (Uber): Wir haben ein allgemeines Verständnis davon, was wir testen. Aber niemand sagt irgendwo, wie viel Prozent der Deckung sein sollen. Teams definieren es selbst.

    Gibt es aus Ihrer Sicht ein "goldenes" Verhältnis von Test und Entwicklung im Projekt?

    Philip Uvarov (Spotify) : Ich kann die ideale Proportion nicht nennen - es hängt alles von der Aufgabe ab.

    Wenn wir zum Beispiel einen Prototyp von etwas herstellen (Beweis eines Konzepts einer Idee), tendiert das Testen hier wahrscheinlich zu Null. Wenn wir ein Produkt herstellen, das vom gesamten Unternehmen mit hoher Last verwendet wird, sollte die gleiche Zeit für Tests wie für die Entwicklung verwendet werden.

    Evgeny Suvorov (Avito): Wir haben zwei QA-Ingenieure, die nicht nur den mobilen Teil, sondern auch das Backend, das Frontend und alles andere für das größte Team mit vier mobilen Entwicklern testen. Das ideale Verhältnis hängt jedoch von den Details der Organisation des Prozesses ab. Zum Beispiel gibt es sechs Ingenieure in meinem Plattformteam, aber im Prinzip gibt es keine Qualitätssicherung.

    Haben Sie Codequalitätskontrollverfahren innerhalb der Entwicklergemeinschaft?

    Philip Uvarov (Spotify) : Ja, Code-Überprüfung ist eine der grundlegenden Prüfungen. Darüber hinaus haben wir eine Vielzahl von Überprüfungen von CI durchgeführt: Wir verfügen über mehrere Tools, die mit der statischen Codeanalyse verbunden sind, die den Codestil und alles überprüfen, und ich werde in meinem Bericht über AppsConf 2018 teilweise darüber sprechen .

    Artem Olkov: In Odnoklassniki gibt es eine Pull-Anforderung. Es gibt eine Kontrolle über den von Formatierern bereitgestellten Code-Stil. Es gibt Linters, die einfache Fehler offenbaren. Es gibt Builds mit Tests, Regeln für die Aufrechterhaltung von Git. Alle sind sehr kleine Schritte auf dem Weg zu einem großen Ziel: die Codebase gut zu machen.

    Maxim Efimov (Uber): Code-Überprüfung ist etwas, das nicht vermieden werden kann. Sie können ein Commit nicht ausfüllen, wenn niemand nachgesehen hat. Aber die Prozessteams stellen sich selbst auf.

    Evgeny Suvorov (Avito): Wir bieten auch Codeüberprüfungsprozesse über Pull-Requests an. Wenn ein Entwickler ein neues Feature implementiert, das Code beisteuert, erstellt er eine Pull-Anforderung, die eine Reihe automatischer Prüfungen durchführt, einschließlich Qualitätsprüfungen. Dann wird der Code von den Nachbarn-Entwicklern betrachtet.

    Wir haben diesen Prozess gestartet, sobald der zweite Entwickler im Team erschien. Mit der Entwicklung des Unternehmens änderte sich der Prozess. Zuerst war es manuell, dann erschien die Automatisierung. Wenig später haben wir die Anzahl der Einheiten von eins auf vier erhöht, ansonsten waren die Leute nicht bereit, Entscheidungen zu treffen, die sich auf die wachsende Codebasis auswirken ("Was ist, wenn ich mich falsch einschätze?"). Bei der Aufteilung in multifunktionale Teams, wenn sich die Menschen auf verschiedene Einheiten verteilten, haben wir die Anzahl der Einheiten auf zwei reduziert.

    In der Tat ist es ein regulierter Prozess. Wenn das Unternehmen wächst, entwickelt sich die Codebasis weiter und wiederholt die Struktur des Unternehmens. Das Team brach in Einheiten auf, und wir begannen, die Codebasis zu modularisieren, so dass sich die einzelnen Einheiten nicht gegenseitig stören und relativ unabhängig voneinander entwickelt werden können. Das war eine lange Geschichte. Dies spiegelte sich natürlich in Pool-Anfragen und Code-Prüfungen wider. Parallel dazu versuchen wir das Mögliche zu automatisieren.

    Wie oft ist es sinnvoll, Releases in einem großen Unternehmensprojekt zu veröffentlichen?

    Philip Uvarov (Spotify) : Je öfter, desto besser.

    Artem Olkov (Klassenkameraden):Es hängt auch sehr stark vom Unternehmen, den Benutzern und dem Vertriebsmodell ab. Vor Odnoklassniki arbeitete ich zum Beispiel bei Akronis. Dort ist die mobile Anwendung eine Komponente eines großen Desktop-Produkts, und ihre Versionen waren an Desktop-Releases gebunden. Das große Produkt hatte zwei große Veröffentlichungen pro Jahr - Sommer und Winter - das ist historisch. Daher wurde die mobile Anwendung im Sommer und Winter veröffentlicht. Dazwischen gab es nur Hotfixes und einige schnelle Korrekturen.

    In Odnoklassniki hängt es auch vom Team ab. Zum Beispiel werden Android-Entwickler jede Woche hart veröffentlicht.

    Maxim Efimov (Uber): Mir scheint, dass die Art und Weise, wie sie hier organisiert wird, ziemlich vernünftig und bequem ist. Wir haben regelmäßig Veröffentlichungen.

    Es gibt einen sogenannten Bauzug, der jeden Montag abfährt. Wenn etwas nicht drin ist - Warten auf die nächste Veröffentlichung. Denn sonst ist die Synchronisation sehr teuer.

    Im Allgemeinen ist dies eine Frage des Geschäftsbereichs. Wir hatten zwei Situationen, in denen wir uns nicht für wöchentliche Veröffentlichungen entschieden haben: Dann haben wir unsere Anwendung für Passagiere und Fahrer komplett neu geschrieben. Aber im gewöhnlichen Leben der großen Veränderungen ist es nicht günstiger, regelmäßige Veröffentlichungen.

    Evgeny Suvorov (Avito): Anfangs hatten wir einmal im Monat eine Veröffentlichung - dies sind nur 12 Veröffentlichungen pro Jahr. Wenn Sie keine Zeit haben, eine Funktion in einer bestimmten Version zu erstellen, warten Sie einen weiteren Monat. Infolgedessen versuchten die Leute, die Veröffentlichung zu verzögern, andere Teams wurden gehemmt und die Qualität litt (einige Funktionen wurden jedenfalls in Eile erledigt).

    So kamen wir auch zu den beliebten Release-Zügen, die auf niemanden warten. Wir haben die Häufigkeit der Veröffentlichungen erhöht. Der erste Punkt wurde alle drei Wochen veröffentlicht. Der zweite Punkt ist alle zwei Wochen. Wir sind jetzt an diesem Punkt und bemühen uns, die Veröffentlichung einmal pro Woche technisch zu ermöglichen. Nicht die Tatsache, dass wir diese Gelegenheit nutzen werden - es besteht die Möglichkeit, dass Benutzer Aktualisierungen unserer Anwendung nicht so oft sehen möchten. Und es ist keine Tatsache, dass die Entwickler in einer Woche Zeit haben, einige vollwertige Funktionen zu implementieren. Deshalb sehen uns zwei Wochen optimal aus.

    Ich kann jedoch nicht jedem Entwickler einen zweiwöchigen oder wöchentlichen Zyklus empfehlen. Wie ein Kollege erwähnte, gibt es Produkte, deren Freigabezyklus in Monaten gemessen wird, was auf sehr gründliche Funktionsprüfungen zurückzuführen ist. Es gibt aber recht komplexe Prozesse. Und wir versuchen alles zu vereinfachen. Es ist bequemer für uns, eine hohe Häufigkeit der Veröffentlichungen zu haben, sodass die Teams nicht über den nächsten Termin nachdenken müssen, sondern lediglich die erforderlichen Funktionen ausführen. Im schlimmsten Fall wird er in zwei Wochen in Produktion gehen.

    Große Teams haben andere Unterschiede. Die Referenten und ihre Kollegen werden auf der AppsConf 2018ApplsConf 2018 über die Details sprechen . Es wird über Werkzeuge und Prinzipien der Organisation großer Teams gesprochen.

    Jetzt auch beliebt: