So belasten Sie nicht das 10-Millionen-Budget Ihres Kunden, während Sie mit Agile spielen

In diesem Beitrag werde ich über die Probleme sprechen, mit denen unser Scrum Front End-Team während eines Jahres bei der Arbeit an einem anständigen Projekt konfrontiert war. Wir haben begonnen, das Projekt mit dem React + Typescript-Technologie-Stack von Grund auf neu zu entwickeln. Rückblickend sehe ich viele Millionen verschwendet, nur weil der Entwicklungsprozess nicht von Anfang an festgelegt wurde. Dafür gibt es aber Gründe.

Zuerst musste man die Ausschreibung gewinnen. Dazu musste schnell ein Produkt mit minimalem Wert eingereicht werden. Und hier liegt der erste Fehler, der für unseren Kunden einen anständigen Betrag gekostet hat. Es klingt so: schnell MVP zerschlagen. Der Kunde möchte das Ergebnis schnell sehen, aber dies bedeutet, dass wir auf eine gute Infrastruktur und eine zuverlässige Architektur verzichten und ein Jahr später zu dem Schluss kommen, dass unsere Front-End-Architektur ernsthaft überarbeitet werden muss. Über ein paar Monate. Also haben wir 500.000 Rubel durchgesickert.

Rückblickend kann ich mit Zuversicht sagen, dass als erstes alle Funktionen berücksichtigt werden mussten, die der Kunde am Ende nach einigen Jahren sehen wollte. So könnten wir Architekturfehler im Stil "Diese Architektur sieht dies nicht vor" vermeiden. Infolgedessen erforderte jeder Hauptchip ein ernsthaftes Refactoring.

Um die Ausschreibung zu gewinnen, schickte unser Unternehmen Entwickler, die keine Erfahrung mit der Entwicklung großer Anwendungen und zuverlässiger erweiterbarer Systeme hatten. Klares Geschäft, die Ausschreibung ist keine Bestellung, und niemand will gutes Personal streuen. Das Fehlen eines technischen Architekten auf (Klassenebene) führte jedoch dazu, dass unsere Anwendung in Spaghetti-Code umgewandelt wurde und die SOLID-Anforderungen nicht mehr erfüllte. Und hier liegt der Fehler jedes Kunden. Es ist nicht möglich, ein konstantes Entwicklungstempo aufrechtzuerhalten, ohne die Teamressourcen zu erhöhen. Das agile Prinzip „Investoren, Entwickler und Anwender sollten in der Lage sein, einen konstanten Rhythmus auf unbestimmte Zeit aufrechtzuerhalten“ funktioniert nur, wenn die Anforderungen von Anfang an bekannt und ausgearbeitet waren, der gesamte Funktionsumfang, eine zuverlässige und erweiterbare Architektur entworfen wurden (kurz gesagt, wenn jede Klasse unter Berücksichtigung des Finales durchdacht wurde Funktionalität des Systems) und klar definierte Prozesse. Und dies musste in MPV erfolgen, bevor das Produkt gesägt wurde. Andernfalls wächst mit der linearen Zeit die Komplexität der Anwendung exponentiell. Dies bedeutet, dass die Schnittfunktion in einem Jahr O (e (N)) teurer kostet als zu Beginn.

In unserem Team war der einzige Designer ein entfernter Mitarbeiter. Es war ein schwerer Fehler. Ein entfernter Mitarbeiter lebt immer sein eigenes Leben. Er zeichnet ein Design für sich, schön und gut, der Kunde ist glücklich. Aber all diese Reize laufen letztendlich darauf hinaus, dass wir auf denselben logischen Formen N verschiedene Stile und Layouts haben. Von Anfang an hat es sich gelohnt, eine Anforderung zu stellen: ein bestimmtes Framework zu stilisieren (wir hatten Ant Design). Wenn etwas nicht da ist, mach was da ist. Der Kunde hielt React für einen Blockkonstruktor. Und er versteht immer noch nicht, warum wir 4 Tage lang primitive Formen sägen. React ist ein Konstruktor, aber nur, wenn wir zu Beginn der Entwicklung eine Reihe ähnlicher wiederverwendbarer Komponenten (UI-Framework) haben. Ein Designer ohne Layouterfahrung wird dies niemals selbst tun. Der Entwickler wird dem Kunden niemals davon erzählen. Dies sollte vom Führer befolgt werden. Daher sollte der Leiter des Front-End-Teams in der Vergangenheit der Front-End-Entwickler sein und nicht wie immer das Back-End. Wir kommen daher zu dem Schluss, dass ein voll funktionsfähiges agiles Team in jedem seiner Arbeitsbereiche (FE, BE) einen kompetenten Leiter umfassen sollte. Diese Führungskräfte müssen über starke Soft Skills verfügen, um dem Kunden zu vermitteln, was ich in diesem Artikel beschreiben möchte. Und das ist sehr, sehr schwierig.

