実践ソフトウェアエンジニアリング 16章で好きなところ
このエントリは実践ソフトウェアエンジニアリング第9版アドベントカレンダー の16日目です。
https://www.amazon.co.jp/dp/4274227944
自分が担当した16章「レビューの推奨手法」における好きなところを3点書こうと思います。
レビューへの向き合い方（P243）
- 作成者ではなく成果物をレビューする。
FTRには、人とエゴが関与している。適切に実施されたFTRは、すべての参加者が達成感を感じるものでなければならない。一方、不適切なFTRは審問のような雰囲気を醸し出すことがある。エラーを指摘するときは優しく、ミーティングのトーンはゆるやかで建設的なものにし、恥をかかせたり、貶めたりすることを意図してはいけない。レビューリーダーは、レビューミーティングにおける適切なトーンと態度が維持されるよう努め、レビューが制御不能になった場合は直ちに中止の判断をすべきである。
読む前はエンジニアリングということで手法の紹介がメインかと思っていたのですが、レビューへの向き合い方がガイドラインとして書かれています。ともすると人格攻撃になったりするので、ビューの場だけではなく、日常的に気を付けないといけないことだと思います。
自分が何かをレビューするときに気にしているところも書いてみます。（できてないときもあるけど意識しようとはしてますｗ）
- 根拠のない高い期待をしない
- まず全体を見て、いいところを探す
- 問題を提示する箇所は理由を言う（可能な限り言語化する）
- 好みの場合はオプションとして提示するが決定は任せる（後で文句は言わない）
レビューは時間を…するもの（P239）
「レビューは時間を奪うものではなく、時間を節約するものである。」
言われてみると当たり前なのですが、レビューに時間を奪われていると感じる人が多いのも事実だと思います。 大抵、「レビュー工数が組み込まれていない」とか「レビューが一人に集中する」とか「定型的に10人が見るようになっている」とかではないでしょうか？自分達のプロセスに合わせて柔軟に変えていきたいところです。
図を見るとレビューの有無によって工数に違いがあります。マズいものは早めにフィードバックする。アジャイルテスティングの本質にも通じることだと思います。
アジャイルのレビュー（P244）
スクラムのフレームワーク（3.4節）を詳しく見ると、非形式的レビューと形式的レビューが行われる場所はいくつかあることがわかる。スプリントプランニングでは、次のスプリントに含めるユーザーストーリーをレビューし、優先度にしたがって順位付けをする。デイリースクラムは非形式的レビューの1 つと見ることができ、（後略）
インスペクションレビュー以外はレビューとして認めないという原理主義みたいな方もいますが、あらゆるところにレビューはありますよという話がここにキチンと書いてあります。インスペクションの良さを否定するつもりはありませんが、日常的に対話をしながら、問題が小さいうちに摘み取ったり、チームとしての共通認識を育てていく方が自分は好きです。
まとめ
今回はレビューの章を紹介しました。 分厚くて堅い本と思われますが、結構いいこと書いていますので是非ご一読ください（宣伝
レビューの向き合い方に関してはこの記事もおススメです。
