Wie kann man aufhören, schnell Eier zu fangen und gleichzeitig die Fristen fallen zu lassen? Welche Toolchain soll ausgewählt werden, um mehrere Aufgaben gleichzeitig zu zerstören? Wir werden dies alles in unserem Artikel offenbaren.

Ich versuche alle Eier zu fangen

In jenen Tagen, als unser Unternehmen gerade im sonnenverwöhnten Glasleib des Büros auftauchte und das Team nur drei Leute (einen Manager und zwei Entwickler) hatte, die begeistert und kaffeereich waren, hatten wir absolut keine Projektmanagementmethode und handelten ahnungsvoll. Annäherung an die Arbeit nach dem Prinzip „eine Person - ein Projekt“. Gleichzeitig ging es nicht einmal darum, dass die Entwickler, die innerhalb derselben Aufgabe interagierten, separate Codeteile untereinander hatten und die gesamte Landschaft der Entwicklungsumgebung auf der Maschine des Entwicklers hing. Als Repository und Versionskontrollsystem verwendeten wir dann SVN , das zu dieser Zeit eher einem Ordner mit Zip-Archivierern ähnelte. Trotz der Tatsache, dass SVN eines der größten Versionskontrollsysteme ist und über eine entsprechende Community verfügt, hat sich seine Funktionalität nur hinsichtlich der Erhaltung des Codes für uns bewährt, ansonsten war alles etwas schlecht: Es gab keine lokale Version und die Möglichkeit, den Code zusammenzuführen. Deshalb suchten wir nach etwas, das besser zu unserem Appetit passt - die Entwicklung des Arbeitsprozesses begann. Das erste, was angegangen werden musste, war die Planung und Festlegung von Aufgaben sowie deren Verteilung relativ zueinander, um von der Monoprojektivität zur gemeinsamen Entwicklung und Einhaltung von Fristen zu gelangen. Zu dieser Zeit war die einzige Art der Planung das Treffen mit Notizbüchern. Mit diesem Ansatz gelang es jemandem, vor der Effizienz und Effizienz wie dem Mond auf dem Kosaken alles zu notieren, jemand vergaß oder vergaß. Infolgedessen verließen die Teilnehmer das Meeting ohne ein klares Verständnis dafür, was und wie zu tun ist, mit einer Reihe von Informationen im Kopf und ein paar Kritzeleien in einem Notizbuch.

Wir wählen eine Toolchain aus

Der erste Schritt zur Reduzierung der Entropie des Workflows bestand darin, ein normales Repository für die Zusammenarbeit an Projekten und die Verbindung der einzelnen Teile des Codes zu erstellen. Wir haben eine alte SVN rausgeschmissen und GIT auf der lokalen Maschine unseres CEO erhöht. Zum Anzeigen und Verbinden des Codes wurden einfache Konsolendienstprogramme verwendet. Es war nicht sehr praktisch, aber es erlaubte zumindest, die Ordnung und Transparenz der Änderungen im Projekt aufrechtzuerhalten.

Wir hatten immer noch Probleme mit der Planung und hielten daher die Fristen ein. Dazu musste ein Mittel gefunden werden, um Aufgaben zu zerlegen und den Status ihrer Implementierung anzuzeigen. Ein Versuch, dieses Problem zu beheben, war die Verwendung der RedMine-Projektmanagementanwendung, mit der das aktive Benchmarking der Toolchain begann. Das Dienstprogramm war gut für Entwickler geeignet (Projektmanagementfunktionen, Foren, Fehlerverfolgung), aber leider war es für Manager sehr schwierig. Entwickler mussten ständig alle Informationen (Merzhrekvesta, Pullrekvesta usw.) aus dem SUV verarbeiten und in das RedMine- Programm eingeben , damit die Manager den Grad der Fertigstellung der Aufgabe verfolgen konnten. Darüber hinaus gab es nicht genügend zusätzliche Projektmanagementfunktionen, sodass wir einen Blick auf FengOffice werfen konnten .

Das Tool verfügte über ein ziemlich breites Funktionsspektrum, sodass man sich das Thema der Kombination von Kommunikations- und Planungswerkzeugen wie einem Gantt-Diagramm in einem einzigen Arbeitssystem ausdenken konnte. Bei allen Geräten dieses Produkts mussten die Entwickler die Aufgaben jedoch manuell schließen und gleichzeitig selbst Statistiken erstellen, da keine automatische Synchronisierung der ausgeführten Aufgaben erfolgte. Darüber hinaus ähnelte die Implementierung des internen Chats eher einer ähnlichen alten Version von ICQ als einem normalen Unternehmenschat, aber für uns war dieser Moment sehr wichtig.