Als wir die erste Veröffentlichung veröffentlichten, stellten wir fest, dass am letzten Tag vor der Demo ständig etwas kaputt ging. Während des gesamten Entwicklungsjahres verwandelt sich jeder Release-Zweig in einen höllischen Satz von Krücken (ausschalten, entfernen), die dann auf magische Weise in den Entwicklungszweig gelangen. Und es gibt eine Reihe von Commits (einschalten, einschalten). Nach einem Jahr kamen wir zu dem Schluss, dass wir eine klare Verzweigungspolitik brauchen. Vor allem aber eine verantwortliche Person, die das bestehende Chaos beseitigen würde. Dies bedeutete: entweder die chaotischen Wünsche des Kunden zu mildern oder die chaotischen Fehler zu mildern oder an jedem Stand eine eigene Konfiguration zu haben, die irgendeine Art von Grafikfunktionen oder Schaltflächen deaktiviert. Es ist verrückt, jeden Knopf in eine if-Anweisung zu packen. Wir sind zu dem Schluss gekommen, dass wir eine Plug-in-modulare Front-End-Architektur benötigen (deaktivieren - aktivieren). Ich habe lange darüber nachgedacht, wie man eine solche Architektur erreicht. Aber eines habe ich sicher verstanden. Wir brauchten einen vollständigen Kontext. So wurde die js-bean-Bibliothek geboren (https://www.npmjs.com/package/js-beans). Jeder Stand hatte seinen eigenen json-Kontext. Plug-Ins wurden in einer Kette (Kette) durch das Proxy-Muster gesammelt. So hatten wir zum Beispiel eine Datenquelle als separate Bin, und verschiedene Transformationen wurden als optionale Proxy-Bins durchgeführt, die diese Bin ersetzten, aber in sich selbst injizierten. Wenn Sie beispielsweise das Datenmodell zum Testen der FPS-Leistung skalieren müssen, füge ich einfach die Zeile hinzu, um das Skalierungs-Plugin in der JSON-Datei zu aktivieren. Bei der Produktion ist etwas kaputt gegangen, aber es wird nicht lokal abgespielt. Ich schalte den Logger mit einer Zeile ein, ohne den Stand neu aufzubauen (der Stand dauert etwa 20 Minuten, und ein Dutzend Stände reichen nicht immer für alle aus). Oder wenn Sie ein Modul schnell ausschalten müssen, weil es beschädigt werden kann (deaktivieren Sie die optionale Bean im Kontext).

Mit der Zeit wurden die Stände für eine Woche ausgeschaltet. Es war unmöglich, die Front vor Ort zu entwickeln. Wir haben keine autonome Architektur auf den Mokas vorgesehen. Ich musste es mit einem Knarren durch den Schmerz schlagen. Wenn ich jetzt zurückblicke, hätte ich es ganz am Anfang getan. Aber wir hatten MVP und mussten Code ohne tiefgreifendes Engineering schreiben. Aber der Kunde betrachtete uns als Profis und meinte, wir sollten sofort fehlerfreien Code schreiben. Hier ist der folgende Fehler. Der Name des Unternehmens spricht nicht für die Professionalität des Teams. Die Professionalität des Teams wird durch die Professionalität des Teamleiters bestimmt. Wenn es keinen technischen Leiter im Team gibt, wird Ihr Projekt in einem Jahr zum Stillstand kommen. Sie verschmelzen also noch ein paar Millionen.

Wir hatten einen entfernten Architekten. Aber nur eines war über ihn bekannt: Er ist es. Die letzte Entwicklungsstufe des Führers nach Vladimir Tarasov. Damit hat unser Architekt Perfektion erreicht. Fehlernummer N: Sie haben keinen technischen Architekten, der das System auf Klassenebene entwirft. Sie haben keine Person, die um Hilfe bittet, wenn Sie im Stillstand sind. Bitten Sie andere erfahrene Teams um Hilfe, teilte uns der Kunde mit. Aber aus irgendeinem Grund hatten die anderen Teams nie Zeit, uns zu helfen. Unsere PR hängt seit dem zweiten Monat. Ich hoffe aufrichtig, dass es einen tapferen Mann gibt, der ihn genehmigt. Infolgedessen hat das Leben unseren Code mit einer Fülle von paranormalen Phänomenen in Form von Magie und Krückensätzen für alle Gelegenheiten belohnt. Nur einer fehlte. Spezielle Anmerkungen Magic und @Kostyle. Gute Idee für die nächste ES.

Wir haben entschieden, dass mehr Mitten und weniger Männer für das Projekt rentabler sind. Jetzt denken wir anders. Wenn Sie ein kleines Budget haben, müssen Sie die teuersten Spezialisten einstellen. Wenn Sie wie wir keine Budgetprobleme haben, können Sie sicher bei Spezialisten sparen und Code Review in einen Kampf der Hellseher verwandeln.

Wir dachten, wir würden die vierteljährlichen Fristen einhalten. Jetzt denken wir anders. Kurz gesagt, für immer müssen wir das Projekt neu schreiben. Und vorzugsweise von Grund auf neu. Ich hoffe, unser Kunde wird nie davon erfahren. Immerhin hatten wir erst kürzlich ein großartiges Teambuilding.

Wir haben uns entschlossen, mit neuen Technologien herumzuspielen, für die wir wenig Fachwissen hatten. Sie wurden uns empfohlen. Natürlich wollten wir Erfahrungen sammeln. Jetzt denke ich, dass es besser wäre, nur die Technologien zu verwenden, mit denen ich Erfahrung habe.

Wir haben Schätzungen basierend auf einem 8-Stunden-Arbeitstag gegeben. In der Realität sollten Schätzungen auf der Grundlage eines 4-Stunden-Arbeitstages erfolgen. Warum schließt niemand Tee ein, erzählt interessante Geschichten, findet eine Toilette im Navigator, telefoniert, korrespondiert, studiert neue Technologien und vor allem begeisterte Streitigkeiten innerhalb des Teams. Letzteres ist wahrscheinlich das unvermeidlichste und teuerste. Um ehrlich zu sein, müssen Sie für Open Space noch ein paar Stunden werfen. Ständiges Sprechen reduziert die Konzentration schrecklich. Gesegnet ist der Kunde, der das alles versteht!

Unsere Schätzungen waren anstrengend und wurden ohnehin zu einer langwierigen technischen Polemik. Die Effektivität der Rallyes war minimal. Aber wir haben eine Lösung gefunden: leckere Pizza. Wenn ein köstlicher Geruch die Nase reizt, beginnt eine Person, ihre Gedanken klarer auszudrücken.

Am Anfang hatten wir ein kleines Team, dann ein großes Team. Die Planung dauerte 2-3 Stunden. 30 Minuten aufstehen. Was ich unsere Bestellung respektiere, liegt daran, dass er beschlossen hat, sie in viele kleine zu unterteilen und jeder von ihnen seine eigene Mini-Bestellung zuzuweisen. Dies war wahrscheinlich die beste Entscheidung in der Geschichte unseres Projekts.

Wir hatten von Anfang an keine Zeit, Tests zu schreiben. Nach einem halben Jahr kamen wir zu dem Schluss, dass sie noch geschrieben werden mussten. Dafür finden wir aber noch keine Zeit. Technische Schulden mit viel höherer Priorität haben sich angesammelt. Sparen Sie keine technischen Schulden - das ist Utopie. Er wird es immer sein.

Meine persönlichen subjektiven Schlussfolgerungen:

• Wenn Ihre Entwickler nicht verstehen, wofür IOC für FrontEnd gedacht ist, ist es höchstwahrscheinlich zu spät, wenn sie verstehen.
• Wenn Ihre Entwickler nicht verstehen, warum FrontEnd Kenntnisse über OOP benötigt, kann Ihr Code kaum unterstützt werden.
• Weniger teure Spezialisten sind besser als rentablere.
• Wenn Sie einen Architekten haben, brauchen Sie höchstwahrscheinlich noch einen.
• Wenn Sie MVP sägen, beenden Sie es und ändern Sie das Projekt.
• Wenn MVP bereits vor Ihnen aufgezeichnet wurde, gehen Sie nicht zu diesem Projekt.
• Wenn Sie MVP verletzen und nicht gehen möchten, werden Sie höchstwahrscheinlich Ihre Meinung ändern.
• Wenn Sie zapilili MVP verwenden und möchten, dass Ihr Projekt überlebt, schreiben Sie es von Grund auf neu.
• Wenn Sie diesen Artikel einem Kunden zeigen, werden Sie höchstwahrscheinlich entlassen.
• Wenn Sie an Agile arbeiten, verstehen Sie mich höchstwahrscheinlich.

Es ist unwahrscheinlich, dass Sie all diese Probleme auch nach dem Lesen dieses Artikels vermeiden. Mein Ziel ist es, Ihnen zu zeigen, dass dies unvermeidlich ist. Und egal wie sehr Sie es versuchen, Sie werden niemals ideale Bedingungen haben. Also sei einfach darauf vorbereitet. Und vor der Entlassung können Sie Ihren Kunden diesen Artikel sicher zeigen. Lass ihn moralisch dazu bereit sein.

PS: Maxim, wenn Sie diesen Artikel jemals gelesen haben, wissen Sie, dass alles, was ich beschrieben habe, völlig fiktiv ist und nichts mit unserem Projekt zu tun hat. Aber das alles ist nicht wichtig, weil ich heute in den Urlaub fahre. Der erste Urlaub in einem Jahr mühsamer unregelmäßiger Arbeit! (als FE führen).