Wie kann man einen Teamkollegen, der sich als Senior versteht, davon überzeugen, die konzeptionellen Grundlagen von SVN zu lernen? [geschlossen]

Zunächst einmal habe ich diesen Sommer eine neue Position als Entwickler angetreten und war das neueste Mitglied im Team, das jedoch über die meiste Erfahrung verfügt.

Bisher habe ich es geschafft, Sanity-Initiativen aufgrund der geringen Einführungskosten (in Bezug auf Zeit und Aufwand) problemlos genug durchzusetzen. Die Dinge haben sich jedoch etwas verbessert.

Einer meiner Teamkollegen, obwohl erfahren, versteht SVN nicht wirklich. Natürlich führen leere Bereiche auf seiner mentalen Karte, die Ozeane von SVN darstellen, dazu, dass er ziemlich seltsame Verwendungsmuster annimmt.

Beispielsweise hatte er die Richtlinie "1 SVN-Festschreibung pro Tag und Entwickler" festgelegt, da sonst "dem Server bald der Speicherplatz ausgehen würde". Als ich ihm erklärte, dass SVN-Commits Deltas sind, keine vollständigen Kopien, antwortete er mit Zweifel und selbst heute bin ich nicht ganz sicher, ob er versteht, was es bedeutet.

Wir hatten auch einen heftigen Streit darüber, ob die Eclipse- .projectKonfiguration in SVN aufgenommen werden soll. Mein Teamkollege bestand darauf, dass wir sollten, obwohl es zahlreiche sinnlose Konflikte verursacht hat. Ich war dagegen, einzelne Entwicklerkonfigurationsdateien in SVN zu belassen. Schließlich stellte sich heraus, dass mein Teamkollege nach jedem Commit den gesamten Quelltextbaum erneut auschecken musste, um sicherzustellen, dass "Code, der in das Repository geschrieben wurde" funktioniert. Aus diesem Grund behielt er die Projektkonfiguration in SVN so unerbittlich bei - so dass es einfach sein würde, das Projekt erneut zu importieren. Als ich erklärte, dass Commit die Arbeitskopie byteweise mit dem entfernten synchronisiert, was ein erneutes Auschecken unnötig macht, antwortete mein Teamkollege erneut mit Zweifel und winkte schließlich das ganze Problem als unbedeutend ab.

Meiner Meinung nach verschwendet unser Team Zeit, indem es SVN-Konflikte in Projektkonfigurationsdateien löst, die nur entwicklerspezifische Einstellungen enthalten, die für SCM überhaupt nicht freigegeben werden müssen. All diese Unordnung, weil jemand den Prozess auf falsche Annahmen zugeschnitten hat.

Wie kann ich einen Teamkollegen, der sich als Senior versteht, davon überzeugen, die SVN-Grundlagen besser zu verstehen?

IMO ist es am besten, die Probleme, die direkte Probleme / Schäden für das Projekt verursachen, von denen zu trennen, die nur diesen einen Entwickler betreffen . Wenn er beispielsweise lieber mehrmals am Tag alles auscheckt, wird er langsamer, wirkt sich aber ansonsten nicht auf andere aus. Sie können ihn das einfach tun lassen (bis eine merkliche Leistungsverzögerung in seiner Arbeit auftritt) und sich die Mühe ersparen, darüber zu streiten.

Andere Themen, die Sie erwähnen, wie das .projectSpeichern von Eclipse- Dateien im Repo oder 1 Commit pro Tag, sollten Sie in den Mittelpunkt stellen, damit das Team so reibungslos wie möglich voranschreiten kann. Als erstes sollten Sie die anderen Teammitglieder fragen / Feedback einholen , ob dies auch für sie Probleme verursacht. Wenn es andere gibt, können Sie gemeinsam mehr Druck ausüben und bei Bedarf ein Problem leichter an das Management weiterleiten.

In Bezug auf die "SVN hat nicht genügend Speicherplatz", wäre es einfach, seine Überzeugung durch ein Experiment (möglicherweise in einem separaten Test-Repo) zu widerlegen . Sie müssen lediglich die Größe der Hierarchie der physischen Repodateien überwachen, bevor und nachdem Sie Änderungen an einer großen Textdatei oder sogar an vielen Dateien vorgenommen haben. Wenn ihn das nicht überzeugt, kann nichts.

In diesem Fall haben Sie wahrscheinlich leider ein Problem mit der Autorität, bei dem der andere Mann das Annehmen von Ratschlägen von jemandem "unterem Rang" als Verlust seiner Würde ansieht. Solche Konflikte können nicht durch logisches Argument gelöst werden. Sie müssen es an das Management weiterleiten, achten Sie jedoch darauf, dass Sie ausreichend Unterstützung (von Teammitgliedern und / oder dem Management) erhalten, bevor Sie dies tun. Ein solcher Schritt kann vom anderen als offener Angriff wahrgenommen werden und daher problematische Konsequenzen haben (für einen von Ihnen und / oder für den Frieden des gesamten Teams). Denken Sie also dreimal nach und besprechen Sie dies mit Ihren unterstützenden Kollegen, bevor Sie diesen Schritt unternehmen.

