Wie Entwicklungsteams organisiert wurden in more.tv / Sudo Null IT News

Hallo alle!

In diesem Artikel möchten wir über die unterschiedlichen Wege der Organisation von Entwicklungsteams sprechen, die das Online-Kino der nationalen Mediengruppe more.tv in drei Jahren durchlaufen hat: die Ziele der Veränderungen, ihre Vor- und Nachteile und die gemachten Fehler . Wir sind sicher, dass dieses Format für viele sinnvoller sein kann, als Theorie aus Lehrbüchern zu studieren.

Mein Name ist Alexey Dmitriev, ich bin der Leiter des M3-Projektbüros.

Anfang

So begann alles Ende 2018 mit der Entscheidung des Managements, auf Basis des bestehenden Produkts Videomore ein neues more.tv Online-Kino zu schaffen. Zuvor hatte die National Media Group keine großen internen Entwicklungsprojekte, daher wurde beschlossen, M3 zu gründen, ein separates Unternehmen mit digitaler Expertise, um more.tv zu starten. Dem Unternehmen wurde ein ehrgeiziges Ziel gesetzt: innerhalb von sechs Monaten ein neues Produkt auf den Markt zu bringen.

Aber die Ergebnisse der ersten Jahreshälfte fielen recht bescheiden aus: Ein Entwicklungsteam von etwa 50 Personen wurde eingestellt, grundlegende Tools wurden bereitgestellt und mehrere funktionierende Prototypen wurden demonstriert. Werfen wir einen Blick darauf, wie das v1.0-Team organisiert war, um zu verstehen, warum dies passiert ist.

  • Produkt: Aufteilung nach Zugriffsfenstern (Web, Mobile, Smart TV)

  • Architektur: unstrukturierte, situative Lösungen

  • Entwicklung: Komponente (PHP, C++, React, Swift, Java Stacking) + mehrere Festpreisanbieter

  • Prüfung: innen und nur manuell

  • DevOps: Systemadministrator + Entwicklungsteamleiter

  • Management: unstrukturiert, Prozesse werden ad hoc aufgesetzt, das gesamte Team ist für Termine verantwortlich

  • Agiles Framework: Getrennte Scrum-Inseln

Die Atmosphäre jener Zeit wird durch folgendes Schema gut vermittelt:

Diese Struktur hatte eine Reihe von Problemen:

  1. Das Produkt bestellte verschiedene Funktionen für verschiedene Plattformen, was erhöhte Kosten von BE erforderte. Angesichts knapper Fristen war dies ein unerschwinglicher Luxus.

  2. BE musste viel und oft eingeführt werden, und manuelles Testen war nicht zu bewältigen. Oft wurde in neuen Releases bereits übernommene Funktionalität vergessen.

  3. Ohne die Architektur der zukünftigen Lösung im Detail zu verstehen, wurde eine kritisch wichtige Funktionalität mit einer unentwickelten technischen Spezifikation vergeben. Klärende Fragen waren sehr ablenkend, und der Festpreis ließ keine wesentlichen Änderungen zu. Das Endergebnis musste zu 70% in Eigenregie umgeschrieben werden.

  4. Die Forderung nach dem Ergebnis gleichzeitig von allen führte nicht zur Identifizierung wirklich problematischer Bereiche. Gleichzeitig brannten die Menschen sehr schnell aus und arbeiteten jeden Tag 12 Stunden und sieben Tage die Woche.

  5. Die gleichzeitige Einstellung von Mitarbeitern mit unterschiedlichem Hintergrund erschwerte eine schnelle Einigung. Ohne Menschen, die dafür verantwortlich sind, alle mit allen zu synchronisieren, gab es eine Situation von Schwan, Krebs und Hecht.

Mannschaft 2.0

Nach dem Erkennen systemischer Probleme wurden folgende organisatorische Änderungen vorgenommen:

Die Verantwortlichkeiten der Produktmanager wurden geändert. Jetzt sind sie für die Funktionalität verantwortlich und nicht mehr für einzelne Zugriffsfenster. Dadurch konnten wir plattformübergreifende Funktionen freigeben, ein einziges Backlog einführen und uns auf das Wichtigste konzentrieren.

Ein Projektbüro wurde organisiert, das die Prozesse in Teams systematisierte, täglich einführte Scrum von Scrum, Retrospektiven in Betrieb genommen, Auftragnehmer zu Zeit und Material versetzt und sie zu einem großen Team gemacht. Dadurch konnten wir die Flexibilität erhöhen, die Reaktion auf auftretende Probleme beschleunigen, die Bemühungen verschiedener Teams synchronisieren und Transparenz für das Top-Management schaffen.

Eigene Fakultät für Architektur. Nun wurde die Systemanalyse nicht im Zuge der Aufgabenumsetzung, sondern im Vorfeld durchgeführt. Dies reduzierte die Anzahl der Krücken bei der Implementierung neuer Funktionen erheblich und verbesserte auch den Kenntnisstand über die Plattform erheblich.

