Von Monolithen zu modularen Teams

Große Unternehmen trauern oft um das Problem der Anpassungsfähigkeit und Manövrierfähigkeit. Genauer gesagt, fast aus der völligen Abwesenheit von beiden.

Stellen Sie sich vor: Alle Plattformteams sind mit einer Funktion beschäftigt, und das Unternehmen muss dringend etwas anderes tun oder die bereits entwickelten Funktionen anpassen. In diesem Moment wird die Arbeit an einer Funktion beendet und die Arbeit an einer anderen beginnt. Im nächsten Moment erscheinen neue Anforderungen aus dem Geschäft, und die Funktion bleibt unvollendet. Entwickler sind beleidigt und das Geschäft leidet.



Hier ist eine andere Situation: Die API ändert sich. Sie müssen dringend zur Backend-Abteilung laufen, um Details herauszufinden, und dann zurück zu den Fronten (iOS / Android / Web). Nachdem Sie Ihre Korrekturen mit den Fronten besprochen haben, müssen Sie zurück nach hinten gehen und unsere Anforderungen ansprechen. Es war sehr anstrengend, verlor die Zeit der Teams, eines einzelnen Entwicklers und die Nerven aller interessierten Leute.

Mein Name ist Valery, unser Team war mit QIWI Wallet für iOS beschäftigt. Es war jedoch immer notwendig, die Kommunikation mit anderen Teams aufrechtzuerhalten, da sonst eine vollständige Desynchronisierung resultieren würde. Was unsere Unannehmlichkeiten angeht, so geht das Geschäft immer weiter und bietet Freiheit zum Experimentieren. Daher stellte sich die Frage, ob die bestehende Struktur geändert werden sollte. Ein günstiges Umfeld, um unsere Ideen für Veränderungen zu testen, war Scrum. Alle zwei Wochen konnten wir innerhalb der Plattform den Kurs so bearbeiten, dass er zumindest irgendwie mit anderen Teams koordiniert war. Es hat lange gedauert, Theorien zu testen. Von einem Monat bis zu sechs Monaten. Welche Optionen haben wir versucht:

Feature oouner

Eine Person aus dem Team wurde für das Feature für den nächsten Sprint verantwortlich gemacht. Diese Person verbrachte einen Teil ihrer Zeit mit Designern und mit einem Feature eines anderen Front-Line-Teams (das Backup entschied sich, das Feature-Ower nicht zu verwenden), um die Fallstricke und Feinheiten der bevorstehenden Arbeit herauszufinden, und stimmte dem Backend bezüglich des Vertrags zu. Er überwachte auch alle Änderungen am Backend und am Geschäft. Und alles scheint in Ordnung zu sein. Niemand gerät in Panik, außer dieser Person, die den Schlag einer veränderlichen Umgebung auf sich nimmt. Alle beruhigten sich für einen Moment.

Aber das Glück hielt genau so lange an, bis das Merkmal des OUNER genau vor seinem Sprint krank wurde. Und die ganze Illusion der Beschwichtigung löste sich auf und wir kehrten dorthin zurück, wo wir angefangen hatten.

Allgemeine Pflege

Vertreter verschiedener Plattformen wurden eingeladen, ein Plattformteam zu pflegen. Es wurde ein bisschen besser, aber die Jungs mochten es nicht (nach dem Wort überhaupt), bei mehreren Treffen hintereinander zu sitzen. Der Hauptgrund ist jedoch die Variabilität der APIs und Verträge, die Änderung der Sprintziele und es ist gut, wenn sie sich nur am ersten Tag des Sprints ändern. Aber normalerweise fielen die Veränderungen in allen zwei Wochen. Fazit: Die Ziele werden nicht erreicht, die Jungs bearbeiten, das Geschäft leidet.

Chats

Eine der nicht standardmäßigen Optionen war die Erstellung von Chats. Für jede Funktion wurde ein separater Chat erstellt. Darüber hinaus gab es Chatrooms von Teams, in denen Probleme besprochen wurden. Und auch ein allgemeiner Chat speziell für Probleme, bei denen alle Teams waren. Zunächst schien das Problem gelöst zu sein.

Aber die Chats vervielfachten sich schnell und es wurde eine Belastung. Als ein Problem auftrat, wurde unklar, wo nach Informationen gesucht werden sollte - entweder im Chat im Profilbereich oder im Chat zum Umgestalten des Netzwerkclients oder zum Ersetzen des Benutzerinformationsmoduls. Infolgedessen wurde es nur noch verwirrender. Wieder musste ich zwischen Abteilungen laufen.

Feature-Tim

Dann kam ein Lebensmittelgeschäft und bot an, das Feature-Tima-Format auszuprobieren. Was bedeutet das: Von jeder Plattform (iOS, Android, Web, Backend) und zwei Testern werden zwei Entwickler übernommen und ein neues Team gebildet.

Dieser Ansatz sollte neben der Kohärenz und Geschwindigkeit der Veröffentlichung von Veröffentlichungen mehrere Hauptprobleme lösen:

Autonomie
Ein Team, das gemeinsam zu Besprechungen geht, ist so unabhängig wie möglich von anderen. Die Hauptverbindung von externen Abhängigkeiten ist das Produkt.

Schneller Theorie-Test
Immerhin, bevor das gesamte Wallet-Team einige neue Funktionen ausführte und es vorkam, dass diese sehr coole Funktionalität nicht an Benutzer ging. Es stellt sich heraus, dass die gesamte Entwicklung unnötige Dinge zersägte und das Budget nirgendwo hin führte.

Das gesamte Team versteht, was „Produktentwicklung“ ist.
Funktionen werden erstellt oder Geschäftsanforderungen werden erfüllt, und der Entwickler versteht nicht immer, warum, warum und wer sie benötigt.

Das gesamte Team beeinflusst das Produkt. Bis zur Erfindung neuer Funktionen
Infolgedessen hat dieser Ansatz allen gefallen, und im Moment haben wir drei unabhängige Teams, die sich mit ihren Produktaufgaben befassen. Wenn Sie den Vertrag ändern, müssen Sie nicht mehr in den Abteilungen herumlaufen und nach verantwortlichen suchen. Sie müssen auch keine verwirrenden Chats führen. Stoßen Sie einfach einen Entwickler in der Nähe an. Es finden Meetings statt, bei denen Vertreter aller Plattformen und der Qualitätssicherung sofort anwesend sind.

Fragen werden in wenigen Minuten in Worten gelöst und niemand hat den gleichen Schmerz. Ein weiterer großer Vorteil für das Unternehmen besteht darin, dass nur eine Funktion des Teams (derzeit von drei) ausgegeben wird und nicht die gesamte Entwicklung wie zuvor, wenn die Funktion die Benutzer nicht erreicht hat.

Dadurch konnten wir folgende Vorteile erzielen:

• Autonomie von anderen Teams.
• Die maximale flexible Entwicklung können wir sicher Kurs ändern, wenn die Software es erfordert.
• Schnelle und einfache Problemlösung.
• Ein kurzer Test der Feature-Theorien.

Ich hoffe, dieses Beispiel hilft Ihnen bei der Lösung von Kommunikationsproblemen zwischen Teams. Wenn Sie andere coole Optionen haben, warte ich auf Feedback.

Vielen Dank.

Und wir werden bald ein Mitap für iOS-Entwickler haben.