バグゼロ/欠陥ポリシーで俊敏性を維持する
私たちのプロジェクトでは、バグゼロ（欠陥ゼロ）方法論で作業します。基本的な考え方は、バグは常に機能よりも優先度が高いということです。ストーリーに取り組んでいて、バグがある場合は、ストーリーが受け入れられるように解決する必要があります。古いストーリーのスプリント中にバグが見つかった場合は、次にそれをバックログに入れて解決する必要があります-最優先事項。
私が解決と言っているのは、常にバグを修正するわけではないからです。それほど重要ではないため、「修正しない」と宣言することがあります。オールインオールそれは素晴らしいですね。私たちは高品質の製品を出荷しており、巨大なバグのバックログという形で「こぶ」を運びません。
しかし、私はこのアプローチが正しいかどうかわかりません。私は常に重大なバグをできるだけ早く修正する必要があり、興味のないバグを破棄する必要があることに同意する傾向があります。しかし、重要ではあるが新機能ほど重要ではないバグはどうですか？私はそれらを適切な優先順位でバックログに提出する必要があると思う傾向があります。
わかりやすくするために例を示します。私のプロジェクトでは、フレックスで記述されたUIを使用しています。すべての画面解像度で同じサイズで開くウィザード画面があります。ウィザードウィンドウを拡張すると、ページの1つが見栄えがよくないことがわかります（ウィザードはすべてを表示でき、スクロールバーを必要としないのに、消えない垂直スクロールバーがあります）。このバグは醜いと思います。きっと直さないといけない。しかし、私たちは厳しいスケジュールをたどっていて、カットをしてリリースに入ることができないと恐れている多くの機能があります。私たちはそのようなバグに耐えられると思います。修正する必要はありますが、他の機能よりも優先度が低くなっています（そのため、完了できない場合に備えて、少なくとも重要な機能を省略していません）。しかし、私たちはバグ0のポリシーで作業しており、今すぐ修正する必要があります（1日以上かけて解決に費やしたため、少なくとももう1つ必要になります）。
「修正しない」とマークしたくないが、最も重要ではないバグを管理する方法についての意見を聞きたいです。
新しいコードを書く前にバグを修正することは、実際には Joel test の12のポイントの1つです。ジョエルはまた、これが必需品である理由を説明しています：
一般に、バグを修正するまでの待機時間が長いほど、修正にコストがかかります（時間とコストの面で）。
あなたには選択肢があります：
リクエストの多い機能を実装してバグの修正を遅らせると、修正コストが必然的に増加します。
または、必要な機能を提供するのが遅いと顧客が失望するので、今すぐバグを修正します。
バグがそれほど重要ではない場合、機能は重要ですが、管理者は最初に機能を実装してからバグを修正するように依頼する傾向があります。ビジネス的には、経営陣が結果を明確に理解している限り、これは完全に有効な選択です。つまり、今よりも後でバグを修正することは困難です。
「すべてのバグが修正されるまで新機能はありません」を続けることは、ビジネスにとって最良の選択ではない場合があります。あなたはすでにその制限について述べましたので、それを説明する必要はありません。
そうは言っても、マイナーなバグを修正する前に非常に重要な機能を実装させるリスクにはリスクがあります。どこに制限を設けるか？ 100の顧客が遭遇したバグよりも、1000の顧客が要求した機能のほうが重要ですか？特定のバグを修正する前に、特定の機能を実行する必要があるかどうかを評価するにはどうすればよいですか？
厳格なルールがなく、経営陣が開発プロセスを十分に理解していない場合、数年後には、バックログがバグでいっぱいになり、別の手の込んだ機能の前に修正するためには十分に重要ではないと考えられていました。
状況の特定の低レベルの詳細に飛び込むだけでなく、基本的で基本的なものを正しく理解していることを確認してください。
この点で、「バグは常に機能よりも優先度が高い」というポリシー、特にWordalwaysAgile Manifesto で述べられている4つの原則のうち少なくとも2つから逸脱している：
プロセスとツール上の個人と相互作用
計画に従った変更への対応
私はあなたがポリシーを変更するべきだとは主張していません。なぜなら、私はアジャイル原則の非常に適用についてアジャイルである必要があると私は 確かに信じている だからです。
しかし、逸脱するときは、少なくとも気づく必要があり、逸脱が正当化されるかどうかとその方法を理解する必要があります。簡単に言うと、 "アジャイル"と呼ばれるものが実際には無意味な偽物に滑り込まないようにするために、雄弁に 半腕アジャイルマニフェスト ：
プロセスとツール上の個人と相互作用
そしてこれらの個人（「リソース」という用語を好む）の相互作用を制御するための必須のプロセスとツールがあります包括的なドキュメントを処理するソフトウェア
そのソフトウェアが包括的に文書化されている限り顧客とのコラボレーション契約交渉
もちろん、厳密な契約の境界内で、厳密な変更管理の対象となります計画に従った変更への対応
ただし、変更に対応するための詳細な計画があり、正確に実行されている
複雑さのために、バグゼロのポリシーが逸脱しているように見えるのは、アジャイルの原則だけではありません。
私が参加した非アジャイルプロジェクトでは、優先度の高い機能のリリースの遅延を正当化するのに十分重要ではないバグの修正にプログラマーの時間を費やすことは、一般にエラーと見なされています...賢明ではありません 。
そのため、管理者は通常、どのバグが次のリリースまで待つことができるかを決定するためにいくらかの労力を費やしました（おそらく投資したと言う方がより正確です）。
- あなたはたまたまミッションクリティカルなソフトウェアに取り組んでいますか？この場合、ゼロバグポリシーはかなり意味があり、アジャイル/非アジャイル/あらゆる原則を妥協する価値があるので、私は尋ねます。この場合、アジャイルプロセスを想像するのに苦労しますが。
ミッションクリティカルなソフトウェアに取り組んでいない限り、経営陣のスキルと思考能力をより詳しく評価することをお勧めします。
つまり、あなたが説明したことから、バグと機能を適切に優先順位付けすることができないだけのように見えます。これが事実であり、そのような比較的日常的なタスクを処理できない場合、他に何ができないのでしょうか？競争力のある給与を提供していますか？キャリア成長の機会？労働条件？
当然のことながら、バグゼロのポリシーには、重大ではない問題が無視されたり、敷物の下に押し込まれたりするリスクがあります。これは、問題を解決するのに最適な時期ではないためです。
あなたができることは、新しい問題が報告されたときに、3方向の決定を下すことです。
- それは本物のバグであり、できるだけ早く修正する必要があります：バックログの上に置く
- これは本物のバグですが、アプリケーションの機能にとって重要ではありません。通常のストーリーに変えて、製品の所有者に優先順位を付けてください。
- それはバグではないか、それとも重複しているか、解決する価値はありません。適切な理由で拒否してください。
このようにして、重要性の低い問題が完全に忘れられることはありませんが、次のスプリントからすべての新しい光沢のある機能が強制されるわけではありません。 「ストーリーに変える」というのは、管理者がバグゼロのポリシーに従っていると主張し続けることができるようにするためであり、製品の所有者は問題の重要性とバックログの機能の重要性のバランスを取ることができるはずです。
この手順では、あなたが言及したスクロールバーのような問題がプロジェクトの最後に解決されない可能性がありますが、それはそれが十分に重要であると誰も考えなかったためです（顧客を含む）。問題が見つかった時刻。
私はあなたが計画するのが好きです、しかし、あなたが確認したように、それを機能させるためにほんの少しの微調整が必要です-あなたが観察したように、現実はしばしば新しい機能がバグ修正を切り捨てることです...
私の提案は、バグの優先度を強制して各スプリントを上げることです。レベル5のバグがあるとしましょう（スケール1-高、5 =低）。それは5、4スプリント後に始まり、レベル1のバグです。ただし、優先度の計算に必要なマインドセットは、「各スプリントの最後で未解決のバグの優先度を上げる」ではなく、「現在の優先度-スプリントの数」です。これにより、優先度が「リセット」されてさらに延期されなくなります。
レベル1のバグは次のスプリントで対処する必要があります......
説明しやすく、実装も簡単です...
さて、機能リクエストまでの範囲、おそらく異なるレート。しばらくすると、リクエストは処理される必要があります-完了または破棄され、値のない機能のバックログを防ぎます......
ソフトウェア開発のあらゆることについて、あまりにも文字どおりに、または厳格にしようとすると、問題が解決します。新しい機能を追加する前にバグを修正する必要がありますが、問題の範囲とともにこの決定を行うときは、それぞれの重要性を考慮します。すべてに例外があります。
一部のアプリケーションは非常に大きく、まったく関連のないセクションがあります。従業員給付GUIにはいくつかの迷惑なバグがあるため、買掛金モジュールのすべての新機能を保留にする必要がある理由はわかりません。ウィザードステップのGUIの煩わしさが会社のWebサイトの購入セクションにある場合は修正してください。ただし、追加された機能が追加のセキュリティ、ビジネスニーズ、特に規制の変更の結果である場合、多くのバグを未修正にする必要があります。
どちらか一方を完了するための時間とリソースの大きな不一致以外に、ユーザー/顧客の入力を取得するのが最善です。新しい機能を入手することを意味する場合、バグに対処できる場合は、機能を追加します。目標は、バグが積み重ならないようにすることであるため、ストップギャップを設ける必要があります。ある時点で、多くの小さな問題が大きな問題になります。