バージョン管理の採用を奨励する方法

私は最近、バージョン管理のないチームで働き始めました。ほとんどのチームメンバーは、どのようなバージョン管理にも慣れていません。私は自分の仕事を追跡するためにMercurialを個人的に使用しています。私は他の人にそれを採用することを奨励し、少なくとも彼らが変更を開発するときに彼らのコードのバージョン管理を開始したいと思います。mercurialなどの分散バージョン管理の採用をどのように奨励できるかについて、誰にでもアドバイスをいただけますか。DVCSのマネージャーを含む人々を獲得する方法に関するアドバイスは大歓迎です。

バージョン管理の使用を主張し、まずそれを同僚に販売してみてください。それが失敗した場合は、プロジェクトリーダーシップ以上にチェーンを上げてください。

仲間のソフトウェアエンジニアにとっては、長期的に見て時間と頭痛の種をどのように節約するかに焦点を当てるべきです。バージョン管理を使用することで生活が楽になる方法について、自分の過去の時間、または公開されたストーリー（ブログ、雑誌の記事、ホワイトペーパー）を見つけてください。バージョン管理がないためにやけどをした場合は、個人的なものにしてください。仲間の開発者が同じ状況にあった場合、彼らは光とこれらのツールがどのように彼らを助けることができるかを見なければなりません。

これが最善の策です。現在ソースを見つけることができませんが、処理するための最も効果的な変更は、変更に対処する必要がある開発者から来ることを（数か所で）読みました。開発者を乗せることができれば、2つのことを達成できます。まず、プロセスの変更の影響を受ける人々からの賛同を得ています。第二に、これは価値のある努力であり、製品とプロジェクトを改善するだろうと経営者を説得する人々のグループがあります。

ただし、開発チームのサポートを得ることができず、バージョン管理の展開について非常に強く感じている場合は、管理に移行できます。しかし、改善を売り込むことを心配するだけでなく、同僚からの反発にも対処する必要があるため、単独で行っている場合はリスクが高くなります。

プロジェクト、プログラム、および組織の管理を行うには、バージョン管理を展開することで組織の時間とお金を節約する方法を検討する必要があります。このレベルの人々は、プロジェクトがどれだけのお金を費やしているのか、見積りと比較してどこにいるのかなどを気にします。ホワイトペーパー、書籍、記事、およびその他の専門的なドキュメントや出版物を探して、バージョン管理を展開することで長期的に他の組織の時間とお金を節約したことを説明してください。組織がソフトウェアの品質に関心がある場合は、ここで品質の観点を紹介することもできます。

分散バージョン管理システムを使用することを具体的に述べました。それをチームや組織の喉に押し付けないでください。バージョン管理とそのオプションを紹介します。個人的にDVCS（Mercurialなど）の使用を好むかもしれませんが、チームや組織に最適ではないかもしれません。不適切なツールを使用すると、スラッシングによって問題が悪化するだけです。

また、プロセスを遅らせることのリスクに注意してください。バージョン管理の使用は一般的に受け入れられているベストプラクティスですが、プロジェクトを完了する大きなリスクなしに現在のプロジェクトにバージョン管理を効果的に導入するには遅すぎるかもしれません。代わりに、将来のプロジェクトとチームの現状を改善することに焦点を当てることをお勧めします。

また、これはプロセスまたは技術の改善を実行するために従うことができる一般的なアプローチです。

最初の質問は：彼らは現在何をしているのですか？確かに、各開発者は、自分が自由に変更するソースコードを自分のボックスに貼り付けているわけではありません。現在彼らが従っているプロセスがあれば、このプロセスを強化するいくつかのツールを提案できます。通常、SCMは異なるプロセスに従うのではなく、これを支援するのに理想的です。

ここでの主なポイントは、仮にSCMの動作方法があり、現在のバージョンをサーバーに保存している場合は、DVCSまたはCVSのどちらが適切かを判断する必要があることです。Mercurialを販売しないでください。 SVNの方が適している場合。

最速の方法は、管理者にそれが必要であることを納得させることです。

いくつかの計算を行います：

バージョン管理ソフトウェアのコスト-無料。
リポジトリをサポートするためのハードウェアのコスト-1台のサーバー。
ソフトウェアの実装コスト-小さなチームでは数人日、大きなチームでは上昇します。

バージョン管理を実装しない場合のコスト：

ベストケース-編集が失われたり、お互いの変更が上書きされたり、バグが繰り返し発生するなどして、失われた日数。
最悪の場合-ただし、チームはこれまでに何年もの労力を費やしました。

この後者の図は、サーバー障害などによりすべての作業が失われる最悪のシナリオですが、「ベストケース」のシナリオでさえ、なぜそれが必要なのかを思い出させるはずです。繰り返し発生するバグのコストは、顧客を失う可能性があるため、より高くなる可能性があります。

また、開発チームはこれらのコストを理解する必要があり、ほとんどの（すべてではないにしても）バージョン管理ソフトウェアがIDEにシームレスに統合されることを考えると、ほとんどの場合に気付かないこともあります。

経営陣は通常、お金を節約することを最も重視します。バージョン管理がどのようにチームに経済的に利益をもたらすかを強調し、すぐに彼らの注意を引くでしょう！

ここにいる他の人が触れていない側面があります-あなたはあなたのコーナーにいると思います-あなたは分散バージョン管理について話している -その性質により、あなたはそれを事実上の実践に潜入することができます一度に。私たちのオフィス（MS Visual SourceSafe）で使用しているような、より面倒なバージョン管理を使用すると、私の向こう側のキューブにいる男に近づいて、1対1で対面販売するのに苦労することになります。バージョン管理。ただし、（任意の）DVCSを使用すると、「ちょっと、これを試して、気に入ったかどうかを確認できます。ロープを紹介します。ご質問にお答えします。何とか」。そうすれば、高いところから「プロセス」を必要とせず、一度に1人ずつ草の根の権限を構築できます。

gbjbaanbの答えに基づいて構築します。

ここで重要なことは、バージョン管理プロセスを既存のプロセスに適合させ、それがチームの残りの労力をどのように節約するかを示すことです。

個人的にもMercurialを好んでいますが、旧バージョンのサーバーベースのロックバージョン管理システムよりも理解するのが少し難しいので、バージョン管理に慣れていない人に必ずしもそれを押し付けたくありません。それは、もしそれが真のグリーンフィールズサイトなら、豚を丸ごと連れて行き、80年代と90年代をスキップしてMercurialに行くのが最善かもしれないということです。また、Mercurialを中心に構築されたサードパーティのソフトウェアライフサイクルの一部を見てみたいと思います。

あなたは小さな会社で働いており、チームに比較的新しいので、それは難しい販売になるかもしれないと思う-特にチームの残りの部分が定着しており、経営の信頼を持っている場合。彼らに何かをひどく詰め込んで救助に来させるのが最善かもしれません。それは妨害行為を意味するものではなく、避けられないものを待つだけです。