Sollte ein (Junior-) Entwickler versuchen, bessere Prozesse und Praktiken in seinem Entwicklungs- / IT-Team voranzutreiben?

108

Ich bin ein Junior-Entwickler, der die Möglichkeit hat, die Prozesse meines Teams mitzugestalten, wenn ich die Änderung rechtfertigen kann und wenn dies dem Team hilft, seine Arbeit zu erledigen. Dies ist neu für mich, da meine früheren Unternehmen mehr oder weniger fest definierte Prozesse hatten, die vom Management kamen.

Mein Team ist ziemlich klein und etwas neu (<3 Jahre alt). Ihnen fehlt:

  • ein gut definiertes Softwareentwicklungs- / Arbeitsmanagement-Framework (wie Scrum)
  • starke Produktverantwortung
  • gut definierte Rollen (zB Business-Mitarbeiter führen manuelle Tests durch)
  • regelmäßige Stand-up-Meetings
  • ein konsolidierter Issue-Tracking-Prozess (wir haben ein Tool, der Prozess wird noch entwickelt)
  • eine Einheit, ein System, eine Regression oder eine manuelle Testsuite oder -liste
  • Dokumentation zu Geschäftslogik und -prozessen
  • Eine Wissensdatenbank, um interne und kundenbezogene Tipps zu dokumentieren

Und die Liste geht weiter. Das Management ist offen für die Umsetzung von Verbesserungen, solange der Wert gerechtfertigt ist und es hilft, die wichtigste Arbeit (nämlich die Entwicklung) zu erledigen. Die zugrunde liegende Annahme ist jedoch, dass Sie die Verantwortung für die Implementierung übernehmen müssen, da dies niemand für Sie tun wird. Und es versteht sich von selbst, dass einige der oben genannten Projekte nicht trivial, zweifellos zeitaufwendig und eindeutig keine Entwicklungsarbeit sind.

Lohnt es sich für einen (Junior-) Entwickler, sich im Laufe der Zeit für das oben Gesagte einzusetzen? Oder ist es am besten, "auf Ihrer Spur zu bleiben" und sich auf die Entwicklung zu konzentrieren und den Großteil der Prozessdefinition und Optimierung dem Management zu überlassen?

overflow831
quelle
10
Ich stelle fest, dass einer Ihrer Tags Scrum ist. Ist Ihr Team ein Scrum-Team? Und wenn ja, halten sie Retrospektiven ab?
Daniel
10
Gibt es einen Grund, warum Sie "sie" anstelle von "wir" verwenden? ZB "Mein Team ist ziemlich klein und etwas neu (<3 Jahre alt). Ihnen fehlt"?
Thomas Koelle
40
Nur ein FYI, wenn Sie für mehrere Unternehmen gearbeitet haben, sind Sie wahrscheinlich kein Junior mehr.
Kevin
11
Was lässt Sie denken, dass die Dinge, die Sie auflisten, "besser" sind und nicht nur die letzte zeitverschwendende Modeerscheinung? Können Sie einen vernünftigen Fall für jeden machen?
Jamesqf
11
"Das Management ist offen für die Implementierung von Verbesserungen [..]" , was weitgehend irrelevant ist, wichtiger ist, ob der Rest Ihres Teams dafür offen ist oder nicht. Wenn dies nicht der Fall ist, ist das Management-Buy-In, aber nicht das Team-Buy-In ein Weg zu einer kontroversen Beziehung mit dem Rest Ihres Teams.
Mark Rotteveel

Antworten:

179

Bisher gute Antworten, aber sie decken nicht alle Grundlagen ab.

Nach meiner Erfahrung verfügen viele Leute, die gerade das College abgeschlossen haben, über fantastische theoretische Kenntnisse - weitaus besser als ich oder viele andere Senioren, die jahrzehntelang Software für ihren Lebensunterhalt entwickelt haben.

ABER, und das ist ein großer ABER, dass Wissen in keinem praktischen Szenario verankert ist. In der realen Welt fällt ein Großteil dieser Theorie ins Wanken oder muss zumindest mit einem massiven Salzkorn genommen werden, da es sich in der Praxis als ungeeignet herausstellt, in einem realen Szenario so gut zu funktionieren.

Ein typisches Beispiel: Eine Anwendung, an der ich vor langer Zeit gearbeitet habe, wurde von einem brillanten OO-Theoretiker entworfen, der so konzipiert ist, dass er den Prinzipien und der Theorie von OO bis T folgt und überall viele Muster anwendet.

Es war ein fantastisches Stück Software-Design.

Leider führte dies zu einem Produktions- und Wartungsalptraum. Die Codebasis war so groß und komplex, dass Orte nicht geändert werden konnten. Nicht weil es besonders spröde war, sondern weil es so komplex war, wagte es niemand, es zu berühren, aus Angst vor dem, was passieren würde (der ursprüngliche Architekt / Designer war ein Bauunternehmer, der längst gegangen war).

Es lief auch sehr schlecht, gerade aufgrund der vielschichtigen Struktur von Mustern und der erforderlichen Klassenbibliotheken. Wenn Sie beispielsweise auf eine Schaltfläche auf einem Bildschirm klicken, um die Datenbank einmal aufzurufen, führt dies zu mehreren hundert Objektinstanziierungen und Methodenaufrufen. Dies alles dient der Gewährleistung einer losen Kopplung und dergleichen.

Dieser Architekt war Universitätsprofessor mit mehreren Büchern zu diesem Thema. Er hatte noch nie einen Tag als Programmierer an einem kommerziellen Projekt gearbeitet.

