最新のバージョン管理システムの利点の定量化[終了]

私は、大規模な金融企業環境でチームリーダー/開発者として3年間の大半を担当しました。生産リリースプロセスは、Clearcaseを中心に展開するため、悪夢です。すべてのリリースを実行し、そこから取得したコードのみを本番環境に許可する変更管理グループがあります。

参加したときに最初にしたことの1つは、Gitでチームを設定することでした。誰もが、Clearcaseはひどく、日々のソース管理の問題を処理するには実用的でないことに同意しました。そこで、ローカルマシンに一種の「非公式」リポジトリをセットアップし、リリース時間前後にgitとClearcaseリポジトリを同期するスクリプトを作成しました。

このことは他のチームにも広まり、いくつかのチームが同じプロセスを採用しています。日々の活動にはgitを「非公式」に使用し、リリースにはClearcaseを使用して「公式に」使用します。私は、Gitの問題については、やる気になりました。

そのため、今週、インフラストラクチャの変更を担当するSVPとの会議を開催し、Gitのメリットを彼女に説明してもらいたいと考えています。明らかに、Clearcaseでの頻繁な暴言が彼女に届いたようです。彼女が私の主張を受け入れれば、私の雇用主がこの忌まわしいものを取り除くのを手伝うことに真剣に取り組むでしょう。

経営者との私の経験は、a）すべてについて非常に簡潔な説明を望んでいること、b）ドルの数字を含む事実のみに関心があることを教えてくれます。

開発者には、Clearcase（またはClearcaseを介した他のバージョン管理システム）を介したGitのメリットを説明できますが、技術的背景のない技術幹部にこれを行う方法について空白を書いています（彼女は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よりも重要であることに注意してください。したがって、あなたが期待するよりも多くを提供する準備ができているはずです。

リリースに必要なものがわかったら、必要なものを提供することを示すことができる詳細な手順文書（詳細な手順に従って）を作成することに同意する必要があります。開発者側があなたにとってより良いようにこれをマッサージする方法はあなた次第です。ソースが適切に管理され、リリースが正しく編成されている限り、開発者が開発者をどのように気にかけてもいないことを想像します。パッチを当て、ビルドし、再リリースするリリース。

特定の例は、抽象的な利点よりも印象的です。（a）Clearcaseが解決に時間がかかる問題を引き起こし、（b）Gitがそれらの問題を解決する特定の例を文書化できる場合、最も成功すると思います。これがなぜそうであるのかについての技術的な詳細に進む必要はないことを覚えておいてください（尋ねられない限り）。経営陣は技術を知る必要はありません、それはあなたが支払われるものです。

特定のタイムスケールと日付をこれらの例に添付することができれば、より良い結果が得られます。また、多くのタスクXを行う場合、ClearcaseでY分、GitでZ分かかることを示すことで、これを補うことができます。

時は金なりです。Gitでの作業が速いことを示すことができれば、経済的にも意味があることを示すことができます。

ここに私がそれをどのように試みるかの試みがあります。

それは開発者にとっては愚かに聞こえるかもしれませんが、管理者にとっては、技術の変化は危険であると考えられています。

「魔法のようなものがすでに機能している場合、なぜそれを壊すためにリスクを取るのですか？」

したがって、テーブルを回す必要があります。gitへの切り替えを行わないように、よりリスクを高めます。どんな犠牲を払っても、それが新しいおもちゃのように聞こえないようにしてください。

gitは現在広く使用されていると言うことから始めます。次のような数字を使用してください：http : //ianskerrett.wordpress.com/2014/06/23/eclipse-community-survey-2014-results/

マネージャーにとって、これはgitを使用して多くの開発者を見つけることができることを意味します。そして、サードパーティツールのエコシステム全体（Microsoftでさえgitとvisual studioを統合していると聞きました）。

また、マネージャーは、主流のものに従うことを非難することはできませんか？対照的に、ここで$ other_cvsを使用するのは誰ですか？

シンプルで、高速で、柔軟で、強力であるため、大規模なプロジェクトがそれを使用していることに重点を置きます。

それが悪い動きにならないことを実証したら、それからあなたのケースで物事を改善する方法に進むことができます。

会社の競争力を維持し、より速く、より機敏なチームに負けないようにしたいですか？Clearcase対Gitを使用して、生産性がどのように変化したかについての内部（書面）推定値を見つけようとします。そこにいる仲間の開発者からの助けを借りることができます。次に、Clearcaseでの滞在数と推定コストを使用して、会社全体（つまり、すべてのソフトウェア開発者）を推定します。

適切な場合でも、会議後に書かれた電子メールですべてを要約します（適切な人を含めます）。

私が本当に必要なのは、「このプロセスは20年間機能していましたが、なぜ変更する必要があるのですか？」引数。

これは無効な引数です（馬車は「何世紀にもわたって機能しました」が、代わりに車を買いたいと思うかもしれません）。

