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?
quelle
Antworten:
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.
quelle
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:
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:
quelle
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.
quelle
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.
quelle
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:
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.
quelle
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
quelle
Es hängt davon ab:
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.
quelle
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.
quelle
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.
quelle
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):
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.
quelle
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.
quelle
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.
Alles andere kann folgen, wenn es Mittel zur kontinuierlichen Verbesserung gibt .
Mein Ansatz, dies zu erreichen, ist:
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:
quelle