そのバグを修正したほうがいいでしょうか？[閉まっている]
https://stackoverflow.com/questions/58006
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
リリースのバグを優先順位付けする場合、そのバグがリリースで修正されるかどうかを判断するために通常どのような基準が使用されますか?
解決
これに関する標準的な記事は次のとおりです コードエコノミストとしての私の人生, 、エリック・シンク著。
この記事は読む価値がありますが、チェックリストにまとめておきたい場合は、次のようにします。
- このバグが発生すると、どの程度の悪影響が出ますか?- 重大度
- このバグはどのくらいの頻度で発生しますか?- 頻度
- このバグを修正するにはどれくらいの労力が必要ですか?- 料金
- このバグを修正するとどのようなリスクがありますか?- 危険
他のヒント
- ユーザーへの影響の重大度
- 出現頻度
- 回避策はありますか?
- 修理にかかる費用
- 修正する時間
- リリース期限までの残り時間
- 修正を行えるリソースの利用可能性
重大度が低く、製品のリリースが近づいている場合は、次のリリースまで修正を保存しておいたほうがよい場合がよくあります。
寝ている犬は寝かせなさいの原則。
コードをロックダウンする必要がある時点が来ます。コードを修正するにはさらに回帰テストが必要であり、それには時間がかかります。
悲しいが本当。
「欠陥ゼロ」の考え方については、語るべきことがたくさんあります。あらゆる種類のバグ すべき 常にスタックの一番上に行かないと、最終的には圧倒されてしまいます。
もちろん、現実の世界では、大きな新しい顧客を獲得できるようにその輝かしい新機能を世に出すことの方が、ちょっとした煩わしさを解決することよりも重要かもしれません。実際、市場投入までの時間が品質を上回ることもあります。
通常は重要性、影響力、そしてお金です。
- 重要度:何が起こるのですか？データが破損したり、システムがダウンしたりすることはありますか。
- インパクト：何人が影響を受けるでしょうか？
- お金：私たちがそれを修正した場合（修正しなかった場合）、誰かが私たちにお金を払ってくれる（さらに悪いことに、支払いを保留してくれる）でしょうか？
重大度に影響するものについては、この投稿ではまだ見ていません。
- SLA - SLA に影響しますか?
- 内部（メンテナンス）と外部の利益 - ほとんどの場合、外部の利益の方が優先されます。
- 視覚的 vs 機能的 - 一般に機能的な方が優先されます。
- 誰が見つけたの？(顧客 vs 同僚) - 顧客の方が優先されます。
これは間違いなくドメイン固有の質問です。私はヘッジファンド、プロップトレーディングデスク、ミューチュアルファンドなどの大規模な取引アプリを書いています。それで：
- コンプライアンスに違反したり、その他の法的問題を引き起こしたりするものは非常に悪いです
- 過剰取引を引き起こす可能性のあるもの (DTE の 100,000 株を購入したかったのに、100,200 株を購入できた) は非常に悪いです
- クライアントが取引したいときにそれを妨げるものは非常に悪いです
- クライアントに迷惑をかけることは非常に悪い
先日、別の分野で働く「バグトリアージマネージャー」と話をしました。彼はそれを簡単に言いました：
まずクラッシュを修正し、次に損失の原因となっているものを修正し、次に見栄えを悪くしているものを修正し、それからその他すべてを修正します。
私の経験では、それは次のとおりです。
- バグの重大度
- リリース前の空き開発時間。
私は RDBMS サーバー ソフトウェアを作成しているため、データ破損を引き起こす可能性のあるバグは即座に重大な問題となります。また、クエリから誤ったデータを返す場合と同様、比較的通常の使用下でデータベース サーバーのクラッシュを引き起こす可能性のあるバグも対象となります。
また、修正がどの程度不安定になるか、また修正にどれくらいの時間がかかるかによっても異なります。
原則として、リリース サイクル以外でシステムをクラッシュさせるバグにはパッチを適用します。
その他のバグは製品バックログに追加され、新機能とともに優先順位が付けられます。リリースに何を含めるかを決定するとき、私たちはそれらのタスクを最も高い優先度で取り上げます。毎月のリリースサイクルがあるため、これはうまく機能します。
私たちは、このスレッドで他の人が言及したものとほぼ同じバグの優先順位付けシステムを使用していますが、クライアントがバグ (または機能) の優先順位を上げるために料金を支払うことができるという追加の例外があります。
入る価値はありますか 技術的負債 修正しなかったり、後で適切に修正するつもりで手っ取り早く汚い修正をしたりすることによってです。
すでに素晴らしい答えがたくさんありますが、もちろん状況はプロジェクト、会社、バグ、リリースまでの時間、依存関係などによって異なります。
ただし、次の 2 つの指標が有用なガイドラインであることがわかりました。
- 何人のユーザーが影響を受けますか?
- どれくらい深刻な影響を受けていますか?
両方の変数でバグのマークが高いほど、より早く修正する必要があります。
私は @Chris Upchurch に同意しますが、重要な要素はすべての当事者の合意を得ることだと思います クランチタイムに入る前に. 。そうすれば、歯ぎしりや胸の高鳴りを最小限に抑えてチェックリストを実行できます。
決定を下すという点では、重大度、影響、コストなどに基づいて、最も優れた回答はありません。
少し注意が必要なこと いつ ただし、これらのルールを適用します。私は、誰の責任でもないためにバグが制御不能になったまま放置されているプロジェクトにあまりにも多く取り組んできました。私が思いついた最良の就業規則は、
- バグを見つけたらバグレポートを提出してください
- 修正できる場合は修正してください。(バグの存在については報告が必要な場合があるため報告します)
- チームリーダーがバグを理解している場合は、優先順位を割り当てる必要があります (またはチームが使用する他の手段)。「これが実際に何を意味するか」情報を追加します。チームリーダーがバグリストを（ある程度）制御できることが重要です。
- 管理レベルで修正されていないバグや優先順位が付けられていないバグをレビューします。理解されていないバグは大きなリスクであり、理解されている権力者にはそのリスクを理解する機会が与えられるべきです。
- 常に、最も重要なバグが何であるかをプロジェクト全体で把握します (これは優先順位とは別にすることができます。上位 5 リスト）
- プログラマーに開発タスクと並行してバグを修正するよう奨励する
それから リリースを検討しているとき。
- コードを分岐させて、 機能の凍結
- 修正する予定のバグを特定します (注文する必要はありません :-))
- 凍結されたコードで再現可能なバグのみをこのリストに追加します。 そして 同意した
