1

わかっていること: Tfs を使用すると、バグを管理できます。バグを追加して、さまざまな状態に移動できます。

必要なもの: バグにさまざまな状態が必要です。これは、特に TFS 2015 では許可されていません。

  • " Not a Bug " (これは NEW > ACTIVE の後であり、開発者が言う場合、それはバグではありません)
  • 「RE- OPENED」 (バグが NEW > ACTIVE > RESOLVED > CLOSED の順に移動し、別のリリース / スプリントで Re-Opened になった場合)。

以下で言及されているどのアプローチを使用できますか?

A- 現在、TFS 2015 を使用しています。WITAdmin アプローチ ( https://www.visualstudio.com/en-us/docs/work/customize/add-modify-field ) を介してカスタマイズを行い、データベース、レポートに影響を与えます。今後は、移行に向けて別の取り組みが必要になります。

B- TFS 2015 を TFS 2017 に移行し、( https://www.visualstudio.com/en-us/docs/work/process/customize-processに従って、すぐに使用できる新しい状態を追加する新機能を取得します。 -field#add-a-custom-field )

C- バグをログに記録する慣行を変更する必要があり、TFS を使用して適切なアジャイル実装を検討する必要があります。なぜなら、AGILE プロセスには上記の必要なもののこのシナリオがあるからです。

A、B、Cは私が考えたアプローチです。専門家が経験、考え、および/または新しいアプローチを共有していただければ幸いです。

4

2 に答える 2

1

追加する「状態」は状態ではなく、せいぜい「理由」である必要があります。箱から出してすぐに使用したいものに近いデフォルトの理由セットが見つかります。

アジャイル プランニング ツールが機能するためには、構成に応じてユーザー ストーリーまたはタスクと同じ状態のバグが必要になるため、状態を追加すると、さらに大きな影響が生じます。試して避けてください。

A を使用して特定の移行の追加の理由を追加し、長期的には C に焦点を当てます。

于 2016-12-22T12:07:24.827 に答える
0

アプローチ B は Visual Studio Team Service にのみ存在し、TFS 2017 には現在この機能がありません。

アプローチ A は適切なオプションです。ただし、ウィザードを実行するためにカスタム プロセスを変更する必要がある場合や、TFS のアップグレード後にチーム プロジェクトを手動で更新する必要がある場合があります。

以下の Web サイトで、メンテナンスとアップグレードの影響 (TFS) の詳細を確認してください。カスタマイズ中に避けるべきことを教えてくれます。

https://www.visualstudio.com/en-us/docs/work/customize/customize-work#maintenance-and-upgrade-implications-tfs

于 2016-12-21T04:24:58.217 に答える