Menschen mit praktischer Erfahrung in der Erstellung von Software hätten erkannt, zu welcher Monstrosität dieses Design zwangsläufig führen würde, und einen pragmatischeren Ansatz gewählt, der zu einem System führt, das einfacher zu warten ist und auch eine bessere Leistung erbringt.

Dasselbe kann für viele andere Dinge gelten, denen Sie als frisch Absolvent oder als neuer Mitarbeiter in einem Unternehmen begegnen. Gehen Sie nicht davon aus, dass es keinen guten Grund dafür gibt, dies so zu tun, da Ihre theoretische Grundlage besagt, dass etwas nicht stimmt oder nicht optimal ist.

Selbst jetzt, da ich über 20 Jahre Erfahrung auf diesem Gebiet habe, muss ich nicht kritisieren, wie die Dinge in Unternehmen ablaufen, mit denen ich zusammenarbeite. Ich erwähne im Vorbeigehen, dass ich bemerkt habe, dass die Dinge anders sind, als ich es am besten empfunden habe, aber nicht auf kriegerische Weise. Dies führt oft zu interessanten Gesprächen darüber, warum diese Dinge so sind, wie sie sind. Vielleicht werden Änderungen eintreten und vielleicht auch nicht, je nachdem, ob der Wert von Änderungen geringer ist als die Kosten.

Haben Sie keine Angst davor, Dinge vorzuschlagen, die besser gemacht werden könnten, aber achten Sie immer darauf, dass Sie nicht als Besserwisser, sondern als Mitarbeiter auftreten, der versucht und bereit ist, nicht nur zu lernen, sondern auch dazu beitragen, Prozesse zur Verbesserung des Unternehmens zu verbessern, nicht nur die theoretische Korrektheit.

jwenting
quelle
19
Ich könnte Ihrer Beobachtung nicht mehr zustimmen. Übung ist bei weitem der beste Weg zu wissen, was funktioniert, und selbst dann gibt es immer noch mehr und anderes.
Kain0_0
226
Wenn ein Projekt wahnsinnig komplex und schrecklich zu ändern ist, dann ist es kein „fantastisches Stück Software-Design“.
Steve Chamaillard
85
Diese Antwort klingt so, als ob OOP ein Wissensbestand ist, von dem Akademiker besessen sind, während die Branche "besser weiß". Meiner Erfahrung nach ist es umgekehrt: Akademiker interessieren sich sehr wenig für OOP, während viele Unternehmen immer noch davon besessen sind. Akademiker beschäftigen sich in der Regel mit zeitloseren, aber undurchsichtigen Konzepten (deren Wert von der Branche oft erst nach Jahrzehnten geschätzt wird).
Theodoros Chatzigiannakis
13
Erwarten Sie außerdem, dass leitende Ingenieure Modeerscheinungen im Auge behalten .
John Wu
67
"Es war ein fantastisches Stück Software-Design. Leider war es in Produktion und Wartung ein Albtraum." Der zweite Teil bedeutet, dass der erste nicht wahr ist. Gutes Design macht Software per Definition besser. Wenn die Theorie nicht wirklich funktioniert, ist sie einfach falsch und es ist eine schreckliche Idee, ihr zu folgen.
jpmc26
43

Ja, aber mit viel Sorgfalt!

Lassen Sie mich das klarstellen.

Sie sollten sich bemühen, die Habitabilität der Software zu verbessern. Wenn Sie sich den Code / das Team / das Unternehmen / das Projekt / das Management ansehen und als erstes duschen, ist er nicht bewohnbar. Wenn Ihre erste Antwort ist, ja zu schreien! ... und sich dann zu beschweren, wenn Sie nicht im Büro sind, dann müssen Sie Ihr Zuhause bewohnbarer machen. Es ist ein Gefühl, und Sie werden es wissen.

Davon abgesehen arbeiten Sie in einer komplizierten Symathese . Alles, was Sie tun, wird wahrscheinlich schief gehen und die Situation zumindest kurzfristig verschlimmern, da eine einfache Änderung Wellen hat. Also werde zuerst demütig, ich meine nicht, dass du vorbeischiebst oder akzeptierst, dass die Dinge schlecht sein müssen.

Das Problem

Mit den besten Absichten könnten Sie das Gefühl haben, dass eine umfassende Veränderung stattfinden muss, und ich bin nicht anderer Meinung, dass diese Situationen existieren, aber nehmen Sie sich einen Moment Zeit, um darüber nachzudenken. Das aktuelle System funktioniert, Sie und Ihr Team produzieren Code, vielleicht ist er langsam, vielleicht ist er schmerzhaft, aber es funktioniert und Sie haben alle Erfahrung damit. Sie wissen ungefähr, was Sie erwartet, kurz, Sie sind Profis in diesem System.

Nach der umfassenden Änderung weiß jedoch niemand, außer vielleicht dem Implementierer, was zu erwarten ist. Kurz gesagt, jeder wurde in diesem Teil des Systems auf ein Neophyten-Level zurückgesetzt. Das ist nicht gut. Neophyten müssen die neuen Regeln lernen, was Zeit kostet. In dieser Zeit machen Neophyten Fehler, weil sie nicht geübt werden. Diese Fehler werden Teil des Systems, mit dem Sie jetzt leben müssen, und es ist nicht annähernd so funkelnd wie jetzt.

Ein Weg nach vorne

