スクラム開発モデルを正しく理解していないかもしれませんが、バックログアイテムが親として設定されている場合でも、TFSがバックログアイテムとは異なる行にバグを配置する理由がわかりません。
バグレポートを作成しようと思い、TODO欄に掲載しました。次に、そのバグにコードをコミットするときに、コミットをバグの特定のタスクIDに関連付けます。その後、完了したらDONEに移動します。それはスクラムの仕組みではありませんか?報告されたバグを修正するための一般的なプロセスは何ですか?
スクラム開発モデルを正しく理解していないかもしれませんが、バックログアイテムが親として設定されている場合でも、TFSがバックログアイテムとは異なる行にバグを配置する理由がわかりません。
バグレポートを作成しようと思い、TODO欄に掲載しました。次に、そのバグにコードをコミットするときに、コミットをバグの特定のタスクIDに関連付けます。その後、完了したらDONEに移動します。それはスクラムの仕組みではありませんか?報告されたバグを修正するための一般的なプロセスは何ですか?
それがタスクボードの見方です。最新のスクラムプロセステンプレート(Microsoft Visual Studio Scrum 2.x)では、バグは要件カテゴリにあります。そうすることで、バグは製品バックログアイテムのように扱われます(ランク付けしてスタックし、実行可能なタスクに分割し、他のPBIと同じようにプロセスにフィードすることができます)。TFS 2012 Update 1またはTFServiceを使用している場合は、製品のバックログページにかんばんボードタブがあります。このタブで、バグを状態(新規/承認済み/コミット済み/完了)に移動します。タスクボード(上のスクリーンショット)では、バグと製品バックログアイテムが行として表示され(ここにタスクとここにバグがあります)、タスクは[実行中]、[進行中]、および[完了]列に存在します。
バグに対処するときは、特にタスクに対処し、コードをチェックインするときにそれらのタスクを関連付け/解決します。「完了の定義」が満たされたら、バグ作業項目を(かんばんボード上で、または状態フィールドを介して手動で)完了に移動できます。
2008年からUrbanTurtleでTFS用のアジャイルツールを開発しています。2012バージョンでは、まさにあなたが探していることを実行しました。緑の線はユーザーストーリー(PBI)を表し、赤いボックスはバグを表します。
必要に応じて、オンラインで当社の製品を試すことができます。
これは、リクエストした機能の印刷画面です。さらに詳しい情報が必要な場合は、私に連絡してください。ddanis@urbanturtle.com