Es scheint, dass in kleinen Entwicklungsteams (über 20 Personen) keine Probleme mit Uneinigkeit auftreten sollten, an einem gemeinsamen Kodex arbeiten und technische Entscheidungen treffen sollten. Aber wir alle wissen, dass dies nicht der Fall ist (ganz zu schweigen von Teams wie unserem, in denen mehr als 80 Personen leben). Um sie zu lösen, haben wir vor drei Jahren eine wöchentliche interne DevForum-Entwicklerkonferenz abgehalten. Unter der Katze erfahren Sie, wie es uns hilft, warum andere Formate (wie wöchentliche Meetings oder Sprint Review) und Anweisungen zum Erstellen nicht immer geeignet sind.
Seit drei Jahren haben wir viele gute Inhalte gesammelt. Daher wird es eine Reihe von Artikeln geben, die auf Reden im DevForum basieren :
1. Schrödinger-Katze ohne Box: das Problem des Konsenses in verteilten Systemen.
2. Infrastruktur als Code: erste Bekanntschaft.
3. Infrastruktur als Code: So überwinden Sie Probleme mit XP.
4. Wie Server miteinander übereinstimmen: Raft Distributed Consensus-Algorithmus.
5. Das Pferd ist tot - Schrei: Übergang von Tslint zu Eslint.
6. Generierung von Typescript-Verträgen für c # -Modelle. (In Bearbeitung ...)
...
Was ist DevForum und welche Probleme löst es?
DevForum ist unsere wöchentliche interne Veranstaltung für Dodo IS-Entwickler. Es läuft seit drei Jahren donnerstags. Entwickler kommen zusammen und widmen eine Stunde der Kommunikation miteinander.
Bei diesem Treffen diskutieren wir technische Fragen, die für das gesamte Team relevant sind. Eine Stunde Zeit, zwei Berichte von einer halben Stunde, Zeit für Fragen und Antworten.
Welche Probleme löst die interne Konferenz?
Um ein gemeinsames Ziel zu erreichen, ist es wichtig, dass wir uns weiterhin auf wichtige Themen des Unternehmens konzentrieren. Für die Gesamtsynchronisation aller Dodo haben wir montags wöchentliche Treffen. Alle Mitarbeiter, Partner / Franchisenehmer sind bei ihnen anwesend, Aufzeichnungen von Besprechungen können
gemeinfrei eingesehen werden. Für eine Synchronisierung mit Unternehmen und Partnern arrangieren wir eine zweiwöchentliche
Sprint-Überprüfung . Für einen einzigen Fokus und eine regelmäßige Synchronisierung des IT-Teams müssen Sie mehr in das technische "Fleisch" eintauchen. Dies ist, was wir auf DevForum tun.
Hier ist eine Liste der Probleme und ihrer Lösungen:
- Wissen teilen . Jetzt haben wir mehr als 80 Entwickler in unserem Team. Jeder von ihnen hat seinen eigenen Hintergrund, seine eigenen Arbeitsspezifikationen, seine eigene Immersionsstufe. Unsere Teams sind nach Produkten unterteilt. Und es kann vorkommen, dass zwei unabhängige Teams die gleiche Wildnis durchlaufen müssen. Wenn sie die Möglichkeit haben, ihre Best Practices, Gedanken, Erfolge oder umgekehrt miteinander zu teilen, wird es besser. Es besteht eine geringe Wahrscheinlichkeit, dass jemand nicht auf den Rechen tritt.
Außerdem wird unser Team ständig erweitert, neue Leute kommen und erhalten ein vorgefertigtes Tool für die regelmäßige Aktualisierung und den Austausch von Wissen. - Schulung . Hier können Sie lernen, wenn Sie es nicht selbst tun können, und unterrichten, wenn Sie können. Training ist ein Punkt, der sehr eng mit dem Austausch von Wissen verbunden ist. Ob es uns gefällt oder nicht, wir müssen unser technisches Niveau ständig verbessern.
- Technische Synchronisation von Befehlen (nicht zu verwechseln mit der täglichen Synchronisation von Befehlen) . Es ist einfach, mit allem auf dem Laufenden zu bleiben, wenn Sie nur drei Personen sind. Jetzt sind wir viel mehr. Manchmal stoßen wir auf ein solches Problem: Teams arbeiteten parallel an einem Produkt, wussten aber nicht, was jedes einzelne tut. Infolgedessen entstanden Konflikte, das Umschreiben des Codes eines anderen usw. Wenn einige dies tun, während andere werfen, kann der Entwicklungsprozess abrutschen. Bei DevForum konzentrieren wir uns auch auf die technische Synchronisation von Teams und kämpfen mit Uneinigkeit.
- Werkzeug zur Veränderung . Sie können hierher kommen und den Lauf der Geschichte ändern. Hier müssen Sie anhand eines Beispiels sagen.
Ein Beispiel. Nehmen wir an, wir haben Oleg. Er sitzt in der Infrastruktur und macht mit den Jungs das Autonomy-Projekt. Wenn das Projekt sein volles Potenzial entfaltet, wird das Leben einfacher Entwickler einfacher. Sie werden aufhören, die Infrastruktur zu ziehen, und alles selbst tun. Du machst alles selbst, du bist von niemandem abhängig, okay.
Oleg ist bereit, Änderungen im Unternehmen vorzunehmen. Aber er weiß, dass es nicht ausreicht, nur über die an Slack vorgenommenen Änderungen zu schreiben. Es ist notwendig, öffentlich zu erzählen, zu erklären, Fragen zu beantworten, einen Artikel zu schreiben, eine Reihe von Aktionen durchzuführen, sonst ändert sich nichts. Oleg kommt zu DevForum und nutzt es als Werkzeug für Veränderungen.
- Training vor der Vorstellung . Hier können Sie vor einer großen Aufführung üben. Nehmen Sie wieder Oleg als Beispiel.
Ein Beispiel . Oleg möchte auf großen Konferenzen sprechen. Er braucht Ehre, Ruhm und Tausende von Ansichten auf Youtube.
Er kommt zu uns und spricht ehrlich über seine ehrgeizigen Ziele. Wir bieten ihm wiederum eine Plattform für ein (praktisch) schmerzloses Training. Bei Bedarf helfen wir, fordern Sie auf, führen Sie.
Der Schwellenwert für die Eingabe von DevForum ist (im Gegensatz zu einem Mitap oder einer Konferenz) minimal. Oleg muss ein Thema vorbereiten, Folien für eine halbe Stunde vorbereiten und zur richtigen Zeit kommen. Dies ist ein großartiger Ort für eine Probe. Training an Katzen, d.h. auf uns. Wir werden Feedback geben und die Folien durchgehen, und Sie können die Witze über uns überprüfen.
Nach DevForuma kann der Bericht bereits auf eine lokale Mitap geworfen werden. Und höchstwahrscheinlich werden sie ihn nehmen.
Ein bisschen retro: wie DevForum entstanden ist
Woher kommt dieses Format? Korotenechko. Vor drei Jahren unternahm unser Unternehmen den ersten Versuch, Sprint Review regelmäßig einzuführen.
Es sah so aus: Alle versammelten sich in einem Raum, absolut alles und erzählten sich abwechselnd, wer was in den letzten Wochen getan hatte. Zu dieser Zeit waren wir nur 20, aber stellen Sie sich vor, wie es sich anfühlt, einem Unternehmensvertreter zuzuhören und nach einem Code zu suchen, und einem Entwickler, der sich die Entwicklung von Pizzerien ansieht. Wir haben sehr schnell festgestellt, dass die Leute nur Themen hören, die für sie von Interesse sind, und bei anderen Themen stecken sie schmerzhaft im Telefon fest.
Wir sind mit der Tatsache konfrontiert, dass eine Demonstration von zutiefst technischen Dingen gegenüber den Menschen, die weit davon entfernt sind, eine solche ist. Sie kamen, um zu sehen, wie die Kasse beginnt, und wir berichten ihnen über die Erfahrungen mit der Verwendung des Polly-Frameworks für die Implementierung von Retrays zwischen Diensten. Wir stellten schnell fest, dass ein solches Format für die Menschen von geringem Nutzen war, und Sprint Review lehnte es in dieser Form ab. Irgendwann wurde es einfach abgesagt und die Besprechung im Kalender blieb bestehen.
Eine Initiativgruppe von Menschen dachte: Es ist so cool, denjenigen, die sich mit dem Thema befassen, technische Dinge zu zeigen. Es gibt ein Treffen, Menschen sind, es gibt einen Wunsch, es gibt Themen. Also versammelten wir uns einmal in der Woche und tun dies bis heute.
Seit drei Jahren hat das Format einige Änderungen erfahren.- Wir begannen unsere Auftritte aufzunehmen. Das Format selbst läuft seit drei Jahren, wir haben Aufzeichnungen in zwei Jahren. Alle von ihnen werden an einem Ort gespeichert, falls gewünscht, können Sie überprüfen.
- Wir haben das Format der Demonstration verlassen, weil wir zu dem Schluss gekommen sind, dass die Vorbereitung und die Demo selbst mehr Zeit in Anspruch nehmen als das Format der Präsentation.
- Wir sind zu dem Präsentationsformat übergegangen, das einfach vorzubereiten ist und buchstäblich 40 Minuten Zeit bietet (obwohl dies hier natürlich von der Komplexität des Themas und des Redners abhängt).
- Zunächst sprach jeder Entwickler im DevForum. Irgendwann gingen wir davon aus, dass nicht jede einzelne Person sprach, sondern ein Vertreter des Teams.
- Dann gingen wir weiter und hörten auf, mit einem Vorschlag zu belästigen, mit den Teams zu sprechen, die jetzt "nichts passiert" haben.
- Anfangs passten wir vier Themen pro Stunde an, kamen jedoch zu dem Schluss, dass, egal wie interessant die Berichte waren, am Ende der Stunde nur noch Haferbrei in meinem Kopf war. Jetzt nehmen wir ein oder zwei Themen auf DevForum, 25 Minuten eines Berichts und 5 Minuten für Fragen.
- Vor kurzem haben wir beschlossen, das Themenspektrum ein wenig zu erweitern und manchmal externe Redner einzuladen.
Wir wissen, dass unser DevForum kein super einzigartiges Format ist, viele unserer Kollegen haben etwas Ähnliches versucht. Leider haben solche regelmäßigen Treffen oft keine Wurzeln, werden schnell obsolet und verdorren. Unser DevForum lebt drei Jahre - dies ist eine lange Zeit, um zu analysieren, Fachwissen zu sammeln und die Erfahrung mit der Erstellung und Pflege dieses Formats mit Ihnen zu teilen.
So organisieren Sie DevForum in Ihrem Unternehmen
Sie benötigen 6 grundlegende Dinge:
1. Grundlegendes zu den Aufgaben und Formaten von DevForum.
Weitere DetailsUm zu verstehen, ob DevForum zu Hause ausgeführt werden muss, können Sie die Aufgaben konsultieren, die dieses Format in unserem Dodo löst.
Dies sind die Aufgaben der Kommunikation, des Trainings und der Selbstverwirklichung von Programmierern. DevForum ist ein flexibler Mechanismus und kann zu der einen oder anderen Zeit mehr arbeiten, um unterschiedliche Ziele zu erreichen.
Es gibt zwei verifizierte Sprachformate, die wir in drei Jahren entwickelt haben. Sie können adoptieren:
Bericht : Ein Entwickler bereitet sich vor und spricht, während andere Fragen stellen.
Ein Beispiel . Früher war das Thema „Strukturelle Protokollierung“, wo über Serilog, seine Verwendung in unseren Projekten und wie es hilft, besser mit Protokollen in Kibana zu arbeiten, gesprochen wurde. Außerdem wurde das Thema der strukturellen Protokollierung über NLog und die Verwendung gemeinsamer ILogging-Schnittstellen für .NET CORE-Projekte behandelt.
Nach der Präsentation gab es eine Sitzung mit Fragen, und alle Teilnehmer verstanden, wie einfach es war, diese Bibliothek einem neuen Projekt hinzuzufügen. Wir haben 30 Minuten gebraucht. Für eine weitere halbe Stunde diskutierten wir an diesem Tag Protokollierungsstufen wie Debug, Info, Warnen, Fehler usw. und insbesondere, welche Stufen welche Situationen im System beschreiben. In der Fragensitzung wurde das Problem von Rauschfehlern in den Protokollen, insbesondere im Zusammenhang mit Retrays, angesprochen. Seit DevForum verwenden alle neuen Microservice-Projekte genau Serilog und es wurde auch in unserer Service-Vorlage angezeigt.
Entscheidungsfindung : Es gibt ein Problem, das irgendwie alle betrifft. Die Leute kommen mit möglichen Lösungen, um über eine Sache nachzudenken.
Ein Beispiel . Wir haben DevForum zusammengebracht, um die Definition von erledigt zu besprechen, und wollten die Qualität des für die Produktion gelieferten Codes stabilisieren. Aber wie geht das, wenn mehrere Befehle gleichzeitig an einem gemeinsamen Code arbeiten? Die Lösung bestand darin, alle Definitionen von erledigten User Stories gemeinsam zu machen. Das vorgeschlagene DOD war ein kontroverser Punkt. Wir kamen zusammen und diskutierten, ob wir es brauchten oder nicht. Eine allgemeine Entscheidung wurde getroffen. Um dies zu implementieren, haben wir der Checkliste in unserem Task-Tracker (Kaiten) ein Element hinzugefügt und es beim Schließen von Aufgaben zu einem obligatorischen Element gemacht. Einige Teams haben dann DoD weiter gestärkt, indem sie ihre eigenen wichtigen Punkte hinzugefügt haben.
2. Leistungsstarke und aufgeladene Organisatoren.
Weitere DetailsWas noch berücksichtigt werden muss, ist die Anwesenheit von Personen, die ständig an der Veranstaltung beteiligt sind - den Organisatoren. Es ist wichtig, dass sie von Entwicklern oder Personen stammen, die den technischen Teil verstehen. Sie müssen den Teilnehmern helfen, Themen zu formulieren, neue Redner zu finden und manchmal sogar eine Diskussion zu führen, indem sie gute Fragen stellen.
In unserem Fall haben wir 3 Organisatoren von den Entwicklern sowie ein aktiv unterstützendes IT-Markenteam.
3. Zustimmung der Leitung Ihrer IT-Abteilung.
Weitere DetailsEin wichtiger Bestandteil für den Erfolg der Veranstaltung ist neben den Zielen und Organisatoren der fehlende Widerstand von oben. Dieser Prozess ist eine reine Basisinitiative, wir können sagen, dass Enthusiasten es tun. Die Hilfe des Managements kann von Vorteil sein, und der Widerstand wird katastrophal sein. Trotzdem versammeln sich die Menschen während der Arbeitszeit, nutzen Büroräume und Geräte. Dies sollte zumindest nicht verboten werden.
4. Verfügbarkeit von Raum und Ausrüstung für Besprechungen.
Weitere DetailsDer Raum kann entweder ein Besprechungsraum im Büro oder ein virtueller Besprechungsort, ein allgemeiner Anruf in Skype oder ein Google-Treffen sein.
Wir versammeln uns immer in einem Besprechungsraum, der "für immer zu dieser Zeit" im Büro gebucht ist, aber gleichzeitig senden wir alles im Allgemeinen, was Google trifft, was auch gleich ist und sich zwischen den Besprechungen nicht ändert.
Unsere Verhandlungen sind groß und bieten Platz für 20-30 Personen. Es gibt einen Projektor und ein Soundausgabesystem für Ferngespräche. Jeder weiß, dass das DevForum donnerstags von 16.00 bis 17.00 Uhr in diesem Besprechungsraum stattfindet.
Aufgrund der Tatsache, dass wir eine teilweise verteilte Entwicklung haben, sind wir sicher, Remote-Mitarbeiter zu einem gemeinsamen Anruf zu bringen. Außerdem können Sprecher ihren Bildschirm von ihrem Computer aus anzeigen und eine Verbindung zu einer Hauptversammlung herstellen. Die Redner können sich im Besprechungsraum oder an einem anderen für sie geeigneten Ort befinden. Wir werden sie alle hören und auch ihren Bildschirm sehen.
Der festgelegte permanente Raum macht dieses Meeting für die Teilnehmer zuverlässiger und vorhersehbarer.
5. Die Anwesenheit eines Zuhörerpublikums.
Weitere DetailsUm Teilnehmer zu sammeln, haben wir einen permanenten Kanal im #devforum slack, in dem alle Entwickler sicher sitzen. Wir haben diesen Kanal sogar in die Liste der erforderlichen Kanäle in der Checkliste des neuen Entwicklers aufgenommen. Außerdem sorgen unerfahrene Mentoren dafür, dass sie in den # devforum-Kanal fallen.
Es gibt Ankündigungen von Treffen, Diskussionen danach, die Auswahl von Themen und Diskussionen über Themen.
Damit die Teilnehmer am Leben des Forums teilnehmen können, organisieren wir Umfragen, bitten die Redner um Feedback und veröffentlichen am nächsten Morgen eine Aufzeichnung des Meetings.
Es ist auch wichtig, dass die Veranstaltung freiwillig und freiwillig ist. Ja, es findet während der Arbeitszeit statt, aber wenn jemand arbeiten möchte oder zu diesem Zeitpunkt wichtigere Dinge zu tun hat, kann er dies vermissen.
Beispiel für eine Veröffentlichung nach der Veranstaltung:
Ein Beispiel für eine Diskussion nach einem Meeting:
6. Anwesenheit von Rednern und Diskussionsthemen.
Weitere DetailsDies ist der wichtigste und schwierigste Teil der Organisation. Hier stehen wir vor Problemen, sowohl bei der Suche nach Referenten als auch bei der Verfügbarkeit von Themen.
Hier ist nur eine kurze Liste von Aktivitäten, die Organisatoren durchführen, um Menschen zu motivieren:
- Wir suchen im Voraus nach Themen und erstellen einen Leistungsplan für mehr als eine Woche. Zuerst haben wir zu Beginn der Woche nach Themen gesucht und am Donnerstag mussten wir sprechen.
- Wir gehen in die Befehlskanäle und fragen explizit: Gibt es Themen für DevForum?
- Wir führen persönliche Gespräche mit Programmierern und ermutigen sie, aufzutreten. Wir untermauern den Wert, den der Redner für die Teilnahme hat: ein tieferes Verständnis des Themas, Erfahrung beim Sprechen, öffentlicher Nutzen, Material für einen zukünftigen Artikel, Konferenz.
- Wir werfen in den Kanal Themen zur Diskussion, die die Leute gerne hören würden. Erfahrene Entwickler können reagieren und als Redner fungieren.
- Wir reagieren auf sozial wichtige Ereignisse und organisieren unabhängig Diskussionen zu problematischen Entwicklungsthemen.
- Wir verfolgen vergangene Konferenzen mit unseren Teilnehmern. Nach der Teilnahme an Konferenzen gibt es immer etwas zu erzählen.
- Nach den Ergebnissen der für uns wichtigen Konferenzen, an denen viele von uns teilgenommen haben, organisieren wir eine Diskussion im Format "3 beste Berichte aus dem neuesten Highload ++".
- Wir laden externe Redner ein.
Noch etwas Wichtiges
Es scheint, dass alles einfach ist (oder umgekehrt, nichts ist klar), daher werde ich einige weitere Merkmale der Organisation auflisten, die berücksichtigt und berücksichtigt werden müssen.
Die Organisatoren müssen mit Sprechern arbeiten. Wir lösen die Angst vor dem Sprechen durch Hilfe bei der Vorbereitung auf die Rede. Faulheit oder Desorganisation werden durch die Aufforderung gestoppt, das Thema im Voraus zu formulieren, auch in Entwurfsform und mit dem genauen Datum der Rede.
Manchmal gibt es keine. Es gibt Zeiten, in denen so viel gefunden wurde, manchmal, wenn es wenig gibt. In diesem Fall können Sie das Ereignis nicht kategorisch abbrechen. Wir müssen versuchen, Themen zu finden oder für uns selbst zu sprechen. Organisatoren sind auch Entwickler, daher haben wir auch immer etwas zu erzählen. Sie können auf Tricks zurückgreifen und mehr kostenlose Diskussionen arrangieren.
Video- und Tonqualität. Es ist ein rein technischer Moment, aber für die Menschen ist es wichtig, dass der Ton gut ist (überprüfen Sie die Verbindung und das Internet im Voraus) und die Demonstration des Codes auf dem Bildschirm lesbar ist. Selbst das interessanteste Thema, das mit technischen Mängeln behaftet ist, kann den Betrachter entfremden.
Wir sammeln Material an. Besprechungen müssen aufgezeichnet werden. Wir haben ein Archiv mit Videos mit Präsentationen und zusätzlichen Materialien. Es gibt Wiedergabelisten auf YouTube. Wir legen alle Aufzeichnungen in unser Dokumentationssystem, wo eine Volltextsuche stattfindet und Sie das gewünschte Thema nachher finden und kennenlernen können.
Engagiert für jene Entwicklungsteams, in denen es keine Manager gibt, in denen Sie an einem einzigen Code arbeiten, in denen Entwickler daran interessiert sind, zu wissen, was los ist, für jene Leute, die sich weiterentwickeln und anderen beim Wachstum helfen wollen, jene Teams, für die Vertrauen wichtig ist.
Von Dodo Pizza Engineering mit der Menschheit