タグ付けされた質問 「backlog」

6
バグや欠陥のないポリシーでアジャイルを保つ
このプロジェクトでは、ゼロバグ(別名ゼロディフェクト)方法論で作業します。基本的な考え方は、バグは常に機能よりも優先度が高いということです。ストーリーの作成中にバグがある場合は、ストーリーを承認するために解決する必要があります。古いストーリーのスプリント中にバグが見つかった場合は、バックログに次に配置して解決する必要があります-最優先事項。 私が解決と言っている理由は、バグを常に修正するとは限らないからです。それほど重要ではないので、「修正しない」と宣言することもあります。全体的に素晴らしいですね。私たちは高品質の製品を出荷しており、巨大なバグのバックログの形で「こぶ」を運んでいません。 しかし、このアプローチが正しいかどうかはわかりません。深刻なバグをできるだけ早く修正する必要があり、重要ではないバグを破棄する必要があることに同意する傾向があります。しかし、重要ではあるが新機能ほど重要ではないバグはどうでしょうか?それらは適切な優先順位でバックログにファイルされるべきだと思う傾向があります。 より明確にするために例を挙げます-私のプロジェクトでは、flexで書かれたUIを使用します。すべての画面解像度で同じサイズで開くウィザード画面があります。ウィザードウィンドウを拡張すると、ページの1つが見栄えがよくないことがわかりました(ウィザードはすべてを表示でき、スクロールバーを必要としないにもかかわらず、消えない垂直スクロールバーがあります)。このバグは見苦しいと思います。修正する必要があると確信しています。しかし、私たちは厳しいスケジュールにあり、多くの機能を備えているので、カットを加えてリリースすることはできないと考えています。私たちはそのようなバグに耐えることができると感じています。修正する必要はありますが、他の機能よりも優先度が低くなります(したがって、完了できない場合は、少なくとも重要な機能を除外しませんでした)。だが、 「修正できない」とマークしたくないが、最も重要ではないバグに対処する方法について意見を聞きたいと思います。
18 agile  scrum  bug  backlog 

5
課題追跡のバックログを管理する方法
私たちはここ数年Tracを忠実に使用しており、「アクティブチケット」リストは約200アイテムに増えました。これらには、優先度が低すぎて複雑すぎて現時点では修正できないバグ、延期された機能リクエスト、実際に苦情が発生したことはないが誰もがいつか修正すべきであることに同意している問題、計画されたコードリファクタリング、およびその他の設計上の問題失くしたいなど その結果、これらの問題の約200と、リストはほとんど圧倒的です。現時点で取り組む必要のあるもののソースとしてはもはや有用ではありません。 この種の問題を追跡する最良の方法は何ですか? 問題の一部は、これらの問題のいくつかは優先度が非常に低いため、実行できない可能性があることです。私はこれらのアイテムを見失うのが嫌いです(いつか必要になる場合に備えて、家から何かを捨てたくないのと同じです)。(Wontfixとしてマークすることにより)関係なくそれらを破棄する必要があり、将来必要になった場合にそれらを見つけることができると想定しますか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.