Es gibt Zeiten, in denen das Schneiden, Brennen und Wiederherstellen bei weitem das Beste ist, was Sie tun können. Es ist besonders attraktiv, wenn im alten System niemand geübt wird, weil nur das kodifizierte Wissen verloren geht. Wenn dieses Wissen völlig unverständlich ist, dann ist es bereits verloren, und von vorne zu beginnen ist die einzige Wahl. Umgekehrt, wenn die Methode der Kodifizierung oder ihre Verwendung problematisch ist, aber funktioniert, ist dieses Wissen immer noch verfügbar und es lohnt sich vielleicht, es beizubehalten, vielleicht auch nicht. Treffen Sie die Entscheidung einfach nicht leichtfertig.

Die andere Möglichkeit besteht darin, mit dem System so zu arbeiten, dass jeder einen Bezugsrahmen hat, aber kleine Teile des Systems so zu ändern, dass jeder im Team davon Kenntnis hat, oder wenn er sich der Änderung nicht bewusst ist, ist beides einfach bemerken und leicht zu erlernen. Dies ist die Grundlage für die Praktiken, die Kaizen genannt werden . Eine stärker auf Entwickler ausgerichtete Formel wird in der Präsentation Shaving the Golden Yak vorgestellt. Ich empfehle dringend, sie sich anzusehen und zu überlegen.

So finden Sie eine kleine Sache, die geändert werden kann, die Ihr Leben verbessern wird, und hoffentlich die von ein paar anderen. Korrigieren oder verbessern Sie die Situation. Dies gibt Ihnen Übung und Erfahrung bei der Umsetzung von Änderungen in die Praxis. Stellen Sie sicher, dass Sie Feedback erhalten: Hätten Sie es besser besprechen können, war es tatsächlich nützlich, hat es einen anderen Teil des Systems verärgert? Entwickeln Sie ein Gespür dafür, was getan werden kann und wie es getan werden kann.

Nun sind drei Dinge passiert:

  • Sie haben das System verbessert,
  • Sie haben Erfahrung mit dem Ändern des Systems
  • Das Team hat gesehen, dass Sie das System erfolgreich geändert haben.

Wählen Sie jetzt eine weitere Möglichkeit zur Verbesserung, da Ihre Erfahrung zunimmt und Sie Probleme mit niedrigen Hängen beseitigen. Sie werden sich mit den schwierigeren Problemen im System auseinandersetzen müssen, aber zumindest jetzt, wenn Sie sagen, wir müssen X ändern:

  • Sie wissen, wie sich die Änderung auf das System auswirkt
  • Sie wissen, welche Probleme entstehen (welche Regeln müssen neu gelernt werden)
  • Sie kennen einige sofortige Möglichkeiten, um Probleme zu beheben oder zu verbessern, die durch die Änderung verursacht werden
  • Die Menschen in Ihrer Umgebung wissen, dass Sie sich mit dem System auskennen und in der Lage sind, es erfolgreich zu ändern
Kain0_0
quelle
Vieles, dem man zustimmen kann. Hervorzuheben ist, dass keine Codebasis oder Prozedur perfekt ist. alles ist immer ein kompromiss. Und so sehr Sie vielleicht alles wegwerfen und von vorne anfangen möchten, wie Sie sagen, IME ist es normalerweise weitaus besser, sich langsam und in kleinen Schritten zu entwickeln. Auf diese Weise können Sie jeden mitnehmen und vermeiden, dass vorhandenes Wissen verloren geht. Wichtig ist, dass Sie wissen, wohin Sie möchten. Auf diese Weise können Sie die sich bietenden Gelegenheiten erkennen und nutzen.
gidds
@gidds Ich denke, das war mein Punkt, es ist am besten, kleine Änderungen vorzunehmen, die jeder kennt oder die zumindest offensichtlich für ihn geändert hat und die leicht zu lesen sind. Ich glaube zwar, dass es wichtig ist, ein langfristiges Ziel im Auge zu haben, um Ihnen bei der Auswahl und Auswahl der Möglichkeiten zu helfen, wie Sie Dinge verbessern können, aber ich denke nicht, dass es immer möglich ist, eines zu formulieren, insbesondere für Junior-Entwickler mit begrenzter Erfahrung in im maßstab mit menschen arbeiten. Das Formulieren von Verbesserungen des Status Quo ist viel einfacher. ärgert dich das Ja Was können Sie tun, um die Situation zu verbessern?
Kain0_0
Wenn @gidds Ihren Kommentar noch einmal liest, bin ich damit einverstanden, dass keine Prozedur oder kein Prozess perfekt ist oder sogar auf eine bestimmte Situation anwendbar ist, und wenn ein Fehler behandelt wird, kann das Team sogar an einen schlechteren Ort gebracht werden, als wenn man es noch nie versucht hätte. Trotzdem ist das Endergebnis in der Regel ein Kompromiss zwischen allen konkurrierenden Anforderungen, die die Software und ihr Team irgendwie erfüllen müssen. Das ist viel schwieriger, wenn sich das Geschäft in einer regulierten Branche befindet. Regierungen mögen Regelverstöße nicht.
Kain0_0
20

Ja, du kannst. ABER...

Du musst vorsichtig sein.

Zu Beginn meiner Karriere (vor sehr langer Zeit) hatte ich das Glück, als "Junior" in ein paar Monate altes Projekt einzusteigen.

Als erstes ist mir aufgefallen, dass es (OMG) kein Code-Repository gibt! Alle Code-Zusammenführungen wurden manuell durchgeführt, indem Zip-Dateien per E-Mail aneinander gesendet wurden.

Also ging ich zu meinem (auch neuen) Manager und schlug vor, dass wir ein Repository haben sollten. Antwort war: Ok, organisiere es ....

Das Organisieren eines Code-Repositorys ohne Hilfe war also neu in der Firma. Das war eine demütigende Erfahrung.

