レビュー

作成日時：2024-08-01以前
更新日時：2024-08-01

レビューはコストがかかる。
基本的にはレビューの時間中、参加している人の作業をストップさせる。
目的を定め、参加する人員は選定する。

レビューの目的

• 仕様確認
  • 文字通り成果物が仕様通りかを確認する。
• 情報共有
  • 実装担当者以外に、その要件を周知する。
  • DRY原則を促す
    • 「ちょうどその処理の共通モジュール作ったから、それ使って」とか
• 新人教育

目的次第でどのような人をレビューに参加させるかを考える。

仕様確認だけならば、PMと担当者だけでいい。
情報共有をしたいならば、共有したい人をレビューに加える。
新人教育をしたいならば、新人も加える。

考え

個人的には下記。

• 設計書レビューはウォークスルー
• コードレビューはパスアラウンド

設計書に関しては、要件はPMが一番詳しい。
PM以外の人間がレビューに参加しても、その設計の要件に対する妥当性は分からない。
ウォークスルー形式かつ、参加者をPM + 担当者 + 詳しい人位の少人数で設計を詰める。

コードレビューはレビューの目的に合わせて自由に。
わざわざ集まる必要もないのでパスアラウンド。
プルリクエスト出して、複数人が机上レビューし、LGTMがN個以上でマージする。などの運用でいいと。

議事録・レビュー記録

基本的には新人が書くべきではない。
仕方がないことだが、新人の書く議事録は品質に問題がある。

目的を何にすべきかが重要。
議事録を詳しく残したいならば、実装者が書けばいい。
新人教育を目的とするならば、新人に書かせるのもありだ。

その他

「会話」はプロセス占有。
「チャット」はコンテキストスイッチ。

チャットでいちいち作業を中断させられるならば、会話でまとめて行え。