Dunkle Seite agil

Der aufmerksame Leser blättert durch das Band und stellt die Frage: „Was ist wieder der Text über Agilität?“. Ja.

In diesem Artikel geht es um Prozesse, technische Aspekte und ein wenig darüber, wie agil in Yandex.Money gelebt und implementiert wird. Wenn Sie mindestens den halben Weg zu wirklich Agilität zurückgelegt haben, scheinen Ihnen einige Dinge offensichtlich zu sein, und das ist in Ordnung.

Unter einer Katze über Prüfstände, das Einschließen von Personen in Besprechungsräumen und das Verwalten einer Abteilung, wenn sich alle in den Teams verteilten und das Leben genossen.

Und ein aufmerksamer Leser wird fragen: "Warum die dunkle Seite? Was ist mit Darth Vader?" Leider, nein, wir werden über die dunkle Seite des Mondes sprechen, die der Menschheit unbekannt war, bis das Gerät eingeflogen ist, um es zu fotografieren und allen zu zeigen.

Wenn Sie agil implementieren, entwerfen Sie ein Monderkundungsprojekt, ohne es zu wissen
Was ist auf der anderen Seite

Alles beginnt mit dem Versuch, neue Entwicklungsprozesse einzuführen.

Scrum, Kanban, Scrambana oder ein anderes lokales Fahrrad sind nicht so wichtig.

Klassische Entwicklungsabteilungen werden normalerweise von einem Ressourcenmanager geleitet. Er sagt zur Außenwelt: "Geh nicht zu den Entwicklern, geh zu mir, ich werde jetzt alles hier verteilen." Sobald ein solcher Manager zum ersten Mal einen Stream zuweist, ist ein spezieller Kunde erschienen. Dann gibt es mehr solche Kunden innerhalb und außerhalb des Unternehmens, Konflikte beginnen, der Kampf um Ressourcen und der Manager muss alles lösen. Auch durch Thread-Zuordnung.

Java - links, JavaScript - rechts

Dieses Spiel setzt sich bis zu einem kritischen Punkt fort, wonach das Unternehmen die Idee akzeptiert, dass jetzt genau agil benötigt wird. Produktteams werden angezeigt, da es für PO nichts Wertvolleres gibt als eine dedizierte Ressource und Ihr eigenes Team. Das Produkt ist glücklich, weil das Live-Team es einfacher macht, für die Funktionalität zu antworten und die Verantwortung für PNL, Verkehr und andere KPIs zu tragen.

Es klingt richtig, aber im wirklichen Leben ist alles ein bisschen falsch.

In den meisten klassischen Entwicklungsabteilungen ist es rentabler, mit einem Monolithen zu arbeiten. In diesem Fall werden alle Attribute angehängt - Freigabezyklus in 3-4 Wochen, lange Tests und Montage.

Manchmal ist ein Monolith normal

Aber die ausgewählten Teams arbeiten nicht so. Im Allgemeinen kam die Welt zu Microservices, weil jeder anfing, zu kleinen Teams zu wechseln und in ihnen zu arbeiten. Ja, dies führt dazu, dass sich der Code "ausbreitet" und alles schwieriger zu kontrollieren ist.

Auf der anderen Seite beschleunigen wir die Veröffentlichung des Produkts, führen häufiger Veröffentlichungen ein, stoßen jedoch auf Probleme beim Testen. Und sie müssen auch irgendwie gelöst werden.

Reform testen

Wenn Sie ein Team und einen Prüfstand haben - alles ist in Ordnung, können Sie sich keine Sorgen machen (oder sich Sorgen machen, aber aus einem anderen Grund). In solchen Fällen wird es oft nicht einmal als kritisch angesehen - zum Beispiel als zusätzliches Tool wie E-Mail oder Unternehmenschat. Jeder überwacht die Produktion genau und es geht ihnen auch gut.

Wenn Sie bereits zum Edgile Moon geflogen sind, verlangsamt der Prüfstand den gesamten Prozess, und deshalb.