Wenn Ihr Unternehmen Wiki verwendet, schreiben Sie einige hochwertige Beiträge über SVN:

• Warum solltest du es benutzen?
• Wann sollten Sie es verwenden?
• Welche Probleme löst es?

usw.

Es wird das Auge des CTO auf sich ziehen und jeder, der sich weigert, muss es benutzen :)

Als Führungskraft, Manager und Teammitglied musste ich mich auf vielen Ebenen mit der Lösung von Berufs- und Persönlichkeitskonflikten befassen. Unabhängig davon, in welche Rolle ich eingestellt werde, werde ich in der Regel als Leiter akzeptiert, auch wenn ich die Rolle nicht möchte. Der Grund dafür ist, wie ich mit diesen Konflikten umgehe.

Im Gegensatz zu vielen anderen hier bin ich nicht der Meinung, dass der Umgang mit dieser Situation ein "Aufgeben" oder "Zeigen Sie ihm ein neues Werkzeug" ist oder "Warten Sie, bis er auf seinen Hintern fällt". Vor allem ist es nie eine gute Idee zu warten, bis die Rollen fester definiert sind. Diese Rollen werden von Menschen definiert, die nicht warten, aufgrund ihrer Überzeugung, ihrer Ethik und ihrer Fähigkeit, mit kritischen Situationen umzugehen, unabhängig davon, ob sie Menschen einbeziehen oder nicht.

Es gibt verschiedene Methoden, um mit dem Typ der Person umzugehen, den Sie in diesen Situationen beschreiben. Der erste und wichtigste Schritt ist zu untersuchen, warum er sich so verhält, wie er ist. Es hat wenig damit zu tun, was er weiß oder nicht weiß. Er hätte diese Information leicht vorher herausfinden können, also ist die Frage wirklich eine von zwei Dingen: "Warum hat er es nicht getan?" oder "Warum lehnt er die Informationen ab, die er erhalten hat?" So finden Sie heraus, worauf es genau ankommt.

Nach meiner Erfahrung lehnen Programmierer (einschließlich meiner selbst) bewährte Verfahren oder neue Tools aus nur wenigen Gründen ab:

• Die Quelle ist nicht glaubwürdig. In einer Branche, die sich von Tag zu Tag mehr zwischen dem "Kult des Mac" und den "MS-Anhängern" polarisiert; zwischen "Open Source Ideology" und "Proprietary Practicality" ... etc etc - Es gibt viele, die aufgrund der Voreingenommenheit des Einreichers oder des Verfassers immer Zweifel an den bereitgestellten Informationen und deren Korruptionspotential haben, selbst wenn diese Informationen vorliegen als glaubwürdig bestätigt.
• Längere schlechte Erfahrungen ... mit einer ähnlichen oder sogar der gleichen Technologie oder Praxis. Nichts ist perfekt, wenn es anfängt, und viele beginnen mit weniger als einem Viertel der Features, als sie am Ende haben. Es ist durchaus möglich, dass er in einer schlecht umgesetzten Phase viele Stunden, Tage oder sogar Wochen mit einem minderwertigen oder demselben Produkt gearbeitet hat.
• Eine "glaubwürdige" Quelle ... widerspricht den Informationen, die ihm präsentiert werden. Mit "glaubwürdig" meine ich eine Person oder Entität, der er vertraut. Viele Menschen neigen dazu, die Menschen, denen wir vertrauen, auf Ebenen zu heben, die nicht der Realität entsprechen. Diese Quelle muss der Person nicht einmal diesen Glauben aufgezwungen haben. Meistens machen wir es selbst. Es gibt uns oft etwas oder jemanden, der danach strebt, in mindestens einem Aspekt so zu sein.
• Mangelnde Sicherheit Dies wurde in einem früheren Poster hervorgehoben. Unsere Programme werden von dem Moment an zu einem Aktivposten, in dem wir mit der Arbeit beginnen. Nicht nur für die Unternehmen, für die wir arbeiten, sondern auch für die Menschen, mit denen wir zusammenarbeiten. Dies ist nicht einfach ein Kontrollproblem. Einige von uns möchten in der Lage sein, den Menschen, die uns interessieren, ihre netten Sachen zu zeigen. Einige von uns möchten sicherstellen, dass es nicht von einer externen Person oder einem Produkt beschädigt wird. Für manche ist es eine Erweiterung unseres Denkens und Fühlens. Es beherbergt einige unserer Philosophien und Ideologien und enthüllt unsere intellektuellen Kerne. Für viele ist es unsere Zukunft, ob für eine Klasse, einen Arbeitgeber oder einen Kunden. Für manche ist das alles. "Sicherheit" in diesem Sinne bezieht sich nicht unbedingt auf die Daten oder den Code.

