3

TFS（少なくとも2010以降）では、反復の概念があります。これは、作業の割り当てに役立つと思われます（リリース1.0で何をするか、1.1で何を計画するか、バックログに何を残すか）。私はTFS2012のスクラムテンプレートを見てきました。

では、バグを製品バージョンごとにどのように分類しますか？たとえば、v1.0とv2.0が実際に使用され、v3.0が開発中の製品があるとします。

ここで、v1.0のバグを発見しましたが、v2.0とv3.0にもバグが含まれていることがわかりました。

コード的には、devのバグを修正してから、v1.1とv2.1にマージして、現在のユーザーが自分のバージョンに悩まされないようにします（常に最新バージョンへのアップグレードを義務付けるとは限らないため） 。

TFSでバグを作成する場合、反復パスを指定するオプションがあります。ただし、使用できるイテレーションは1つだけですが、バグを3つのバージョンすべてに存在するものとして宣言し、マージが発生したときに個別に修正済みとしてマークできるようにする必要があります。

TFSでのその作業方法をサポートする方法はありますか、それとも私はそれを間違って見ていますか？

4

2 に答える 2

2

これを実現する1つの方法は、TFSのバグのデフォルトの作業項目タイプを変更することです。

  1. VS 2010ではTools > Process Editor > Types > Open WIT From Server、メインメニューから選択してエディターを開きます

  2. [作業項目の種類の選択]ダイアログで、このテンプレートを適用するチームプロジェクトを展開し、[バグ]を選択して、[ OK ]をクリックします。

  3. エディターを開くと、バグ作業項目で使用可能なすべてのフィールドのリストが表示されます。リストにあるFoundInフィールドに気付くはずです。このフィールドにバージョン番号を入力することで、バージョンごとにバグを見つけることができるクエリを簡単に作成できるようになります。

  4. このフィールドを表示するには、 [レイアウト]タブを選択してフォームエディタを表示します。基本的には大きなツリービューです。[グループ]-[分類]（またはこのフィールドが最も適切と思われる場所）のグループを展開し、[列]を右クリックして、[新しいコントロール]を選択します。

  5. 属性パネルで、「フィールド名」として「検出済み」を選択し、ラベルも更新します。

  6. [フォームのプレビュー]を選択して変更をテストし、エディターを保存して閉じます

于 2012-08-10T14:37:54.333 に答える
0

どのようにアプローチするかによって、これを回避する方法はいくつかあります。1 つは、標準の Areas フィールドを使用しないことです (Mike C は適切な代替案を提案しています)。もう 1 つの方法は、現在行っている作業の状態をより正確に反映する作業項目を作成することです。私が意味するのはこれです：

ソフトウェアの 3 つの異なるバージョンにまたがる修正をリリースする場合、修正がすべてのコードベースで一貫していると仮定するために、3 つのバージョンすべてに対してテストする必要があると思います。V1.0 で機能した修正は、V3.0 では同じように機能しない可能性があります。これは、周囲の/影響を受けるコードが異なる可能性があるためです。

したがって、そのプロセスのある時点で、バグの 3 つの別個の (ただしリンクされた) 表現を持つことができます。たとえば、バグ自体の 3 つのコピー、または 3 つのテスト ケース (バグをテストする必要があるバージョンごとに 1 つ) すべてがオリジナルにリンクされています。バグ。次に、バグが V1.0 で修正されたが、V3.0 で修正するためにさらに作業が必要な場合、作業項目はこれを正確に反映します。

于 2012-08-10T14:44:27.277 に答える