Wie man Teamkollegen in skalierbarem Scram überlebt und die Codequalitätskontrolle aufrechterhält

Der technische Direktor von ivi , Evgeny Rossinsky ( eross ), ist mit den Teilnehmern unserer Konferenzen über Berichte über die technische Seite des Streamings bestens vertraut. Aber heute haben Sie das Protokoll von Eugenes Bericht über TeamLead Conf darüber, wie sich die agile Transformation in Teamleitern widerspiegelt.



Vor nicht allzu langer Zeit haben wir in ivi die agile Transformation durchlaufen und einen guten Gewinn daraus gezogen in Bezug auf:

• Geschäft
  
• Entwicklungsgeschwindigkeit
  
• Markteinführungszeit;
  
• andere interessante Metriken.
  

Aber die Konsequenzen dieser kreativen Entscheidung haben die Teamleiter ziemlich ernsthaft getroffen. In dem Bericht geht es nur darum, wie man damit umgeht und welche Tools zu verwenden sind.

Vor der Transformation

Um zu verstehen, worüber ich sprechen werde, müssen wir uns ein wenig mit unserem Produkt vertraut machen. Dann werden wir analysieren, warum wir ein solches Befehlsformat haben und warum wir diesen Pfad gewählt haben.

Die Entwicklung in ivi erfolgt unter fünf Hauptplattformen:

• iOS
  
• Android
  
• Web
  
• Smart TV
  
• Windows + Xbox.
  

Und natürlich das Backend, ohne das nirgendwo. Bevor wir uns für die Transformation entschieden haben, wurden unsere Teams durch Kompetenzen gebildet.



Leute, die zum Beispiel Swift oder Objective C kennen:

• im selben Raum sitzen;
  
• Aufgaben von Produktmanagern erhalten;
  
• arbeite daran und produziere ein Ergebnis.
  

Alles scheint in Ordnung zu sein, aber es gibt ein Problem: Die Plattformen unterscheiden sich sehr stark in Bezug auf den Produkt- und Benutzerverbrauch von Inhalten.

Dies bedeutet, dass in jedem Team sein Rückstand und seine Prioritäten auftauchten . Beispielsweise zahlen Benutzer einer Webanwendung nicht gern, und Inhalte werden über ein Werbemodell konsumiert. Funktionen, die für diese Plattform benötigt werden, erscheinen natürlich im Backlog. Smart-TVs zeichnen sich dadurch aus, dass sie gut gekauft sind und sich die Merkmale eines kostenpflichtigen Modells manifestieren.

Es stellt sich folgende Situation heraus: Jemand hatte eine brillante Idee, wie ein Produkt verbessert werden kann. Ich habe viele Tickets geschrieben, die an die Produktmanager gehen, die jeweils für ihre Plattform verantwortlich sind. Manager leiten Ideen durch das Prisma ihrer Wahrnehmung, vielleicht modernisieren sie etwas und fügen es in ihren Arbeitsplan ein. Das Problem hierbei ist, dass eine Funktion länger als ein Jahr auf allen Plattformen veröffentlicht werden kann, da "ich glaube, dass dies für meine Plattform überhaupt keine Priorität hat". Und in einem Jahr, sechs Monaten oder nur wenigen Monaten kann mit dem Produkt alles passieren - zum Beispiel eine Neugestaltung oder eine Änderung des Konzepts. Diese Funktion muss bereits eingeführt werden und ist völlig anders als alle anderen Plattformen.

Infolgedessen stellte sich nach einiger Zeit heraus, dass wir auf verschiedenen Plattformen völlig unterschiedliche Produkte mit unterschiedlichen Kommunikationsbotschaften und Geschäftslogiken haben. Der Benutzer in dieser Situation beginnt verwirrt zu werden, weil er keinen einzigen Bereich hat, in dem er sich sicher fühlt. Darüber hinaus ist es sehr schwierig, Hypothesen zu erstellen , da nicht immer klar ist, auf welcher Plattform welche Funktionalität am besten funktioniert. Es hängt alles von der Größe des Bildschirms ab und davon, wie Benutzer Inhalte konsumieren. Und alles sah ungefähr so ​​aus:



Das geniale Produkt bringt die Idee auf den Markt, und Entwickler auf verschiedenen Plattformen empfinden sie als ziemlich unfreundlich, mit Ausnahme des Backends, das im Allgemeinen keine Rolle spielt, was geschrieben werden soll.

Da das Unternehmen über ausreichende Kompetenzen hinsichtlich flexibler Methoden verfügt, haben wir uns mit dem Unternehmen darauf geeinigt, die Barriere zwischen:

• Produkt
  
• Geschäft
  
• Technologie
  

produktiv interagieren und eine gemeinsame Sache tun.

Nach der Transformation

Dies führte zu einer Architektur mit dediziertem Wertstrom , in der jedes Team in einem bestimmten Geschäftsbereich tätig ist.



Um eine neue Struktur zu bilden, haben wir:

• führte mehrere Schulungen durch;
  
• Festgelegt, was die Hauptbereiche für unser Geschäft sind;
  
• sie zwangen die Menschen freiwillig zum Wertstrom;
  
• begann zu implementieren.
  

Zuvor haben wir ein solches Team gebildet, an dessen Beispiel wir Demonstrationen durchgeführt haben , nachdem wir eine Funktion auf allen Plattformen mit einer hervorragenden Markteinführungszeit heruntergespült haben.

Darüber hinaus wurde das Feature sehr gut ausgewählt und war auf allen Plattformen erfolgreich. Wir hatten also ein Beispiel, das zeigte, dass alles schneller und besser gemacht werden kann . Dadurch konnte das gesamte Entwicklungsteam von 130 bis 140 Mitarbeitern verstehen, dass Sie anders arbeiten können.

Als wir den Wertstrom bestimmten, stellte sich die Frage, was mit Teamleitern zu tun ist. Früher waren sie die Basis für alles in ihre Richtung, jetzt gibt es einen Wertstrom und einen größeren Einfluss des Geschäfts. Was haben wir getan Wir haben Menschen mit unterschiedlichen Kompetenzen in jeden Wertstrom einbezogen, jeweils mindestens einen:

• iOS-Entwickler
  
• Android-Entwickler
  
• JavaScript-Entwickler
  
• Smart-TV-Spezialist
  
• Layout Designer,
  
• zum Tester.
  

Es stellte sich heraus, dass es sich um ein unabhängiges Team handelte, das jedoch in Worten und auf schönen Folien eines agilen Trainers unabhängig war . Tatsächlich vergisst jeder, dass Menschen, die in derselben Programmiersprache schreiben können, noch etwas gemeinsam haben - dies ist ihr Programmcode, über den sie irgendwie kommunizieren müssen. Aus irgendeinem Grund schweigen viele darüber, aber dies ist wirklich ein ziemlich großes Problem, an das man sich erinnern muss.

Angenommen, Sie platzieren Personen in verschiedenen Stockwerken oder Räumen und sie schreiben denselben Code. Es gibt einen Release-Zyklus und Funktionen, die sich nicht gegenseitig stören sollten. Es gibt viele Probleme.

Vom Konzept

Wir haben mehrere Grundkonzepte übernommen:



Wir haben Wertstrom- und Plattformbefehle . Im Wertstrom implementieren die Jungs eine bestimmte Funktion, und auf den Plattformen gibt es einen Teamleiter - das Kompetenzzentrum. Innerhalb der Plattformen können auch einige Funktionen entwickelt werden, dies ist jedoch eher eine architektonische Sicht auf die Softwareentwicklung.

Wir haben das Konzept der „ Gilden “ eingeführt. Indem wir dieselben iOS-Entwickler in verschiedenen Räumen platzierten, mussten wir ihnen ein formelles und sogar ein informelles Zeichen geben, dass sie dieselben iOS-Entwickler blieben und nicht nur Teilnehmer am Wertstrom des Werbeprodukts. Und dann musst du mit dieser Gilde etwas tun und den Leuten irgendwie beibringen, im Inneren zu kommunizieren.

