Bauprozesse von Grund auf neu: Vom Chaos zur Ordnung

In diesem Artikel werde ich über das Erstellen von Workflows in einer kleinen Webentwicklungsabteilung sprechen. Die Abteilung wurde von Grund auf neu gegründet und begann sofort mit der autonomen Arbeit. Daher mussten wir die Produktionsprozesse selbst aufbauen, auf alle Arten von Rechen treten und daraus die notwendigen Schlussfolgerungen ziehen. In der Hoffnung, dass dies jemandem hilft, Zeit, Geld und Nerven zu sparen, beschreibe ich die Probleme, mit denen wir konfrontiert sind, und unsere Möglichkeiten, sie zu lösen.

Es ist wichtig zu beachten, dass dies keine universelle Methodik ist, die in jedem Entwicklungsteam implementiert werden kann, und dass alles sofort wunderbar sein wird. Dies ist nur eine Mischung aus bekannten Techniken und praktischen Erfahrungen, die wir effektiv an unsere Entwicklungsmerkmale anpassen konnten. Es gibt keine einfache Lösung für dieses Problem. Sie müssen immer auf der Größe und Erfahrung des Teams selbst, den Merkmalen des Unternehmens, den Besonderheiten von Projekten usw. aufbauen.

Die ersten Daten unserer Abteilung: ein kleines (5-10 Personen), teilweise verteiltes Produktteam (einige Mitarbeiter arbeiten remote, andere im Büro) mit Kunden innerhalb des Unternehmens. Webprojekte. Es gibt keine Systemadministrationsspezialisten innerhalb der Abteilung, aber es gibt Abteilungen, die am Unternehmen beteiligt sind.

Teamkommunikation

Beginnen wir mit dem Aufbau einer effektiven Kommunikation innerhalb der Abteilung. In jedem Team ist es wichtig, effektive Kanäle und Kommunikationswege aufzubauen. Wenn das Team jedoch verteilt wird, verstärkt sich dieser Bedarf. Hier erreichte es seine maximale Schärfe, weil das Team nur teilweise verteilt war. Wir mussten lernen, die Welten der Büro- und Remote-Mitarbeiter zusammenzuführen.

Das wichtigste Problem, auf das wir gestoßen sind, sind mündliche Diskussionen. Büromitarbeiter haben immer die Versuchung, schnell eine Tasse Kaffee einzupacken und den Status des Projekts zu besprechen. In diesem Fall können die Remote-Mitarbeiter jedoch nicht an dieser Diskussion teilnehmen, daher können sie ihre Ideen nicht einbringen und wissen auch nicht, dass etwas passiert. Dies führt in der Regel zu einer Desynchronisation der Aktionen des Teams, wiederholten Diskussionen aufgrund der Entstehung neuer Gedanken und Vorschläge aus dem verteilten Teil des Teams und nur zu einem unangenehmen Nachgeschmack.

Es wurde klar, dass einige wichtige gemeinsame Dinge in allgemeinen Chats oder bei einigen Gruppenanrufen schriftlich besprochen werden sollten.

Dies führt zu einem weiteren sehr häufigen Problem, das in Teams auftritt, in denen Sie viel schreiben müssen - dem Problem der Schreibkultur. Sie können nicht einfach zu einem Kollegen gehen, am Ärmel ziehen, etwas auf eine Serviette zeichnen und Ihrer Geschichte Gesten hinzufügen. Dies erschwert einerseits die Arbeit und andererseits entwickeln die Menschen die Fähigkeit, ihre Gedanken verständlich und strukturiert zu schreiben. Infolge dieses Ansatzes wurde die Dokumentation besser formalisiert, die Aufgaben wurden klarer formuliert, alle begannen darüber nachzudenken, wie sie ihre Gedanken so präsentieren sollten, dass sie von der ersten Lesung an für andere verständlich waren.

All dies bedeutet nicht, dass wir die persönliche Kommunikation, Sprach- und Videoanrufe vollständig aufgegeben haben. Wir haben es uns jedoch zur Regel gemacht, dass die Ergebnisse solcher Diskussionen schriftlich festgehalten werden sollten, als eine Art Artefakt des Wissens, das immer jedem zur Verfügung steht.
Schauen Sie sich kurz die banale Liste der Tools an, mit denen wir unsere Kommunikationsaufgaben im Team gelöst haben.

Zuerst haben wir einen Chat über Telegramm gestartet. Aber dann, im Zusammenhang mit dem Wachstum des Teams, stellten wir fest, dass wir in einem Chat bereits in der Nähe waren und wechselten zu Slack. Dort haben wir den allgemeinen Ablauf in thematische Kanäle unterteilt und klare Regeln festgelegt - aus welchen Gründen auf welchen Kanal geschrieben werden soll. Dies trug dazu bei, nützliche Informationen und Überschwemmungen nicht zu vermischen.