Herauszufinden, worauf es ankommt, ist häufig recht einfach. Bringen Sie die Person in eine neutrale Umgebung. Erklären Sie der Person, was Sie im Allgemeinen beobachten. Fragen Sie die Person ehrlich, was dieses Verhalten verursacht. Jetzt läuft es nicht immer gut, aber die meisten Erwachsenen reagieren ziemlich gut, wenn Sie jemandem helfen möchten, der irrational zu handeln scheint. Wahrscheinlich handelt er nicht irrational, ist sich aber nicht bewusst, dass niemand verstehen kann, was wirklich vor sich geht.

Sobald Sie herausgefunden haben, worum es eigentlich geht, können Sie sich mit den richtigen Werkzeugen ausstatten, um damit umzugehen. Wenn es sich um Szenario 1 handelt, ermutigen Sie ihn, die Recherchen aus den Quellen durchzuführen, denen er vertraut, und (dies ist wichtig)melde dich bei dir mit seinen eigenen erkenntnissen. Dies wird ihm sagen, dass seine eigenen Informationen für Sie von Wert sind. Stellen Sie im Fall von Szenario 2 genaue Vergleiche zu den aktuellen Unterschieden her. Ermutigen Sie ihn, es zu versuchen, aber haben Sie einen Backup-Plan für den Fall, dass es schief geht. Fordern Sie ihn in Szenario 3 auf, seine Quelle mit IHREN Informationen anzufordern. Wahrscheinlich ist seine Quelle nicht der Ansicht, dass er glaubt, dass er es tut, sondern hat es auf einmal getan. Die meisten von uns passen sich im Laufe der Zeit an, sodass sich sein Standpunkt wahrscheinlich geändert hat. Wenn er nicht bereit ist, ermutigen Sie ihn, Ihnen seine Quelle vorzustellen. Und schließlich versichern Sie ihm für Szenario 4, dass seine Sorgen Ihre eigenen sind. (Sie sollten sich auf einer bestimmten Ebene befinden.) Zeigen Sie, wie dieses "neue" Tool seine Interessen schützen und seine Sicherheit erhöhen kann. Und wenn es nicht geht,

Ich weiß, dass das alles zu einfach klingt, aber manchmal ist es einfach so. In der Tat, je aufrichtiger Sie sind, desto öfter tut es. Indem Sie auf seine Bedürfnisse eingehen, gehen Sie auf die Bedürfnisse des Teams ein, unabhängig davon, ob es ein "Senior" ist oder nicht, weil es ein Teil des Teams ist. Wenn Sie ihm zeigen, dass Sie auf der gleichen Seite wie er sein möchten, dies aber nicht tun, könnte dies ihn ermutigen, mit Ihnen zusammenzuarbeiten. Wenn Sie all dies getan haben und noch immer keine Lösung gefunden haben, haben Sie alles getan, was Sie können, um nicht mit dem Teamleiter zu sprechen.

FuzzicalLogic

Es gibt viel Aberglauben um die Quellcodeverwaltung. Es ist nicht intuitiv, die Mathematik ist geheimnisvoll und es handelt sich um den wichtigsten Vermögenswert, den ein Softwareunternehmen besitzt. Ich muss zugeben, dass es einen Teil von mir gibt, der ihm immer noch nicht vertraut. Aber ich würde keine Minute darauf verzichten.

Eine Lösung könnte darin bestehen, die Übernahme der Verantwortung für das Repo anzubieten. Natürlich, wenn Sie es als "es ist eine Menge Arbeit für Sie, und dies ist nur ein Bereich, in dem ich etwas Erfahrung habe", anstatt "Sie wissen nicht, was Sie tun", die haben wird eine bessere Chance zu arbeiten.

Wenn "sieht sich als Senior" bedeutet, was ich denke, dass es tut, wird er nicht loslassen, weil er es als Quelle der Autorität und Kontrolle sieht. Sie können es also umgehen, indem Sie Git lokal zum Verwalten vernünftiger Festschreibungseinheiten und -zweige verwenden und dann einfach einmal am Tag auf Anfrage auf svn klicken. Git ist als Peer-to-Peer-System konzipiert und verfügt auf jedem lokalen Computer über eine vollständige Repokopie. Sie könnten anderen Entwicklern, die es vorziehen würden, Git anbieten, und es kann nur eine Ergänzung zu SVN bleiben, die einzelne Arbeitsgruppen (ob ein oder mehrere Entwickler, formal oder ad-hoc) intern verwenden. Und wenn der Tag kommt, an dem ein älterer Mann nachgibt, zu einer anderen Abteilung oder Firma wechselt oder sich mit seinen SVN-Richtlinien in eine nicht behebbare Ecke stürzt, haben Sie einen Vorsprung bei der Bereinigung.

