it-swarm.com.de

Sollte ein (Junior-) Entwickler versuchen, auf bessere Prozesse und Praktiken in seinem Entwicklungs- / IT-Team zu drängen?

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, die Arbeit zu erledigen. Dies ist neu für mich, da meine früheren Unternehmen mehr oder weniger streng definierte Prozesse hatten, die vom Management kamen.

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

  • ein gut definiertes Framework für Softwareentwicklung/Arbeitsverwaltung (wie Scrum)
  • starker Produktbesitz
  • gut definierte Rollen (z. B. führen Geschäftsmitarbeiter manuelle Tests durch)
  • regelmäßige Standup-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 zur Dokumentation interner und kundenorientierter Tipps

Und die Liste geht weiter. Das Management ist offen für die Umsetzung von Verbesserungen, solange der Wert gerechtfertigt ist und die wichtigste Arbeit (nämlich die Entwicklung) erledigt wird. 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, ohne Zweifel zeitaufwändig und eindeutig keine Entwicklungsarbeit sind.

Lohnt es sich für einen (Junior-) Entwickler, im Laufe der Zeit zu versuchen, Push für das oben Genannte zu tun? 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?

110
overflow831

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

Nach meiner Erfahrung haben viele Leute, die gerade das College abgeschlossen haben, 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ßes ABER, dieses Wissen basiert nicht auf einem praktischen Szenario. In der realen Welt fällt ein Großteil dieser Theorie flach oder muss zumindest mit einem massiven Salzkorn aufgenommen werden, da es in der Praxis in einem realen Szenario nicht so gut funktioniert.

Ein typisches Beispiel: Eine Anwendung, an der ich vor langer Zeit gearbeitet habe, wurde von einem brillanten OO Theoretiker, der so konzipiert ist, dass er folgt OO Prinzipien und Theorie zum T, mit vielen Mustern überall angewendet.

Es war ein fantastisches Stück Software-Design.

Leider führte dies zu einem Albtraum in Produktion und Wartung. 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 gewesen, der längst gegangen war).

Es lief auch sehr schlecht, gerade wegen der vielschichtigen Struktur von Mustern und Klassenbibliotheken, die das Design erforderte. Wenn Sie beispielsweise auf eine Schaltfläche auf einem Bildschirm klicken, um einen einzelnen Aufruf der Datenbank durchzuführen, werden mehrere hundert Objektinstanziierungen und Methodenaufrufe ausgeführt - alles im Namen der Sicherstellung einer losen Kopplung und ähnlicher Dinge.

Dieser Architekt war ein 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 beim Erstellen 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 geführt hätte, das einfacher zu warten und auch besser zu betreiben ist.

Das Gleiche 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 sehr guten Grund dafür gibt, weil Ihre theoretische Basis Ihnen sagt, dass etwas nicht stimmt oder nicht optimal ist.

Selbst jetzt, mit über 20 Jahren Erfahrung auf diesem Gebiet, bin ich vorsichtig, die Art und Weise zu kritisieren, wie Dinge in Unternehmen gemacht werden, mit denen ich zusammenarbeite. Ich werde nebenbei erwähnen, dass ich bemerkt habe, dass die Dinge anders sind als meiner Erfahrung nach die optimalsten, 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 der Änderung von Dingen geringer ist als die Kosten.

Haben Sie keine Angst vor der Annahme, dass die Dinge besser gemacht werden könnten, aber stellen Sie immer sicher, dass Sie nicht als Besserwisser, sondern als Mitarbeiter auftreten, der versucht und bereit ist, nicht nur zu lernen, sondern auch zu lernen helfen, Prozesse zur Verbesserung des Unternehmens zu verbessern, nicht nur theoretische Korrektheit.

178
jwenting

Ja aber mit viel Sorgfalt !

Lassen Sie mich das klarstellen.

