MSF for CMMI におけるバグと変更リクエストの違いは何ですか?

Question

現在評価中です MSF for CMMI プロセステンプレートの下 TFS 私の開発チームで使用するためのものですが、バグと変更リクエストの作業項目タイプを個別に分ける必要性を理解するのに苦労しています。

レポートを生成するときに、バグ (エラー) と変更リクエスト (要件の変更) を区別できることが有益であることを理解しています。

ただし、現在のシステムでは、変更リクエストのタイプは 1 つだけであり、それがバグであるか、要件の変更であるかなどを示すためにフィールドを使用するだけです (このフィールドはレポート クエリの構築に使用できます)。

バグ用に別のワークフローを持つことの利点は何ですか?

開発者がバグに対して作業を提出できるという事実にも困惑しています または 変更リクエストですが、意図されたワークフローは、開発者が変更を加えるときに参照する変更リクエストをバグが生成することだと思いました。

Answer 1

@ルーク

私もあなたの意見に同意しませんが、通常、この違いは、2 つのタイプの問題を処理するために 2 つの異なるプロセスが利用できる理由の説明となります。

ホームページの色が元々赤になるように設計されていたのに、何らかの理由で青になった場合、それは簡単にすぐに修正でき、変更に多くの人や工数を費やす必要はないと思います。ファイルをチェックアウトし、色を変更し、再度チェックインしてバグを更新するだけです。

ただし、ホームページの色が赤になるように設計されており、赤であるが、誰かが青にする必要があると考える場合、つまり、とにかく私にとっては、別の種類の変更です。たとえば、青色の背景に重なる画像やロゴなど、ページの他の部分にこれが及ぼす影響について誰かが考えたことがありますか?見た目が悪いものには境界線があるのでしょうか？リンクの下線が青になっていますが、表示されますか?

例として、私は赤/緑の色盲であり、何かの色を変えることは私にとって軽視することではありません。ウェブ上には問題を引き起こすウェブページがたくさんあります。あらゆることを考慮すると、最も些細な変更であっても、重要ではない可能性があることを強調しておきます。

実際の最終実装の変更はおそらくほとんど同じですが、私にとっては変更リクエストです は 期待どおりに動作するかどうかをさらに検討する必要があるためです。

ただし、バグは誰かが言ったということです これが私たちのやり方です そして誰かが別のやり方をした。

変更リクエストは次のようなものです しかし、これ以外のことも考慮する必要があります...ふーむ....

もちろん例外はありますが、例をあげてみましょう。

サーバーが 設計 300,000,000,000 を超えるページビューを処理するには、そうです、それができないのはバグです。しかし、これだけ多くのページビューを処理できるようにサーバーを設計するということは、単に言うだけではありません。 私たちのサーバーは 300,000,000,000 ページビューを処理できるはずです, が含まれている必要があります。 とても 処理時間の保証やディスク アクセスの平均時間に至るまで、それを実現する方法に関する詳細な仕様が記載されています。コードが設計どおりに実装されても、期待どおりに動作しない場合、次のような疑問が生じます。 設計が間違っていたのか、それとも実装が間違っていたのか?.

この場合、設計上の欠陥とみなされるのか実装上の欠陥とみなされるのかは、期待に応えられない実際の理由によって決まることに私は同意します。たとえば、誰かがディスクが実際の 100 倍の速度であると仮定し、それがサーバーが期待どおりに動作しない理由であるとみなされた場合、これは設計上のバグであり、誰かが再設計する必要があると思います。 。それほど多くのページビューという元の要件がまだ維持されている場合は、メモリ内データなどを増やして大規模な再設計を行う必要がある可能性があります。

ただし、誰かが RAID ディスクの動作方法とストライプ メディアの利点を正しく活用する方法を考慮に入れていないだけであれば、それはバグであり、修正するためにそれほど大きな変更は必要ない可能性があります。

繰り返しますが、もちろん例外もあります。

いずれにせよ、私が述べた最初の違いは、ほとんどの場合に真実であると私が発見したものです。

Answer 2

TFS の作業項目タイプ定義の一部は、作業項目が取り得る状態と状態間の遷移を意味する「ワークフロー」の定義であることに注意してください。これはセキュリティ ロールによって保護できます。

したがって、一般的に言えば、「変更リクエスト」は、組織内の比較的上位の人物 (システムに (おそらく非常に大規模な) 変更を加えるためのリソースの支出に関連する「スポンサー」権限を持つ人物) によって開始され、承認されます。最終的には、この人が変更が成功したことを承認することになります。

ただし、「バグ」の場合は、アプリケーションのどのユーザーもバグを開始できる必要があります。

私が TFS を導入した組織では、部門長のみが「変更リクエスト」の発信者になれますが、「バグ」は「ヘルプ デスク」チケットから作成されました (自動化されておらず、単にプロセスを通じて...)

Answer 3

一般に、私は CMM について話すことはできませんが、変更リクエストとバグは通常、アプリケーションのライフサイクルの異なる部分を参照するため、異なる方法で処理され、考慮されます。

バグとは、プログラムの実装における欠陥です。たとえば、2 つの数値を加算してその合計をユーザーに提供できるようにプログラムを設計した場合、負の数値が正しく処理されないという欠陥、つまりバグが発生します。

変更リクエストは、設計に欠陥がある場合に発生します。たとえば、プログラムでは負の数を処理すべきではないと具体的に言ったかもしれません。その後、その部分を再設計して再実装するために、変更リクエストが提出されます。設計上の欠陥は意図的なものではない可能性がありますが、最初にプログラムを設計したときにその部分を考慮しなかったか、元の設計が作成された時点では存在しなかった新しいケースが発明または発見されたことが原因である可能性は簡単にあります。以来。

言い換えれば、プログラムは設計どおりに動作する可能性がありますが、変更する必要があります。これは変更リクエストです。

---

通常、バグはプログラムの一部として意図されたものではないため、バグを修正することは、変更リクエストを実行するよりもはるかに低コストのアクションであると考えられています。しかし、デザインはそうでした。

したがって、2 つの異なるシナリオを処理するには、別のワークフローが必要になる場合があります。たとえば、バグを確認して報告する方法は、変更リクエストの場合とは異なる方法があり、変更の結果を明らかにするためにより多くの作業が必要になる場合があります。

Answer 4

バグとは、実装がすでに承認されている要件に違反しているものです。

変更リクエストは、その変更に対する影響と労力を見積もる必要があるサイクルを経る必要があり、その後、作業を​​開始する前に実装が承認される必要があります。

CMM では、この 2 つは根本的に異なります。

Answer 5

変更リクエストはバグから生成されるべきだという私の仮定は間違っていますか?すべてのバグが実装のために自動的に承認されるべきではないと思うので、私は混乱しています。それらは些細なものである可能性があり、少なくとも私たちの場合、開発者に割り当てられる前に変更リクエストと同じレビュープロセスを通過します。