Es wurden QA-Automatoren eingestellt, die die Geschwindigkeit der Durchführung regelmäßiger Tests der ständig wachsenden BE-Funktionalität erheblich steigern konnten.

Es wurde eine DevOps-Abteilung geschaffen, die sich um die Systemorganisation von CI/CD, die Einrichtung von Monitoring und Fehlertoleranz kümmerte.

All diese organisatorischen Veränderungen ermöglichten nicht nur den erfolgreichen Start von more.tv, sondern auch die schnelle Umsetzung der zunächst verzögerten Funktionalität.

Überstunden für das Team wurden zu einer Seltenheit, die Mitarbeiterzufriedenheit stieg, die technischen Schulden gingen zurück und die Leute begannen, häufiger positive Fälle bei Retrospektiven vorzubringen.

Gleichzeitig traten andere Probleme auf.

Strategische Funktionalität wurde reibungslos und ohne Verzögerung ausgerollt – die Teams arbeiteten gerne an einem Ergebnis, das für das Produkt sehr wichtig ist. Aber wenn es um Aufgaben mit niedriger Priorität ging, konnte es mehrere Blöcke von der Entwicklung bis zum Rollout dauern. Kunden, deren Aufgaben in der End-to-End-Priorität nicht hoch waren, waren über diesen Umstand sehr verärgert.

Dann haben wir uns entschieden, uns auf die Verbesserung des durchschnittlichen Time-to-Market-Parameters (TTM) zu konzentrieren.

Dazu haben wir alle beteiligten Einheiten befragt, alle Lösungsvorschläge zur Beschleunigung des TTM aufgeschrieben und priorisiert.

Fokussiert auf drei Bereiche:

  1. Reduzierung des Intervalls zwischen den Veröffentlichungen,

  2. Beseitigung von Engpässen,

  3. Erhöhung des Umfangs der Autotests.

Teaser: Nur der erste Punkt hatte einen signifikanten Effekt, und dann für nicht sehr große Änderungen (bis zu vier Tage Entwicklung).

Wir haben benutzerdefinierte Testumgebungen, Feature-Releases, Canary-Releases, keine neuen Aufgaben bis zur Veröffentlichung der vorherigen und vieles mehr implementiert. Dadurch konnten wir das durchschnittliche Intervall zwischen Veröffentlichungen neuer FE- und BE-Funktionen von 23 auf 9 Werktage reduzieren.

Als wir uns vorgenommen haben, Engpässe zu beseitigen, haben wir deutlich gesehen, dass sobald ein Engpass verschwindet, sofort ein anderer auftaucht. Es ist unmöglich, sie vollständig zu besiegen, Sie müssen lernen, mit ihnen umzugehen.

Die Zunahme von Autotests führte irgendwann dazu, dass deren vorzeitige Aktualisierung bereits die Veröffentlichung von BE verlangsamte. So führte beispielsweise ein Urlaub oder eine Krankheit eines der beiden Autotester sofort zu einer Erhöhung der Warteschlange der gesamten BE. Ich musste Autotests nur für grundlegende Funktionen verlassen und mehr Verantwortung auf die Unit-Tests der Entwickler verlagern.

Mannschaft 3.0

Irgendwann haben wir gemerkt, dass wir, um die Auslieferung weiter zu verbessern, die Organisation der Teams noch einmal überarbeiten müssen.

Wir beschlossen, zu versuchen, vollwertige funktionsübergreifende Produktteams oder Feature-Teams zusammenzustellen. Glücklicherweise war die gesamte notwendige Infrastrukturvorbereitung für den unabhängigen Rollout von Teams bereits fertig.

Um die Dinge nicht durcheinander zu bringen, beschlossen wir, mit einem solchen Team zu experimentieren und es von Freiwilligen zusammenzustellen.

Infolgedessen bestand das Team aus sechs Personen mit jeweils eigener Rolle:

  1. Produkteigentümer

  2. Geschäftsanalysen

  3. Scrummaster

  4. Entwickler BE

  5. Entwickler F.E.

  6. QS-Handbuch

Nach den Ergebnissen von zwei Vierteln der Arbeit des Feature-Teams wurde eine signifikante Verbesserung der durchschnittlichen TTM festgestellt.

Zu diesem Zeitpunkt hatten wir bereits neue Prozesse und Interaktionen zwischen Teams ausgearbeitet, wir sahen die Stärken und Schwächen solcher Teams.

Vorteile und Nachteile

Zu den Vorteilen einer solchen Organisation führten wir die Unabhängigkeit der Versorgung von anderen Teams uumstärkeres Team-Engagement

Die Hauptnachteile für uns waren die großen Busfaktor und eine geringere Auslastung einzelner Teilnehmer, da nicht jede Rolle in einem bestimmten Sprint voll ausgelastet werden kann.

Lösung