Als ich alles eingerichtet habe, wollte (Schock) niemand es benutzen. Also habe ich versucht, die Dinge voranzutreiben, und zum Glück hat mein Vorgesetzter verstanden, wie wichtig es ist, und ich hatte Unterstützung.

Dies hatte jedoch zur Folge, dass ich nicht sehr beliebt war und leider einen Spitznamen bekam, der vom Versionsverwaltungssystem abgeleitet war.


Meine Meinung dazu ist also, zuerst Ihre Teammitglieder zu verstehen, was sie als nächstes für wichtig halten.

Vielleicht haben sie auch eine Liste wie deine. Vielleicht haben sie alles durch und wollten das "Ding" auf der Liste machen. Vielleicht sie .... (was auch immer) ....

Das ganze Team muss ausgerichtet werden.

Aber wenn nicht, können Sie trotzdem professionell arbeiten. Und finde Gleichgesinnte und arbeite zusammen, wie du denkst, dass es gemacht werden sollte. Wenn dies gute Ergebnisse bringt, werden mehr Menschen mit Ihnen zusammenarbeiten, und es wird schließlich "der" Prozess.

Genau wie bei Code gilt auch für Entwicklungsprozesse: Es ist eine kontinuierliche Verbesserung erforderlich.

Also ja, du solltest immer versuchen, das zu verbessern, was möglich ist, zu verbessern.

Aber denken Sie auch daran, dass viele Leute, mit denen Sie arbeiten, bereits Profis sind und wissen, was falsch ist und was gebraucht wird.

Robert Andrzejuk
quelle
1
Es hört sich für mich so an, als ob Sie den Leuten den Rücken gekehrt hätten, ohne Ihren Mitentwicklern zuvor etwas zu rechtfertigen. Niemand mag "diesen Kerl". Wenn Sie also Verbesserungsvorschläge haben, sprechen Sie sie mit Ihren Kollegen an. Am wichtigsten ist jedoch, dass Sie in der Lage sind, Ihre Vorschläge zu begründen. Warum wird es die Dinge verbessern? Wie werden die Menschen Zeit und Mühe sparen? Gibt es irgendwelche Nachteile für den neuen Weg? Etc. Wenn Sie Antworten auf die Bedenken von Personen vorhersagen und vorbereiten können, werden diese Ihre Vorschläge eher bereitwillig als mit Gewalt annehmen.
Alex
2
Ich hatte nicht das Gefühl, dass es "hinter den Rücken der Menschen geht". Ich habe das Problem meinem Vorgesetzten gemeldet, er hat mir gesagt, ich solle mich darum kümmern, und das habe ich auch getan.
Robert Andrzejuk
17
"Bekomme leider einen Spitznamen, der vom Versionsverwaltungssystem abgeleitet ist." LOL Ich hoffe du hast keinen Schwachsinn genommen.
BЈовић
Git war noch nicht da.
Robert Andrzejuk
10
@ BЈовић Vielleicht nannten sie ihn "subversiv" ... :-)
Alexander
14

Lohnt es sich für einen (Junior-) Entwickler, sich im Laufe der Zeit für das oben Gesagte einzusetzen?

Ja, es lohnt sich immer zu versuchen, die Dinge zu verbessern. Sie wissen am besten, mit welchen Problemen Sie konfrontiert sind.

Aber wie Sie bereits erwähnt haben, gibt es viele Probleme zu lösen, und viele dieser Probleme sind nicht besonders wertvoll. Und an vielen Orten wird es unüberwindbare Hindernisse für Ihren Erfolg oder für andere Menschen geben, die weitaus besser positioniert sind, um sich für sie einzusetzen. Sie sollten also immer versuchen, die Dinge zu verbessern, auch wenn dies bedeutet, dass Sie auswählen, welche Dinge Sie in Ihrer Zeit verbessern möchten.

Denn am Ende sind Sie Teil des Problems, wenn Sie nicht Teil der Lösung sind.

Telastyn
quelle
13