私はsvn対mercurialについて同じ議論を聞いたことがあります（私は開発システムでmercurialを使用していました）。

この問題は、機能するものを置き換えることではありません。それをそのように表現しようとしないでください、そしてこれがあなたが「打ち負かす」必要がある質問であるなら、あなたはそれが何が機能するかどうかの問題ではなく-あなたがgitでどのような利点があるのか​​を指摘することから始めるべきです、両方が機能する場合（およびgitがよりうまく機能する理由）。

gitを使用するための適切な引数：

• gitは、ファイル中心ではなく、チェンジセット中心です。これは、ファイル全体の変更の追跡が容易であることを意味します（プロジェクト全体の追跡可能性）。

• gitは中央集中型ではなく配布されます。これは、スタッフのチェックインがネットワーク速度に制限されないことを意味します-繰り返しますが、多くの時間を節約できます。また、ClearCaseサーバーがダウンした場合に単一障害点がないことも意味します。

• ブランチシステムのため、gitはマージの必要性を最小限に抑えます（つまり、すべてのチェックインではなく、完了したすべての機能でファイルをマージします）。マージの競合の解決（ある場合）を1日に数回（コミットごとに）から週に1回または2回（完了した機能ごとに）に切り替えます。これは、開発者の開発時間が長くなることを意味します（マネージャーが最大限に活用したいものです）。

他のチームが内部でGitを使用し始めたという事実は意味のある兆候であると思いますが、個人的な好みとしては却下される可能性があるため、まだ十分ではありません。

定性的な違いは非常に大きいため、社内の開発者は、追加機能のために、Clearcaseの上にgitをインストール、構成、使用する複雑さを好むことを指摘できます。これは実際には強力な議論です（ユーザーエクスペリエンスと機能セットを一緒に提供しなかった場合、特に企業が必要としないものであるため、人々はそれを使用するために余分な距離を移動しません）。

そのため、今週、インフラストラクチャの変更を担当するSVPとの会議を開催し、Gitのメリットを彼女に説明してもらいたいと考えています。

2つのシステムでのコミットを表すチャートを描き、公開していない開発者によって得られた合理化を示します（つまり、ファイルを作成した場合、チームの残りはブロックされず、修正するまでコンパイルできません）。また、他の人に影響を与えずに中間コミットを行うことができる場合に行うことができる追加の品質管理、機能ごとにクリーンな差分を取得できるという事実（コードレビューに不可欠）も説明します。

私が本当に必要なのは、「このプロセスは20年間機能していましたが、なぜ変更する必要があるのですか？」引数。

シーンの目撃者でなくても、良い議論になるものを本当に判断するのは難しい。しかし、私はあなたがあなたの議論が聞こえるようにあなたの議論を組み立てるのを手伝うようにします。

あなたの聴衆は、そのトピックに関する専門知識のないレベルの知識を持ち、現在のコースを維持することに関心があると思います。彼らにはさまざまな懸念と責任があり、何かがうまくいかないと深刻な結果を被る可能性があるため、その考え方から取り組む必要があります。彼らが持つかもしれない質問や心配のいくつかを予想してください：

• これによりどのような新しい機能がもたらされますか？ 私たちが現在できないこと、やりたいこと、この新しいことで私たちができることはありますか？肯定的なメモから始めます。

• リリーススケジュールへの影響は何ですか？ すぐ次のリリースに向けてこの変更を実装するコストはいくらですか？次のリリースのコストと利点は何ですか？

• これにはプロセスの変更が必要ですか？ リリーススケジュールとは異なり、この変更では、リリースプロセスの担当者が方法を変更する必要がありますか？これは彼らにとって透過的ですか、それとも彼らは適応する必要がありますか？他の部門と協力する必要がありますか？人々は変化に抵抗します。

• 現在のシステムに固執する差し迫った危険はありますか？ 現在のプロセスには、ソフトウェアまたはハードウェアの依存関係がありますか、それとも間もなく終了しますか？雇用コストを押し上げる個人の専門知識に依存していますか？新しいシステムが差し込む潜在的なセキュリティホールがありますか（このホールが法的措置につながる場合のボーナスポイント）。手を振ったり、「多分」、「おそらく」これをしないでください。20年間うまく機能しているという意味なので、証拠の負担は変化の提唱者にあります。

また、問題と解決策について具体的に説明してください。特定の例を見つけることができない場合は、専門家としての立場からの正直な見積もりを使用してください。できればあなたの業界から、そのような変更を採用している他の企業/部門/エンティティの例、およびその変更の評価はあなたを助けます。（近年何らかのITの問題が公表された例を選択しないでください。そうしないと、この変更が原因ではないことを証明する責任があなたにあります。）

あなたは見つけることがこの回答するバージョン管理を実装するためのI社の作業を説得しますか？役に立ちました。