本日の講義は IBM細川さんによる「プロセス改善ベストプラクティス」~レビュー、インスペクションの効果的実践と阻害要因 QI法の実践事例の紹介~です。
2010-11-19 23:45:56今日の参加者は、レビューを実践されている方が多数参加されています。 レビューをやるときに必要なのはお菓子。 先輩に赤ペンを入れてもらうという文化が無くなっている。 どうして人に見てもらうのか、というところからレビューの話が始まります。
2010-11-19 18:07:04レビューの目的。 プラスを増やす。 マイナスを減らす。 レビューは単なる技法です。技の一つ。 レビューの目的は欠陥をとるだけではない。 レビューの目的は「安心」すること。自信を持つことができるのか すべてのコードを、すべての文書をレビューすることはできない。
2010-11-19 18:08:57レビューの目的が安心感を得るためであったら、進捗遅延でレビューを省いていいのだろうか。進捗が遅延し始めると、開発者は孤独になる。レビューを省くとみんなで話をする場が無くなってしまう。そのため、コミュニケーション不足に起因するバグが入り込む。
2010-11-19 18:13:52レビューのコツ。欠陥をたくさん知ること。たとえば、桁落ち。この概念を知らない若者がいる。まぁ、この桁落ちレベルはレビューではなく、その前段階でつぶして欲しいけど。
2010-11-19 18:17:05品質は上流で作り込む。これは全部嘘です。日本に入ってきたときに誤訳されました。正しい解釈は、潜在期間を短くすること。上流から下流まで一貫してレビューをし続けること。毎日繰り返す、これの方が効く。
2010-11-19 18:30:46修正中心型= Correctness Centric。予防中心型= Prevention & Prediction。テストスタート時の残存欠陥を最小限にする。欠陥が生まれたらできるだけ早く検出する。
2010-11-19 23:53:47バグを埋め込みきってから、コネクトレス・セントリック。バグを作り込んでだから除去する。予測と予防タイプ。欠陥を軽くする。ワインバーグのテストの本。テストのいうのは所詮サンプリング戦略。標本の抜き方が大切。レビューもサンプリング戦略。全部レビューできない。
2010-11-19 18:32:53レビューの効果は? このページを使え。CCはテスト中心戦略。最後のシステムテストで全部のテストをしようとすると、48%をテストに時間がかかる。一定の検証時間を入れる。5%とか。修正中心182時間、均等にすると93時間で済む。
2010-11-19 18:36:1127%期間短縮できる技法って少ない。対象が大きくなると効果がそれほど大きくならないけれど、2割は切らないだろう。圧倒的に時間差がでる。
2010-11-19 18:37:34レビューは生産性を下げるという声がある。生産性を上げると端折ることになる。時間短縮、効率を上げることで品質が下がるケースがある。平均的に5枚以上書くと、バグが上がり始める。デマルコのいくら頑張っても考える時間を短くすることはできない。作業は短くできるけれども。
2010-11-19 18:41:24生産性の上限と下限を押さえている組織は少ない。身の丈を知っておくこと。これ以上生産性を上げると、バグが入り込むという数字は持っていた方がよい。
2010-11-19 18:42:28