Wie bringe ich als Neuling die Leute dazu, all ihr großes Gerede in die Tat umzusetzen?

Ich bin "der Neue" in der IT-Abteilung eines kleinen Produktionsunternehmens. Wir haben ein kleines Team von 3 Anwendungsentwicklern + 1 Datenbankentwickler/DBA-artige Rolle. Ich bin seit ein paar Monaten hier, also bin ich an dem Punkt angelangt, an dem ich angefangen habe, das Vertrauen und die Anerkennung meiner Kollegen zu gewinnen.

Während meines Vorstellungsgesprächs wurde viel darüber gesprochen, agiler werden zu wollen. Es wird noch viel darüber geredet , aber nichts dagegen unternommen. Um ehrlich zu sein, ist es mir egal, ob wir „agil“ sind oder nicht, aber wir müssen wirklich anfangen, einige Dinge zu tun, die nur Best Practice sind, agil oder nicht. Dinge wie Unit-Tests und Code-Reviews. Ja, lassen Sie uns zuerst mit diesen beiden gehen, da sie das größte Preis-Leistungs-Verhältnis bieten.

Jetzt habe ich Code, den ich berühre, getestet, bevor ich ihn ändere. Teilweise, weil ich die Vorteile gesehen habe, und teilweise, weil ich Angst davor habe, irgendetwas in einer Legacy-Codebasis zu beschädigen. Mein Vorgesetzter ist sehr zufrieden damit. Er hat es mir selbst gesagt. Der Rest des Teams scheint die Idee von Tests und geschlossenen Check-Ins zu mögen, hat aber nichts unternommen, um diese Dinge tatsächlich zu tun . Ich denke, es könnte daran liegen, dass sie einfach nicht wissen, wie, aber es ist möglich, dass sie denken, "sie haben keine Zeit". (Der Teil, keine Zeit zu haben, ist übrigens völlig falsch. Das Management weiß, dass es sich um eine Investition im Voraus handelt, die sich auszahlt, und unterstützt die Bemühungen vollständig.)

Es ist ehrlich gesagt ein bisschen frustrierend für mich, so viel Gerede zu hören, aber keine Aktion von meinen Teamkollegen zu sehen. Wie kann ich als Neuling sie in Aktion bringen, ohne die Federn zu zerzausen? Ich will nicht dieser Typ sein .

Dies ist kein Duplikat der vorgeschlagenen Frage, da dieser Typ gefragt hat, ob/wie er seine Ideen vorantreiben soll. Dies sind nicht meine Ideen (obwohl ich ihnen offensichtlich zustimme). Meine Frage dreht sich darum, wie ich meine Kollegen dazu bringen kann, ihren Worten Taten folgen zu lassen .

Sie scheinen nur die „Idee von Tests und geschlossenen Check-ins“ zu mögen, weil sie nicht darüber streiten wollen.
Was meinst du mit @MarkRogers?
Sie sind möglicherweise nicht in der Stimmung oder haben die Energie, ihre Arbeitsweise zu ändern, also geben sie der Idee nur ein Lippenbekenntnis ab, während sie mit dem weitermachen, was sie bereits getan haben. In der Hoffnung, dass irgendwann jemand anderes es für sie herausfinden wird oder das Problem anderweitig verschwindet. Klassisches Ausweichen.
Ich kenne @MarkRogers nicht. Sie mögen Recht haben, aber sie scheinen wirklich daran interessiert zu sein, die Dinge zu verbessern. Oder zumindest sind sie daran interessiert, darüber zu sprechen , Dinge besser zu machen. Hmm
Wenn sie wirklich interessiert sind, aber nichts passiert, kann es daran liegen, dass sich niemand wohl dabei fühlt, die Führung zu übernehmen, um es zum Laufen zu bringen. Bist du der Typ? Wenn ja, erstellen Sie einen Plan und stellen Sie ihn auf. Sie werden Sie unterstützen und vielleicht für Ihre Führung dankbar sein. Wenn Sie nicht bereit sind, die Führung zu übernehmen, dann ist es ein bisschen heuchlerisch, sie dafür zu kritisieren, dass sie dies auch nicht tun, unabhängig davon, wie lange die Situation schon andauert. Betrachten Sie dies als Chance, nicht als Problem.
Für alle Interessierten habe ich nach dem Standup von heute Morgen vorgeschlagen, dass wir unserem Kanban-Board eine Spalte „Überprüfung“ hinzufügen. Alle waren sich einig, dass es eine gute Idee war, also taten wir es und ich zeigte allen, wie man ein Änderungsset kommentiert. Wir werden sehen, wie es läuft. Danke für all die tollen Ratschläge an alle. Es tut mir leid, dass ich kein Häkchen vergebe, aber ich fand, dass alle Antworten gleichermaßen hilfreich waren.

