どんな問題？
背景
- ソフト設計は会議で作られると言っても過言ではない．
- 変数が多いため，すべての仕様を明らかにして比較するのは不可能
- もし設計ができたとしてもテストはできない
症状と問題
- 設計書が下記の特徴を備えている
- 複雑
- 大規模
- 読みにくい
- 一貫性がない
- わけがわからない
- 会議が上手くいかない
- よく議論されない
- 進行が遅い
- 真剣に会話しているがシングルスレッドで，他の大部分の人の存在が意味をなさない
- 周りの環境が変わる
- 政治的都合により会議の内容が陳腐化する
- 決断を迫られるなど
- 設計に優先順位がない
- どの要素が重要なのか
- プロトタイプでなにができていないといけないのか
- アーキテクトや開発者が設計に対して衝突している
- 設計開発が予算超過する
どんなときに起きる？
- アーキテクトがいないとき
- ソフト開発プロセスが決まってないとき
- 会議のプロセスが悪いとき
- ファシリテータがいない
- うるさい人が勝つ
- 皆で幸せになろうとして，全員の意見を取り入れるとき
- 5人以上の会議で決議がとられるとき
- 優先度が決まっていないとき
- 関心事が明確に整理されていないとき
どう解決する？
会議のプロセスを見直すことが有効．
そのためには，下記のことをやるとよい
- 時間を気にして会議する
- コメントを25語程度にする．詳細は要求されたら行う
- 「なぜ会議しているのか」「どんな結果が欲しいのか」を明確にしておく
- 個人個人の役割を明確にする
- Owner
- Facilitator
- Architect
- Developer
- Tester
- Domain expert
会議には3種類ある．
- divergent（ブレスト）
- convergent（選択や決議）
- information sharing（情報共有）
Spitwads
会議を成功させるプロセスとしてSpitwadsという手続きがある．
- 質問をする
- 誤解を減らすため
- 参加者は意見を簡潔にメモする
- Toss spitwads（意見やアイデアを書いた紙を一箇所にあつめる）
- 集められた紙がランダムに参加者に戻される
- 共通理解へ達する．
- お互いに確認して誤解をなくす
- 重複を削除する
- 優先順位をつける
- 会議する