Ja. Aber organisatorische Veränderungen sind selbst für Senioren schwierig. Wenn Sie also wirklich etwas bewirken möchten, tun Sie es auf die richtige Art und Weise:

  • Nicht in den ersten Wochen: Verwenden Sie diese Zeit, um:

    • Erstellen Sie einen guten ersten Eindruck. Zeigen Sie, dass Sie in das Team passen.
    • Verstehe die Kultur und Politik deines Unternehmens. Ist es sicher, auf Änderungen zu drängen?
    • Bauen Sie eine gute Beziehung zu Kollegen auf
    • Erfahren Sie mehr über die Abläufe, Regeln und Bedürfnisse Ihres Teams
    • Lerne deine Arbeit und mache sie so gut du kannst. Sie werden sicherlich beschäftigt genug sein.
  • Wählen Sie Ihre Schlachten. Erhalten Sie einige frühe Siege : Sie können mit Energie anreisen, um alles zu ändern, aber das ist unrealistisch. Konzentrieren Sie sich auf einige niedrig hängende Früchte und zeigen Sie, dass Ihre Ideen funktionieren. Sie möchten, dass sie für komplexere Verbesserungen empfänglich sind. Und denken Sie daran, dass es in Büchern einfacher ist.

  • Betrachten Sie die Implikation für andere : Ich mache Refaktoren, die viele Dateien betreffen. Selbst wenn sie den Code verbessern, muss ich sehr vorsichtig sein, um zu vermeiden, dass das Zusammenführen zu einem Schmerz im Arsch wird. Versuchen Sie auch zu verstehen, warum sie so weitermachen. Möglicherweise können sie Scrum nicht verwenden, da ihnen Tests fehlen und sie verständlicherweise Angst haben, nicht getesteten Code häufig in die Produktion zu bringen. Einen realisierbaren Test zu schreiben ist keine leichte Aufgabe. Der aktuelle Code könnte wirklich schwer zu testen sein. Darüber hinaus darf das Team weder zum Schreiben von Tests noch von testbarem Code verwendet werden. Die aktuelle Codebasis ist möglicherweise nur schwer zu testen und muss überarbeitet werden. Es kann Jahre dauern, bis dieses Problem behoben ist, aber Sie können sich zumindest auf die eigentliche Ursache konzentrieren.

  • Urteile nicht. Verlange nicht. Fragen Sie danach und hören Sie genau zu: Dies ist ein Moment, in dem die Kommunikation von entscheidender Bedeutung ist und wir, die Programmierer, in subtilen Nuancen normalerweise nicht sehr gut sind. Es gibt Techniken, die helfen . Es ist einfach, unsere Idee weiter voranzutreiben, anstatt sich auf die Antwort zu konzentrieren. Stellen Sie zunächst sicher, dass sie das Gefühl haben, dass Sie ihre Punkte haben. Verstehe, dass Gefühle wichtig sind. Was fühlen sie sich durch diese Veränderung? Angst? Unzulänglichkeit? Zorn? Frustration? Hoffnung? Faul? Blöd? (Machen Sie niemals Leute dumm). Natürlich hättest du vorher viele Fragen gestellt und das wird viele falsche Schritte verhindern.

  • Lassen Sie sich vom Beispiel leiten: Beschwerden sind einfach, Änderungen sind schwierig. Zeigen Sie Ergebnisse und die Leute werden es Ihnen glauben. Wenn sie keinen Test verwenden, können Sie Ihre Komponententests schreiben. Wenn keine Dokumente vorhanden sind, können Sie einige Google-Dokumente für das Team freigeben. Verstehen Sie, dass "Ok, mach es" eines der bestmöglichen Szenarien ist, und dann müssen Sie liefern. In diesem Fall müssen Sie überlegt haben, welche Ressourcen Sie benötigen . Beispiel: Geben Sie mir eine kleine Amazon-Instanz und zwei Stunden von den Administratoren für einen Jenkins-Server

  • Halten Sie es klein und einfach (und billig): Sie möchten nicht auf eine formelle Budgetgenehmigung warten oder Ihre Chefs glauben, dass Sie wertvolle Zeit von teuren Programmierern verlieren. Es wäre großartig, wenn dieser Code die Software überprüfen oder mehrere Open-Source-Tools evaluieren würde, aber wir werden das Repo im Moment nur verwenden.

  • Kritische Masse erreichen: Treffen Sie eine Gruppe von Menschen, die sich auf die Verbesserung der Qualität konzentrieren. Sie können sogar mit ihnen zu Konferenzen gehen und um Hilfe oder Mentoring bitten. Peopleware beschreibt das "Aufwecken des Riesenphänomens", in dem sich die Basis des Teams buchstäblich gegen einige dumme Praktiken auflehnt, die die Produktivität verlangsamen. Dies wäre im Einzelfall sehr gefährlich gewesen und ich hätte es nicht weiterempfehlen können. Aber wenn sich alle einig sind, ist der Wechsel einfacher.

  • Lass dir etwas Zeit. Stimmen Sie anschließend mit Ihren Füßen ab: Möglicherweise möchten Sie es einige Monate lang bis zu zwei Jahre lang ausprobieren. Einige Unternehmen haben jedoch keine einfachen Lösungen. Einige Teams möchten sich nicht ändern und haben keine Anreize. Und manche Codebasen sind pures Grauen. Wenn Sie das Gefühl haben, dass Sie gegen die Welt sind, denken Sie daran, dass es im Jobpool viele Angebote gibt. Sie möchten bewährte Praktiken lernen und sind auf lange Sicht besser in einer Situation, in der Sie etwas weniger verdienen, aber Erfahrungen sammeln, die Sie wertvoller machen.

Bonus: Wenn Sie erfolgreich sind, schreiben Sie es für Ihren Lebenslauf / Ihre Interviews auf. Als Junior hat man normalerweise sehr wenig zu sagen und eine Veränderung zum Besseren herbeizuführen, ist immer ein gutes Zeichen. Sie möchten eine sehr klare und realistische Vorstellung davon haben, was Sie persönlich getan haben und was die Arbeit anderer war. Stellen Sie sich die folgende Interviewfrage vor.

  • Erzählen Sie mir von einer Zeit, in der Sie im Team einen Unterschied gemacht haben.
  • Nun, ich war an einem Ort, an dem es sehr altmodische Praktiken gab. Viele Leute waren damit nicht zufrieden und die Produktivität hatte einen großen Spielraum, sich zu verbessern. Also schlug ich vor, ein schnelles Experiment mit Retrospektiven durchzuführen, wir machten X und Y und als Ergebnis hatten wir dieses wundervolle messbare Ergebnis. "
Borjab
quelle
„Nicht in den ersten Wochen“ Ich denke, dass es gerade in den ersten Wochen viel bringen kann, einfach nur Fragen zu stellen. Sie lernen nicht nur das Projekt und den Arbeitsablauf kennen, sondern bringen Ihre Kollegen auch dazu, sich Gedanken darüber zu machen, warum X in Y und nicht in Z ist, fehlende Dokumentation, umständliche Tools (warum benötige ich 20 Befehle, um meine Änderung zu integrieren?) Usw
Michael
1
Ich kann es falsch ausgedrückt haben: Natürlich sollten Sie Fragen zu anderen Momenten und besonders in den ersten Tagen stellen. Meine Absicht ist, aber vielleicht, dass Sie als Junior in den ersten Tagen nicht auf Veränderungen drängen, weil Sie vielleicht ein Besserwisser sind und es Ihnen an Werkzeugen mangelt, um etwas so Schwieriges wie eine Organisation zu verändern
Borjab
9