Der Wechsel zu Slack bot uns außerdem einige gute Möglichkeiten zur Automatisierung und Integration mit anderen Diensten, z. B. einem Repository-Verwaltungssystem oder einem Bug-Tracker.

• Audio- und Videoanrufe - Skype for Business.
• Wir erledigen Aufgaben in Jira.
• Die Wissensdatenbank wird in Confluence gespeichert.

Aufgabenplanung, -ausführung und -steuerung

Als wir die Kommunikation aufbauten, wurde das Problem des Einstellens, Kontrollierens und Erledigens von Aufgaben innerhalb des Teams relevant (ich werde etwas später über die diesbezügliche Zusammenarbeit mit dem Kunden sprechen).
Wir hatten keine einzige Liste von Aufgaben, deren Prioritäten, Bereitschaftsstatus usw. Anstelle eines klaren, transparenten und nachvollziehbaren Plans war eine spontane kurzfristige Planung und Ausführung vorhanden.

Um mit dieser Situation fertig zu werden, haben wir begonnen, einen Bugtracker zu verwenden (tatsächlich haben wir fünf davon ausprobiert). Es zeigten sich Umrisse der allgemeinen Ausrichtung des Projekts, ein Verständnis des Zustands, in dem bestimmte Aufgaben und das Gesamtbild insgesamt auftraten. Wir waren jedoch mit dem Problem der mangelnden Disziplin bei der Verwendung des Bugtrackers konfrontiert, was viele unserer Bemühungen abwertete. Nicht alle Aufgaben wurden im Bugtracker gestartet, vorhandene wurden nicht immer aktualisiert usw. Einfach ausgedrückt, das Bild des Projektstatus ist nicht mehr relevant und zuverlässig.

Um dem entgegenzuwirken, haben wir unsere eigene Kultur des Aufgabenmanagements entwickelt und implementiert:

• Die Arbeit sollte erst ausgeführt werden, wenn die entsprechende Aufgabe gestartet wurde. Dies hilft, die Geschichte des Projekts und die Arbeit des Teams auf dem neuesten Stand zu halten.
• Wenn Sie mit einer Aufgabe arbeiten, müssen Sie ihren Status rechtzeitig ändern. In unserem Fall reichen vier Status aus: "Zu erledigen" - der Startstatus der Aufgabe, "In Bearbeitung" - die laufende Aufgabe, "In der Warteschleife" - die Aufgabe, die sie ausgeführt haben, aber die Arbeit wird ausgesetzt (wir warten auf einige zusätzliche Informationen ), "Fertig" - die Aufgabe ist fertig. Die Bereitschaft der Aufgabe muss irgendwie vom Kunden oder Manager im Team bestätigt werden.
• Im Laufe der Zeit hat die Anzahl der Aufgaben und Projekte erheblich zugenommen, daher haben wir die allgemeine Liste der Arbeiten in separate Teilprojekte unterteilt, und die Aufgabe sollte gemäß dieser Liste der Teilprojekte gestartet werden.
• Der Aufgabe muss Priorität zugewiesen werden. Dies hilft zu verstehen, welche Aufgaben in welcher Reihenfolge ausgeführt werden müssen, um den maximalen Nutzen für das Projekt zu erzielen.
• Regelmäßig überprüfte Aufgaben und ihre Prioritäten. Da Projekte leben und sich entwickeln und sich Geschäftspläne im Laufe der Zeit manchmal ändern, werden einige Aufgaben weniger oder relevanter oder müssen sogar entfernt werden.
• Einige wichtige Diskussionen zu Aufgaben, die mündlich oder schriftlich im Chat ausgeführt wurden, erfordern die Festlegung der endgültigen Lösung in der Aufgabe selbst, damit wir nach Abschluss immer die relevantesten Informationen über sie und ihren Verlauf sehen. Es kommt oft vor, dass die anfängliche Aussage des Problems nach einer Reihe von Diskussionen in etwas völlig anderes umgewandelt wird, und wir müssen dies überwachen.
• Wenn die Aufgabe von einer Gruppe von Spezialisten auf eine andere innerhalb des Teams übertragen wird, muss die übertragende Gruppe alle erforderlichen Wissensartefakte darin fixieren, die auf die nächste Gruppe übertragen werden müssen. Beispielsweise muss ein Designteam Modelle und die gesamte für die Entwicklung erforderliche Dokumentation beifügen, bevor die Aufgabe an das Entwicklungsteam übertragen wird. Dies vermeidet unnötige Fragen, Ablenkungen und Kontextwechsel.
• Anhängen von Commits an Aufgaben. Unter Verwendung einiger Regeln zum Benennen von Commits fügen wir automatisch Links zu Commits zu GitLab-Aufgaben hinzu. Dies hilft bei der Entwicklung sehr zu verstehen, wer, was, wie und wann diese Aufgabe erledigt hat. Und in der entgegengesetzten Richtung finden Sie durch korrekt benannte Commits immer eine Aufgabe, die den Grund für die vorgenommenen Änderungen enthält.

