最新のバージョン管理システムの利点の定量化
私は、大規模な金融企業環境でチームリーダー/開発者として3年間働いてきました。私たちの製品リリースプロセスは、Clearcaseを中心に展開するため、悪夢です。すべてのリリースを実行する変更管理グループがあり、そこから取得したコードのみを本番環境に導入できます。
入社時に最初に行ったことの1つは、Gitでチームを設定することでした。 Clearcaseはひどいものであり、日々のソース管理の問題を処理するのは現実的ではないことは誰もが同意しました。そこで、ローカルマシン上に一種の「非公式」リポジトリをセットアップし、リリース時間を中心にgitとClearcaseリポジトリを同期するスクリプトを書きました。
これは他のチームにも広まり、いくつかのチームが同じプロセスを採用しています。日常の活動には「非公式」の方法でgitを使用し、リリースには「公式」にClearcaseを使用します。私は、Gitの問題について、ある種の頼りになる人になりました。
そこで、今週、インフラストラクチャの変更を担当するSVPと会議を行い、Gitのメリットを具体的に説明してほしいと望んでいます。どうやら、私のClearcaseに関する私の頻繁な怒りの言葉が彼女に届いたようです。彼女が私の主張を受け入れれば、雇用主がこの嫌悪感を取り除くのを手伝うことができるでしょう。
経営幹部との私の経験から、a）すべてについて非常に簡潔な説明が必要であるb）ドルの数値を含む事実にのみ関心がある
開発者には、Git over Clearcase（またはClearcaseに関連する他のバージョン管理システム）のメリットを説明できますが、技術的な背景のない技術担当者にこれを行う方法については空白にしています（彼女には、 MBAと彼女の地理学の学部生をしました）。
私が彼女に対してするどんな議論も、技術的な意味不明のように聞こえるか、個人的な好みを伝道していると思います。
私が見つけようとしているのは、開発者がGit、またはあらゆる最新のソース管理システムをより効果的に使用していることを示す具体的な事実です。
他のチームが内部でGitを使い始めたという事実は意味のある兆候だと思いますが、それでも個人の好みとして却下される可能性があるため、まだ十分ではありません。
私が本当に必要としているのは、「このプロセスは20年間機能してきましたが、なぜ変更する必要があるのか」を突破するのに十分強力なものです。引数。
私は非常に似た状況にあります（航空宇宙および自動車産業で）。この会議またはその後の会議では、それほど遠くに進むことを期待しないでください。これらの状況はどちらも、改善のために戦い続けたいという私の願望よりも長続きしましたが、これが私がこれまでに見た中で最高の戦術です...
「このプロセスは20年間働いています」とおっしゃっていますが、本当にそうですか。 「私たちの製品リリースプロセスは悪夢です」という意味を概説することから始めます。 ClearCaseにできるだけ依存しない現在のプロセス/ツールで問題のリストを作成します。
次に、可能な限りGitにとらわれないプロセス/ツールの「ソリューション」のリストを作成します（Gitまたは最新のDVCSは、法案に正確に適合します）。 GitがClearCaseより優れている理由を説明しても、ユーザー以外には何の意味もありません。
インフラストラクチャチームが、現在のアプローチに特定した問題があることを確認できるようにします。これはおそらく、これらの問題を「修正」するためにIBMにサポートを求めることになります。 IBMが問題を回避しないように、接続を維持してください。 ClearCaseには、バージョン管理に関する現代的な理解の基本的な特性がないため、これらの問題のほとんどは修正できないか、大きなインフラストラクチャの変更が必要になります。
この時点でうまくいけば、インフラストラクチャチームはこれをビジネス上の問題と見なしますが、簡単な解決策がないものと見なします。この時点で、追加のソリューションを見積もりコストでベンチマークすることを提案します。多くのチームがすでにGitを使用しているため、トレーニングを費用として削除できるはずです。
幸運を！
私たちの製品リリースプロセスは、Clearcaseを中心に展開するため、悪夢です。すべてのリリースを実行する変更管理グループがあり、そこから取得したコードのみを本番環境に導入できます。
いいえ、変更管理グループとリリース手順のため、プロセスは「悪夢」です。 SVNまたはgitまたはFossilのClearcaseを置き換えてください。 まったく同じ問題になります。 （私は彼らがTBHを正しく行っていると思います、強力なリリース管理が不可欠です）。
これはあなたが集中する必要があるものであり、gitのマニアックな資格情報（開発者以外には関係ない）ではなく、プロセスを変更するビジネスケースに集中する必要があります。 Clearcaseを使用してそれを実行できる可能性がありますが、とにかくgitを使用するアイデアをこっそりと見る機会が与えられます。
ここで「全体像」を見ていない場合は、リリースグループが必要とするのと同じ制限付きでgitを使用するのが最良のケースです。変更管理の目的の幅広い側面を検討する場合、組織が必要とする厳密に制御されたリリースプロセスの種類でgitを有用にするために実装する必要がある制限に感謝します。
あなたのためのいくつかのアイデア：開発者の観点から現在のシステムの生産性の問題を見てもらいます。これを2の第1部として実行します。第2部では、開発者が理解する必要のある制御の問題を確認できるように、リリースでそれらを操作します。双方が反対側の見解を理解するための学習課題として扱うと、どちらかの側の主要な要件を解決するソリューションをより適切に考案できるはずです。リリースは開発よりも重要であるため、期待以上の成果を上げる準備ができている必要があります。
リリースに何が必要であるかを理解したら、必要なものを提供していることを示すことができる詳細なプロセスドキュメント（手順の詳細を含む）を作成することに同意する必要があります。これをマッサージして開発者側がより良くなるようにする方法は、あなた次第です。ソースが適切に管理され、リリースが正しく整理されている限り、開発者がdevがどのようにdevを実行するかは気にしないと思います。つまり、コードの変更を変更チケットに結び付ける方法、作成したコードの取得方法を示す必要があります。パッチを当ててビルドし、再リリースするリリース。
具体的な例は、抽象的な利点以上のものを印象づけます。 （a）Clearcaseが解決に時間がかかった問題を引き起こし、（b）Gitがそれらの問題を解決する特定の例を文書化できれば、最も成功すると思います。 whyの技術的な詳細に入る必要がないことを忘れないでください。これは（質問されない限り）単純であることを示すためです。経営者は専門性を知る必要はありません、それはあなたが支払われるものです。
これらの例に特定のタイムスケールと日付を付けることができれば、はるかに優れています。また、よく行うタスクXがClearcaseでY分、GitでZ分かかることを示すことで、これを上回らせることもできます。
時は金なりなので、Gitでの作業がquiickerであることを示すことができれば、それが経済的にも意味があることを示すことができます。
ここに私がそれをどうやって試すかという試みがあります。
それは開発者にとって愚かに聞こえるかもしれませんが、管理者にとって、技術的な変更は危険であると考えられています。
「魔法のものがすでに機能しているなら、なぜそれを破るリスクを取るのか？」
したがって、あなたはテーブルを回す必要があります。 gitへの切り替えを危険にさらすことではなく。どんな犠牲を払っても、それが新しいおもちゃのように聞こえないようにしてください。
まずgitが広く使われるようになったことから始めましょう。次のような数字を使用します。 http://ianskerrett.wordpress.com/2014/06/23/Eclipse-community-survey-2014-results/
管理者にとって、これはgitを使用する多くの開発者を見つけることができるはずであることを意味します。そして、サードパーティツールのエコシステム全体（Microsoftでさえ、現在gitとビジュアルスタジオを統合していると聞きました）。
また、マネージャーは主流の事柄をフォローしたことについて本当に非難されることはできませんか？対照的に、ここで$ other_cvsを使用しているのは誰ですか？
シンプルで高速、柔軟、強力なので、大規模なプロジェクトでの使用方法に重点を置きます。gitを使用する大きな名前が付いた大きなプロジェクト（GNU/Linux、Google、Microsoft ...）を見つけます。
それは悪い動きではないことを示したので、あなたはそれがあなたの場合に物事をどのように改善するかについて進むことができます。
あなたは会社が競争力を維持し、より速く、より機敏なチームに追い越されないようにしたいですよね？ ClearcaseとGitを使用して、生産性がどのように変化したかについて、内部の（書面による）見積もりを見つけようと思います。そこでは、他の開発者の助けを借りることができます。次に、企業全体（つまり、すべてのソフトウェア開発者）を、Clearcaseに留まるための数と推定コストを使って推定します。
ミーティング後、必要に応じてメールで全体を要約します（適切な人物を含めます）。
私が本当に必要としているのは、「このプロセスは20年間機能してきましたが、なぜ変更する必要があるのか」を突破するのに十分強力なものです。引数。
これは無効な議論です（馬車は「何世紀にもわたって機能しました」が、代わりに自動車を購入したいと思うでしょう）。
私はsvn対Mercurialについて同じ議論を聞いたことがあります（私は開発システムでMercurialを使用していました）。
この問題は、機能するものを置き換えることに関するものではありません。それをそのように表現しようとしないでください。これが「敗北」する必要がある質問である場合、最初に指摘する必要があります。それは何が機能するかどうかではなく、gitを使用する利点の問題です。 、両方の作業の場合（およびgitがうまく機能する理由）。
Gitを使用するための適切な引数：
gitはファイル中心ではなく、チェンジセット中心です。つまり、変更はファイル全体で追跡しやすくなります（プロジェクト全体の追跡可能性）。
gitは集中管理されているのではなく配布されています。つまり、チェックインはネットワークの速度によって制限されず、時間を大幅に節約できます。また、ClearCaseサーバーがダウンした場合に単一障害点がないことも意味します。
ブランチシステムであるため、gitはマージの必要性を最小限に抑えます（つまり、すべてのチェックインでファイルをマージするのではなく、完了したすべての機能でマージします）。マージ競合の解決（ある場合）から1日数回（コミットごと）から週1回または2回（完了した機能ごと）に切り替えます。これは、開発者の開発時間が増えることを意味します（マネージャーが最大化したいと思うもの）。
他のチームが内部でGitを使い始めたという事実は意味のある兆候だと思いますが、それでも個人の好みとして却下される可能性があるため、まだ十分ではありません。
定性的な違いはso bigであることが指摘できます。これは、会社全体の開発者が、追加機能のために、Clearcaseに加えてgitのインストール、構成、使用の複雑さを好むことを示しています。それは実際には強力な議論です（全体としてより優れたユーザーエクスペリエンスと機能セットを提供しなかった場合、人々はそれを使用するために余計な努力をしません-特にそれが何かのためにnot会社）。
そこで、今週、インフラストラクチャの変更を担当するSVPと会議を行い、Gitのメリットを具体的に説明してほしいと望んでいます。
2つのシステムでのコミットを表すグラフを描き、開発者が公にコミットしないことで得られた合理化を示します（つまり、ファイルを中断した場合、チームの残りのメンバーはブロックされず、修正するまでコンパイルできません）。また、他の人に影響を与えずに中間コミットを実行できる場合に実行できる追加の品質管理について説明します。クリーンな差分を取得できるという事実機能ごと（コードレビューに不可欠）。
私が本当に必要としているのは、「このプロセスは20年間機能してきましたが、なぜ変更する必要があるのか」を突破するのに十分強力なものです。引数。
シーンの目撃者にならないと、何が良い議論になるのかを本当に判断することは困難です。しかし、私はあなたがそれらが聞かれることができるようにあなたの議論を組み立てるのを助けるように努めます。
私はあなたの聴衆がトピックについての非専門家レベルの知識を持ち、現在のコースを続けることに興味を持っていると思います。彼らにはさまざまな懸念と責任があり、何かがうまくいかないと深刻な結果を被る可能性があるため、その考え方から作業する必要があります。彼らが持つかもしれないいくつかの質問や心配を予想してください：
これにより、どのような新しい機能がもたらされますか？現在実行できないこと、実行したいこと、およびこの新しいことにより、 ？肯定的なメモから始めます。
リリーススケジュールにどのような影響がありますか？すぐ次のリリースに向けてこの変更を実装するコストはどのくらいですか？次のリリースのコストと利点は何ですか？
これにはプロセスの変更が伴いますか？リリーススケジュールとは異なり、この変更ではリリースプロセスの担当者が方法を変更する必要がありますか？これは彼らに透過的ですか、それとも彼らは適応する必要がありますか？他の部門と協力する必要がありますか？人々は変化に対して抵抗力があります。
現在のシステムに固執する差し迫った危険がありますか？現在のプロセスにはソフトウェアまたはハードウェアの依存関係がありますか？なくなったか、まもなく寿命を迎えますか？採用コストを押し上げる個人の専門知識に依存していますか？新しいシステムが差し込む潜在的なセキュリティホールはありますか（このホールが法的措置につながる可能性がある場合のボーナスポイント）？手を振ったり、「多分」または「多分」これをしたりしないでください。20年間はうまく機能したという意味です。そのため、変更の擁護者に立証責任があります。
また、問題と解決策について具体的に記述してください。特定の例が見つからない場合は、専門家としての立場からの正直な見積もりを使用してください。このような変更を採用している他の企業/部門/事業体、できればあなたの業界からの例、およびその変更の彼らの評価は、あなたを助けるでしょう。 （ここ数年、何らかの公表されたIT問題があった例を選択しないでください。この変更が原因ではないことを証明する責任はあなたにあります。）
この回答 から バージョン管理を実装するために私が働いている会社を説得しますか？ が役立つかもしれません。