Wir haben verstanden, dass einfache Besprechungen eindeutig nicht ausreichen, damit der gesamte Mechanismus harmonisch funktioniert. Es mussten operative Tools ausgewählt werden, um kurze Kommunikationen herzustellen, die selbst für Personen erforderlich waren, die nebeneinander im selben Raum saßen. Hier treten zwei Punkte auf: der erste - wenn Sie kurze Gespräche im üblichen Format führen, nimmt diese zu viel Arbeitszeit in Anspruch, was den Zusammenbruch aller Fristen und eine erhebliche Verzögerung des Zeitplans begrüßen würde, und der zweite - wenn Sie ein Minimum an kurzen Interaktionen durchführen, führt dies zu Verlusten Enge Kommunikation zwischen Teammitgliedern, Inkonsistenz ihrer Aktionen, Codeduplizierung und andere Probleme. Aus diesem Grund haben wir eine einfache Lösung gefunden: Mikro-Meetings in einen Team-Chat zu übertragen, mit dem Sie ohne starke Ablenkung vom Workflow ständig kommunizieren, die Aktionen der Entwickler koordinieren und die wiederholte Ausführung derselben Aufgaben sowie Streitigkeiten darüber vermeiden können, wer die Aufgabe besser ausgeführt hat. Die Lösung mag offensichtlich und trivial erscheinen, aber es geht nicht um die Art der Interaktion, sondern um den Ansatz und die Qualität der Verwendung des Tools. Die Frage war, wie der Chat von einem Ort zum Überfluten und Brennen in einen teilweisen Ersatz für Besprechungen und persönliche Gespräche verwandelt werden kann.

In der Zwischenzeit reichte das übliche GIT nicht aus, es fehlte stark an einem Webinterface. Wir hatten zwei Optionen im Menü: ein privates Repository auf GitHub und ein Repository auf GitLab. GitLab ist kostenlos - und sie haben es genommen. Er hat auch eine coole, freundliche Community. Darüber hinaus verfügte GitLab bereits über ein integriertes Taskplanungssystem und bot eine praktische Schnittstelle für merzhrekvest. Wenn Sie als Team gearbeitet haben, wissen Sie wahrscheinlich, wie wichtig es ist, schnell eine genehmigte Merzhrekvest zu erhalten. Letztendlich haben wir FengOffice begraben und uns für GitLab entschieden. Darüber hinaus haben wir Slack zu diesem Zeitpunkt bereits als Team-Chat verwendet. Angesichts der Tatsache, dass GitLab die gegenseitige Integration mit Slack geplant hat und all diese Dinge auch kostenlos waren, wurde die Wahl für uns offensichtlicher als je zuvor.

Bücher haben nicht gelogen

Dann kam der Moment, in dem es notwendig war, die am besten geeignete Methodik für unser flexibles Projektmanagement auszuwählen. Wir haben uns für zwei der am weitesten entwickelten und beliebtesten Ansätze entschieden: Kanban und Scrum. Die Initiative kam vollständig von unserem CEO, Ilya Bykoni, der mit Prometheus-Feuer in den Augen mit dem Team über die bevorstehenden Änderungen sprach. Zu seiner großen Überraschung traf das Team zunächst auf Innovationen, als die Spartaner Xerxes mit heftiger Sturheit konservativer Kopien begegneten. Was können Sie tun, Illusionen, Illusionen, denn in den Büchern wurde gewarnt ... Eine interessante Tatsache wurde sofort bemerkt, dass eine negative Einstellung zu neuen Ansätzen nicht mit der Angemessenheit und Fähigkeit der Menschen zur Arbeit korreliert. Sogar die jungen Junes, die das alles leicht aufgreifen sollten, widersetzten sich und argumentierten: "Sie sollten besser 15 Minuten programmieren, als diese Zeit am nächsten Tag zu verbringen." "Warum müssen Sie planen, wenn die Fristen sowieso sind? werden nicht ausgeführt oder werden ausgeführt, sondern mit Abweichungen “,„ Warum sollte der Frontend-Entwickler auf das Backend hören “usw. Tatsache ist, dass die Agile-Ansatz-Methodik einen Arbeitsstil impliziert, bei dem es unmöglich ist, auf den atlantischen Schultern eines starken Entwicklers zu sitzen und mit seinen Fähigkeiten zum Projekt zu gelangen, da viele Menschen daran gewöhnt sind, daran zu arbeiten, so dass solche Änderungen für sie werden schmerzhaft.


Als wir anfingen, Agile in die Arbeit einzuführen, haben wir den Wert einer kurzen und qualitativ hochwertigen Kommunikation voll und ganz gespürt. Es kommt häufig vor, dass Projektmanager keine Duplikate abfangen können, wenn ähnliche Aufgaben aus der Eingabe der RnD-Abteilung aus mehreren Quellen stammen. Und hier spielen kurzfristige Interaktionen und tägliche Rallyes, die vollständig vor solchen Problemen schützen, eine sehr wichtige Rolle, indem sie Gemeinsamkeiten zwischen Entwicklern verschiedener Teams identifizieren. Es gibt noch einen weiteren interessanten Punkt: Die meisten Programmierer sind introvertiert, dh jede Kommunikation ist mit Mikrostress verbunden, insbesondere bei Rallyes in großen Teams, bei denen eine Person mit einem breiten Publikum verschiedener Spezialisten sprechen muss. Und viele Menschen, die Angst vor solchen Beschwerden haben, erkennen nicht, dass die Alternative für solch kurze Besprechungen noch unangenehmer sein kann als die tägliche. Dies wird durch ständige Kommunikation im Laufe des Tages ersetzt, um die Arbeit in einen kontrollierten Prozess zu bringen. Wir sind zu dem Schluss gekommen, dass Agile die Introversion der Entwickler berücksichtigt und die mit der Notwendigkeit der Kommunikation verbundenen Unannehmlichkeiten auf ein Minimum reduziert. Für die jungen Mitarbeiter des Unternehmens wird dies natürlich auf jeden Fall einige Zeit stressig sein, bis er sich mit den Besonderheiten seiner Arbeit befasst und das Team genauer kennenlernt. Je freundlicher und effizienter die agile Kultur im Unternehmen ist, desto schneller endet der Anpassungsprozess.