Kundenkommunikation

Die nächste Kategorie von Schwierigkeiten, die wir lösen mussten, war die Zusammenarbeit mit Kunden. Das erste, was wir ausrotten mussten, war, Wörter in Wörter zu setzen. Wenn wir die Kultur des Schreibens innerhalb der Abteilung eingeführt haben, ist es an der Zeit, sie auf externe Kontakte auszudehnen.

Es ist kein Geheimnis, dass sich ein anderer Manager gerne an den Entwickler wendet. Sagen Sie ihm in Worten, was zu tun ist, stecken Sie die Finger auf den Bildschirm, um zu überzeugen, und gehen Sie, in der Hoffnung, dass alles gut und pünktlich erledigt wird. In dieser Situation können der Manager und der Entwickler durch einen Product Owner und einen bestimmten Manager des Entwicklungsteams ersetzt werden, der alle diese Aufgaben leitet. Das Ergebnis wird sich nicht ändern.

Bei diesem Ansatz gibt es mehrere Probleme:

• Was in Worten und Gesten gesagt wird, wird (zumindest teilweise) über morgen, bestenfalls übermorgen, vergessen. Es geht nicht so sehr um einige kleine Dinge, sondern um die Gefahr, die Aufgabe völlig zu vergessen. Gleichzeitig ist es unmöglich zu bestätigen, dass Sie es jemandem geben oder dass Ihnen jemand versprochen hat, zumindest etwas zu tun.
• Normalerweise ist eine solche Aussage des Problems ziemlich chaotisch, und es gibt keine tiefen Details darin. Infolgedessen ist es sehr schwierig, die fehlenden Informationen zu klären.
• Wie bereits erwähnt, gibt die Erklärung des Problems in Worten der korrupten Zurückhaltung nach, zu lernen, ihre Gedanken schriftlich so zu formulieren, dass andere Menschen sie verstehen.

Wenn Sie viele Kunden haben und jeder seine eigenen Merkmale hat, ist es schwierig, mit jedem eine einzige Arbeitsreihenfolge aufzubauen. Im Idealfall möchten wir alle Kunden zu einem Bug-Tracker bringen, wo sie Aufgaben festlegen, Prioritäten festlegen, Details besprechen und Arbeiten annehmen können. Dies bleibt jedoch eine unmögliche Aufgabe. Wir konnten jedoch einen Kompromiss finden, bei dem die Aufgaben in einem streng schriftlichen Ablauf an unsere Unternehmenspostabteilung zusammenfließen, und unsererseits startet und führt der Manager sie im Bug-Tracker gemäß den in unserem Land bereits festgelegten Regeln weiter. Aufgaben gingen nicht mehr verloren, wurden vergessen, in den Köpfen bestimmter Personen gespeichert, diskutiert durch die unvollständige Zusammensetzung der erforderlichen Spezialisten usw.

Als nächstes standen wir vor einem weiteren wichtigen Problem: Es ist für den Kunden schwierig, eine Aufgabe zu formulieren. Der Kunde ist nicht immer kompetent genug (oder vielmehr fast immer unzureichend kompetent) bei der Formulierung technischer Spezifikationen für das technische Team. Und das ist normal. Der menschliche Faktor kann nicht ignoriert werden: Es kann für den Kunden banal sein, sich zu schämen und sich unwohl zu fühlen, mit einer Anfrage zum Team zu kommen, wenn er es selbst noch nicht vollständig formulieren konnte. Eines der Kriterien eines ausgereiften professionellen Teams ist die Fähigkeit, dem Kunden bei der Identifizierung seiner Probleme, Anforderungen und Lösungen zu helfen.

Es kommt häufig vor, dass der Kunde, anstatt ein Problem zu haben, eine Anfrage zur Implementierung einer Lösung stellt, die er bereits erfunden hat. Um weder uns noch den Kunden mit den Ergebnissen der Arbeit an der ToR „auf einer Serviette“ zu überraschen, haben wir eine grundlegende Checkliste mit Fragen für den Kunden erstellt. Bereits auf der Grundlage dieser Antworten ist es für den Kunden einfacher zu verstehen, was er wirklich will, und für das Entwicklungsteam, was davon verlangt wird. Und dann sind Sie an der Reihe, einige suggestive Fragen zu stellen, um Anforderungen zu klären oder zu identifizieren.

