ピアレビュー―高品質ソフトウェア開発のために

作者: Karl E.Wiegers,大久保雅一
出版社/メーカー: 日経BPソフトプレス
発売日: 2004/02
メディア: 単行本
購入: 7人クリック: 148回
この商品を含むブログ (26件) を見る

会社ではピアレビューをやっている。
ピアレビューはコードを共有したり、より良くしていくために必要な行為だ。
でも、上手く運営していくにはそれなりにコツがいりそうということで
この本を手に取った。

気になった箇所は以下の通り。

プロジェクトレビューの種類(p2)
- 教育レビュー
- マネジメントレビュー
- ピアレビュー
- プロジェクト終了後レビュー
- ステータスレビュー
ソフトウェアプロジェクトの主なレビューのチェックポイント(p11)
レビューとチームの文化(p17)
- 個人とチームの両方の成功を助ける活動
- 作業実績の劣る人間を特定する事ではない
- 品質問題の責めを負わせるスケープゴートを見つける事ではない
文化の影響(p19)
- 作成者はレビュアーに信頼と尊敬の念を持たなければならない。
- レビュアーは作成者に、才能と、ハードワークに敬意をしめす必要がある。
ピアレビューへのマネジメントコミットメントを示す11の行動(p21)
- レビュー結果を決して個人の業績の評価に使わない事
プロジェクトの各役割がピアレビューで受ける利益(p28)
公式レビューをプロジェクトのスケジュールもしくはWBSに組み込む(p31)
レビューの原則(p33)
- 始める前に自身のエゴをチェックせよ
- レビューチームは小さくせよ
- 問題の発見に努め、解決を試みるな
- レビューミーティングは2時間に制限
- 事前準備を要求する
各種ピアレビューが実施するアクティビティ(p37)
ウォークスルー (p40)
- 非公式のレビュー
- 作成者の要求を満たすためにある。
さまざまな目標に適したレビュー方法の提案 (p49)
インスペクションチームの参加者は3-7人 (p55)
インスペクションする文書の作成者と配布先/提出先
いつインスペクションを行なうか (p70)
- 作業成果物が完了のマイルストーンに到達し、次の開発ステップに渡せる状態になった時に行なうように計画する。
インスペクションの開始基準 (p77)
- 作業成果物に関する作業基準がのっている
レビュアーの選択基準、作成者が知っていることと同じ事を知っている人だけでなく、異なる知識を持っていて初期作業成果物をほかの視点から見られる人を捜す(p79)
管理者とオブザーバ (p83)
インスペクションパッケージ (p85)
- インスペクション対象物や、必要な資料のこと
ルールセット (p101)
- ソフトウェアインスペクション(共立出版)
ソースコード (p105)
- コードを上から順に読んでいくのではない
- 体系的に横切って進んでいく
モデレータの役割 (p108)
欠陥と課題を挙げる (p119)
- インスペクタは言い方を良く考えてコメントを述べる
- 不快な感じをあたえない
- インスペクションを建設的な土俵上に保つ
記録する場合は、どんな種類の課題や欠陥であるかを示す (p112)
ミーティング中に欠陥をどうやって修正するかを決めるのに、約1分以上かけてはいけない。
測定機能障害 (p145)
- データの使用方法が、データを供給する人の間に逆効果になること。
- 欠陥の重大性の過大評価、または過小評価
- 修正した欠陥の割合の細工
- 欠陥密度、準備時間、欠陥発見速度の歪曲
インスペクションデータの項目例 (p147)
ピアレビュープロセス説明書の内容 (p168)
ピアレビュートレーニングセミナー1日間コース見本 (p173)
ピアレビューの効果を上げる (p179)
非同期レビュー (p198)
的確なレビュアーの不足 (p202)
- ふさわしいスキルのある同僚を他の部署か時には他の企業から見つけてくる。

ピアレビューを始めたい会社の人はぜひ目を通してみてください。
始めから上手く運用できるにこした事は無い。