Sprich einfach mit ihnen. Ich bin ein leitender Entwickler, aber es gibt Dinge, die ich nicht kenne. Das ist die Natur des Geschäfts. Wenn sie defensiv oder aggressiv werden, ist dies eine Frage der Persönlichkeit des Entwicklers, die vom Teamleiter oder, wenn sie der Teamleiter sind, von seinem Chef behandelt werden sollte.

Starten Sie eine Brown-Bag-Initiative. Einmal in den ersten Wochen hält jemand ein Gespräch zur Mittagszeit über etwas ab, von dem er weiß, und präsentiert es den anderen.

Sie benutzen dies als Ausrede, um SVN im Detail vorzustellen und vielleicht einige der Überlegungen, die hinter einigen Alternativen stehen.

Ein paar Wochen später kann jemand anderes es versuchen.

Ich werde versuchen, Ihnen einige Hinweise zu geben, die auf meinen persönlichen Erfahrungen beruhen.

Einer meiner Teamkollegen, obwohl erfahren, versteht SVN nicht wirklich. Natürlich führen leere Bereiche auf seiner mentalen Karte, die Ozeane von SVN darstellen, dazu, dass er ziemlich seltsame Verwendungsmuster annimmt.

Beispielsweise hatte er die Richtlinie "1 SVN-Festschreibung pro Tag und Entwickler" festgelegt, da sonst "dem Server bald der Speicherplatz ausgehen würde". Als ich ihm erklärte, dass SVN-Commits Deltas sind, keine vollständigen Kopien, antwortete er mit Zweifel und selbst heute bin ich nicht ganz sicher, ob er versteht, was es bedeutet.

Selbst wenn Speicherplatz ein Problem wäre, könnte man immer eine Menge Dateien auf einmal festschreiben, und ich denke, was er vorschlägt, ist die falsche Lösung. Darüber hinaus kann durch das Einchecken großer Binärdateien viel Speicherplatz verschwendet werden, da SVN keine Deltas für Binärdateien speichert. Ein Check-in pro Tag ist ebenfalls schlecht, da Sie gezwungen sind, Änderungen vorzunehmen, die nicht zusammengehören, z. B. wenn Sie mehr als einen Fehler pro Tag beheben.

Die Lösung, die wir in unserem Unternehmen übernommen haben, ist, dass es einen Filter gibt, der alle Festschreibungen mit Binärdateien ablehnt. Wir können das Commit erzwingen, indem wir ein spezielles Schlüsselwort im Check-in-Kommentar verwenden (wir müssen SVN zeigen, dass wir wissen, was wir tun). Ein bis zwei Mal im Jahr archiviert ein Projektmanager alte Zweige und entfernt sie aus dem Repository. Mit dieser Strategie haben wir keine Speicherplatzprobleme, die mir bekannt sind (unser Repository unterstützt mehrere verschiedene Projekte und hat über 100000 Revisionen).

Zusammenfassend könnten Sie ihm sagen, dass Sie ihm zustimmen, dass Speicherplatz ein wichtiges Thema ist, aber auf der anderen Seite darauf hinweisen

1. die Wichtigkeit von merkmalsbezogenen Eincheckvorgängen anstelle eines monolithischen täglichen Eincheckvorgangs;
2. die Tatsache, dass man durch das Einchecken einer großen Binärdatei pro Tag die Festplatte trotzdem füllen könnte.

Dann können Sie vorschlagen, dass Sie ein Meeting haben (möglicherweise auch mit anderen Entwicklern oder Systemadministratoren), um Strategien zu besprechen, mit denen Sie die Auslastung des Festplattenspeichers unter Kontrolle halten können (z. B. Binärdateifilter, regelmäßige Sicherung und Bereinigung von alten nicht verwendeten Zweigen).

Wir hatten auch einen heftigen Streit darüber, ob die .project-Konfiguration von Eclipse in SVN aufgenommen werden soll. Mein Teamkollege bestand darauf, dass wir sollten, obwohl es zahlreiche sinnlose Konflikte verursacht hat. Ich war dagegen, einzelne Entwicklerkonfigurationsdateien in SVN zu belassen. Schließlich stellte sich heraus, dass mein Teamkollege nach jedem Commit den gesamten Quelltextbaum erneut auschecken musste, um sicherzustellen, dass "Code, der in das Repository geschrieben wurde" funktioniert. Aus diesem Grund behielt er die Projektkonfiguration in SVN so unerbittlich bei - so dass es einfach sein würde, das Projekt erneut zu importieren. Als ich erklärte, dass Commit die Arbeitskopie byteweise mit dem entfernten synchronisiert, was ein erneutes Auschecken unnötig macht, antwortete mein Teamkollege erneut mit Zweifel und winkte schließlich das ganze Problem als unbedeutend ab.

