バグや欠陥のないポリシーでアジャイルを保つ

このプロジェクトでは、ゼロバグ（別名ゼロディフェクト）方法論で作業します。基本的な考え方は、バグは常に機能よりも優先度が高いということです。ストーリーの作成中にバグがある場合は、ストーリーを承認するために解決する必要があります。古いストーリーのスプリント中にバグが見つかった場合は、バックログに次に配置して解決する必要があります-最優先事項。

私が解決と言っている理由は、バグを常に修正するとは限らないからです。それほど重要ではないので、「修正しない」と宣言することもあります。全体的に素晴らしいですね。私たちは高品質の製品を出荷しており、巨大なバグのバックログの形で「こぶ」を運んでいません。

しかし、このアプローチが正しいかどうかはわかりません。深刻なバグをできるだけ早く修正する必要があり、重要ではないバグを破棄する必要があることに同意する傾向があります。しかし、重要ではあるが新機能ほど重要ではないバグはどうでしょうか？それらは適切な優先順位でバックログにファイルされるべきだと思う傾向があります。

より明確にするために例を挙げます-私のプロジェクトでは、flexで書かれたUIを使用します。すべての画面解像度で同じサイズで開くウィザード画面があります。ウィザードウィンドウを拡張すると、ページの1つが見栄えがよくないことがわかりました（ウィザードはすべてを表示でき、スクロールバーを必要としないにもかかわらず、消えない垂直スクロールバーがあります）。このバグは見苦しいと思います。修正する必要があると確信しています。しかし、私たちは厳しいスケジュールにあり、多くの機能を備えているので、カットを加えてリリースすることはできないと考えています。私たちはそのようなバグに耐えることができると感じています。修正する必要はありますが、他の機能よりも優先度が低くなります（したがって、完了できない場合は、少なくとも重要な機能を除外しませんでした）。だが、

「修正できない」とマークしたくないが、最も重要ではないバグに対処する方法について意見を聞きたいと思います。

新しいコードを記述する前にバグを修正することは、実際にはJoelテストの 12ポイントのうちの1つです。ジョエルはまた、これが必須アイテムである理由を説明します。

一般に、バグを修正する前に長く待つほど、（時間と費用の面で）修正にコストがかかります。

次の選択肢があります。

• リクエストの多い機能を実装し、バグの修正を遅らせると、必然的に修正コストが増加しますが、

• または、顧客が非常に必要な機能の提供が非常に遅いことに失望することを考えると、すぐにバグを修正します。

バグがそれほど重要ではない場合、機能は重要ですが、管理者はまず機能を実装してからバグを修正するように依頼する傾向があります。経営陣が結果を明確に理解している限り、つまり、バグを今よりも後で修正することがより困難である限り、ビジネス面では、これは完全に有効な選択です。

「すべてのバグが修正されるまで新しい機能を使用しない」ことにこだわるのは、最善のビジネス選択ではないかもしれません。あなたはすでにその制限について言及しているので、それを説明する必要はありません。

そうは言っても、マイナーなバグを修正する前に非常に重要な機能を実装させるリスクにはリスクがあります。制限をどこに置くか？100人の顧客が遭遇するバグよりも、1 000人の顧客が要求する機能の方が重要ですか？特定のバグを修正する前に、特定の機能を実行する必要があるかどうかを評価する方法は？

厳格なルールがなく、経営陣が開発プロセスをあまりよく理解していない場合、数年後には、他の派手な機能の前に修正するのに十分重要ではないと考えられていたバグでいっぱいのバックログが表示されます。

状況の特定の低レベルの詳細に飛び込むことに加えて、基本的で基本的なものが正しいことを確認することをお勧めします。

この点で、私はあなたが言及したポリシー、「バグは常に機能よりも優先順位が高い」とは、特に単語があることを指摘することは非常に重要であると信じて、常にに記載された少なくとも2つから4つの原則から逸脱アジャイルマニフェスト：

プロセスとツールを介した個人と相互作用

計画に従うことによる変化への対応

私はので、私は、あなたがポリシーを変更する必要があることを主張していない固く信じている 1があるべきことをアジャイルアジャイルの原則の非常にアプリケーションに関する。

しかし、あなたは、少なくともする必要があります注意してくださいあなたが外れたときに、どのように偏差があるかどうかを理解して正当化。簡単に言えば、あなたはより良いそう雄弁にカバーされ、あなたが「アジャイル」と呼んでいるもの、実際には無意味な偽物にスライドしないことを確認するハーフArsedアジャイルマニフェスト：

プロセスとツールに対する個人と相互作用。
これらの個人（「リソース」という用語を好む）の相互作用を制御するための必須のプロセスとツールがあります。

ソフトウェアが包括的に文書化されている限り、包括的な文書
よりも機能するソフトウェア

もちろん、厳格な契約の境界内で、厳密な変更管理の対象となる契約交渉に関する顧客コラボレーション

変更に対応するための詳細な計画が用意されていて、正確に遵守されている場合、計画に従うことで変更
に対応する

