レビューの最近のブログ記事

設計作業や仕様書作成作業といったものは楽観的な観点に立ったプロセスであるため、レビューに参加するメンバーは懐疑的な観点に立って、見落としがないかをチェックすることになります。

「アート・オブ・プロジェクトマネジメント」

重大な、あるいは本質的な設計エラーまたはアーキテクチャ上の問題点は、インスペクションの焦点を特定の問題に絞らない限り、表面的なレビューではまず明らかになりません。

「ソフトウェア プロジェクト管理」

レビュー・リーダは、プロダクトの出来、不出来に対して責任は取れないし、とる必要もないが、そのレビュー自身についてだけは、その出来栄えに責任をとれるし、そうしなければならない。

「ソフトウェア技術レビュー・ハンドブック」

レビュー結果を無視するときには危険を覚悟せよ。

「ソフトウェア技術レビュー・ハンドブック」

プロダクトの品質が悪くてもよいレビューには報いること。

「ソフトウェア技術レビュー・ハンドブック」

製作者を評価しないこと。

「ソフトウェア技術レビュー・ハンドブック」

技術的問題点のみを扱うこと。

「ソフトウェア技術レビュー・ハンドブック」

標準に忠実であること、さもなければ標準を捨てること。

「ソフトウェア技術レビュー・ハンドブック」

形式についての議論を避けること。

「ソフトウェア技術レビュー・ハンドブック」

問題点を提起しても、それを解決しないこと。

「ソフトウェア技術レビュー・ハンドブック」

肯定と否定の両面から検討すること。

「ソフトウェア技術レビュー・ハンドブック」

レビュー・リーダの仕事は、レビューがうまくいくようにすることである。さもなければ、なぜレビューがうまくいかなかったかを報告することである。

「ソフトウェア技術レビュー・ハンドブック」

欠陥発見にはたくましく創造的であれ。欠陥との戦いに勝つためには、何の制約も存在しない。

「ソフトウェアインスペクション」

チェック作業でのチェッカの目標は、ユニークな重大欠陥を最大数見つけ出すことである。ユニークな欠陥とは、ロギングミーティングで他のインスペクタが提示しないものである。重大欠陥とは、テストや運用時に見つけるよりも、今見つけることによって労力を軽減できるものである。

「ソフトウェアインスペクション」

インスペクション自身は、きわめて不合理な納期をも守れることを保証するものではない。しかし、その品質とコストの尺度を通して、阻害要因に関する警告を早い時期に与えることができる。また、品質マイルストーン（完了承認）を示すことにより、早期に危険信号を出すことが可能で、拙速を好む管理者の承認よりはるかに信頼がおける。

「ソフトウェアインスペクション」

問題発見には自動化ツールの利用をまず考える。ただし、発見時期が遅れ、修正コストが自動化の利点を上回るようであれば、迷わず別の手を考える。

「ソフトウェアインスペクション」

インスペクションはテストを代替するものではない。双方は互いにユニークな機能を持っており、それらは他者にとって変えられるものではない。インスペクションはテストで発見できない欠陥を発見し、テストはインスペクションで発見できなかった問題を発見する。

「ソフトウェアインスペクション」

ウォークスルーは訓練に、レビューはコンセンサス作りに！　インスペクションは文章とそのプロセスの品質改善に！

「ソフトウェアインスペクション」

予防は治療に勝る。　つまり1回の予防は何回もの治療に値する。

「ソフトウェアインスペクション」

レビューは、スケジュール効率を改善し、冗長作業を除去し、テストを補い、そして訓練をもたらす。

「ワインバーグのシステム洞察法」

大きなプログラムについての調査では、査閲（レビュー）に費やした1時間ごとに保守を33時間も削減したことがわかり、査閲はテストの20倍も効率がよいという結果が出た。

「ラピッド デベロップメント」

過度にコストがかかり信頼性を低くする機能を発見し排除することができるので、技術審査にはそのコストの何倍にも相当する効果がある。

「ソフトウェア　プロジェクト　サバイバル　ガイド」