Ein Stock tut weh, viele Stöcke sind tödlich

Eine der Hauptmotive eines flexiblen Ansatzes ist, dass sich die Menschen daran gewöhnen, ihre Fälschungen und Fehler zu minimieren. Tatsache ist, dass, wenn Sie die standardmäßige vertikale Managementstruktur verwenden, der Entwickler für seine Fehler gegenüber dem unmittelbaren Chef verantwortlich ist, der bestraft und „mit einem Stock auf den Kopf schlägt“, wenn der Mitarbeiter fälscht oder „den Kopf streichelt“, wenn alles klar gemacht wird. Das heißt, in der vertikalen Struktur hat eine Person die Möglichkeit, aufgrund persönlicher Beziehungen oder „leckerer Kekse“ abzuprallen. In Agile wird die Teaminteraktion horizontal aufgebaut, was bedeutet, dass eine Person bei täglichen Rallyes dem gesamten Team Bericht erstatten muss. Er hat einfach nicht genug Geld für so viele Kekse. Daher müssen Sie sich daran gewöhnen, dass Ihre Fehler von Ihren Kollegen überprüft werden. Entweder sind Sie auf einem Pferd und sie schütten Rosenblätter auf Sie, weil Sie professionell sind, oder Sie stehen unter einem Pferd. In jedem Fall ist dies ein starkes Aufpumpen der persönlichen Fähigkeiten einer Person Wenn die Atmosphäre im Unternehmen warm genug ist, beginnt sich die Person langsam zu öffnen und leistet einen zunehmenden Beitrag zum Ökosystem seiner Abteilung und des gesamten Unternehmens. Wir haben auch aus Erfahrung den Filtereffekt von Agile erlebt, der mehr als einmal mit einer Situation konfrontiert wurde, in der objektiv schwache Entwickler die ständige Analyse ihrer Fehler nicht ertragen können und letztendlich nur dann zusammengeführt werden, wenn sie feststellen, dass ihnen interne Motivation und Stärke fehlen um vom Bagodel-Status zum Bogacode-Status zu wechseln.

Zusammenfassend

Ich muss sagen, dass sich der Prozess der Einrichtung einer agilen Maschine als ziemlich langwierig und sehr stressig herausstellte: „Ohne Gewalt hätte es nicht gehen können“ - anfangs mussten die Menschen praktisch mit einem Stock zu Kundgebungen und täglichen Ereignissen gefahren werden, damit die Menschen irgendwie anfingen, ihre Position zu den Aufgaben auszudrücken, die sie lösten. Obwohl wir ständig „unter die Motorhaube klettern“ und am „Motor“ basteln müssen, um uns die Hände mit Heizöl schmutzig zu machen, lohnt es sich, wenn das Team schneller wird und vorwärts eilt und den Kontrollpunkt für den Kontrollpunkt sammelt. Wir stoppen unsere Entwicklung nicht einmal für eine Sekunde, wir sind immer im Status ewiger Spediteure, studieren ständig neue und modifizieren bestehende Modelle des Managements und der Interaktion zwischen Mitarbeitern. Eines verstehen wir absolut sicher - wo es keine Bewegung und keinen Kampf gibt, gibt es kein Leben. Wie die Zen-Mönche sagen: "Ich habe den Gipfel erreicht, setze den Aufstieg fort ..." Viel Glück für alle in deinen Aufstiegen und lass alle auf ihren Höhepunkt gehen, egal was passiert!

PS:

Hier ist eine Beispielliste und das Timing der Schritte, die wir durchlaufen haben:

1. Planungsbildung ~ 4 Monate
2. Arbeiten Sie mit kurzen Kommunikationen ~ 1 Monat
3. Suchen Sie nach einer geeigneten Toolchain und Workflow-Entwicklung ~ 2 Monate
4. Wahl der Methodik ~ 2 Monate
5. Einführung von Scrum in den Workflow ~ 8 Monate

Und hier eine kleine Auswahl unseres CEO:

1. Agile verstehen - Andrew Stellman und Jennifer Green
2. "Der Weg des Scrum-Meisters" - Zuzan Shokhov
3. "Scrum A Revolutionary Project Management Method" - Jeff Sutherland
4. "Kanban Alternative Way to Agile" - David Anderson
5. „An der Spitze der Transformation. Anwendung der Prinzipien von Agile und DevOps im gesamten Unternehmen "- Harry Gruver und Tommy Mauser