バグの中には、リリースされたコードで顧客などによって発見されるものもあれば、たとえばスプリントでの開発中に内部で発見されるものもあります。
そのため、リリースのバックログ コンテンツを見ると、どのバグ修正を顧客に通知する必要があり、どれが単なる内部情報なのかわかりません。
これに関するベストプラクティスはありますか? 命名規則を使用していますか、それとも私たちのニーズに合うようにテンプレートを変更できますか?
質問する
1015 次
1 に答える
1
これが私がリリースのバグに対処する方法です。
バグは単なる PBI であり、製品のバックログに追加されます。次に、PO はバグをトリアージし、他の作業と一緒に注文します。これは、重大なバグもあれば、次のリリースに必要なバグもあれば、価値が低く表面的なバグもあるからです。
コーディングの点から、私は次のリリース、製品、およびサービス パックに分岐戦略を使用します。
[システム] タブで、欠陥の [ビルドで見つかった] を使用して、それがどのビルド (開発、リリース、SP など) であったかを識別します。
次に、他の PBI と同様に、反復フィールドを使用してスプリントで修正されるようにスケジュールします。
課題は、多くのチームがビルド番号とビルドで戦っているということです。この場合、作業するブランチを示す追加フィールドをバグに追加することをお勧めします。偏執的である場合は、その検証に関するカスタム ルールを作成します。要件にリンクされたチェックインは、(フィールドを使用して) 正しいブランチにあります。
于 2013-07-14T01:45:10.270 に答える