変更のリスクによってタスク/バグを分類する
私が現在取り組んでいるプロジェクトには問題があります。バグやタスクは、あまりにも新しいまたは経験が浅い人々に割り当てられることが多く、彼らの仕事は将来、より多くのバグを生み出すことになります。問題は、コードの品質の問題により、ソフトウェアの一部が他のソフトウェアよりも「危険」であることです。私は、タスクに関連するリスクを推定し、どの開発者がどのタスクを割り当てられるかに細心の注意を払うことで、この問題に対処しようとしています。
私たちは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のスコアを比較するときに得られます。 PEFが21、REVが7の場合、これは大きな勝利になる可能性があります。 PEFが7でREVが21の場合は、リスクと労力の面でそれを修正するメリットを上回る可能性があるため、しばらくは回避する必要があります。
次に、REVスコアを確認し、リスクの少ないものを経験の浅い開発者に割り当てます（この状況では、リスクが低く、労力が多いことが理想的です）。
ここであなたが言及していることは、「複雑さ」と呼ぶ方がよいと思います。もちろん、変更が複雑であるほど、「リスク」が高くなります。経験の浅いプログラマが新しいバグを持ち込む可能性があります。それが本当の問題であるならば、そのような分野を導入することは悪い考えではありません。
しかし、あなたが書いたものから判断すると、2つの問題があるようです：
- あなたは、新規または経験の浅いプログラマーを扱っています。
- あなたのコードの（多く/いくつかの）品質は疑わしいようです。
「複雑さ」フィールド（作業の管理と優先順位付けに役立つ）のようなものを導入することに加えて、上記の2つの問題のリスクを軽減することに焦点を当てることをお勧めします。
最初の問題に対処するには、新しいプログラマーがすべての新しいバグについて、経験のあるプログラマーと話し合ってからバグに取り組むプロセスを作成します。また、コードレビューを導入して、新しいバグが導入されるリスクを軽減し、新しいプログラマがより迅速に習得するための指導の機会として使用するようにします。
コードの品質に関しては、2つのことを行います。まず、腐敗プロセスを停止します。新しい下位コードが導入されないようにするコーディング標準と慣行に同意します。提案されたコードレビューはここでも役立ちます。次に、コードの最悪の部分を特定し、リファクタリングとクリーンアップを開始します。
はい、経験の浅い開発者に複雑すぎる問題を与えないことをお勧めします。しかし、逆に言えば、簡単なことだけを行わせると、学習できなくなります。
別の戦略として、コードレビュー体制を確立することをお勧めします。初心者が（合理的な範囲で）トリッキーなものの作業に取り掛かるようにしますが、彼らの作業を徹底的に見直します。
短期的には、これは誰にとってもより多くの仕事です。長期的には、コードの品質に関する限り、複雑なものを処理でき、かつ「同じページ」にいる開発者のチーム全体で終わることになります。