Ja. Aber nicht die Dinge, die Sie vorschlagen.

Aus Ihrer Liste heraus sind Unit- / Integrationstests das einzige Element, bei dem Sie Fortschritte erzielen können.

Sie können diese mit minimalem Zeitaufwand selbst hinzufügen und sofort den Wert anzeigen. Es ist ein technisches Problem mit allgemein akzeptierten Vorteilen, das die Arbeitspraktiken anderer nicht beeinträchtigt. Gleichzeitig erhalten Sie mehr Kenntnisse über die Codebasis, auch wenn die Ergebnisse nicht akzeptiert werden. Ein einfacher Verkauf.

Die anderen sind in der Regel Geschäftsprozesse, an denen das gesamte Team oder sogar andere Teams beteiligt sind. Sie können Verbesserungen vorschlagen, die sich für einen Nachwuchsmitarbeiter jedoch nur schwer ändern lassen. Der Änderungsprozess ist in der Regel technisch nicht relevant und steht wahrscheinlich in keinem Zusammenhang mit Ihrer normalen Arbeit.

Ich würde auch Dinge wie das Einrichten von CI-Pipelines, automatisierte Bereitstellungen, Versionsverwaltung und das Packen von Bibliotheken als gute Angriffsmöglichkeiten vorschlagen

Ewan
quelle
6
Als Juniorangestellter schlug ich all dies vor. Über mehrere Jahre hinweg habe ich sie dann mit etwas Unterstützung (und viel Buy-in) erfolgreich implementiert. Am Ende war ich der leitende Architekt. Es kann funktionieren und es lohnt sich oft, es zu versuchen. ;) Sie müssen jedoch Ihre Schlachten auswählen und wissen, wann Sie vor einem harten Kampf um etwas stehen, das möglicherweise nicht einmal gut zum Profil / der Dynamik der Organisation passt. In einer weiteren Rolle war ich den gleichen Weg zu gehen versucht, und beschlossen , nicht einmal das Thema anschneiden , weil dort würde es nie gearbeitet haben und war nicht besonders wichtig.
Leichtigkeitsrennen im Orbit
4
Unit-Test und kontinuierliche Integration sind eine gute Wahl, um zu beginnen. Sie bieten Ihnen den besten Return on Investment. Probieren Sie Scrum nicht ohne die technischen Methoden aus, die es ermöglichen, zu funktionieren. Wie kann es zu häufigen Bereitstellungen kommen, wenn alle gefährlich sind und viel Arbeit von Testern und Systemadministratoren erfordern?
Borjab
Unit-Tests / Integrationstests sind aufgrund der Architektur nicht unbedingt etwas, mit dessen Implementierung man sofort beginnen kann. Darüber hinaus neigen sie dazu, bestimmte Muster zu erzwingen, die gegen die bestehende Ordnung der Dinge verstoßen können. Sie haben zwar Wert, aber es ist nicht immer ein einfacher Homerun, wie vorgeschlagen.
NPSF3000,
2

Es hängt davon ab:

  • Wie viel erwarten Sie von besseren Praktiken?
  • wie viel Mühe Sie aufwenden müssen, um dorthin zu gelangen
  • Was sind die Erfolgsaussichten und Risiken - von einfachen Adoptionsfehlern bis zu neuen Praktiken sind sie furchtbar, die Codequalität verschlechtert sich, Schlüsselpersonen gehen, jeder hasst Sie und Sie müssen einen anderen Job in einer anderen Stadt finden, in der niemand Ihren Namen kennt

Grundsätzlich gilt: Es liegt in Ihrer Verantwortung, sich angemessen für das einzusetzen, was Sie für am besten halten. Die Entscheidung sollte jedoch in der Verantwortung eines Teams oder des Managements liegen. Denken Sie daran, dass es sich selten lohnt, Menschen zu entfremden, auch wenn Sie am Ende bessere Praktiken haben.

ptyx
quelle
1

Beginnen Sie nicht mit den kompliziertesten Dingen wie Scrum. Beginnen Sie mit den einfachsten Schritten.

Sie haben die Quellcodeverwaltung nicht erwähnt. Haben Sie ein Quellcode-Repository (git, svn, cvs, ...)? Eine Strategie zum Markieren und Verzweigen? Dies sind einfache Schritte, die ein Anfänger ausführen kann. Lesen Sie, welche Probleme diese Schritte lösen (versuchen) und wie dies Ihrem Unternehmen hilft, die Kosten zu senken (das ist es, woran das Management interessiert ist).

Der nächste Schritt könnten automatisierte Builds sein, jede Nacht oder direkt nach jedem Einchecken, z. B. mit Jenkins. Sie können Tests auch automatisch ausführen. Und fügen Sie einige Tools zum Messen der Codequalität hinzu (ach ja: das Definieren einiger Codierungsstandards ist auch ein guter Schritt).

Lesen Sie für Scrum besser über "Extreme Programming" (XP). Scrum basiert auf vielen XP-Ideen und fügt einen formalisierten Prozess hinzu - die XP-Konzepte können auch ohne diesen Prozess verwendet werden.