Die nächste Frage war, was mit den Release-Zyklen zu tun ist . Auf den Plattformen, auf denen Sie die Funktion bereitstellen können, gibt es keine Fragen. Und im Fall von iOS oder Android müssen Sie einige Pakete sammeln, wenn es aufgrund der Besonderheiten des Erhalts der Apple-Genehmigung unmöglich ist, die Anwendung zweimal täglich zur Veröffentlichung zu senden.

Wir haben beschlossen, dass jede Plattform, die nicht sofort veröffentlicht werden kann, alle zwei Wochen veröffentlicht wird . Sie stellten allen einen speziellen Kalender zur Verfügung, in dem das Team das Einfrierdatum der Funktion und das Veröffentlichungsdatum veröffentlicht. Wenn Sie möchten, dass Ihre Aufgabe im Wertstrom einem echten Benutzer zur Verfügung steht, sollten Sie rechtzeitig zum Einfrieren der Funktionen sein. Hatte Zeit - na ja, hatte keine Zeit - du wartest auf den nächsten Zug.

Timlid im neuen Schema

Was ist mit den Timlids passiert? Sie gingen durch das klassische Schema des Bewusstseins für Probleme, die nicht gelöst werden können.



Zuerst stießen wir auf eine Ablehnung . Weil der Teamleiter seit mehreren Jahren ein cooles Team aufgebaut hatte, jeden Mitarbeiter pflegte und jemanden von Mitbewerbern lockte. Und diese Spezialisten wurden nun mit Arbeiten beauftragt, die nicht immer ihren Erwartungen entsprechen.

Natürlich gab es nach der Ablehnung Ärger .

Es gab viele Skandale, nach denen Verhandlungen begannen. Alle hatten die Frage: "Lassen Sie uns alle Ihren eigenen Weg gehen, aber ich habe ihn wie zuvor, aber ich nehme einen Marker, schreibe" Agile "in mein Haus, ich werde ein T-Shirt mit dieser Inschrift tragen, aber alles wird wie zuvor sein." Hat nicht funktioniert.

Aber am Ende passierte das, was ich wirklich erwartet hatte - die Leute verstanden, warum wir das taten. Ich hoffe, sie haben verstanden, obwohl sie vielleicht gelogen haben. Der allererste erfolgreiche Fall zeigte einen bemerkenswerten Unterschied zwischen dem, was vorher war und wie es anders gemacht werden kann. Die halbierte Markteinführungszeit ermöglichte es uns, einen Maßstab für alle zu setzen. Der nächste Schritt erfolgte, der im klassischen Modell der Psychologie als Stockholm-Syndrom bezeichnet wird . Menschen, die die neuen Regeln übernahmen, lernten, in ihnen zu existieren und begannen, diese „Religion“ langsam zu verbreiten. Ich kann nicht für alle Timlids sagen, aber ungefähr 30% von ihnen sind jetzt aktive "Prediger" in dieser Richtung.

Probleme und Schwierigkeiten

Jetzt werde ich versuchen, die Schwierigkeiten, auf die wir gestoßen sind, struktureller aufzulisten:



Aufgrund der Tatsache, dass Mitarbeiter in verschiedenen Büros saßen, ging die mündliche Kommunikation verloren. Es wurde einen Monat lang sehr schwierig , weil es vorher möglich war, schnell einen Nachbarn zu fragen, von was Sie erben müssen, und dann eine Antwort zu erhalten. Und jetzt sitzen Sie in einem separaten Raum, es gibt Leute um Sie herum, deren Technologie Sie vielleicht nicht mögen, und es gibt niemanden, den Sie konsultieren können. Um jemandem eine Frage zu stellen, müssen Sie in einem Chat schreiben, und die Person, die antworten kann, ist weg - das ist alles, Sie sind auf sich allein gestellt.

Wir hatten sofort Probleme mit der Codeüberprüfung , was meines Erachtens kein Problem, sondern eine große Entdeckung ist. Wir haben festgestellt, dass eine große Anzahl von Mitarbeitern nicht unabhängig ist . Angenommen, es gab einen Mitarbeiter, der laut Statistik die Überprüfungsprobleme beim zweiten Mal maximal bestanden hat, normalerweise beim ersten Mal, wenn alles in Ordnung war. Und als er ging, um im Wertstrom zu arbeiten, wurden es aus irgendeinem Grund 5-6 Iterationen.

