レビューを考える - SEA関西プロセス分科会 - #seakansai
森崎先生のレビューの講演に参加しました。
個人的には@ITの記事のようなことを期待していたのですが、そのような記事ではわからない議論をすることができてとても有用な講演でした。
議論を通じて感じたことは以下の点です。
(a) 開発者は項目の抜けに敏感
実践していなくても頭の中がWモデルになっているのかもしれません。テスト項目の源泉を仕様書に求めるので、どうしても項目の抜けが気になるのでしょう。
(b) レビューに優先順位をつける
優先順位というとリスクベーステストを思い浮かべてしまい、全てをしないでどうするのかと思われるかもしえません。しかし、極限までレビューすることは困難で、時間の制約や体力の限界で終わってしまうので、優先順にレビューのフォーカスを変えていくことが有効だと思いました。
(c) レビュー道の極意は、レビューをせずにバグをとる
私が勝手にN先生のフロントローディングの話をまねました。すべてをレビューできなければ、その対象を減らすために、ドキュメントのひな型を用意する、ワープロの文章チェック機能を使う、エディタの自動整形機能を使う、静的解析ツールを利用するなど、効率化や自動化は有効でしょう。
(d) レビュー技術の研鑽には経験を積むことも重要
ドメイン知識がソースコードになっていることから、コードを良く知っているというのも、抽象化できる人なら高度な技術者なのだろうと思います。理由もなく、これまでそうしていたからというのは統一性には役立ちますが、将来役に立たなくなるでしょう。
(e) レビューの特性を生かせ
テストで見つかると工数がかかるからということがレビューのモチベーションになっていますが、それだとどれだけ時間をかけても良いことになってしまいます。しかし、欠陥の種類によってはテストの方が早く見つかるものも少なくないでしょう。懇親会ではテストは積み上げという議論があり、それからするとレビューの特徴はトップダウンです。レビューに向いているトップダウンでしかわからない所を攻めるべきでしょう。ボトムの細かなところは、なるべくほかの手段で済ませたいですね(それには(c)が有効でしょう)。
つらつらと書きましたが、このようなことを考える良いきっかけになりました。
« [#TiDD] デジタル化の効果をファシリテーションに利用する | トップページ | [#TiDD] チケット駆動開発で自律的な組織を目指す »
「ソフトウェア」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- 論文研修会(導入編)- 論理的思考のすすめ -(2019.12.01)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
「プログラミング」カテゴリの記事
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 論理的に考え伝える – SEA関西「開発現場で役立つ論文の書き方のお話」 -(2021.05.09)
- 論文研修会(導入編)- 論理的思考のすすめ -(2019.12.01)
- スクリプト言語入門 - シェル芸のすすめ - 第2回クラウド勉強会(2019.01.27)
- デブサミ関西でNode-REDとペンギンと勇気の話をしました #devsumiB(2018.10.28)
この記事へのコメントは終了しました。
« [#TiDD] デジタル化の効果をファシリテーションに利用する | トップページ | [#TiDD] チケット駆動開発で自律的な組織を目指す »
コメント