Daher bitten wir Sie, vor dem ersten Treffen mit dem Kunden (so viel wie möglich) vorab auszufüllen und uns diese Checkliste zu senden, damit Sie danach keine Zeit mit denselben Fragen verschwenden müssen, sondern sofort einen fruchtbaren Dialog beginnen. Es ist erwähnenswert, dass es bei der Interaktion mit dem Kunden wichtig ist, nicht nur die von ihm bereitgestellten Antworten zu klären, sondern auch auf der Grundlage seines angegebenen Problems, um die Anforderungen zu identifizieren, über die er möglicherweise nicht nachgedacht hat.

Liste der Fragen an den Kunden:

• Was ist der Zweck des Projekts? Welches Problem löst das? Welchen geschäftlichen Wert hat es?
• Ist dies die einzig mögliche Lösung für dieses Problem? Wenn nicht, welche anderen Optionen gibt es?
• Gibt es allgemeine Anforderungen, die das gesamte Projekt betreffen? Wenn es sich beispielsweise um einen Online-Shop handelt, muss er den Gesetzen für den Online-Handel vollständig entsprechen.
• Gibt es funktionale Anforderungen? Was soll ein Abschnitt tun (Seite, Projekt)? Beispielsweise sollte der Abschnitt Informationen zu den Produkten des Unternehmens enthalten und über das Formular auf der Seite diejenigen sammeln, die Fragen zu diesem Produkt stellen oder es erwerben möchten.
• Gibt es nicht funktionale Anforderungen? Wie gut sollte er das machen? Beispielsweise sollte die Seitenöffnungszeit nicht mehr als 5 Sekunden betragen.
• Zusätzliche Anforderungen. Freies Format, in dem Sie die Seele ausschütten können.

Ein weiteres Problem, dem wir uns stellen mussten: Aufgaben, die von allen Seiten gleichzeitig kommen. Wenn es viele Kunden in verschiedenen Projekten gibt, möchte jeder seiner Aufgabe höchste Priorität einräumen. Im allgemeinen Idealfall kann ein solches Problem wahrscheinlich nicht zu 100% gelöst werden. Wie leben wir damit? Mit der Einführung von Disziplin bei der Formulierung und Verwaltung von Aufgaben sowie einigen Elementen agiler Methoden wurde unser Aufgabenpool rationalisiert, für einen externen Beobachter transparent und vor allem vorhersehbar. Wir haben Ordnung und Pläne in unserem Team festgelegt und müssen nur das Feedback mit den Kunden stärken. Bei der Erörterung von Prioritäten, Fristen und Plänen haben wir gelernt, wie man einen argumentativen Dialog aufbaut, anstatt sich blind auf Aufgaben zu stürzen und ständig brennende Brände zu löschen (die eigentlich nicht immer relevant und nicht immer Brände sind).

Als Teil dieses Absatzes haben wir auch versucht, das klassische Antimuster-Möwenmanagement zu beseitigen, als der Kunde oder Manager einflog, Aufgaben „festlegte“ - und mit voller Zuversicht davonflog, dass er, sobald er die Aufgabe festgelegt hatte, mit Sicherheit ein hervorragendes Ergebnis erzielen würde. Wie die Praxis gezeigt hat, war das Ergebnis mit diesem Ansatz nicht das beeindruckendste. Wie gehe ich damit um? Auch hier gibt es keinen universellen Rat, keine magische Phrase, die das Verhalten der Menschen verändert. Um dies zu tun, müssen Sie sprechen, erziehen, erklären, zeigen, Sie können sagen, erziehen. Nur pädagogische Arbeit und entweder sehr visuelle oder sehr messbare (und vorzugsweise beide) positive und negative Beispiele werden dazu beitragen, das „Möwenmanagement“ ausreichend zu überwinden.

Dev gegen Ops

Und unser letztes wichtiges Thema ist das Kommunikationsproblem zwischen den Abteilungen Dev und Ops.
Wir sind mit einer klassischen Situation konfrontiert, in der Entwickler die Funktionsweise des Servers nicht sehr gut verstehen und ein Verwaltungsteam von Drittanbietern die Funktionsweise der Anwendung nicht wirklich versteht. Jede Schwierigkeit an der Verbindung dieser beiden Sphären wurde uns mit Schmerz und viel Zeit gegeben. Es war schwierig, überhaupt zu diagnostizieren, auf welcher Seite des Problems:

• Sie haben es dort programmiert!
• Nein, da hast du was mit dem Server da!