Sie begannen zu verstehen, und es stellte sich heraus, dass die maßgebliche Meinung der Ikone des Teamleiters, der alle Informationsflüsse relativ zu sich selbst kontrolliert und zentralisiert, die Entwicklung der Entwickler nicht sehr gut beeinflusst. Die Leute sind faul , sie bitten um Hilfe in allen Fragen und erhalten kompetente Antworten. Und so ist die Überprüfung schnell und cool. Viele Entwickler waren mit sich selbst allein und mussten deutlich über sich selbst hinauswachsen, um die gleichen architektonischen Entscheidungen zu treffen . Niemand hört gerne fünfmal hintereinander, dass Ihr Code nicht sehr gut ist. Es ist frustrierend, es lässt Sie sich als unzureichend qualifizierten Mitarbeiter betrachten, es kann sogar zu Depressionen oder der Überzeugung führen, dass der Job möglicherweise schlecht ist. Aber der Punkt ist, dass Sie sich selbst betrachten müssen, um zu verstehen, dass Sie in der vorherigen Arbeitsweise nicht über diese Dinge nachgedacht haben, sondern sich jetzt entwickeln und anfangen sollten, über sie nachzudenken .

Andererseits hatten wir einige sehr interessante Dinge, die meiner Meinung nach in Bezug auf die Codeüberprüfung überflüssig sind. In einem der Teams gab es eine Regel: Damit die Aufgabe überprüft werden kann, müssen alle Teammitglieder ihre Entscheidung treffen. Wenn sie zusammen saßen, waren sie mehr oder weniger erfolgreich, und jetzt setzten sie sich alle zusammen - einige hatten zu einer Zeit ein tägliches Stand-up-Meeting, andere hatten andere Geschäfte - und das Überprüfen von Aufgaben wurde zu einem engen Engpass. Im Nachhinein erfuhren sie immer wieder, dass einige Aufgaben zwei Wochen lang überprüft wurden und gezwungen waren, etwas zu ändern.

Dann begann: Separatismus, Diskriminierung und Neid .

Zuvor glaubte eine Person zu wissen, was sie tun wollte. Und mit der Trennung von Wertstrom und Plattform entstand der Verdacht, dass „der Nachbar besser schmeckt“: Die Aufgaben sind interessanter und das Wachstum ist schneller. Das zweite Problem ist, dass sich die Qualität des Codes stark verschlechtert , wenn sich alles auf Funktionen konzentriert . Um Sie herum sind Menschen, die schnell das Ergebnis erzielen möchten, und es ist nicht ihre Aufgabe zu glauben, dass es unterstützt, in irgendeiner Weise modernisiert werden muss und dass die Kollegen von der neuen Funktion nichts abbringen sollten.

Es entstanden Situationen, in denen die hohe Entwicklungsgeschwindigkeit ihren entgegengesetzten Code mit schlechter Qualität hatte , der sich in unmenschlichen Mengen zu vermehren begann. Wenn der verantwortliche Teamleiter die Korrektur dieser Fehler und das Refactoring übernimmt, stellt sich heraus, dass sein Leben für fahrlässige Mitarbeiter zu einem Müll wird. Die Entwickler bekommen schnell alles, alle sind glücklich und sie bemerken die titanische Arbeit des Teamleiters nicht, dank der tatsächlich alles funktioniert. Nach ungefähr zwei Monaten äußerte jeder Teamleiter seine Unzufriedenheit mit der aktuellen Situation.

Um diese Probleme zu lösen, haben wir mehrere Treffen zuerst mit den Timlids und dann mit allen Gilden abgehalten, um den Leuten zu erklären, dass es möglich ist, anders zu arbeiten. Wenn Sie etwas anderes ausprobieren möchten, müssen Sie zum Teamleiter kommen, und Sie können leicht die Plätze wechseln. Die Hauptsache ist, sich untereinander zu einigen.

