第2章 友達のささやかな助け¶

2.1 お互いの背中をかいてあげる¶

エゴレスプログラミング

• 作成者は一歩下がり、成果物のどこに改善の余地があるのか指摘してもらう
  • 他人に理解してもらうため成果物は他人が理解しやすいものでなくてはならない

2.2 レビューとチームの文化¶

レビューには作成者に望ましくない影響を与える可能性

• レビュアにミスを見つけてもらうことを期待する
  • 仕事が甘くなる
• ミスを指摘されたくないから、作成物を完璧にしてからレビューをする

2.2.1 文化の影響¶

• 作成者とレビュアは互いに尊重しなくてはならない。
• 成功体験が必要
  • ひどいレビューを受けた経験がある作成者は二度とレビューには出ない

2.2.2 レビューと管理者¶

• マネージャはレビューに対して理解を示すこと
• マネージャはピアレビューで収集したデータを評価に用いないこと

2.2.3 なぜ人々はレビューをしないのか¶

• レビューへの理解不足
• 文化の問題
• 変化に対する抵抗

2.2.4 レビューへの抵抗を克服する¶

• レビューの効果を実感させる

2.3 ピアレビューの洗練度の尺度¶

レビューを実施することにより組織の価値が高まる

2.4 レビューを計画する¶

• 公式レビューの時間をあらかじめプロジェクトの計画に含める
• レビューの実施をマイルストーンとしないこと、レビューはタスクとして扱う
  • レビューに合格した時点でマイルストーンに達したと扱うこと

2.5 レビューの原則¶

• 1. 始まる前に自身のエゴをチェックせよ
  • 作成者として心を広く持ち、改善の提案に受容的になる
  • レビュアとして作成者より頭がよいこと示すために行っているのではないことを心におく
• 2. レビューチームは小さくせよ
  • 通常参加者は3-7人
• 3. レビューでは問題の発見に努め、解決を試みるな
  • 識別された問題を解決するのはレビュー後
• 4. レビューミーティングは約2時間に制限せよ
  • 長時間のミーティングは成果が上がらない
  • 作業成果物はチームが1-2時間で調べられる論理的な量にすべき
• 5. 事前準備を要求する
  • 特に公式のレビュー
  • ミーティングの数日前には資料を受け取る
  • ミーティングの前にあらかじめ作業成果物を理解、問題を発見する