In diesem Fall hat es uns geholfen, dass ein Entwickler im Team erschien, der sich mit Administration gut auskannte. Er konnte mit jeder Gruppe in ihrer Sprache sprechen und jedes Problem von beiden Seiten diagnostizieren. Die Diskrepanzen nahmen ab, aber wir blieben an diesen Mann gebunden. Um all diese Probleme von sich zu lösen, begann er Administratoren zu helfen, die Funktionsweise der Anwendung und Programmierer zu verstehen - was auf dem Server passiert. Wir ergänzen die Erklärung der Voice-Writing-Dokumentation und erhalten nicht nur das Wissen des gesamten Teams, sondern auch die koordiniertere Arbeit der Dev- und Ops-Abteilungen. Ja, in großen Teilen des blutigen Unternehmens gibt es spezielle Teams und qualifizierte Leute, die alles so einrichten, dass die Entwickler möglicherweise nicht einmal wissen, wie und wo ihre Arbeit auf dem Server funktioniert. In kleinen Teams wäre es jedoch schön, dieses Kompetenzniveau in Menschen zu entwickeln und mindestens einen Mitarbeiter zu haben, der in dieser Hinsicht bereits gut entwickelt ist.

Entwicklung

Parallel dazu haben wir die Entwicklung einer Entwicklungskultur aufgenommen.
Ich werde mich nicht auf den technischen Teil konzentrieren, und jetzt ist er bereits ein De-facto-Standard, und fast jeder weiß nicht, wie wichtig ein Versionskontrollsystem, CI / CD und andere Entwicklungs-, Montage- und Bereitstellungstools sind. Ich werde nur auf sanfte Momente der Entwicklung eingehen.

• Codestyle Es ist sehr wichtig, die Regeln für das Code-Design zu entwickeln und explizit zu genehmigen. Erstens ist es ästhetisch ansprechend, einen einzigen harmonischen Look im Projekt zu sehen, anstatt einen Zoo mit unterschiedlichen Stilen und Standards. Zweitens erhöht es die Lesbarkeit des Codes, und wie wir wissen, schreibt der Programmierer die meiste Zeit nicht seinen Code, sondern liest den eines anderen.
• Namensverpflichtungen . Wir haben bestimmte Regeln für die Benennung von Commits eingeführt, sodass anhand des Namens des Commits klar war, welche Änderungen von wem und innerhalb welcher Aufgabe vorgenommen wurden.
• Codeüberprüfung . Die Besonderheiten unserer Projekte und des Teams sind so, dass wir keine obligatorische Codeüberprüfung haben, ohne die es unmöglich ist, unseren Code in die Produktion zu integrieren. Wir haben es jedoch zur Regel gemacht, dass mindestens eine Person den Code betrachtet, den ein Kollege pusht. Dies hilft sowohl, Mängel zu erkennen als auch alternative Ideen einzuführen und sich über alle Teile des Systems auf dem Laufenden zu halten. Die Codeüberprüfung ist mit der zunehmenden Anzahl und Komplexität von Projekten besonders relevant geworden, weshalb nicht mehr jeder Entwickler genug Zeit hat, an allen Projekten zu arbeiten, um alle Details zu verstehen.
• Architektur im Team frühzeitig ausrichten . In dem Bestreben, ein Feature schneller zu erstellen, beginnt das Frontend häufig, etwas Eigenes zu tun, das Backend startet schnell sein eigenes und es stellt sich heraus, dass es sich nur schwer oder gar nicht integrieren lässt. Bei der Entwicklung großer Funktionen werden Architektur, Datenaustauschformate usw. im Voraus gemeinsam erörtert. Infolgedessen ist die Integration nicht mehr langwierig und schmerzhaft.
• CV-gesteuerte Entwicklung . Dies ist ein Problem, bei dem Entwickler neue (frische, modische, hochbezahlte) Technologien nicht zum Zweck des Projekts, sondern zum Zwecke eines Häkchens im Lebenslauf in das Projekt ziehen. Wir sind offen für neue Technologien und versuchen, unsere Projekte technologisch weiterzuentwickeln. Es ist jedoch wichtig, ein Gleichgewicht zu halten, in dem technologischer Fortschritt und erfolgreich abgeschlossene Projekte innerhalb eines angemessenen Zeitrahmens stattfinden. Bei diesem schlüpfrigen Thema sind zwei Dinge wichtig: Der Kunde verschiebt die Fristen nicht, damit die Entwickler keine Pause einlegen, und das Entwicklungsteam (oder zumindest der kompetente Teamleiter oder das technische Team) kümmert sich nicht nur um die Entwicklung seines LinkedIn-Profils, sondern auch um das Wohlergehen des Projekts im Allgemeinen.

Refactoring, technische Verschuldung und das Prinzip der kontinuierlichen Verbesserung

