アジャイルを使ってクリスマスまでに彼女を作る方法を考えてみる が理想的にすぎるように思えたのでメテオフォール型開発に基づく破綻が起こらないよう検証しておきたいと考えた。
メテオフォール恋活・婚活の流れ（アジェンダ）とは
0. アジャイルの各役割（ロール）説明
1. プロダクト・ビジョン（Product Vision）
2. プロダクト・ロードマップ（Product Roadmap）
3. プロダクト・バックログ（Product Backlog）
4. スプリント計画（Sprint Planinng）
5. スプリント（Sprint）
6. デイリー・スクラム（Daily Scrum）
7. スプリント・レビュー（Sprint Review）
8. スプリント・レトロスペクティブ（Sprint Retorspective）
→すべてを破壊するメテオフォール。詳細は メテオフォール型開発とは 参照のこと
アジャイル型恋活・婚活が破綻する可能性
スクラムマスター「母」への大きな依存がリリース直前に明らかになることでこれは重大な要件未達ではとの意見がステークホルダー「恋人」から噴出する
などなど
なぜこのような恐ろしいことが起こるのか
メテオフォール型開発は基本的にはウォーターフォール型開発と同じだが、「神」が存在し、気まぐれに「メテオ」を落として要件定義や基本設計、詳細設計、実装をぶち壊していく点が異なる。つまりアジャイル型恋活・婚活に置いては不確定要素の高い「恋人」それ自体が「神」となり設計を揺らがせる危険があると考えられる。
どうすれば回避できるのか
【vsメテオフォール】エンジニアらしく組織を変える為のプログラミング・マネジメント が詳しい。
「プログラミング原則」でプロダクトオーナーの問題を炙り出しておこう
- 母や友人、兄弟という各役職が自身の「役割」から逸脱した行動を取らないか → 「単一責任の原則」
- 同じく母や友人、兄弟という各役職の意思決定が他層の情報に強く依存しないか → 「依存性逆転の法則」や「モジュール結合度」
- 父・母という経営層がマネージャーの頭を跨いでしまっている → 「デメテルの法則」etc...
- あるいは「役職の責務」がボヤけてしまっている点。本人の、他への依存度が強すぎる点に根本的な原因が無いか。このあたりに焦点を絞り、「プログラミング的手法」を通じて依存度をリファクタリングしていくとよい。