Meiner Meinung nach verschwendet unser Team Zeit, indem es SVN-Konflikte in Projektkonfigurationsdateien löst, die nur entwicklerspezifische Einstellungen enthalten, die für SCM überhaupt nicht freigegeben werden müssen. All diese Unordnung, weil jemand den Prozess auf falsche Annahmen zugeschnitten hat.

Verwenden Sie einen Build-Server? Wir haben einen Build-Server, der das gesamte Projekt auscheckt und es jede Nacht kompiliert. Am nächsten Morgen haben die Tester ein testfertiges Installationsprogramm für das Produkt (wenn der Master-Build ordnungsgemäß ausgeführt wurde) und wir (die Entwickler) haben einen Build-Bericht mit allen Warnungen (und Fehlern, falls vorhanden). Natürlich müssen Sie Standardkonfigurationsdateien für den Build-Server einrichten und einchecken. Jeder Entwickler kann sie dann zusammen mit dem Rest des Projekts auschecken, sie dürfen jedoch keine lokalen Änderungen einchecken .

In diesem Szenario müssen Sie das gesamte Projekt auschecken und es jederzeit erstellen können. Sie vermeiden auch, dass Sie Zeit für das Zusammenführen von Änderungen aufwenden, die eigentlich nicht überprüft werden sollten, da sie nicht Teil des Produkts sind: Das Produkt ist der Master-Build und muss sauber gehalten werden. Wenn jemand den Master-Build bricht (z. B. seine eigene .project-Datei eincheckt), können Sie die Änderungen rückgängig machen oder den Entwickler zwingen, das Problem zu beheben.

Wenn er das Problem erneut aufwirft, können Sie möglicherweise erneut vorschlagen, ein Meeting (möglicherweise mit anderen Entwicklern) abzuhalten und eine gemeinsame Strategie zu finden.

Wie kann ich einen Teamkollegen, der sich als Senior versteht, davon überzeugen, die SVN-Grundlagen besser zu verstehen?

Ich denke, die beste Strategie wäre es, den Konflikt nicht auf eine persönliche Ebene zu bringen, sondern die anstehenden Probleme und möglichen Lösungen zu diskutieren. Wenn Sie den Eindruck haben, dass er eine persönliche Konfrontation sucht, sind hier einige Vorschläge (wiederum aus persönlicher Erfahrung):

• Wie ist Ihre Teamdynamik? Haben Ihre anderen Kollegen eine ähnliche Erfahrung mit diesem Teamkollegen? Es gibt viele kleine, nicht zu explizite Hinweise, die ein Team einem seiner Mitglieder geben kann, um bestimmte Verhaltensweisen (kleine Witze oder Beobachtungen) zu entmutigen und konstruktive Konfrontationen anzuregen (ein Treffen vorzuschlagen oder ein Thema informell während einer Kaffeepause anzusprechen) ). Manchmal kann ein gutes Team ein störendes Element schnell isolieren und die Dinge wieder normalisieren.
• Wie gut ist Ihr Personalmanagement? Wir hatten einen Konfliktfall in unserem Unternehmen und der Personalleiter musste eingreifen, um die Situation zu klären. Es war nicht schön, aber manchmal verschlechtert sich die Arbeitsatmosphäre so sehr, dass es von selbst nicht besser wird. Ich hoffe, das ist nicht Ihr Fall (ich habe noch nicht den Eindruck, dass es so weit gekommen ist), aber es ist immer gut zu wissen, ob Sie eine gute Personalverwaltung haben oder ob Sie Konflikte alleine lösen müssen.

Warum schreibe ich das? Sie sagen, Sie möchten "einen Teamkollegen, der sich als Senior versteht, davon überzeugen, die SVN-Grundlagen besser zu verstehen". Für mich klingt es so, als würde der Konflikt zu persönlich werden. Einige Psychologen behaupten, dass 70% unserer Kommunikation auf der emotionalen Ebene stattfindet. Wenn diese Ebene nicht funktioniert, hören die Leute auf, über Fakten zu sprechen, weil sie zu beschäftigt mit Emotionen sind.

Sie können also nicht nur Ihre Punkte erläutern, sondern auch versuchen, die Kommunikation zu verbessern. Wenn Sie zu einem Kaffee oder einer gemeinsamen Mittagspause einladen, ein kurzes Gespräch über ein Thema führen, das nicht mit der Arbeit zu tun hat usw., können Sie die Kommunikation verbessern und die Aufmerksamkeit Ihres Kollegen auf die wichtigen Fakten lenken, die er verstehen soll. Wenn er diese Art der Kommunikation akzeptiert, dann haben die Konflikte, die Sie bisher hatten, möglicherweise damit zu tun, dass Sie sich nicht gut kennen und es einige kleine Missverständnisse gab, aber er ist wahrscheinlich offen für eine konstruktive Zusammenarbeit. Wenn er sich weigert, könnte es eine tiefere Feindseligkeit auf seiner Seite geben.

