レビューはペア作業であるべき
SW開発でいつもボトルネックと感じる工程がレビュー。
僕が経験した過去のどのプロジェクトも、レビュー工程は効果的と思えなかった。
少なくとも、開発者の立場では、レビューは嫌なもの。
自分の成果物にケチをつけられ、何度も直しては叩かれる。
今、管理者の立場でレビューに携わっているが、レビューが成果物の品質Upになっているとはとても言えない。
設計レビューは、設計の元ネタとなる要件定義と化している。
レビューアーにひたすら質問しまくって、本来の仕様を聞き出す。
ソースレビューは、コーディングルールの徹底と化している。
CheckStyleで十分なのに、レビューワーは業務ロジックまで分からないから、ただ直すだけ。
いつも思うのは、レビューはペアプロ、ペア作業であるべきだ。
レビューワーが、レビューイーの席の隣に座り、レビューイーのPCで成果物を見ながら、間違っている箇所はその時その場で即修正する。
その方が効率的だし、レビューワーと情報共有しやすくなる。
ペアプロをレビュー工程の代替手段として捉えられないか？
| 固定リンク
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想～大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2～プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1～CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「ソフトウェア工学」カテゴリの記事
- Jiraの機能はTracに似ている気がする #redmine(2025.06.01)
- チームトポロジーの感想～大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか～島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか？～Software Processes are Software, Too（ソフトウェアプロセスもまたソフトウェアである）(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2～非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
コメント
はじめまして。
とおりすがりのものです。
自分もレビューにかける時間をなんとか効率よくできないかと、レビューする方法に悩んだりしています。
＞いつも思うのは、レビューはペアプロ、ペア作業であるべきだ。
＞レビューワーが、レビューイーの席の隣に座り、レビューイーのPCで成果物を見ながら、間違っている箇所はその時その場で即修正する。
アリだと思いますよ。
自分はペアプロというかドキュメントのレビューで、レビュー対象の成果物をプロジェクタで見せて、指摘されたらその場で修正する、というのをよくやっていました。
紙に印刷したり、修正箇所を再レビューする手間が省けていいですよね。
ただ、欠点は、全部その場で修正していると、レビューアがそのレビューに携わる時間は多くなってしまうので、あまりたくさんのレビューアに参加してもらうのが難しいところでしょうか。
投稿: zeroaka | 2009/03/15 12:38
◆zeroakaさん
ペア作業の長所と欠点はご指摘の通りで参考になります。
レビューはSW開発の品質UPに必要であるにも関わらず、レビューをいくらやっても成果物も作業効率も変わらない現状が多いです。
レビュー工程はその内容や品質についてもっと考えるべきだと思います。
投稿: あきぴー | 2009/03/21 00:07