Lebensgeschichte : In einem Unternehmen begann die Entropie um Agilität zu schnell zu wachsen. Zu diesem Zeitpunkt betraten die Tester den Zeitplan des einzigen Prüfstands im Kalender - sie teilten die Zeit in halbstündige Slots auf und versuchten, das Chaos irgendwie zu kontrollieren.

Tatsächlich sollten 20 Teams den Stand benutzen, aber sie können nicht, weil einer von ihnen alles kaputt gemacht hat

Über Prüfstände

Es war einmal, wir hatten mehrere Monolithen, jeder mit einem Prüfstand, und alle waren glücklich. Nachdem wir ein komplexes Projekt zur Trennung von Ständen erstellt hatten, teilten wir Teams zu, und dann gab es 20 Stände.

Jetzt gibt es 70 von ihnen, aber wir streben 200 an - damit jeder, kostenlos, und niemand beleidigt wird.

Aus dem Dialog mit dem Administrator:
- Sagen Sie mir, wo ist die Bereitstellungsautomatisierung?
- Die Berechnung alle zwei Wochen dauert eine Stunde. Was soll ich hier automatisieren?

In der Tat: (200 Stände + Produktion) * (50+ Komponenten) = Viel Aufwand bei der Bereitstellung.
Jetzt haben wir mehr als 50 Komponenten, die der Roboter ausrollt. Wenn er nicht wäre, wären alle schlecht.

Zu diesem Zeitpunkt wird das auf Agilität ausgerichtete Unternehmen über automatisierte Systeme für die Montage und Lieferung an die Produktion verfügen, die Teamarbeit wird schrittweise verbessert und die Leistung wird ebenfalls gesteigert - bis zu 60-80 Releases pro Woche, und jede Komponente wird 2-3 Mal pro Tag veröffentlicht .

An diesem Punkt versteht jeder, dass das System zu groß geworden ist, als dass eine Person es verstehen könnte

In jedem Team, das den Monolithen unterstützt, gibt es sicher ein paar Oldtimer. Sie waren von Anfang an hier und erinnern sich an alle Fehler aller Zeiten, an die seltsamen logischen Entscheidungen, die das Unternehmen verkaufte.

Lebensgeschichte:
"Im Allgemeinen ist es normal, dreimal zu versuchen, an einen Kunden zu klopfen, aber dieser Kunde ist etwas Besonderes. Wir werden 100 Mal anklopfen, es gibt einen Korrekturfaktor, und wir müssen ihn nicht berühren, bitte berühren Sie ihn, es ist nicht einfach so."

Für die Instandhaltung der Stände werden so viele Ressourcen aufgewendet, dass der Betrieb „golden“ wird - multiplizieren Sie die gesamte Farm mit der Anzahl der Prüfstände, erhöhen Sie die Produktion, ärgern Sie sich und rufen Sie schließlich Administratoren an.

Andere Überwachung

Admins werden kommen und sagen: "Alles wird durch Überwachung bei uns abgedeckt". Dies ist in Ordnung, aber mit einer Klarstellung - Überwachung wäre schön, benutzerdefiniert zu sein.

"Iron" -Metriken, die von Java verbrauchte Speichermenge, die Temperatur aller Kerne aller Prozessoren - all dies ist nützlich, hilft aber nicht immer bei Vorfällen mit Kunden. Geschäftsmetriken sind auch ahnungslos, wenn Sie sie nicht benutzerdefiniert haben. Die Welt ist komplex - es kommt selten vor, dass alle idealen Clients Ihre ideale API ideal verwenden. Die Leute machen alles und jeder muss sich anpassen - manchmal sind Kunden für Sie, manchmal sind Sie für Kunden.

Wie ein Kernkraftwerk

Lebensgeschichte : Lange Zeit haben wir einen Fehler in unseren Produkten gesucht und behoben. Danach hat einer der Clients mehrere Prozesse unterbrochen, bei denen dieser Fehler berücksichtigt wurde.

In solchen Momenten müssen Sie eine benutzerdefinierte Überwachung hinzufügen, da dies ohne Isolieren von Ausnahmesituationen und Aggregation einfach nicht funktioniert. Daher sprechen und schreiben sie übrigens oft über maschinelles Lernen und komplexe Systeme, die Probleme anstelle von Menschen definieren.