In diesem Fall sollten Sie warten, bis Ihre Rollen klarer werden. Wenn Ihr Teamkollege offiziell keinen höheren Rang als Ihren hat, hat er keinen Grund, sich über Ihre Versuche, Dinge zu verbessern, zu ärgern. Mit der Zeit wird er es akzeptieren oder sich lächerlich machen müssen, wenn er weiterhin zu zeigen versucht, dass er es besser weiß. Wenn er hat einen höheren Rang, sollten Sie einen Weg zu lassen , ihn finden zu verstehen , dass dies nicht in der Diskussion: Ihre Beobachtungen , die Produktivität zu verbessern und nicht zu untergraben , seine Position ausgerichtet sind, muss dieser 100% klar sein. Wenn die Rollen geklärt sind und er konstruktive Vorschläge oder Kritik immer noch nicht akzeptieren kann, muss er wirklich ein Problem mit dem Selbstwertgefühl haben oder so.

Wenn also alle oben genannten Strategien scheitern und Sie sich (sehr) frustriert fühlen, ist es meiner Meinung nach das einzig Vernünftige, Ihre Sachen zu packen und einen besseren Ort zu suchen. Ich habe diese Erfahrung vor drei Jahren gemacht und ein viel besseres Unternehmen gefunden, mit dem ich jetzt sehr zufrieden bin. Vielleicht ist dies nicht Ihr Fall (ich hoffe natürlich nicht), aber versuchen Sie auch, diesen Punkt zu verstehen.

Nur meine 2 Cent.

Weisen Sie ihn auf Lernmaterial über die Funktionsweise von SVN und die empfohlenen Vorgehensweisen bei der Verwendung von SVN hin.

Wie @Peter sagt - wählen Sie Ihre Schlachten sorgfältig aus und verschwenden Sie Ihre Energie nicht darauf, mit jemandem zu kämpfen, der die Grundlagen offensichtlich nicht versteht. SVN ist nicht gerade die neueste Technologie, und es ist schon eine Weile hier, also gibt es genug Informationen darüber.

Führen Sie ein Protokoll über die "SVN-Zeitverschwendung". Notieren Sie sich bei jedem Konflikt / Checkout / Versionsproblem, das gelöst werden muss, wie lange Sie / das Team für die Lösung benötigt haben. Wenn sich herausstellt, dass Sie jede Woche viel Zeit verschwenden, eskalieren Sie dies mit ihm und dem Management. Ich bin sicher, das Management wird bald nach Lösungen fragen, wenn es erkennt, dass die Produktivität durch einfache Änderungen im Arbeitsprozess verbessert werden kann.

Oder versuchen Sie, Ihren Kollegen von einer Testwoche zu überzeugen, in der das Team Ihr Check-in-System verwendet (sofern dies mit Ihren aktuellen Projekten und Ihrer Codebasis problemlos möglich ist). Versprich ihm, dass du nach Ablauf der Woche auf das alte System zurückschalten kannst, wenn es nicht funktioniert. Aber er könnte vorbei kommen, nachdem er es selbst ausprobiert hat.

1. Lassen Sie Subversion das Problem für Sie lösen. So wie Sie es sagen, ist Ihr Kollege relativ unkompliziert, wenn es um Subversion geht. In diesem Fall könnte eine technische Lösung eine gute Option sein. Wenn der Rest des Teams stimmt und Sie können Ihre Manager Segen zu bekommen, ein hinzufügen - global-ignoresFeld in die Repository - Konfigurationsdatei , so dass Sie die .project Dateien und andere ausschließen , dass Sie nicht unter Versionskontrolle wollen.

2. Helfen Sie ihm aus. Anstatt ihm aufzuzwingen, wie Sie Dinge tun, versuchen Sie, dem Kerl zu helfen, die Dinge auf seine Weise zu tun, ohne Probleme für alle anderen zu verursachen. Wenn Ihr Mitarbeiter in seiner eigenen Niederlassung arbeitet, sollte es Ihnen wirklich egal sein, was er festlegt. Wenn er seine .project-Datei festschreiben möchte, damit er eine neue Kopie des gesamten Verzeichnisses auschecken kann, ist dies für Sie kein Problem. Sie sollten sich nur darum kümmern, dass er seine .project-Datei nicht wieder mit dem allgemeinen Entwicklungszweig zusammenführt. Dies sollte wiederum einfach zu handhaben sein, indem Sie die ignore-Eigenschaft im Entwicklungszweig so einstellen, dass die .project-Datei ausgeschlossen wird.