複雑さのために、ゼロバグポリシーが逸脱しているように見えるのはアジャイルな原則だけではありません。

私が参加したアジャイル以外のプロジェクトでは、一般に、優先度の高い機能のリリースの遅延を正当化するほど重要ではないバグの修正にプログラマーを費やすのは賢明ではないと考えられてきました。

そのため、管理者は通常、次のリリースまでにどのバグを待つことができるかを決定するためにいくらかの努力を費やしました（投資したと言う方が正確かもしれません）。

• ^{ミッションクリティカルなソフトウェアに偶然取り組んでいますか？この場合、ゼロバグポリシーは非常に理にかなっており、アジャイル/非アジャイル/あらゆる原則を妥協する価値があるためです。この場合、アジャイルプロセスを想像するのは難しいですが。}

ミッションクリティカルなソフトウェアに取り組んでいない限り、経営陣のスキルと思考能力をより詳細に評価することをお勧めします。

つまり、あなたが説明したことから、バグや機能を適切に優先順位付けするのは単純に不可能だと思われます。この場合、そのような比較的日常的なタスクを処理できない場合、他に何ができませんか？競争力のある給与を提供しますか？キャリア成長の機会？労働条件？

当然のことながら、ゼロバグポリシーには、重大ではない問題を無視したり、敷物の下に押し込んだりするリスクがあります。

あなたができることは、新しい問題が報告されたときに、3つの決定を下すことです：

1. これは本物のバグであり、できるだけ早く修正する必要があります。バックログの先頭に置きます
2. これは真のバグですが、アプリケーションの機能にとって重要ではありません。通常のストーリーに変えて、製品の所有者に優先順位を付けてください。
3. それはバグではなく、重複していないか、解決する努力の価値はありません。適切な理由で拒否してください。

このように、それほど重要でない問題は完全に忘れられることはありませんが、次のスプリントからすべての新しい光沢のある機能を強制するわけでもありません。「ストーリーに変える」というのは、管理者がバグゼロのポリシーに従っていると主張し続け、製品所有者が問題の重要性とバックログの機能の重要性のバランスを取ることができるようにするためです。

この手順では、あなたが言及したスクロールバーのような問題がプロジェクトの最後でまだ解決されていない可能性がありますが、それは誰もそれが十分に重要ではないと思ったためです（顧客を含む）問題が見つかった時間。

私はあなたのスキームが好きですが、あなたが特定したように、それを機能させるにはわずかな微調整が必​​要です-あなたが観察したように、現実は多くの場合、新しい機能はバグ修正に勝ります.....

私の提案は、各スプリントのバグの優先度を上げることです。レベル5（スケール1-高、5 =低）にバグがあるとしましょう。それは、5、4スプリントの後で始まり、レベル1のバグです。ただし、優先度の計算に必要なマインドセットは、「各スプリントの終了時に未解決のバグの優先度を上げる」ではなく、「現在の優先度-スプリントの数」です。

レベル1のバグは、次のスプリントで対処する必要があります......

説明が簡単で、実装が簡単です。

さて、それが機能リクエストまでの範囲、おそらく異なるレート。しばらくすると、リクエストを処理する必要があります-完了または破棄され、価値のない機能のバックログを防ぎます......

ソフトウェア開発のすべてのことについて、文字通りまたは頑固にしようとすると、私たち全員が本当に物事を切り詰めて乾燥させたいと思うので、あなたはトラブルに巻き込まれます。バグは新しい機能を追加する前に修正する必要がありますが、問題の範囲とともにこの決定を行う際には、それぞれの重要性を検討します。すべてに例外があります。

一部のアプリケーションは非常に大きいため、まったく関連しないセクションがあります。従業員の福利厚生GUIにいくつかの迷惑なバグがあるため、買掛金モジュールのすべての新機能を保留にする必要がある理由はわかりません。ウィザードステップのGUIの煩わしさが会社のWebサイトの購入セクションにあった場合は修正しますが、追加された機能が追加のセキュリティ、ビジネスニーズ、および特に規制の変更の結果である場合、多くのバグを未修正にする必要があります。

どちらか一方を完了するための時間とリソースの大きな相違以外に、ユーザー/顧客の入力を取得するのが最善です。新しい機能を取得することを意味する場合、彼らがバグに耐えることができる場合は、機能を追加します。目標は、バグが山積みにならないようにすることです。ある時点で、多くの小さな問題が大きな問題になります。

テストの実行時にバグを表示するテストを作成することは、バグを修正するための良い出発点です。しかし、最優先事項のバグを修正しようとするときは、先に進む前によく考えてください。修正をスキップするつもりはありませんでした。ただし、重要ではないリソースを使用してこれらのバグを修正できます。私のチームでは、バグリストで最も優先順位の低いバグで新しいリソースをトレーニングするとします。この方法により、新しいリソースをトレーニングする機会が得られるだけでなく、アプリケーションへのエントリが修正されたことを確信することができます。これにより、確実に次の優先度の高いタスクにボランティアが参加します。

お役に立てれば ：）