Die Stärke flexibler Methoden besteht darin, dass es nicht jedem wichtig ist, wie alles abläuft. Hauptsache, die Menschen sind sich einig und zufrieden.

Dies ist einerseits. Auf der anderen Seite werde ich etwas später darauf zurückkommen, damit gerecht wird, wer am Refactoring beteiligt ist und wer neue Funktionen ausführt. Die Teamleiter beginnen, mit Rückständen zu arbeiten.

Und dann begannen die Schwierigkeiten mit dem Release Management . Es gibt Tester im Wertstrom, Tester auf den Plattformen, etwas ist automatisiert, etwas ist nicht automatisiert, Sie müssen darüber nachdenken, wie Sie eine allgemeine Regression durchführen können. Und es gibt Begriffe. Wir haben uns freiwillig entschlossen, alle zwei Wochen freizulassen, und was ist, wenn ein Partner mit der Aufforderung kommt, bis morgen alles zu erledigen (und zum Beispiel eine Tüte Geld), ihm zu sagen, er solle auf den nächsten Zyklus warten? Dennoch muss ein Kompromiss gesucht werden . Und dann kann sich ein schönes Schema mit Veröffentlichungen sehr ändern.

Ein gutes Beispiel ist das Gesetz FZ-54, wonach alle Einkäufe im Internet von elektronischen Schecks an Benutzer und an die Steuer begleitet werden müssen. Sie können auf Konferenzen so viel sprechen, wie Sie möchten, und über flexible Methoden und Vorschriften sprechen. Sobald jedoch die Gefahr besteht, dass 70% Ihres Umsatzes bestraft werden, wechseln Sie zu einem völlig anderen Regime und stellen sicher, dass Ihr Unternehmen nicht mit Geldstrafen belegt wird. Solche Fälle sind selten, aber es gibt. Insbesondere mussten wir bei Änderungen im Schema die zweite Kommunikationsebene einrichten. Es ist nicht einfach, aber möglich.

Das nächste Problem, auf das wir infolge der Transformation gestoßen sind, betrifft neue Mitarbeiter . Meiner Meinung nach sollten Anfänger in eine Umgebung eintauchen, die der Umgebung, in der sie arbeiten werden, so nahe wie möglich kommt. Und dort erhält er aufgrund der Umwelt schnell das nötige Wissen. Aber wir haben die Spezialisten, aus denen diese Umgebung besteht, in verschiedene Stockwerke und Räume gezogen. Das Leben eines Anfängers in einem Unternehmen wird zu einer ziemlich ernsten Führungsaufgabe, deren Lösung durchdacht werden muss.

Die Werkzeuge

Hier sind die Werkzeuge, die wir verwenden.



Ich beginne die Geschichte mit einer Streckenkarte für einen neuen Mitarbeiter. Leider ist dies etwas, das wir noch nicht gelernt haben, wie man es vollständig automatisiert und tatsächlich für jeden Mitarbeiter separat durchdacht, je nachdem, was er tun wird.

Es gab ein ziemlich interessantes Beispiel: Wir mussten einen universellen Tester entwickeln , der absolut alle Produkte auf einen Werbestream testen kann. Sie haben viel gemeinsam, aber sie haben auch ihre eigenen Besonderheiten. Es ist kein Geheimnis, dass ein Tester, der beim Testen einer Webanwendung cool ist, zum ersten Mal verloren geht, wenn er mit Tools arbeitet, beispielsweise für iOS. Für diesen Tester hat unser Direktor für Qualitätskontrolle eine spezielle Streckenkarte erstellt. Auf dieser Karte sammelte ein neuer Mitarbeiter in jeder Kompetenz zwei Wochen lang Wissen, nahm an Regressionen teil und vieles mehr. Bei Entwicklern ist die Situation bei der Implementierung ungefähr dieselbe. So finden wir bereits im Interview heraus, was Candida anzieht und was ihn interessiert, und wir versuchen zu entscheiden, in welche Richtung er geschickt werden soll.