Einmal alle sechs Monate müssen Sie Überwachungsprüfungen durchführen, da die Geschäftserwartungen mit der Zeit steigen. Es passiert so - alles wird im Unternehmen aufgebaut und kontrolliert, und das Geschäft bringt einen neuen Kunden, der eine viel höhere SLA benötigt. Und die ganze Geschichte ist vorbei.

Wenn dies überwunden ist, funktioniert das System in allen Fällen recht gut, mit Ausnahme von "Dach" -Projekten.

Dachprojekte

Dies ist zum Beispiel die Einführung von 54-FZ, wenn der Staat sagt: "Und alle Bargeldprozesse im Land umstrukturieren." Oder wenn das Marketing für das Projekt bezahlt hat, musste das Produkt immer noch funktionieren, und die Frist war real, und dann haben sie es dafür gedreht. Oder wenn jemand vom Top-Management gerade hereinkommt, spielt es keine Rolle, aus welchem ​​Grund, und er hat auch ein Projekt mit einer Frist.

Spoiler - nur wenige Leute auf dem Markt verstehen, wie man sie herstellt. Sie können verschiedene Add-Ons über Scrum und Kanban kaufen, Sie können Erfolgsgeschichten lesen, aber die Praxis zeigt, dass es theoretisch teurer ist, solche Projekte durchzuführen. Darüber hinaus sind alle diese SAFE und LEAN administrativ und ressourcenschonend teuer und erfordern auch teure und komplexe Kompetenzen, die nicht auf dem Markt sind.

Lebensgeschichte: Spotify ist eines der beispielhaften agilen Unternehmen. Irgendwann kamen sie auf ein Familienabonnement, konnten es aber aufgrund der Schwierigkeiten bei der Synchronisierung und Planung zwischen Teams, die ihre eigene Roadmap und Pläne haben, nicht realisieren. Ein Jahr später haben Google und Apple das Familienabonnement eingeführt.

Synchronisations- und Planungskonflikte

Das Hauptproblem bei Dachprojekten ist die Synchronisation aller teilnehmenden Teams. Es hängt damit zusammen, dass die Leute nicht gerne verhandeln.

Dies äußert sich in vielen Dingen, beginnend mit Scrum, wenn sich die Mitarbeiter nicht im Rahmen einer Ressourcenabteilung einigen können. In Agile müssen Sie alles synchronisieren und koordinieren, was mit mehreren Teams passiert. Und wenn Sie irgendwann aufhören, alle zur Zusammenarbeit zu verpflichten, kehrt jedes Team in seine dunkle Lieblingsecke zurück und arbeitet unabhängig. Dies führt zum Ausfall.


Life Hack
Wenn noch zwei Monate bis zum nächsten Gesetz oder vor der Werbekampagne verbleiben oder der Chef dies verlangt - nehmen Sie Leute aus 4 Teams, sperren Sie sie in einen Raum, geben Sie Essen und Wasser und kontrollieren Sie sie. Das ist unhöflich, aber es funktioniert. Denn wenn Sie versuchen, für eine begrenzte Zeit eine Synchronisierung durchzuführen, schlagen Sie das Projekt fehl.

Im Allgemeinen ist eine Synchronisierung erforderlich, und ohne diese können Sie nicht fortfahren. Dies verkompliziert das Leben in Projekten mit einer klaren Frist und einer hohen Kritikalität - die Fristen liegen zwischen 10% und 50%, was häufig nicht akzeptabel ist.

Wie geht das?

Der klassische Leiter der verteilten Abteilung versteht seine Rolle nicht, weil ihm das Paradigma "Ich habe Aufgaben an alle vergeben" beigebracht wurde und ich mit "Ich habe überhaupt keine Leute, warum bin ich im Unternehmen?" Arbeiten muss.