Schlagen Sie Dinge vor, liefern Sie Hintergrundinformationen, versuchen Sie, andere davon zu überzeugen, sie auszuprobieren, analysieren Sie die Ergebnisse, ... aber erwarten Sie nicht viel Zusammenarbeit von anderen: Die meisten Menschen ziehen es vor, an ihren alten schlechten Gewohnheiten festzuhalten. Aber wenn Sie das nicht versuchen, wird sich nichts verbessern.

Bernhard Hiller
quelle
0

Sie sagten, das Team sei ziemlich neu (3 Jahre alt). Wenn Sie also jetzt einige gute Prinzipien nicht einführen können, wird es 10 Jahre später schwieriger sein, dies zu tun. Einige der Dinge, die Sie erwähnt haben, wie z. B. das Testen und das Versionssystem, könnten Sie bereits vorschlagen, aber werfen Sie den Vorschlag nicht einfach so weg, ohne auf ihre offensichtlichen Vorteile zu achten und die Tools auszuwählen, die Ihr Entwicklungsstapel benötigt.

Billal Begueradj
quelle
0

Stellen Sie am Anfang Fragen

Wenn ich Ihre Liste lese, würde ich die folgenden Fragen vorschlagen (schauen Sie auf Ihre Liste zurück, um zu sehen, wie sie passen):

  • Wie sehe ich, welche Arbeit die Geschäftsinhaber anfordern?
  • Hast du es mit [Scrum] versucht?
  • Wer ist der Product Owner dafür?
  • Welche Rollen gibt es?
  • Was macht [diese Rolle]?
  • Welche Rolle ist für [diese Aktivität] verantwortlich?
  • Haben Sie versucht, täglich aufzustehen?
  • Wie kommuniziere ich meine Hindernisse mit dem Rest des Teams?
  • Wie finde ich heraus, an welchen anderen Teammitgliedern ich arbeite?
  • Sollen wir [dies] in das Issue-Tracking-Tool aufnehmen?
  • Wie sollen wir [dies] in das Issue-Tracking-Tool schreiben?
  • Wenn [dies] passiert, sollten wir es als [das] in das Issue-Tracking-Tool einfügen?
  • Wie testen wir?
  • Wie zeichnen wir unsere Tests auf, damit andere sie wiederverwenden können?
  • Hast du es mit [JUnit] versucht?
  • Wo ist das dokumentiert?
  • Hast du [MediaWiki] ausprobiert?

Ersetzen Sie die Angaben in [Klammern], damit die Fragen sinnvoll sind oder Ihren Prioritäten entsprechen. Erwägen Sie eine Neuformulierung, wenn meine Formulierung nicht zu Ihrem Stil passt.

Möglicherweise haben Sie bereits damit begonnen. Bevorzugen Sie Einzelgespräche gegenüber Gruppengesprächen. Durch Einzelgespräche können Sie besser nachvollziehen, was die andere Person denkt. Ist diese Person für diese Änderung? Dagegen? Schwach? Tollwütig?

Wenn Sie neu sind, ist das Stellen von Fragen praktisch kostenlos. Die Leute sollten erwarten, dass Sie Fragen stellen. Selbst wenn Ihre Fragen implizit eine Position vertreten, der sie widersprechen, sollten sie nicht wütend werden. Sie sollten erklären, warum sie sich dieser Position widersetzen. Ich empfehle, nicht mit ihnen zu streiten. Argumente verhärten Positionen mehr als sie überzeugen. Notieren Sie, wer welche Position hat, und fahren Sie fort.

Später Schritte unternehmen

Suchen Sie nach Möglichkeiten, wie Sie und möglicherweise andere (dh diejenigen, die Sie zuvor als zustimmend eingestuft haben) die gewünschten Änderungen vornehmen können. Will nicht jeder einen Aufstand? Warum nicht? Vielleicht können diejenigen von Ihnen, die einen wollen, Ihren eigenen Standpunkt vertreten. Nicht so effektiv wie mit dem gesamten Team, aber mehr als Sie jetzt haben.

Wenn Sie ein Hindernis haben (und davon ausgehen, dass Sie nicht an einem Standup teilnehmen können), senden Sie eine E-Mail an das Team, um Hilfe zu erhalten.

Identifizieren Sie die Rollen, möglicherweise mit Unterstützung anderer, die Ihnen zustimmen. Gehen Sie konsequent zu Menschen, wenn die Arbeit die Rolle umfasst, die Sie (möglicherweise eine Gruppe, die Sie) für nötig halten. Wenn sie zurückschieben, bitten Sie sie, zu bestimmen, wem diese Rolle gehören soll.

Bitten Sie die Produktbesitzer (die Sie identifiziert haben), Beschreibungen darüber zu verfassen, wie sie der Meinung sind, dass ihr Produkt jetzt und in Zukunft funktionieren sollte.

Installieren Sie ein Testframework (falls andere dies befürworten, treffen Sie eine gemeinsame Entscheidung für welches Framework) und verwenden Sie es für Ihre Projekte. Wenn Sie Fehler beheben, schreiben Sie Tests. Dokumentieren Sie dies im Fehlerbericht auf dem Issue Tracker (geschriebener Test, der den Fehler demonstriert und unter [Ort] gespeichert ist). Ermutigen Sie andere, die Tests auszuführen, wenn sie Änderungen vornehmen. Wenn dies nicht der Fall ist, führen Sie die Tests selbst durch und senden Sie die Probleme bei Bedarf an den Tracker.