3. Bitten Sie um Unterstützung von oben. Verwickeln Sie sich nicht in eine Auseinandersetzung mit dem Typen "Sie sind nicht der Boss von mir", aber wenn sein Verhalten ein Problem für Sie darstellt, stellen Sie sicher, dass sich Ihr Manager der Situation bewusst ist. Wenn Sie sich nicht sicher sind, wie Sie sich an Ihren Manager wenden sollen, fragen Sie ihn um Rat: "Mike, ich habe versucht, mit Larry zu sprechen, aber ich komme einfach nicht durch. Er besteht auf X, Y und Z und der Rest von uns verbringt viel unnötige Zeit damit, die Probleme zu lösen, die entstehen. Kannst du mir Hinweise geben, wie ich mit dem Typen umgehen soll? "

4. Ignoriere ihn. Warum hört jemand im Team auf diesen Typen? Hat er eine tatsächliche Autorität über das Projekt? Wen interessiert es, wenn er eine Ein-Commit-pro-Entwickler-Richtlinie festlegt, wenn er nicht die Befugnis hat, diese durchzusetzen? Lassen Sie ihn denken, dass er Yertle the Turtle ist, wenn er sich dadurch besser fühlt. Lassen Sie ihn nur keine echten Probleme für Sie schaffen.

Lass den Kerl feuern und sei fertig mit seiner schleppenden Ferse und der offensichtlichen Neigung zu neuerer Technologie. Oder fangen Sie an, GIT zu verwenden. Wenn er SVn nicht verstehen kann, wird er sicherlich von GIT umgehauen.

Du scheinst einen verlorenen Kampf zu führen, aber du kannst durchziehen. Machiavelli beschrieb in The Prince , wie schwierig es ist, den Status Quo zu ändern. Ich würde vorschlagen, dieses Kapitel noch einmal zu lesen und dann vielleicht nicht zu tun, was er vorschlägt - es kann hart sein.

Sie sollten Ihre Bedenken privat an den leitenden Entwickler weitergeben und sicherstellen, dass Sie konstruktiv die Art und Weise kritisieren, in der die Dinge erledigt werden, und nicht an ihm oder einem anderen Entwickler. Bieten Sie dann an, einen Vortrag zu halten und einen Leitfaden für bewährte Verfahren zu schreiben. Zeigen Sie ihnen, wie ein besseres Verständnis von SVN ihr Leben leichter macht. Letztendlich geht es um Kosten und Effizienz. Wenn Sie beweisen können, dass Ihr Weg die Dinge verbessert, ohne auf die Zehen zu treten, können Sie diesen gewinnen.

Versuchen Sie zu verstehen, warum die älteren Mitarbeiter das Repository so verwenden, wie es ist. Was sind ihre Anliegen? Was versuchen sie zu erreichen? Wie können Sie ihnen helfen, produktiver zu werden? Versuchen Sie vor allem, ruhig und professionell vorzugehen. Es ist leicht, frustriert zu werden. Seien Sie selbstbewusst: Durchsetzungsvermögen bei der Arbeit: Ein praktischer Leitfaden zum Umgang mit unangenehmen Situationen von Ken Back und Kate Back ist eine gute Lektüre. Zum Schluss überlegen Sie, wie ich mich zum Umstieg überreden würde. Seien Sie ein ehrlicher Anwalt des Teufels, und das kann Ihnen helfen, gute Antworten und Fragen zu finden.

Als Randnotiz würde ich vorsichtig sein, Humor zu verwenden. Es kann Wunder wirken oder Sie wie ein Arschloch klingen lassen. So würde ich es vermeiden.

Grundsätzlich sollten Sie Ihre Schlachten sorgfältig auswählen, da Sie diese möglicherweise nicht gewinnen. Wenn dies der Fall ist, kümmern Sie sich entweder nicht mehr darum oder suchen Sie einen anderen Job. Hart, ich weiß.

Ich war vor ungefähr 8 Jahren einmal in der Umkehrung Ihrer Position, als SVN eine einigermaßen neue Technologie war. Ich war ein Senior-Entwickler und wurde von einem Junior-Entwickler gebeten, SVN zu installieren (eigentlich war er genauer IT-Support als ein Entwickler). Ich war trotz meiner anfänglichen Vermutungen bezüglich einer erhöhten Arbeitsbelastung, unnötiger Komplexität usw. aufgeschlossen und wurde dann ein großer Fan davon.

Meiner Ansicht nach kommt es, wie Sie beschrieben haben, definitiv auf die Teampersönlichkeiten an - seine Hartnäckigkeit ist ein Hindernis für das gesamte Team in dieser Angelegenheit. Vielleicht ist es besser, wenn Sie an diesem Punkt zurücktreten und den Druck des restlichen Teams auf natürliche Weise aufbauen, um seine Hand zu zwingen.

Dies ist so ziemlich ein Fall von "Mangel an Autorität" und einer Person, die die Kraft ihrer eigenen Angst einsetzt, um die Dinge "unter Kontrolle" zu halten.

