質問

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

ソース管理(またはTFSの任意のもの)を使用するためにプロセステンプレートを選択する必要があるため、決定にどの程度拘束されますか?後で別のプロジェクトを作成する必要を回避したい(それとも私が思っているほど悪くないですか?)。

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

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

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

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

役に立ちましたか?

解決

つまり、一定量の「ロックイン」があるため、プロセステンプレートについて考えるのは正しいことです。ただし、それほど深刻ではありません。まるで、スーパーグルーではなく蜂蜜でプロセステンプレートにこだわっているようです。

個人的には、MSFアジャイルテンプレートから始めます。それははるかに軽量で、作業項目が少ないので、物を取り去るのではなく(TFSで非常に簡単で、非常によくサポートされている)物を追加したい(より複雑で、完全に満足できるものではありません)。

ただし、12か月後に新しいプロセステンプレートを作成し、魔法のように使用してほしいと判断した場合、完全に失われるわけではありません。新しいサーバープロジェクト(またはTFS 2010のプロジェクトコレクション)にある限り、新しいチームプロジェクトを作成したい場合は、新しいチームプロジェクトにコードを分岐させることができます(つまり、履歴は多少なります) TFSクライアントの現在のバージョンでは不明瞭になっています)、またはソース管理用の空のフォルダーを使用して新しいチームプロジェクトを作成し、古いフォルダーから新しいフォルダーに子フォルダーを移動できます。 TFSは同じTFSインスタンスでの移動の履歴を保持するため、これにより履歴が完全に保持されます。ただし、移動前のワークアイテムは古いプロセステンプレートに残っているため、コピーするか、そのままにしておくかを決定する必要があります。

明らかに、実際のプロジェクトで12か月間TFSを実際に使用することで、ノックするパワーも、あなたのピカピカの新しいプロセステンプレートをどのように見せたいかを知るために、はるかに良い位置にいます。 「これは決して起こらないエクササイズであり、ほとんどの人はMSFアジャイルの端をいじったり、 Scrum For Team System

役立つこと、

マーティン。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top