Wenn Sie Managementunterstützung erhalten können, installieren Sie Wiki-Software oder ähnliches und beginnen Sie mit der Dokumentation Ihrer Inhalte. Wenn Ihnen jemand Fragen stellt, aus denen hervorgeht, dass er die Dokumentation nicht gelesen hat, weisen Sie ihn auf die entsprechenden Seiten. Ermutigen Sie sie, weitere Fragen zu stellen, wenn sie die Dokumentation nicht verstehen. Wenn sie weiterhin Fragen stellen, die in der Dokumentation behandelt werden, zitieren Sie diese bei der Beantwortung aus der Dokumentation. Ermutigen Sie sie, das Wiki zu aktualisieren, wenn Sie der Meinung sind, dass das Problem eher struktureller Natur ist, als dass sie es nicht lesen.

Ich würde vorschlagen, sich immer nur auf eine Aufgabe zu konzentrieren. Und sicherlich nur einen nach dem anderen schieben. Schieben Sie nicht hart. Sehen Sie sich dieses Beispiel an, bei dem Sie mehr Druck machen, als die Gruppe wollte. Konzentriere dich mehr darauf, dein Verhalten zu ändern als das ihre. Wenn Ihr Weg der richtige ist, sollte dies für die Leute, die Sie beobachten, offensichtlich sein. Taten sagen mehr als Worte. Versuchen Sie, sich nicht mit derselben Person zu wiederholen, wenn Sie stupsen. Wenn Sie das Pferd zum Tränken gebracht haben, können Sie dem anderen überlassen, wann oder ob er trinkt.

Schließlich wirst du älter sein

Im Laufe der Zeit wird Ihr Team neue Mitarbeiter einstellen. Sie werden aufhören, die neue Angestellte zu sein, und Ihre Positionen mit neuen Leuten vertreten können. Arbeiten Sie mit ihnen zusammen, um Änderungen vorzunehmen. Vielleicht stellen Sie auch fest, dass Sie Fortschritte mit Ihren vorhandenen Teamkollegen erzielen. Oder wenn das nicht funktioniert, suchen Sie nach einem neuen Job, bei dem es bessere Praktiken gibt. Es gibt keine wirkliche Eile. Du hast einen Job. Sie können eine Weile auf einen besseren Job warten, entweder indem Sie diesen verbessern oder einen besseren finden.

mdfst13
quelle
+1; eine der besseren antworten mit vielen guten ideen.
Keith
0

Kurze Antwort : Nein, aus allen in den anderen Antworten genannten Gründen. Selbst wenn Sie ein mittlerer oder älterer Entwickler sind, ist es normalerweise besser, zuerst zu versuchen, zu verstehen, wenn Sie einem neuen Team beitreten.

Eine vorgeschlagene Lösung :

1) Wann immer Sie etwas sehen, von dem Sie glauben, dass es verbessert werden sollte, nehmen Sie es zur Kenntnis! (in einem Notizbuch, in einer digitalen Notiz ...)

2) Gehen Sie nach 6 Monaten zu Ihren Notizen zurück und überprüfen Sie diese. Wie viele Ideen fühlen sich jetzt sinnlos und unzureichend an? Höchstwahrscheinlich haben Sie sich einige Verlegenheit erspart. Wenn einige Ideen noch gültig sind, ist jetzt ein guter Zeitpunkt, sie vorzustellen, wenn möglich, indem Sie sie zuerst selbst testen.

Offirmo
quelle
0

Verspätete Antwort, und vereinbaren Sie viele gute Inhalte in den anderen Antworten.

Ich denke, es muss darauf hingewiesen werden, dass ein zentrales Thema hier nicht die spezifischen Praktiken sind, sondern die gesamte Teamkultur.

  • Es ist schwer, einen kulturellen Wandel herbeizuführen .
  • Umso mehr, wenn Sie als "Junior" gesehen

Alles andere kann folgen, wenn es Mittel zur kontinuierlichen Verbesserung gibt .

Mein Ansatz, dies zu erreichen, ist:

  • Dokumentierte Prozesse und Abläufe
  • Rückblicke mit dem Team, dessen Aktionen Änderungen an der Prozessdokumentation sind.

Ich denke, wenn du keine Sprints hast, hast du noch keine regulären Retros. Alles, was Sie brauchen, ist ein Gespräch mit dem Team und dann die Aktion.

Sie können problemlos mit der Dokumentation von Prozessen beginnen. "Ich bin der Neue, habe ich das richtig verstanden? Lass mich das aufschreiben." Es ist wichtig, den Prozess dann tatsächlich selbst zu verfolgen oder zu versuchen, uns dort anzurufen, wo er bricht.

Vielleicht fängst du mit solchen Gesprächen ad hoc an und schlägst dann regelmäßige Rituale vor.

Wenn Sie diesen Ansatz wählen, können Sie schrittweise und leise vorgehen. Sie können vermeiden, als Junior aufzutreten, der alles weiß, und stattdessen versuchen, dem Team zu helfen, Änderungen vorzunehmen.

Einige Überlegungen:

  • Einige Teams haben einen schlechten Prozess, wissen das aber bereits. Sie wollen sich ändern und brauchen nur etwas, um das zu katalysieren. Andere Teams haben sich sehr verhalten und es ist viel schwieriger, sich zu ändern.
  • Gleiches gilt für Einzelpersonen.
  • Sie müssen sich dessen bewusst sein und herausfinden, wer im Team offen für Veränderungen ist und wer nicht. Verstehen warum.
  • Finden Sie einfache Gewinne.
  • Begrüßen Sie die Änderungen im Team: Finden Sie die einzelnen Schwachstellen und versuchen Sie, sie zu beheben.
Keith
quelle