Antworten (3)

Es ist ehrlich gesagt ein bisschen frustrierend für mich, so viel Gerede zu hören, aber keine Aktion von meinen Teamkollegen zu sehen. Wie kann ich als Neuling sie in Aktion bringen, ohne die Federn zu zerzausen? Ich will nicht dieser Typ sein.

Die Verwendung von Ausdrücken wie „großes Gerede“ und „dränge sie“ kann dich tatsächlich zu diesem Typen machen , also willst du nicht dorthin gehen.

Erwägen Sie, Ihren Vorgesetzten zu fragen, ob es für Sie in Ordnung wäre, eine Präsentation zu einigen der Praktiken zu erstellen, die Sie für wichtig halten. Einige Unternehmen führen während des Mittagessens "Brown Bag Talks", bei denen solche Themen üblich sind.

Wenn Sie angenommen werden, können Sie darüber sprechen, was Sie vorschlagen, warum Sie es für wichtig halten (hoffentlich nicht nur, weil Sie der Meinung sind, dass es eine „Best Practice“ ist, sondern mehr darüber, warum es dem Team/Unternehmen in seinem speziellen Kontext zugute kommt) und wie Sie alle können diese Ideen umsetzen.

Versuchen Sie, die ausdrückliche Zustimmung des Managers rechtzeitig zu erhalten, und nutzen Sie dann Ihre Überzeugungskraft, um andere davon zu überzeugen, auf den fahrenden Zug aufzuspringen. Manchmal fängt es gut an, ein Pilotprojekt vorzuschlagen – oft ist es der einfachste Weg zu Verbesserungen, klein anzufangen.

Das ist es. Sie kennen die Vorteile, sonst würde man nicht so viel darüber reden... Das Pilotprojekt ist aber eine gute Idee. Ich mag es. Das kann ich vielleicht hinbekommen.
Zu wissen, dass etwas eine Verbesserung wäre, und davon profitieren zu wollen und in der Lage zu sein, die erforderlichen Ressourcen zu finden, um es anzunehmen, sind oft sehr unterschiedliche Dinge. In der Theorie sollte die Praxis mit der Theorie identisch sein; in der Praxis ist das nicht immer möglich, und wenn, dann muss man es normalerweise schrittweise erreichen.
Ich habe eine zufällige positive Bewertung erhalten, die mich darauf aufmerksam gemacht hat. Ich hatte es bis jetzt ganz vergessen. Ich möchte nur Danke sagen. Als ich dieses Unternehmen verließ, wuchs die Testabdeckung und wir veröffentlichten zwei- bis viermal pro Woche für Prod.

Der Rest des Teams scheint die Idee von Tests und geschlossenen Check-Ins zu mögen, hat aber nichts unternommen, um diese Dinge tatsächlich zu tun

Wissen sie eigentlich, wie man Unit-Tests durchführt?

Wenn Sie dies noch nie zuvor getan haben, ist es möglicherweise nicht einfach, damit anzufangen. Vor allem, wenn Sie jahrelange Erfahrung damit haben, keine Tests durchzuführen.

Es klingt, als wäre zumindest Ihr gesamtes Team offen für die Idee, ihre Prozesse zu ändern. Ich würde mich darauf konzentrieren, sicherzustellen, dass Sie wissen, warum sie nichts tun. Ich vermute, es ist entweder ein allgemeiner Widerstand gegen Veränderungen oder ein Mangel an Verständnis dafür, wie man Dinge tut.