Sie sollten sich bemühen, die Bewohnbarkeit der Software zu verbessern. Wenn Sie sich den Code/das Team/das Geschäft/das Projekt/das Management ansehen und Ihre erste Antwort darin besteht, zu duschen, ist er nicht bewohnbar. Wenn Ihre erste Antwort darin besteht, ja zu schreien! ... und sich dann zu beschweren, wenn Sie aus dem Büro entlassen werden, 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 bescheiden, ich meine nicht, ein Push-Over zu werden oder zu akzeptieren, dass die Dinge schlecht sein müssen, ich meine, dich damit abzufinden, dass deine guten Absichten dich bösartig anmachen werden.

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 es langsam, vielleicht schmerzhaft, aber es funktioniert und Sie alle haben Erfahrung damit. Sie wissen ungefähr, was Sie erwartet, kurz gesagt, Sie sind geübte 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 Neophytenniveau zurückgesetzt. Das ist nicht gut. Neophyten müssen die neuen Regeln lernen, was Zeit braucht. 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 jetzt nicht annähernd so funkelnd.

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, denn das einzige, was verloren geht, ist das kodifizierte Wissen. Wenn dieses Wissen völlig unverständlich ist, ist es bereits verloren, und ein Neuanfang ist die einzige Wahl. Umgekehrt, wenn die Kodifizierungsmethode oder die Art und Weise, wie sie verwendet wird, problematisch ist, aber funktioniert, ist dieses Wissen immer noch zugänglich, und vielleicht lohnt es sich, es zu behalten, vielleicht nicht - treffen Sie die Entscheidung einfach nicht leichtfertig.

Die andere Möglichkeit besteht darin, mit dem System so zu arbeiten, dass jeder einen Referenzrahmen 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 lernen. Dies ist die Grundlage für die Praktiken namens Kaizen . Eine stärker entwicklerorientierte Formel wird in der Präsentation Rasieren des goldenen Yaks vorgestellt. Ich empfehle dringend, sie anzuschauen und durchzudenken.

Finden Sie also eine kleine Sache, die geändert werden kann, um Ihr Leben zu verbessern, und hoffentlich die einiger anderer. Beheben oder verbessern Sie die Situation. Dies gibt Ihnen Übung und Erfahrung darin, Änderungen in die Praxis umzusetzen. Stellen Sie sicher, dass Sie Feedback erhalten: Hätten Sie es besser diskutieren können, war es tatsächlich nützlich, hat es einen anderen Teil des Systems verärgert? Entwickeln Sie Ihr Gefühl dafür, was getan werden kann und wie es geht.

Jetzt sind drei Dinge passiert:

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

Wählen Sie jetzt eine andere Sache aus, die Sie verbessern möchten, wenn Ihre Erfahrung wächst und Sie Probleme mit niedrigem Hängen beseitigen, werden Sie anfangen, sich den schwierigeren Problemen im System zu stellen, 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 dadurch entstehen (welche Regeln müssen neu gelernt werden)
  • Sie kennen einige unmittelbare Möglichkeiten, um Probleme zu beheben oder zu verbessern, die durch die Änderung entstehen
  • die Menschen in Ihrer Umgebung sind sich bewusst, dass Sie sich mit dem System auskennen und es erfolgreich ändern können
43
Kain0_0

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 fiel mir auf, dass es (OMG) kein Code-Repository gab! Alle Zusammenführungen von Code wurden manuell durchgeführt, indem Zip-Dateien per E-Mail aneinander gesendet wurden.

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

Das Organisieren eines Code-Repositorys ohne Hilfe war also neu im Unternehmen, und 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 Manager verstanden, dass es wichtig ist, also hatte ich Unterstützung.

Dies führte jedoch dazu, dass ich nicht sehr beliebt war und leider einen Spitznamen erhielt, der vom Quellcodeverwaltungssystem abgeleitet war.


Ich gehe also davon aus, dass Sie zuerst Ihre Teammitglieder herausfinden, was sie für wichtig halten, um es als nächstes einzurichten.

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 gesamte Team muss ausgerichtet sein.

Wenn dies nicht der Fall ist, können Sie trotzdem professionell arbeiten. Und finden Sie Gleichgesinnte und arbeiten Sie zusammen, wie Sie denken, dass es getan werden sollte. Wenn dies gute Ergebnisse bringt, werden mehr Menschen mit Ihnen zusammenarbeiten, und schließlich wird es "der" Prozess.

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

Also ja, Sie sollten immer versuchen, das zu verbessern, was verbessert werden kann.

Aber denken Sie auch daran, dass viele Menschen, mit denen Sie arbeiten, bereits Profis sein könnten und wissen, was falsch ist und was benötigt wird.

20

Lohnt es sich für einen (Junior-) Entwickler, im Laufe der Zeit zu versuchen, Push für das oben Genannte zu tun?