Natürlich ist das erste Mal, dass ein neuer Mitarbeiter Kompetenzen pumpt, dh in unseren Begriffen, im Plattformteam und kann dann bereits auf den von uns benötigten Wertstrom migrieren. Routenkarten sind übrigens gut, aber ihre Anpassungsfähigkeit muss auch nicht ausgeschlossen werden.

Dann haben wir Guild Sync eingeführt - Synchronisation von Gildenaktionen .

Warum wird das benötigt? Alle hörten sich einen Vortrag über Scrum an, in dem über die Notwendigkeit eines täglichen Stand-up-Meetings gesprochen wurde, um Sie über die Vorgänge zu informieren. Unser Spezialist ist zum Beispiel einerseits ein Android-Entwickler und andererseits ein Mitglied des Produktteams. Wenn er zweimal am Tag laufen und kommunizieren muss, bekommt er eine Art Frachtkult. Mit dieser Geschwindigkeit können Sie Ihr ganzes Leben in Besprechungen verbringen. Auf jeden Fall wird es die Leute nerven.

Wenn wir sagen, dass wir auf einem funktionsorientierten Modell basieren, ist das tägliche Stand-up-Meeting in seinem Wertstrom wichtiger. Gleichzeitig kannst du dich von dem lösen, was in der Gilde passiert. Zu diesem Zweck organisieren einige Gilden einmal pro Woche, einige zweimal pro Woche Treffen. Und hier denkt der Teamleiter methodisch darüber nach, worüber es sich zu sprechen lohnt. Dies sollte nicht zu leeren Gesprächen führen, sondern ist eine Entwicklungsstrategie für das Technologieteam, das die Gilde ist. Guild Sync-Meetings sind erforderlich, damit jeder versteht, welche Technologien das Unternehmen verwenden wird und welche strategischen Entscheidungen in Bezug auf diese Plattform getroffen werden. Darauf findet eine teilweise Überprüfung der architektonischen Lösungen statt.

In einigen Teams haben wir mehr als einen Teamleiter. Im Allgemeinen ist die Definition des Teamleiters sehr vieldeutig. Es gibt Meinungsführer, die Teamleiter sein können und die Lösung einiger organisatorischer Probleme tragen. In einem Team kann es mehrere Meinungsführer mit Managementfähigkeiten geben. Und dann können sie sich organisieren, wer wofür verantwortlich ist. Zum Beispiel kann einer der Meinungsführer zum Wertstrom gehen. In diesem Fall müssen Sie Ihre Architekturentscheidungen synchronisieren, die in Zukunft die Entwicklungsstrategie der gesamten technologischen Plattform bestimmen werden.

Dann begannen wir, in bestimmten Bereichen interne und externe Mitaps durchzuführen. Im Allgemeinen ist dies ein ziemlich normaler Fall, teils ein HR-Fall, teils ein Teambuilding-Fall. Bei internen Besprechungen wird manchmal abgestimmt, welches Thema am interessantesten ist, Redner werden entweder innerhalb des Unternehmens gesucht oder wir laden jemanden von außen ein, mieten einen speziellen Raum und diskutieren verschiedene wichtige Punkte. Im Durchschnitt haben wir zwei interne Mitaps pro Monat, manchmal aber auch vier. Menschen aus anderen Kompetenzen können zu diesen Mitaps kommen, um zu hören, wie Nachbarn leben, und um zu sehen, ob sie ihre Spezialisierung ändern möchten. Das passiert auch.

Jetzt auf dem Arbeitsmarkt in Sachen Entwickler ist nicht alles sehr einfach. , , . , , , . , , .

. , , Agile- , Guild Sync .

, , , . , , Guild Sync , .



, , , , , . 10 .

— . , , -. - , , , . - , , , . , - . , , , , , - .

. , . , , , , . , , , . , - , , , , , .. . , « ». , , .

Guild , . - , , .

, product owner' value stream. , 10 , - , , . , product owner' . backlog' . , , . , ( , , , , ).

— , .

Teamlead —

, , - .

, . , , , , , , — .

, , , « ». , , , . , , , , value stream. , , . , , .

24 25 . - Saint TeamLead Conf .

, 40 , — 10 .