Wenn es ein Mangel an Wissen ist, können Sie Möglichkeiten in Betracht ziehen, dabei zu helfen. Ein guter Weg könnte sein, jemanden um Hilfe zu bitten und eine Art Paarprogrammierung zu machen, wenn Sie mit Code arbeiten, den Sie nicht (so vollständig) verstehen. Sie können besprechen, was Sie tun, und sehen, ob Sie mit der anderen Person dort Tests schreiben können, in denen Sie erklären, was Sie tun.

Beachten Sie, dass es nicht unbedingt dasselbe ist, einen Test geschrieben zu sehen (Code Review) und zu wissen, wie man an das Schreiben eines Tests herangeht.

Wenn es nur ein Problem ist, dass wir gerne darüber reden und hip klingen, ohne etwas zu tun, könnten Sie versuchen, wenn dieses Gespräch stattfindet, sehr spezifische, praktische Dinge vorzuschlagen oder nach ihnen zu fragen (anstatt sich nur über mangelnde Codeüberprüfung oder Komponententests zu beklagen , auch):

  • "Mann, ich wünschte, wir wären agiler."
  • "Nun, möchten Sie den Code des anderen überprüfen? Ich habe heute Nachmittag frei und habe eine Verpflichtung, die ich mache."
Sie wissen es legitimerweise vielleicht nicht . Paarprogrammierung könnte eine großartige Vorgehensweise sein. Ich bin mir nicht sicher, ob ich das tun würde, um Legacy-Code zu testen, aber vielleicht mit ein bisschen Greenfield-Code. Danke. Solide Beratung.
@ThatGuy-Leute werden höchstwahrscheinlich auch nicht herauskommen und das sagen. Dem Neuen zu sagen: „Hey, wir älteren Leute wissen nicht, wie man etwas macht, von dem Sie denken, dass es grundlegend ist und das das Management will“, ist unwahrscheinlich. Legacy-Code, mit dem Sie nicht vertraut sind, ist dafür perfekt . Sie können etwas sagen wie: „Ich hoffe, einige Tests für Legacy-Code schreiben zu können, und Sie sind mit dieser Codebasis besser vertraut – können Sie mir helfen?“ und wieder, sprechen Sie einfach durch den Prozess, während Sie es tun. Menschen mögen Schmeicheleien im Allgemeinen und um Hilfe zu bitten, ist eine großartige Möglichkeit, sich in Zukunft Unterstützung aufzubauen.
Das ist ein ziemlich gutes Argument. Punkt genommen.

Um Code-Reviews praktikabel zu machen, brauchen Sie ein System, das sie erleichtert. Zum Beispiel wie GitHub es mit Pull Requests macht oder wie GitLab mit Merge Requests. Ich habe tolle Dinge über Gerrit gehört, aber ich habe es nicht benutzt. Installieren Sie eines davon oder ähnliches (zunächst auch nur auf Ihrem eigenen PC), sonst ist es einfach nicht praktikabel.

Hier ist ein Beispiel für die Einführung von Codeüberprüfungen bei einem Kollegen, der GitHub verwendet.

Implementieren Sie eine einigermaßen interessante Änderung in einem Zweig und lassen Sie absichtlich einige Fehler ein. Erstellen Sie einen Pull-Request und bitten Sie einen Teamkollegen, ihn freundlicherweise zu überprüfen. Setzen Sie sich zu ihm, zeigen Sie ihm Ihren Fehler und wie er einen Kommentar in die entsprechende Zeile eingeben kann. Führen Sie ihn durch den Rest Ihrer Änderungen, wenn er irgendwelche Bemerkungen macht, bitten Sie ihn, sofort einen Kommentar einzugeben. Nachdem Sie alle Änderungen gemeinsam überprüft haben, kehren Sie zu Ihrem Schreibtisch zurück, übernehmen Sie die Korrekturen und geben Sie sie weiter. Die früheren Kommentare werden aus dem Pull-Request entfernt. Bitten Sie ihn, einen weiteren Pass zu machen, falls er noch etwas findet. Wiederholen Sie dies, bis er nichts findet und der Pull-Request akzeptiert werden kann.