Ja, es lohnt sich immer, die Dinge besser zu machen. Sie wissen am besten, mit welchen Problemen Sie schließlich 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 gibt es unüberwindbare Hindernisse für Ihren Erfolg oder für andere Menschen, die weitaus besser positioniert sind, um sich für sie einzusetzen. Sie sollten also immer versuchen, die Dinge besser zu machen, auch wenn dies bedeutet, welche Dinge auszuwählen, die Sie in Ihrer Zeit damit verbringen, besser zu machen.

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

14
Telastyn

Ja. Aber organisatorische Veränderungen sind selbst für Senioren schwierig. Wenn Sie also wirklich etwas bewirken möchten, tun Sie dies auf die richtige 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.
    • Verstehen Sie die Kultur und Politik oder Ihr Unternehmen. Ist es sicher, auf Änderungen zu drängen?
    • Bauen Sie eine gute Beziehung zu Kollegen auf
    • Erfahren Sie mehr über den Prozess, die Regeln und die Bedürfnisse Ihres Teams
    • Lernen Sie Ihre Arbeit und tun Sie es so gut Sie können. Sie werden sicherlich beschäftigt genug sein.
  • Wähle deine Schlachten. Holen Sie sich einige frühe Siege : Sie können mit Energie ankommen, um alles zu ändern, aber das ist unrealistisch. Konzentrieren Sie sich auf 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 Auswirkungen auf andere : Ich mache Refactors, die viele Dateien betreffen. Selbst wenn sie den Code verbessern, muss ich sehr vorsichtig sein, um zu vermeiden, dass die Zusammenführungen zu einem Schmerz im Arsch werden. Versuchen Sie auch, die Gründe zu verstehen, warum sie so weiterarbeiten. Möglicherweise können sie Scrum nicht verwenden, da ihnen Tests fehlen und sie verständlicherweise Angst haben, ungetesteten Code häufig in die Produktion zu bringen. Einen realisierbaren Test zu schreiben ist keine leichte Aufgabe. Der aktuelle Code könnte sehr schwer zu testen sein. Darüber hinaus darf das Team weder Tests noch testbaren Code schreiben. Die aktuelle Codebasis ist möglicherweise besonders schwer zu testen und muss überarbeitet werden. Es kann Jahre dauern, bis dieses Problem behoben ist, aber Sie können sich zumindest auf die Grundursache konzentrieren.

  • Nicht beurteilen. Verlangen Sie nicht. Fragen Sie danach und hören Sie genau zu: Dies ist ein Moment, in dem die Kommunikation kritisch ist und wir Programmierer normalerweise nicht sehr gut in subtilen Nuancen sind. Es gibt Techniken, die helfen . Es ist einfach, weiter auf unsere Idee zu drängen, 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 durch diese Veränderung? Angst? Unzulänglichkeit? Zorn? Frustration? Hoffnung? Faul? Blöd? (Niemals Leute dumm machen). Natürlich hätten Sie schon viele Fragen gestellt, und dies verhindert viele falsche Schritte.

  • Mit gutem Beispiel vorangehen : Sich zu beschweren ist einfach, die Änderung zu erstellen ist schwierig. Zeigen Sie Ergebnisse und die Leute werden Ihnen glauben. Wenn sie keinen Test verwenden, können Sie Ihre Komponententests schreiben. Wenn Personen nicht dokumentieren, können Sie einige Google-Dokumente für das Team freigeben. Verstehen Sie, dass "Ok, mach es" eines der bestmöglichen Szenarien ist und Sie dann liefern müssen. In diesem Fall müssen Sie sich ü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 lassen, dass Sie wertvolle Zeit verlieren von teuren Programmierern. Es wäre großartig, wenn diese Code-Software überprüft oder mehrere Open-Source-Tools evaluiert würden, aber wir werden das Repo im Moment nur verwenden.

  • Kritische Masse erhalten: Sammeln Sie die 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 beschreiben das "Aufwecken des Riesenphänomens" in der Basis des Teams, das sich buchstäblich gegen einige dumme Praktiken auflehnt, die die Produktivität verlangsamen. Dies wäre individuell sehr gefährlich gewesen und ich hätte es nicht empfohlen. Aber wenn alle der Gruppe zustimmen, ist Veränderung einfacher.

  • Geben Sie ihm etwas Zeit. Stimmen Sie anschließend mit Ihren Füßen ab: Möglicherweise möchten Sie es in einigen Monaten bis zu zwei Jahren versuchen. Einige Unternehmen haben jedoch keine einfachen Lösungen. Einige Teams wollen sich nicht ändern und haben keine Anreize. Und einige Codebasen sind purer Horror. 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 erlernen, und auf lange Sicht werden Sie in einem Frieden mit etwas weniger Lohn besser sein, aber Erfahrungen sammeln, die Sie wertvoller machen.