Unsere Abteilung begann sich um eine bestehende Flotte von Projekten von Outsourcern zu bilden. Natürlich gab es dort keine Dokumentation, niemand verfolgte die Relevanz und Qualität des Codes. Da wir verstanden haben, dass wir noch lange damit arbeiten, warten und entwickeln müssen, wurde beschlossen, einen Teil der Zeit darauf zu verwenden, die Dinge in Ordnung zu bringen - Refactoring, Löschen irrelevanten Codes usw.

Da das Projekt groß war, war auch die Entropie hoch. Wir haben erkannt, dass es in einer Sitzung unmöglich ist, alles physisch zu überwinden und die Aussicht auf einen solch kolossalen Job moralisch aufzugeben. Wir haben uns entschlossen, das japanische Prinzip der kontinuierlichen Verbesserung "Kaizen" anzuwenden. Wir haben die technischen Schulden nach und nach in viele kleine Teile aufgeteilt, diese kleinen Teile jedoch regelmäßig geschlossen und sowohl die Projekte als auch die Arbeit des Teams selbst kontinuierlich modifiziert und verbessert.Moralisch gesehen verursachte dies keine Unannehmlichkeiten, hatte jedoch gleichzeitig keinen wesentlichen Einfluss auf die Entwicklung neuer Funktionen und die Abdeckung der Geschäftsanforderungen. Nach anderthalb Jahren stellten wir fest, dass die alten technischen Schulden vollständig zurückgezahlt waren, und dies eröffnete uns die Möglichkeit, die Funktionalität eines grundlegend neuen Niveaus an Komplexität und Bedeutung zu entwickeln.

Dies bedeutet natürlich nicht, dass wir jetzt keine technischen Schulden mehr haben. Wenn Projekte leben, sich entwickeln, wachsen und sich entwickeln, baut sie sich auf. Wir überwachen es jedoch sorgfältig, verschieben es in einen speziellen Aufgabenpool und widmen regelmäßig einige Zeit der Auszahlung. Eine solche kontinuierliche Arbeit mit technischen Schulden ermöglicht es uns, ein Gleichgewicht zwischen der Entwicklung neuer Funktionen und einer qualitativ hochwertigen Unterstützung für die alten zu finden.

In unserem Fall konnten wir, die Entwickler, dem Unternehmen die Bedeutung der Tilgung technischer Schulden erklären und zeigen. Wie haben wir das gemacht? In der Praxis haben wir Situationen aufgezeigt, in denen die Entwicklung neuer oder die Änderung der alten Funktionalität im Prinzip unmöglich (oder möglich, aber um ein Vielfaches langsamer) unmöglich ist, wenn Sie das aktuelle Projekt nicht umgestalten oder andere strukturelle Änderungen vornehmen.

Implementieren Sie agile Methoden

Durch die Implementierung einiger Ideen agiler Methoden konnten wir die Transparenz unserer Arbeit sowohl im Team als auch für das Unternehmen erhöhen, die Entwicklung vorhersehbarer und flexibler gestalten und das Ergebnis stabiler gestalten.

Das erste, was wir gemacht haben, war, tägliche Stand-Ups innerhalb des Teams zu organisieren. Da das Team verteilt ist, hat Slack hierfür einen eigenen Kanal zugewiesen, in dem jeder Mitarbeiter jeden Morgen drei Punkte schreibt: Welche Aufgaben er gestern bearbeitet hat, woran er heute arbeiten möchte, gibt es Probleme, die seine Arbeit behindern. Das Überfluten in diesem Kanal, das Besprechen von Aufgaben oder Problemen einer Person ist verboten. Dieser Kanal dient ausschließlich der Zusammenfassung von Informationen über den Stand der Dinge. Die verbleibenden Diskussionen sollten in den entsprechenden thematischen Kanälen geführt werden. Dadurch konnte jeder im Team verstehen, was seine Kollegen tun, was mit dem Projekt im Allgemeinen passiert und wem geholfen werden kann und sollte. Wenn die Probleme ohne Stand-Ups vertuscht wurden und sich nach langer Zeit plötzlich herausstellte, dass die Aufgabe noch nicht fertig war, ist jetzt klar, wer Hilfe braucht.Was muss getan werden, damit das Team effektiver arbeitet?