Zeigen Sie es auch anderen Teamkollegen, weisen Sie ihnen weiterhin Pull-Requests zu und ermutigen Sie sie, dasselbe mit Ihnen zu tun. Hoffentlich setzt sich die Praxis durch.

Der Prozess ist bei GitLab (kostenloser Klon von GitHub) genau gleich, aber sie nennen Pull Requests Merge Requests. Ich weiß nicht, bei Gerrit und anderen würde ich mir vorstellen, dass es ähnliche Funktionen gibt.

Wir haben diese Idee in den letzten 3 Jahren bisher in zwei Teams umgesetzt. Es ist die beliebteste Methode, die wir implementiert haben. Die Leute, die es machen, lieben es und schicken mir gelegentlich Zusammenführungsanfragen, selbst nachdem ich zu einem anderen Team gewechselt bin. In meinen neuen Teams versuche ich, die Praxis genau so zu verbreiten, wie ich es oben beschrieben habe.

Was Unit-Tests angeht:

  • Bringen Sie ein kontinuierliches Build-System zum Laufen, das Unit-Tests als Teil des Builds ausführt.
  • Schlagen Sie einen Brown-Bag-Lunch-Talk vor, der Beispiele für gute Unit-Tests und schlechte Unit-Tests zeigt. Legen Sie die von Ihnen verwendeten Inhalte in einem öffentlichen Repository ab.
  • Schreiben Sie gute Unit-Tests und weisen Sie Merge Requests einem Teamkollegen zu, der am ehesten von der Idee überzeugt ist.
  • Setzen Sie sich dafür ein, dass jeder (mindestens) einen Unit-Test pro Woche durchführt. Achten Sie darauf, den Fortschritt zu messen und zu verfolgen (ich verwende eine einfache Excel-Tabelle).

Was die Verbesserungen der Codequalität betrifft:

  • Holen Sie sich ein statisches Analysetool, das in das kontinuierliche Build-System integriert ist. Zum Beispiel SonarQube.
  • Implementieren Sie Korrekturen an Problemen, die vom statischen Analysetool aufgeworfen wurden, und weisen Sie Zusammenführungsanfragen einem Teamkollegen zu, der die Idee am wahrscheinlichsten unterstützt.
  • Schlagen Sie vor, Bücher zu kaufen, die bekanntermaßen gute Ressourcen in Ihrem Bereich sind, lassen Sie sie auf Ihrem Schreibtisch liegen und ermutigen Sie andere, jederzeit mitzunehmen und auszuleihen.
  • Setzen Sie sich für eine Praxis ein, bei der jeder (mindestens) eine Korrektur von Problemen durch das statische Analysetool pro Woche durchführt. Achten Sie darauf, den Fortschritt zu messen und zu verfolgen (ich verwende eine einfache Excel-Tabelle).

Beachten Sie das gemeinsame Muster in den beiden obigen Beispielen:

  1. Holen Sie sich ein Tool-Setup, mit dem Sie Ihre Ziele effizient erreichen können
  2. Verwenden Sie Code-Reviews, um mit gutem Beispiel voranzugehen
  3. Holen Sie sich zusätzliche unterstützende Materialien
  4. Setzen Sie sich dafür ein, Verbesserungen in kleinen, überschaubaren Schritten umzusetzen

All diese Ideen sind so kleine und einfache inkrementelle Änderungen, dass sie wirklich einfach zu verkaufen sind.

Anpassen und eine an Ihre Umgebung angepasste Variante verwenden.

Danke dafür. Ich bin eher davon überzeugt, dass ich es lehren muss, wenn das passieren soll. Dies wird definitiv helfen.
Wie bringe ich als Neuling die Leute dazu, all ihr großes Gerede in die Tat umzusetzen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v