Das Schlimmste ist für Kontrollfreaks, die keine einzige Aufgabe verpassen, die die Abteilung löst, doppelte Überprüfungen des öffentlichen Codes arrangieren und buchstäblich alles kontrollieren. Wenn Leute in Teams aufgeteilt werden, stellen sie die Frage: „Warum bin ich hier?“. Die Antwort lautet, dass die Entwickler in allen Teams Informationen austauschen, synchron in eine Richtung wachsen und das System nicht crawlt.

Wenn eine solche Frage gestellt wird, muss der Leiter im Allgemeinen entweder geändert oder unterrichtet werden.

Unterrichten, weil viele Führungskräfte (einschließlich uns) aus Ingenieuren hervorgehen und niemand ihnen jemals Soft Skills beigebracht hat. Wir glauben, dass dies wichtig ist, und kamen einmal zu HR und baten um einen großen zweijährigen Kurs für Manager - von den Grundlagen über Leistung bis hin zu nichtfinanzieller Motivation.

Kultur in der IT

Es gibt noch einen weiteren subtilen Punkt in Bezug auf Agilität bei der Organisation von Teams. Wenn sich Entwickler auf etwas im Team einigen, können sie beginnen, die Interessen des Teams zu verteidigen, wobei sie die Interessen des Unternehmens vergessen.



Idealerweise, wenn die Leute verstehen, dass sich um ihren Ajail-Mond jemand anderes befindet - ein Sicherheitsdienst mit eigenen Anforderungen; Architektur, die nicht nur erfunden wurde; andere Teams, deren Interessen berücksichtigt werden müssen. Wir bemühen uns, ein solches Verhalten zu identifizieren, zu fördern und zu fördern.

Agile - Spitze des Eisbergs

Dieser Weg hat wichtige Eigenschaften.
Eine lange Zeit. Zum Beispiel ist DevOps vor fünf Jahren auf den Markt gekommen, und seine Implementierung wird nun je nach Unternehmensgröße 1-2 Jahre kosten. Wenn Sie anfangen, sich damit zu befassen, wenn Sie Linien an den Prüfständen haben, dann sind Ihnen sechs Monate Hölle garantiert, weil Administratoren zwischen allem hin und her gerissen werden.

Teuer Sie können agil implementieren und diesen Weg nur beschreiten, wenn Sie ein starkes Geschäft und ein starkes Unternehmen haben und Sie verstehen, dass Sie in Zukunft noch wachsen müssen.

Es gibt keine Leute. Agile braucht neue Kompetenzen, die Menschen nicht so viele haben. Es stellt sich ein Teufelskreis heraus - es gibt keine Menschen -> alles läuft nicht sehr gut -> es gibt kein Geld -> es gibt keinen Ort, an den man Menschen nehmen kann.

Drei Schlussfolgerungen

1. Berühren Sie die "klassischen" Entwicklungsabteilungen nicht ohne Notwendigkeit. Ein Hybridsystem funktioniert in Yandex.Money - es gibt ein Produktteam, aber es gibt Abteilungen, die effektiv ohne Agilität arbeiten können.
   
2. Wenn Sie nicht die Aufgabe haben, das gesamte Unternehmen wieder aufzubauen, sondern den Wunsch oder die Notwendigkeit haben, ein neues Produkt mit neuen Ansätzen schneller zu machen, ist es manchmal einfacher, Outsourcer einzustellen, die agil arbeiten und dem Produkt eine externe Ressource zur Verfügung stellen.
   
3. Wenn eine IT-Transformation unvermeidlich ist, ist es am besten, sich auf alles „an Land“ zu einigen. Es lohnt sich, mit der Führung eine Art "Gentleman-Vereinbarung" abzuschließen - dass es ein Budget für Hardware und Mitarbeiter gibt (für neue Positionen für Systemadministratoren, Tester und Entwickler). In diesem Fall ist es möglich, regelmäßig zu dieser Vereinbarung zurückzukehren und zu besprechen, was und wie getan wurde.
   

All dies hat ein Problem. Geh den ganzen Weg! = Komm zum Erfolg. Nicht bestehen = garantiert scheitern.

Aber wenn Sie unterwegs sind - viel Glück!