Als nächstes beschlossen wir, Sprints zu entwickeln. Jeden Freitag am Ende des Tages führen wir eine Sprint-Retrospektive durch, schauen uns an, welche Aufgaben geplant waren, was fertig ist, was nicht fertig ist und wenn etwas nicht fertig ist, warum ist das passiert? Wir überlegen, welche Probleme wir hatten und was wir tun könnten, um ähnliche Schwierigkeiten in Zukunft zu vermeiden. Dann planen wir einen Sprint für die nächste Woche, basierend auf der Arbeitsbelastung der verschiedenen Bereiche innerhalb des Teams und den geschäftlichen Prioritäten. Infolgedessen wissen alle Entwickler zu Beginn der Woche, was zu tun ist und in welcher Reihenfolge, und das Unternehmen weiß, welche Anforderungen in naher Zukunft erfüllt werden, und kann bereits eine eigene „Wunschliste“ für die nächsten Sprints erstellen. Es ist erwähnenswert, dass wir nicht von plötzlichen Aufgaben verschont bleiben, die unsere Sprintpläne stören könnten.In diesem Fall müssen Sie auf der Grundlage der spezifischen Art der Arbeit handeln: Wie oft entstehen solche Aufgaben? Wie viel? Kann das vorhergesagt werden? In unserem speziellen Fall in der Entwicklung haben wir experimentell berechnet, wie viel Zeit durchschnittlich auf ungeplante Aufgaben fällt, und versucht, diesen Spielraum im Sprint zu legen. Unabhängig davon ist anzumerken, dass wir nach Beginn der Sprintarbeiten gezielt herausfinden konnten, wie viel Arbeit an einem außerplanmäßigen Eingang an uns geliefert wird, diesen Betrag analysieren und reduzieren konnten, die Prioritäten sorgfältig mit dem Kunden besprachen und klar zeigten, wie sich der momentane Wunsch nach dem derzeit notwendigsten Feature auswirkt auf die Gesamtproduktivität des gesamten Teams.Was ist die durchschnittliche Zeit für ungeplante Aufgaben und versuchen Sie, diesen Spielraum im Sprint zu legen. Unabhängig davon ist anzumerken, dass wir nach Beginn der Sprintarbeiten gezielt herausfinden konnten, wie viel Arbeit an einem außerplanmäßigen Eingang an uns geliefert wird, diesen Betrag analysieren und reduzieren konnten, die Prioritäten sorgfältig mit dem Kunden besprachen und klar zeigten, wie sich der momentane Wunsch nach dem derzeit wichtigsten Feature auswirkt auf die Gesamtproduktivität des gesamten Teams.Was ist die durchschnittliche Zeit für ungeplante Aufgaben und versuchen Sie, diesen Spielraum im Sprint zu legen. Unabhängig davon ist anzumerken, dass wir nach Beginn der Sprintarbeiten gezielt herausfinden konnten, wie viel Arbeit an einem außerplanmäßigen Eingang an uns geliefert wird, diesen Betrag analysieren und reduzieren konnten, die Prioritäten sorgfältig mit dem Kunden besprachen und klar zeigten, wie sich der momentane Wunsch nach dem derzeit notwendigsten Feature auswirkt auf die Gesamtproduktivität des gesamten Teams.Wie sich ein momentaner Wunsch nach einer unnötigen Funktion auf die Gesamtproduktivität des gesamten Teams auswirkt.Wie sich ein momentaner Wunsch nach einer unnötigen Funktion auf die Gesamtproduktivität des gesamten Teams auswirkt.

Wir sind auch von langen zu kurzen Veröffentlichungen übergegangen. Zuvor haben wir TK erhalten, Wochen oder Monate haben eine ganze Reihe von Funktionen ausgeführt und diese erst dann dem Kunden gezeigt. Infolgedessen stellte sich oft heraus, dass der Kunde seine Meinung geändert oder nicht ganz damit gerechnet hatte, und wir begannen, alles oder einen Teil dessen, was wir bereits getan hatten, zu wiederholen. Und Änderungen an einem vorgefertigten großen Funktionsumfang vorzunehmen, ist ein zweifelhaftes Vergnügen. Jetzt demonstrieren wir jede Funktion so früh wie möglich, damit der Kunde eine Entscheidung trifft - ob dies das ist, was er wirklich wollte oder etwas geändert werden muss. Je schneller er es genehmigt oder zur Überarbeitung sendet, desto weniger Arbeit werden wir investieren, desto schneller wird das Feature in Produktion gehen. Infolgedessen kamen Features schneller in die Produktion, Hypothesen wurden schneller getestet und das Projekt ging schneller.

Busfaktor

Da unser Team klein ist, haben wir sofort über die Probleme nachgedacht, die bei der Rotation des Personals auftreten können. Bestimmte Personen sind die alleinigen Verwalter einiger Kenntnisse geworden, Projekte wurden ausreichend erweitert, und daher haben wir begonnen, eine Kultur der Wissensspeicherung und -verwaltung zu entwickeln.

Die Beseitigung dieses Problems wurde durch die Anhäufung von Wissensartefakten unterstützt, die sich von den Köpfen bestimmter Personen in die physisch geschriebene Welt bewegten. Nämlich:

• Alle Arbeiten werden nur ausgeführt, wenn sich eine Aufgabe im Bugtracker befindet. Auf diese Weise können Sie einen vollständigen Verlauf der Änderungen im Projekt erstellen.
• Wenn wir irgendwo im Chat oder auf der Rallye die Änderungen in der Aufgabe besprochen haben, müssen wir das Ergebnis dieser Diskussion in der Aufgabe selbst widerspiegeln.
• . , Gitlab. , .
• Confluence , - , .
• - postmortem « — — — ».

Es gibt immer noch bewährte Verfahren, bei denen Sie die Maßnahme natürlich kennen und nicht auf das Absolute bringen müssen: Wenn Sie nach einem Teil des Systems gefragt werden, den nur Sie kennen, ist es ratsam, eine Dokumentation darüber zu schreiben und mit einem Link darauf zu antworten. Sie müssen diese Frage also nie wieder beantworten und andere Personen fragen.

Diese Methode zur Pflege von Wissensartefakten hat uns wiederholt dabei geholfen, Informationen über die Teile des Projekts zu finden, die sonst notwendigerweise verloren gehen würden. Außerdem reduzierte er die Risiken für das Projekt und das Team während der Personalrotation erheblich. Das letzte Beispiel: Wir haben schnell und einfach Informationen über die Geschäftslogik, das Funktionsprinzip und die Methode zur Bereitstellung des Tools abgerufen, die von dem Mitarbeiter durchgeführt wurden, der vor zwei Jahren gekündigt hat.

Wenn wir bei dieser Technik mit Stand-Ups und Sprints arbeiten, wird der Busfaktor noch weiter reduziert. Vor nicht allzu langer Zeit haben wir ein Experiment durchgeführt: Ein Entwickler war im Urlaub und ein anderer Entwickler hat gearbeitet. In diesem Moment, als der erste in den Urlaub ging, ging der zweite in den Urlaub. Die Essenz des Experiments bestand darin, keine erklärenden Briefe und Botschaften zu schreiben, den Fall nicht zu übergeben und zu sehen, wie schwierig es für einen Menschen nach einem langen Urlaub sein würde, zu verstehen, was in seiner Abwesenheit geschah, was sich änderte, genau wie und welche Pläne für die Zukunft. Wie die Praxis gezeigt hat, ermöglichte das Anzeigen des Bugtrackers, der Commits, der Dokumentation, der Stand-Ups und Sprints dem Mitarbeiter, ganz einfach in den Geschäftsverlauf einzusteigen und seine Arbeit autonom fortzusetzen.

Fazit

Abschließend möchte ich darauf hinweisen, dass keines der oben genannten Probleme sofort und fehlerfrei gelöst wurde. Organisatorischer Wandel ist immer eine lange und methodische Arbeit. Sie können nicht einfach sagen "Jetzt machen wir das" und hoffen, dass jetzt alles anders wird. Alle Entscheidungen, die Sie treffen, alle Veranstaltungen, die Sie organisieren, erfordern Kontrolle, Schulung und Aufklärung der Menschen, Zeit, um sowohl das Team an neue Techniken als auch die Techniken selbst an eine bestimmte Situation anzupassen. Ich stelle auch fest, dass die Einführung einer Methodik für Menschen ein sehr mühsamer und ineffizienter Prozess ist. Die Leute werden sich ausruhen, vergessen, vielleicht sogar sabotieren.

Damit die erforderlichen Änderungen im Team beginnen können, muss das Team selbst diese Änderungen vornehmen wollen. Es ist notwendig zu überwachen, wie es ihr geht, Problembereiche zu identifizieren, sich dieser Probleme bewusst zu sein, Lösungen zu finden und sie erst dann umzusetzen. Natürlich sollte und will nicht jedes Mitglied des Teams dies tun, aber wenn es jemanden gibt, der diese Probleme erkannt und Lösungen gefunden hat, wird er das Team zunächst aufklären.

Teilen Sie Ihr Wissen, Ihre Beobachtungen, Erfahrungen, argumentieren, zeigen und beweisen Sie, wo die Probleme jetzt liegen und welche Schritte unternommen werden können, um sie zu lösen. Nur so können groß angelegte organisatorische Transformationen so effizient wie möglich durchgeführt werden. Selbst wenn Sie eine Führungskraft sind und Ihre Position und Ihre Entscheidung vorantreiben möchten, versuchen Sie dies so überzeugend und überzeugend wie möglich zu tun, um Zeit bei der Implementierung zu sparen und das Team vor unerwünschter Negativität zu bewahren.

Gepostet von Evgeny Antonov, Leiter der Entwicklungsgruppe Positive Technologien