CEDEC 2010「Q-Games流アジャイル開発手法：PixelJunk での実践例を紹介」
今回はQ-Gamesさんのアジャイル開発手法のセッションまとめます。
このセッションでは、Q-Gamesさんが開発手法としてアジャイルを取り入れた経緯と、取り入れた後の問題点を紹介しており、その変遷での試行錯誤の内容に共感出来るところが多かったです。う〜ん、うちもあるなぁと…。
ではレポートです。
概要
Q-gamesの開発スタイル
問題点
- 当初の仕様や計画通りには進みにくい？
- ただし、実際に遊んで感じた結果の方が重要
- 無駄な実装が多くなる傾向？
- 面白くなるためには、無駄も必要なプロセス
アジャイル開発の試みと必然性
→元々アジャイルを導入する土壌があった
Mantisの特徴
- 無料
- 処理が高速
- 検索条件が多様(絞り込み)
- セキュリティが高い
- ロードマップが定義しやすい
- マイルストーンの管理に重宝
- タスクの親子関係・関連付けがしやすい
- ツール自体のカスタマイズがしやすい
- 社長のディラン自ら、カスタマイズしている
Shooter2以前の課題点
- マイルストーン式なので、最終チェックまでのスパンが長い
- タスクの割り振りが外部依存になりがち
- Q-Gamesではプランナーがほぼ全てのタスク入力を行う
- タスクが多すぎて、精神的プレッシャーが大きくなった
- 管理側がスペックの実装漏れに気づきにくい
- 調子にのって入力していると、管理側が見落とす事があった
→そこで、Q-Gamesなりにスプリントを導入スプリント導入意図
- 2週間分のタスクだけに集中出来るので、タスク過多による精神的プレッシャーが減る
- 2週間ごとに成果物が出来上がるので、イテレーションが早くなる
- 開発の軌道修正がしやすい
→クオリティと、作業効率アップが期待できる
Shooter2のスプリントタスク
- 現在、16スプリント経過したShooter2での3つのフェーズ
スプリント運用で発生した問題点
- タスクをこなす事に慣れ常態化
- スプリントの定義を混同
- 達成すべきタスク = ゲームの目的になってしまった
→本来は品質的要求仕様(Quality)をスプリントの目的として設定するべき
Q-Gamesさんのレポートは以上です。
次は、セガさんのファンタシースターシリーズでのPERFORCE導入事例を書こうかと思います。あのセッションもタメになりました。