Bonus: Wenn Sie erfolgreich sind, schreiben Sie ihn für Ihren Lebenslauf/Ihre Interviews auf. Als Junior haben Sie normalerweise sehr wenig zu sagen und es ist immer eine Veränderung zum Besseren ein tolles Zeichen. Sie möchten eine sehr klare und realistische Sicht auf das 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 etwas bewirkt haben.
  • Nun, ich war an einem Ort, an dem sie sehr altmodische Praktiken hatten. Viele Menschen waren damit nicht zufrieden und die Produktivität hatte einen großen Verbesserungsbedarf. 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. ".
13
Borjab

Ja. Aber nicht die Dinge, die Sie vorschlagen.

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

Sie können diese mit minimalem Zeitaufwand selbst hinzufügen und sofortigen Wert anzeigen. Es ist ein technisches Problem mit allgemein akzeptierten Vorteilen und wirkt sich nicht auf andere Arbeitspraktiken aus. Sie erhalten auch mehr Wissen über die Codebasis, auch wenn die Ergebnisse nicht akzeptiert werden. Ein einfacher Verkauf.

Bei den anderen handelt es sich im Allgemeinen um Geschäftsprozesse, an denen das gesamte Team oder sogar andere Teams beteiligt sind. Sie könnten Verbesserungen vorschlagen, aber für einen Nachwuchsmitarbeiter ist es schwierig, sie zu ändern, und der Prozess ihrer Änderung ist im Allgemeinen nicht technisch und hängt wahrscheinlich nicht mit Ihrer normalen Arbeit zusammen.

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

9
Ewan

Es hängt davon ab:

  • wie viel erwarten Sie von besseren Praktiken?
  • wie viel Aufwand müssen Sie aufwenden, um dorthin zu gelangen?
  • was sind die Chancen auf Erfolg und Risiken - von einfachen Adoptionsfehlern bis hin zu neuen Praktiken sind sie tatsächlich schrecklich, die Codequalität verschlechtert sich, Schlüsselpersonen gehen, jeder hasst dich und du musst einen anderen Job in einer anderen Stadt finden, in der niemand deinen Namen kennt

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

2
ptyx

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? Das sind einfache Schritte, die ein Anfänger machen kann. Lesen Sie, welche Probleme diese Schritte lösen (versuchen) und wie dies Ihrem Unternehmen hilft, Kosten zu senken (daran interessiert sich das Management).

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

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

Schlagen Sie Dinge vor, geben Sie Hintergrundinformationen, versuchen Sie andere zu überzeugen, es zu versuchen, analysieren Sie die Ergebnisse ... aber erwarten Sie nicht zu 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.

1
Bernhard Hiller

Sie sagten, das Team sei ziemlich neu (3 Jahre alt). Wenn Sie 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 das Test- und Versionsverwaltungssystem, gehören zu denen, die Sie bereits vorschlagen könnten, aber werfen Sie den Vorschlag nicht einfach so, ohne die offensichtlichen Vorteile hervorzuheben und die Tools auszuwählen, die Ihr Entwicklungsstapel benötigt.

0

Stellen Sie am Anfang Fragen

Wenn Sie Ihre Liste lesen, würde ich die folgenden Fragen vorschlagen (sehen Sie in Ihrer Liste nach, wie sie passen):

  • Wie sehe ich, welche Arbeit die Geschäftsinhaber anfordern?
  • Haben Sie [Scrum] ausprobiert?
  • 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 teile ich meine Hindernisse dem Rest des Teams mit?
  • Wie finde ich heraus, welche anderen Mitglieder des Teams arbeiten?
  • Sollten wir [dies] in das Problemverfolgungstool aufnehmen?
  • Wie sollen wir [dies] in das Issue-Tracking-Tool schreiben?
  • Wenn [dies] passiert, sollten wir es als [das] in das Problemverfolgungstool aufnehmen?
  • Wie testen wir?
  • Wie zeichnen wir unsere Tests auf, damit andere sie wiederverwenden können?
  • Haben Sie [JUnit] ausprobiert?
  • Wo ist [dies] dokumentiert?
  • Haben Sie [MediaWiki] ausprobiert?

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

