どんな問題?
- オブジェクト指向では,分析時に完璧すぎるモデルを作る必要はない
- ドメイン専門家に任せる事ができるがOODの強みであるはず
- Analysis Paralysisを引き起こす誤った前提:
- 詳細な分析はコーディングの前にできる
- 問題はすべて前もってわかっている
- 分析したモデルはコーディング中に改変されるべきではない
症状と結果
- 人員や方針の変更により,既存プロジェクトの再始動が何度も起こる
- 設計・実装の問題が分析段階で何度も議論にあがる
- 分析コストが当初の予想より大きくなる
- ユーザテストの結果と関係ない分析が行われる
- 分析が複雑になる.その結果として開発,文書化,テストがしにくくなる
- GoFパターンが分析段階で使われる
原因
- 管理側がウォーターフォールを想定している
- 実際にはどんなプロジェクトも非公式にアジャイル開発を含むもの
- 管理側が設計・実装よりも分析・問題の解析に対して自信を持っている
- 管理側が設計開始前に,すべての分析を終わらせたがる
- 分析フェーズの終わりが定義されていない.
- 管理側が十分分析されているドメインに関する意思決定をしたがらない
- プロジェクトのユーザに対するvisionとfocusが発散している
どう解決する?
- Incremental developmentを行うべき
- ウォーターフォールでは問題領域の知識を事前に知っていることが前提だが,
- incremental developmentでは,問題領域はプロセスの中で学ぶこととなっている
- Incremental developmentのphases
- analysis
- design
- coding
- test
- validation
- Incrementsには2種類ある
- internal increments
- 実装のインフラに関わる部分のincrement
- サード・パーティのdatabaseやdata-access layer
- 色んなユースケースに使われる
- external increments
- アーキテクチャレベルでもanalysis paralysisは起こる
- 開発者が守るべきアーキテクチャ原理や拘束条件を超えて,詳細な仕様を決めてしまう
- マネージャーレベルでもanalysis paralysisは起こる
- micromanagementとして知られる
- やることを詳細に決めてその監督をしてしまう
yusuke-ujitoko.hatenablog.com