JSTQBのFLシラバスでも紹介されていますが、レビュータイプには色々なものがあります。
JSTQB FLシラバスで主に紹介されているのは
- 非形式的レビュー
- ウォークスルー
- テクニカルレビュー
- インスペクション
上記の4つですが、他にも様々なレビュータイプがあり、それぞれに目的ややり方・ルールがあったり、無かったりします。
細かいことは置いておいて、ざっくり各レビュータイプについて一言で解説したいと思います。
様々なレビュータイプを一言解説
IEEE標準1028で定義されているレビュータイプは以下の5つがあります。
- ウォークスルー
- 一言で言うと、作業成果物の作成者がレビューミーティングを主導して行う
- テクニカルレビュー
- 一言で言うと、技術的な部分をレビュー
- インスペクション
- 一言で言うと、一番公式なレビュー。ルールが色々ある
- ソフトウェア・マネジメントレビュー
- 一言で言うと、プロジェクト全体の進捗などをレビュー
- 監査
- 一言で言うと、国際的な標準や規制や規則、チーム内の開発ルールなどに沿っているかレビュー
カール・ウィーガーズという人が「ピアレビュー 高品質ソフト開発のために」で定義しているレビュータイプは以下の5つです。
- 教育レビュー
- 一言で言うと、関係者の教育の為のレビュー
- マネージメントレビュー,準備レビュー,ゲートレビュー
- 一言で言うと、プロジェクトの進捗や進め方などの方針のレビュー
- ピアレビュー
- 一言で言うと、チームメンバー、同僚などにレビューしてもらう
- プロジェクト終了後レビュー
- 一言で言うと、プロジェクトが終了した後に、「で、どうだったの？」と今後の為にレビュー
- ステータスレビュー
- 一言で言うと、マイルストーンに合わせて進捗、発生した問題やリスクの確認を行う
というようなレビュータイプがあります。
もちろん上記に記載した事以外にもルールややり方はありますが、細かい事はここでは割愛します。
また、レビュータイプではありませんが、レビューをする際の原則として、カール・ウィーガーズの論文「Improving Quality through Software Inspections」で、以下の原則が定義されています。
- まず、自分のエゴをチェックする。 – Check your egos at the door
- 作成者ではなく、作成物そのものを批評する。 – Critique the products, not the producers
- レビューで問題を見つける。ただし、見つけた問題をレビューの場で解決しようとしない。 – Find problems during the review; don’t try to fix them
- レビューの時間は最大2時間に制限する。 – Limit inspection meetings to a maximum of two hours
- 作成物の理解に影響がないのならば、スタイルに関する問題は避ける。 – Avoid style issues unless they impact performance or understandability
- 公式だろうと非公式だろうと、早期に点検を行い、また頻繁に点検を行う。 – Inspect early and often, formally and informally
とのことです。レビューをする際の心構えとして覚えておきたいですね。
というわけで以上。レビュータイプを3分で理解する説明でしたー
未経験からプログラマーへの転職率95.1％
参考文献
