変更のリスク別にタスク/バグを分類する

私が現在取り組んでいるプロジェクトには問題があります。バグやタスクは、あまりにも新しい人や経験の浅い人に割り当てられることが多く、彼らの仕事は将来的にさらにバグを生み出すことになります。問題は、コードの品質の問題のために、ソフトウェアの一部が他の部分よりも「危険」であるということです。私は、タスクに関連するリスクを推定し、どの開発者にどのタスクが割り当てられるかに細心の注意を払うことで、この問題に対処しようとしています。

JIRAを使用しているため、この推定を追跡するために問題のラベル付けを開始しました。バグ/タスクを分類するためにいくつかのメトリックを使用することになったことに気付きました：

• それがどれほど明確/単純か。たとえば、多くの設計作業が必要なのか、単純なUIのバグ修正が必要なのかなどです。
• コードの影響を受ける領域の保守性。うまく設計されたエリアなのか、泥だらけの大きなボールなのか。
• 必要な変更の影響を受けると思うプログラムの量。

考えられるカテゴリが何であるかを始めたとき、私は明確な考えを持っていなかったので、私のラベルは少し厄介です。仕事を誰かに割り当てる前に見積もりを要求できるように、新しいフィールド（「リスク」のようなもの）の追加を要求することを考えています。

誰もこのようなことを以前に扱ったことがありますか？

ほとんどのバグトラッキングアプローチの欠点の1つは、方程式の片側のみを処理することです-エンドユーザーのシステムのビュー。これは、1週間待機する可能性がある（優先度が高い）これを修正する重大なバグです。このバグは、これがs複数形のグリッチ（重大度）であるために苦痛です。

多次元バグ追跡について説明しているブログ投稿では、開発者のビュー（PEFおよびREV）を含むこの問題に対処しています。

PEF値はユーザーのビューです。

• P ‍ain-バグに遭遇したときの苦痛はどれくらいですか？
• E ‍ffort-回避するのにどれだけの労力がかかりますか？
• F頻度-バグはどのくらいの頻度で発生しますか？

REV側は開発者の視点からのものです。

• R ‍isk-修正のリスクはどれくらいですか？
• E ‍ffort-修正にどれだけの労力がかかりますか？
• V検証可能性-バグが修正されたことを確認するのはどれくらい簡単ですか？

これらはそれぞれ1..9スケールで測定され、1は低/簡単、9は高/ハードです。数値は一緒に加算されて、PEFとREVのスコアが与えられます。

説明されているビットに対応する部分：

• それがどれほど明確/単純か。たとえば、多くの設計作業が必要なのか、単純なUIのバグ修正が必要なのかなどです。
• コードの影響を受ける領域の保守性。うまく設計されたエリアなのか、泥だらけの大きなボールなのか。
• 必要な変更の影響を受けると思うプログラムの量。

これらは、REVで説明されている労力とリスクの要因です。

はい、それは前に戦ってきたものです。私は（過去に）Redmineのカスタムフィールドにこのモデルを使用しましたが、かなり成功しました。

これの大きな利点は、PEFスコアとREVスコアを比較するときに現れます。21のPEFと7のREVを持っている場合、それは大きな勝利になる可能性があります。7のPEFと21のREVは、リスクと労力の側面がそれを修正する利益を上回る可能性が高いため、しばらくは避けるべきものです。

次に、REVスコアを見て、リスクの少ないものを経験の浅い開発者に割り当てることができます（この状況では、多くの場合、低リスク、高労力が理想的です）。

あなたがここで言及していることは、「複雑さ」と呼ぶ方が良いと言えます。もちろん、変更が複雑になるほど「リスク」は高くなり、経験の浅いプログラマーによって新しいバグが導入される可能性があります。それが実際の問題である場合、そのようなフィールドを導入することは悪い考えではありません。

ただし、書いたことから判断すると、2つの問題があるようです。

1. あなたは新しいプログラマーまたは経験の浅いプログラマーを扱っています。
2. あなたのコードの（大/中）の品質には疑問があるようです。

「複雑さ」フィールド（作業の管理と優先順位付けに役立つ）のようなものを導入することに加えて、上記の2つの問題のリスクを軽減することに集中することをお勧めします。

最初の問題に対処するために、新しいプログラマーがバグに取り組む前に経験豊富なプログラマーとすべての新しいバグについて最初に議論するプロセスを作成します。また、新しいバグが導入されるリスクを低減し、新しいプログラマーがより速くスピードアップするためのコーチングの機会として使用するために、コードレビューを確実に紹介します。

コードの品質に関しては、2つのことを行います。最初に、腐敗プロセスを停止します。新しい劣悪なコードが導入されるのを防ぐコーディング標準とプラクティスに同意します。推奨されるコードレビューはここでも役立ちます。次に、コードの最悪の部分を特定し、これらのリファクタリングとクリーンアップを開始します。

はい、経験の浅い開発者に複雑すぎる問題を与えないことをお勧めします。しかし、逆に、簡単なことだけをさせてしまうと、彼らは学習しません。

私は、別の戦略がコードレビューの体制を確立することであることを提案します。初心者に（理由の範囲内で）トリッキーなものの作業をさせますが、作業を徹底的に確認します。

短期的には、これは全員にとってより多くの作業です。長期的には、複雑なものを扱うことができる開発者チーム全体になり、コードの品質に関する限り「同じページに」いることになります。