現在、開発チームで使用するためにTFSMSF for CMMIでプロセステンプレートを評価していますが、個別のバグと変更要求の作業項目タイプの必要性を理解するのに苦労しています。
レポートを生成するときに、バグ（エラー）と変更要求（要件の変更）を区別できることが有益であることを理解しています。
ただし、現在のシステムでは、変更要求のタイプは1つだけであり、フィールドを使用して、それがバグ、要件の変更などであるかどうかを示します（このフィールドはレポートクエリの作成に使用できます）。
バグ用に個別のワークフローを用意することの利点は何ですか？
また、開発者がバグや変更要求に対して作業を送信できるという事実にも混乱しています。意図されたワークフローは、開発者が変更を行うときに参照する変更要求をバグが生成することであると思いました。
@ルーク
私はあなたの意見に同意しませんが、通常、この違いは、2 種類の問題を処理するために 2 つの異なるプロセスが利用できる理由を説明するものです。
ホームページの色がもともと赤に設計されていて、何らかの理由で青になっている場合、それは簡単に修正でき、多くの人や工数を必要とせずに変更できると思います. ファイルをチェックアウトして色を変更し、再度チェックインしてバグを更新するだけです。
ただし、ホームページの色が赤になるように設計されていて、赤であるにもかかわらず、誰かが青にする必要があると考えている場合、つまり、私にとっては別の種類の変更です。たとえば、画像やロゴが青い背景に重なるなど、ページの他の部分に与える影響について誰か考えたことはありますか? 見栄えの悪いものの境界線はありますか？リンクの下線が青になっていますが、表示されますか?
例として、私は赤/緑の色盲です。何かの色を変えることは、私にとって軽視することではありません。Web 上には、問題を引き起こす十分な Web ページがあります。すべてを考慮すると、最も些細な変更でさえ重要な変更になる可能性があることを強調しておきます。
実際の最終的な実装の変更はおそらくほとんど同じですが、私にとって変更要求は別物です。それはまさに、期待どおりに機能することを確認するために、さらに検討する必要があるからです。
ただし、バグは、誰かがこれが私たちがやろうとしている方法だと言ったのに、誰かが別の方法でやったということです.
変更要求はもっと似ていますが、この他のことも考慮する必要があります... うーん... .
もちろん例外もありますが、あなたの例を分解してみましょう。
サーバーが300,000,000,000 を超えるページビューを処理するように設計されている場合、はい、そうでないのはバグです。しかし、多くのページビューを処理するようにサーバーを設計することは、サーバーが300,000,000,000 ページビューを処理する必要があると言うだけではなく、処理時間の保証やディスクアクセスの平均時間まで、それを行う方法について非常に詳細な仕様を含める必要があります。コードが設計どおりに実装され、期待どおりに実行できない場合、問題は次のようになります。設計が間違っていたのか、それとも実装が間違っていたのか? .
この場合、それが設計上の欠陥と見なされるか、実装上の欠陥と見なされるかは、期待に応えられない実際の理由に依存することに同意します. たとえば、ディスクが実際の 100 倍の速さであると仮定し、これがサーバーが期待どおりに動作しない理由であると見なされた場合、これは設計上のバグであり、誰かが再設計する必要があると言えます。 . その多くのページビューの元の要件が引き続き保持される場合は、より多くのインメモリ データなどを使用した大規模な再設計が必要になる可能性があります。
ただし、誰かが RAID ディスクの動作方法とストライプ メディアを正しく活用する方法を考慮に入れていない場合、それはバグであり、修正するためにそれほど大きな変更を加える必要はないかもしれません。
繰り返しますが、もちろん例外はあります。
いずれにせよ、私が述べた元の違いは、ほとんどの場合に真実であることがわかったものです.
TFS の作業項目タイプ定義の一部は、作業項目が取り得る状態と状態間の遷移を意味する「ワークフロー」の定義であることに注意してください。これは、セキュリティ ロールによって保護できます。
したがって、一般的に言えば、「変更要求」は、組織の比較的高い地位にある人 (システムに (おそらく非常に大きな) 変更を行うためにリソースを費やすことに関連する「スポンサーシップ」権限を持つ人) によって開始され、承認されます。変更が正常に行われたことを承認する人になります。
ただし、「バグ」の場合、アプリケーションのすべてのユーザーがバグを開始できる必要があります。
私が TFS を実装した組織では、部門長だけが「変更要求」の発信者になることができますが、「バグ」は「ヘルプデスク」チケットから作成されました (自動化されておらず、プロセスによってのみ...)
一般に、CMM について話すことはできませんが、変更要求とバグは通常、アプリケーション ライフサイクルのさまざまな部分を参照するため、異なる方法で処理され、考慮されます。
バグは、プログラムの実装における欠陥です。たとえば、2 つの数値を加算してユーザーに合計を与えることができるようにプログラムを設計した場合、負の数値を正しく処理できないという欠陥、つまりバグが発生します。
変更要求は、設計上の欠陥がある場合です。たとえば、プログラムで負の数を処理してはならない、と具体的に述べた可能性があります。次に、その部分を再設計して再実装するために、変更要求が提出されます。設計上の欠陥は意図的なものではないかもしれませんが、最初にプログラムを設計したときにその部分を考慮していなかった、または元の設計が作成された時点では存在しなかった新しいケースが発明または発見されたことが原因である可能性があります。以来。
つまり、プログラムは設計どおりに動作する可能性がありますが、変更する必要があります。変更依頼です。
通常、バグを修正することは、変更要求を実行するよりもはるかに安価なアクションと見なされます。これは、バグがプログラムの一部になることを意図したものではないためです。しかし、デザインはそうでした。
したがって、2 つの異なるシナリオを処理するには、別のワークフローが必要になる場合があります。たとえば、バグを確認して報告する方法は、変更要求の場合とは異なる場合があり、変更の結果を説明するためにより多くの作業が必要になる場合があります。
バグとは、実装がすでに承認されている要件で壊れているものです。
変更要求は、その変更に対する影響と労力を見積もる必要があるサイクルを経る必要があります。次に、変更要求の作業を開始する前に、実装が承認される必要があります。
この2つは、CMMでは根本的に異なります。
変更要求はバグから生成されるべきであるという私の仮定は間違っていますか？すべてのバグの実装が自動的に承認されるとは限らないため、混乱しています。それらは些細なことであり、少なくともこの場合、開発者に割り当てられる前に変更要求と同じレビュープロセスを経ます。