Die ursprüngliche Idee war, die gesamte Entwicklung an funktionsübergreifende Teams zu übertragen.

Aber wir stießen auf mehrere Probleme:

Nicht alle Aufgaben können unter die Ziele von Feature-Teams gebracht werden. Das können Gesetzesinitiativen, überbetriebliche Aufgaben, Optimierungsaufgaben aus internen Abteilungen sein, die keinem Teamziel unterfallen.

Feature-Team-Systemlösungen können miteinander in Konflikt geraten. Beispielsweise beschloss ein Team, die Geschäftslogik in einen separaten Microservice zu verschieben, und das zweite Team beschloss, ein ähnliches Problem zu lösen, indem es die Funktionalität eines vorhandenen Microservices erweiterte.

Nicht alle Entwickler möchten in Feature-Teams arbeiten. Einige sind von der Tatsache eingeschüchtert, dass sie in einem Team allein für ihren Stack oder ihre Rolle verantwortlich sind. Auch empfinden manche Mitarbeiter den Übergang zu funktionsübergreifenden Teams als Einschränkung ihres Horizonts und ihrer Weiterentwicklung, obwohl dies nicht der Fall ist.

Um das kohärente System nicht zu brechen und keine Mitarbeiter zu verlieren, haben wir uns entschieden, diese Menschen in ihrer gewohnten Konfiguration zu belassen.

Infolgedessen haben wir jetzt acht Teams: sechs Produktteams, ein technisches und ein Komponenten-Core-Team.

Produktteams sind für das Pumpen bestimmter Metriken verantwortlich. Die meisten von ihnen sind für ihre verantwortlich AARRR-Metriken.

Das Tech-Team reduziert Altlasten und verbessert das Leben von Entwicklern, Testern und DevOps.

Das Kernteam ist verantwortlich für die Integrität des gesamten Systems, die Entwicklung großer Knoten oder Aufgaben, die nicht unter das Produkt oder die Technik fallen. Es beschäftigt Teamleiter, Entwickler, die nicht alleine in ihrem Stack arbeiten möchten, und Junioren, die noch nicht bereit sind, alleine zu arbeiten. Für ein beschleunigtes Onboarding werden alle neuen Mitarbeiter in den ersten Arbeitswochen in das Kernteam aufgenommen.

In Teams, vierteljährlich Gesundheitskontrolle. Dies ermöglicht den Teilnehmern, mögliche Wachstumspunkte klar zu artikulieren, und das Management kann sehen, was und wo nicht gut funktioniert oder wo Hilfe benötigt wird.

Aber auch diese Entwicklungskonfiguration beseitigt nicht alle Probleme. Manchmal gibt es Abhängigkeiten zwischen Teams, und das Wechseln von Entwicklern zu den Aufgaben anderer Teams verringert ihre Effizienz und verringert das Engagement. Es gibt auch Verzögerungen beim Warten auf Codeüberprüfungen, da Entwickler in verschiedenen Teams sind. Glücklicherweise wissen wir, wie man mit diesen Problemen umgeht, und freuen uns darauf, ihre Auswirkungen in Zukunft stark zu reduzieren.

Schlussfolgerungen

Wie Sie jetzt sehen können, haben wir in drei Jahren drei verschiedene Ansätze zur Organisation der Entwicklung ausprobiert. Die Versuchung ist groß zu sagen: „Warum konnte es nicht gleich gut gemacht werden, um es später nicht noch einmal zu machen?“

Unsere Erfahrung zeigt, dass bei engen Fristen und schnellem Wachstum des Teams die Standardmethode der Gebäudeentwicklung gut funktioniert: vertikale Komponententeams und klare TORs für das, was zu tun ist.

In der Phase, in der es ein funktionierendes Produkt, ein etabliertes Entwicklungsteam und fortschrittliches CI / CD gibt, erweisen sich funktionsübergreifende Produktteams als viel effektiver.

Auch ein Hybrid aus beiden Modellen ist möglich. In dieser Version steigen jedoch die Verwaltungskosten für die gleichzeitige Unterstützung von zwei Verwaltungsmodellen.

Jedes Unternehmen hat seine eigenen Besonderheiten: Größe, kultureller Code, technisches Erbe, geschäftliche Anforderungen. Vielleicht sind die Erfahrungen, die wir gesammelt haben, nicht auf Ihre Landschaft anwendbar. Es ist wichtig, dort nicht stehen zu bleiben, regelmäßig Problempunkte zu identifizieren und nach Lösungen zu suchen.

Sicherlich haben auch Sie beim Experimentieren mit der effektiven Organisation von Teams viele Erfolge erzielt. Es wäre toll, wenn du in den Kommentaren erzählst, was funktioniert hat und was nicht. Vergessen Sie nur nicht, den Kontext Ihrer Situation einzubeziehen.

Autor des Artikels:

Similar Posts

Leave a Reply

Your email address will not be published.