version-control - TFSプロセスガイダンステンプレートのロックイン？

Question

私のチームは、多くのツール（SCM、バグ追跡、ビルド、テスト）をTFSに移行することを検討しています。各システムを段階的に移動することを検討しています。たとえば、最初にソース管理を移動し、次にバグ/機能の追跡などを行います。

ソース管理（またはTFSの何か）を使用するためにプロセステンプレートを選択する必要があるので、決定にどの程度固定されていますか？後で別のプロジェクトを作成する必要がないようにしたいと思っています（または、思ったほど悪くはありませんか？）。

理論的には、プロセステンプレートが事後に構成するすべてのものをカスタマイズできることは知っていますが（右？）、これは実際にはどの程度実現可能ですか？

これが私が物事が起こっているのを見る方法です：

1. ソースコードを移行します。MicrosoftのCMMIテンプレートを選択します。
2. 従来のバグ追跡システムへの簡単なリンクである新しい作業項目（またはチェックインノート）を作成します。
3. 私たちはしばらく働きます。
4. 私たちは、新しいTFS開発ワークフローを実行する力（私たちはまともな規模のソフトウェア会社です）まで待ちます。これは、新しい作業項目の単純なコレクション、またはあらゆる種類のものを構成するまったく新しいテンプレートの場合があります。
5. 私たちは、歴史を失うことなく、TFSプロジェクトをこの新しいシステムに移行しようとしています。

TFSを使用する前に、これらすべての決定が完了するまで待たなかったのは残念ですか？

Answer 1

したがって、ある程度の「ロックイン」があるので、プロセステンプレートについて考えるのは正しいですが、それほど深刻ではありません。瞬間接着剤ではなく、蜂蜜でプロセステンプレートに固執しているようなものです。

個人的には、MSFアジャイルテンプレートから始めます。はるかに軽量で、作業項目が少ないため、削除する（より複雑で完全に満足できるものではない）のではなく、追加したい（TFSで非常に簡単で、非常によくサポートされている）方が好きです。

ただし、ユーバープロセス定義プロセスを停止し、12か月以内に魔法のように新しいプロセステンプレートを作成して、使用してほしいと判断した場合でも、完全に失われることはありません。まったく新しいチームプロジェクトを作成したい場合は、そのサーバー（またはTFS 2010のプロジェクトコレクション）上にある限り、コードを新しいチームプロジェクトに分岐できます（つまり、履歴は多少異なります）現在のバージョンのTFSクライアントでは隠されています）、またはソース管理用の空のフォルダーを使用して新しいチームプロジェクトを作成し、子フォルダーを古いチームプロジェクトから新しいチームプロジェクトに移動できます。TFSは同じTFSインスタンスでの移動の履歴を維持するため、これにより履歴が完全に保持されます。

明らかに、実際のプロジェクトで実際にTFSを12か月間使用することで、ノックする力が、光沢のある新しいプロセステンプレートをどのように見せたいかを知るためのより良い立場に立つことができます。これは決して起こらない演習であり、ほとんどの人はMSFアジャイルの端をいじくり回したり、 Scrum ForTeamSystemのようなより規範的なものを選んだりすることに満足していることがわかりました。

お役に立てば幸いです。

マーティン。