Um dieses Problem zu lösen, suchen Sie jemanden, der Ihren Teamkollegen oder jemanden, den er respektiert, inspiriert hat und der in der Lage ist, die Dringlichkeit der Verwendung von SVN zu erklären. Auf diese Weise spielt seine Angst vor Veränderungen und dem Verlust der Autorität keine Rolle, da ihm kein Teammitglied sagt, was zu tun ist. Ich würde es unterlassen, jemanden wie einen Manager zu gebrauchen, um mit diesem Typen zu sprechen, da dies nur zu mehr Druck und möglicherweise sogar zu einer stressigeren Situation für Sie führt.

Ich habe kürzlich Driving Technical Change gelesen : Warum Menschen in Ihrem Team nicht mit guten Ideen handeln und wie man sie davon überzeugt, dass sie das sollten. Dies wird von The Pragmatic Programmers veröffentlicht. Dieses Buch bietet Hintergrundinformationen, die Sie kennen sollten, bevor Sie versuchen, technische Änderungen einzuführen, eine Reihe von Mustern bei Personen, die Änderungen ablehnen oder ablehnen, Techniken zur Implementierung der Änderungen sowie Strategien zur Maximierung der Verwendung dieser Techniken und aller Personen in der Umgebung Sie.

Aufgrund Ihres Beitrags würde ich sagen, dass Ihr Teamkollege wahrscheinlich in das uninformierte oder das zynische Muster fällt, aber er könnte auch ein Fall des Irrationalen sein. Einige der Techniken, die empfohlen werden, um diese Art von Menschen zu bekämpfen, sind, Erfahrung in der Zielumgebung zu sammeln, damit Sie Probleme finden und Antworten auf Probleme präsentieren können, die anderen Menschen begegnen werden, bevor sie auftreten, das richtige Problem lösen, die Botschaft leidenschaftlich aber übermitteln Führen Sie die Techniken vor, ohne zu eifrig zu sein, indem Sie die Vorteile Ihrer Methoden und Tools deutlich machen und sie organisch verkaufen (aber keine Probleme schaffen, nur um sie zu lösen), und machen Sie den Rest Ihres Teams bekannt und kaufen Sie sie ein. Wenn er jedoch irrational ist, gibt es

Wenn Sie diese Techniken anwenden, benötigen Sie eine Gesamtstrategie. Es ist wichtig, nicht zuzulassen, dass diejenigen, die aktiv feindselig oder irrational sind, Sie verlangsamen - ignorieren Sie sie. Finden Sie stattdessen Leute, die Sie demonstrieren und davon überzeugen können, dass Sie einen besseren Weg haben, und wenden Sie die entsprechenden Techniken an, die auf ihnen als Individuum basieren. Sobald die Leute die Verbesserungen sehen, die Ihr Wissen bietet, können Sie sie nutzen, um andere zu überzeugen. Verwenden Sie diese Basisanstrengungen, um das Management davon zu überzeugen, dass es einen besseren Weg gibt, aber stellen Sie sicher, dass Sie ihn in Begriffen formulieren, die sie verstehen können (Zeit, Geld, Qualität).

Versuchen Sie nicht, diesen Typen von irgendetwas zu "überzeugen". Leute (sogar Programmierer) werden nicht auf vernünftige / logische Argumente von jemandem reagieren oder diese respektieren, den sie als jünger ansehen. Verschwende also nicht deinen Atem. Arbeiten Sie stattdessen daran, ein gewisses Maß an Vertrauen zu dieser Person aufzubauen. Diese Person hört nur zu, was Sie zu sagen haben, wenn sie dafür offen ist.

In der Zwischenzeit haben Sie echte Probleme:

1. Der Typ checkt seine .project-Datei in das Repo ein: Ignorieren Sie es einfach. Sie müssen weder die Datei ändern, noch jemand im Team, der es besser weiß. Vergiss es. Wenn es Ihrem "älteren Mitglied" ein warmes, fröhliches Gefühl wie eine Sicherheitsdecke gibt, dann sei es so.
2. Auf dem Festplattenspeicher ist ein Budget vorhanden: Dies ist der Grund, warum Mr. Senior vorschreibt, täglich 1 Commit durchzuführen. Ist der Platzmangel real oder wahrgenommen? Auch wenn es nur wahrgenommen wird, gibt es vielleicht etwas, das Sie tun können, um diese Wahrnehmung zu ändern. Das sollte sofort erledigt werden - wenn Sie die Initiative ergreifen, hilft es auch, Vertrauen aufzubauen.

Ich könnte auch hinzufügen, dass dieser Typ bereit sein wird, bessere SVN-Praktiken anzuwenden, wenn er denkt, dass sie seine Ideen waren. Das erfordert von Ihrer Seite einige Überlegungen, und er wird wahrscheinlich die Ehre haben, bessere Praktiken zu etablieren - aber Sie sind damit einverstanden.