Möglicherweise haben Sie bereits damit begonnen. Bevorzugen Sie Einzelgespräche gegenüber Gruppengesprächen. Im Einzelgespräch können Sie besser lesen, 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, die sie ablehnen, sollten sie nicht wütend werden. Sie sollten erklären, warum sie sich dieser Position widersetzen. Ich empfehle, nicht mit ihnen zu streiten. Streiten verhärtet Positionen mehr als es überzeugt. Beachten Sie, wer welche Position hat und fahren Sie fort.

Machen Sie später Schritte

Suchen Sie nach Möglichkeiten, wie Sie und möglicherweise andere (d. H. Diejenigen, die Sie zuvor mit Ihnen einverstanden waren) die gewünschten Änderungen starten können. Nicht jeder will aufstehen? Warum nicht? Vielleicht können diejenigen von Ihnen, die einen wollen, Ihren eigenen Standup haben. Nicht so effektiv wie im gesamten Team, aber mehr als jetzt.

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 beinhaltet, die Sie (möglicherweise eine Gruppe) Ihrer Meinung nach haben sollten. Wenn sie zurückschieben, bitten Sie sie, herauszufinden, wem diese Rolle gehören soll.

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

Installieren Sie ein Test-Framework (wenn andere dies bevorzugen, treffen Sie eine gemeinsame Entscheidung über 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 (schrieb einen Test, der den Fehler demonstriert und unter [Speicherort] 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 aus und senden Sie die erforderlichen Probleme 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 Leute Fragen stellen, die zeigen, dass sie die Dokumentation nicht gelesen haben, verweisen Sie sie 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 bei der Beantwortung die Dokumentation. Erwägen Sie, sie zu ermutigen, das Wiki zu aktualisieren, wenn Sie der Meinung sind, dass das Problem eher struktureller Natur ist, als dass sie nicht lesen.

Ich würde vorschlagen, sich jeweils nur auf eine Aufgabe zu konzentrieren. Und sicherlich immer nur einen nach dem anderen. Nicht hart drücken. Siehe dieses Beispiel stärker drücken als die Gruppe wollte. Konzentrieren Sie sich mehr darauf, Ihr Verhalten zu ändern als auf 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 Nudge machen. Wenn Sie das Pferd zum Wasser geführt haben, lassen Sie die Wahl, wann oder ob Sie dem anderen trinken möchten.

Schließlich wirst du älter sein

Im Laufe der Zeit wird Ihr Team neue Mitarbeiter einstellen. Sie werden aufhören, der neue Mitarbeiter zu sein, und in der Lage sein, Ihre Positionen bei neuen Leuten zu vertreten. Arbeiten Sie mit ihnen zusammen, um Änderungen vorzunehmen. Und vielleicht stellen Sie fest, dass Sie auch mit Ihren vorhandenen Teamkollegen Fortschritte machen. 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 warten, bis Sie einen besseren Job haben, indem Sie diesen verbessern oder einen besseren finden.

0
mdfst13

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 verstehen, wenn Sie einem neuen Team beitreten.

Eine vorgeschlagene Lösung:

1) Wenn Sie etwas sehen, das Ihrer Meinung nach verbessert werden sollte, nehmen Sie es zur Kenntnis! (in einem Notizbuch, in einer digitalen Notiz ...)

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

0
Offirmo

Späte Antwort und stimme vielen guten Inhalten in den anderen Antworten zu.

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

  • Kulturwandel zu schaffen ist schwer .
  • Mehr noch, wenn Sie als "Junior" gesehen werden

Alles andere kann folgen, wenn es ein Mittel gibt, um kontinuierliche Verbesserung zu erreichen.

Mein Ansatz, um 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 Maßnahmen.

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, unseren anzurufen, wo er bricht.

Vielleicht beginnen Sie mit solchen Gesprächen ad hoc und schlagen dann regelmäßige Rituale vor.

Dieser Ansatz ermöglicht einen inkrementellen, sanft-weichen Ansatz. Sie können vermeiden, als Junior aufzutreten, der alles weiß, und stattdessen versuchen, dem Team, das Änderungen vornimmt, als Vermittler zu dienen.

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 blieben wirklich im Weg und waren viel schwerer zu ändern.
  • Gleiches gilt für Einzelpersonen.
  • Sie müssen dafür sensibel sein und herausfinden, wer im Team offen für Veränderungen ist und wer nicht. Verstehen warum.
  • Finde einfache Gewinne.
  • Machen Sie die Änderungen im Team willkommen: Finden Sie ihre individuellen Schwachstellen und versuchen Sie, sie zu beheben.
0
Keith