【第4回】［#5］レビューの終わり方～レビュー評価・ふりかえり（2/2）｜ソフトウェアレビューをエンジニアリングっぽく語ってみる

みなさんこんにちは。

「ソフトウェアレビューをエンジニアリングっぽく捉える会」の”きたのしろくま”です。

前回に引き続き、「#5レビューの終わり方～レビュー評価・ふりかえり(2/2)」をお伝えします。

＜ソフトウェアレビューをエンジニアリングっぽく語ってみる　記事一覧＞※クリックで開きます

打開策2：レビュー指摘事項の分類／評価の実施

打開策1と同様、レビュー終了直後に、レビューにより検出された指摘事項をいくつかの視点で分類し、評価します。

分類／評価の方法にはいろいろありますが、ここでは2つの事例（視点）を紹介します。

1つ目の視点は、このフェーズで作り込まれた欠陥・不備なのか、他のフェーズで作り込まれたものなのかの分類です。理想的なのは、このフェーズで作り込まれた欠陥・不備を同じフェーズのレビューで見つけ出すことです。（図2の上）これが実現できなければ、プロジェクトが混乱する原因となってしまいます。（図2の下）

よって、他のフェーズで作り込まれた欠陥・不備があれば、作り込まれたフェーズのレビューを見直す必要があることに気づきます。

2つ目の視点は、レビュー目的の達成度と指摘事項の効果です。

レビューの“効果”を何で示すのかについてもいろいろ考えられますが、今回はその一例として「仮に今回のレビューでこの欠陥・不備を見逃した場合、あとでどの程度悪い影響が出るものかの度合い」をご紹介します。

あとになって発生する悪い影響を正確に把握することはできない場合も多いので、下記のように進めます。

少なくとも自分たちの開発の進め方から想定すると、この欠陥・不備はこの先どのフェーズで見つかる可能性が高いか、見つかった時の対処にどのくらい期間、工数を費やして対処することになるのかを（ザックリでもOK）見積もります。その際にプランニングポーカーを使うなどの工夫が可能です。
見積結果を活用して3つの枠：効果大、効果中、効果小に割り振ってマッピングします。
さらに、それぞれの指摘事項がどのような観点にあたるのか？を明らかにして、効果大中小の観点分布を把握します。（以上、図3）

続きを読むにはログインが必要です。
ご利用は無料ですので、ぜひご登録ください。