大規模jsプロジェクト ロードオブナイツの管理手法紹介 2012-11-06
TRANSCRIPT
大規模 JS プロジェクトロードオブナイツの管理手法紹介 (+α)
株式会社 Aiming東京開発グループ ゼネラルマネージャ
小林 俊仁 (@toshi_k)2012年11月6日 / Aiming Study #7
About: 小林 俊仁
• http://about.me/toshi_k• オンラインゲームを作って早10年• 根は web っ子のつもり
About: 小林 俊仁
• Community Engine でオンラインゲーム作って (2001~2003)
• → 中国でオンラインゲーム&周辺のシステム開発の子会社作って (2003~2007)
• → 子会社を閉じて日本に帰ってきて、ゲームのサーバ書いたり技術コンサルしたり (2007~2010)
• → チームごと ONE-UP へ (2010)
• → チームごと Aiming へ (2011~)
最近書いた本(共著)
昨日発売!
About: Aiming
Games
ロードオブナイツ 剣と魔法のログレス
Blade Chronicle
Games
RPG三国志クイーンズブレイドTHE CONQUEST
ロードオブナイツ
• iOS の RPG/ストラテジー。ブラ三タイプ。• クライアントは C# + Unity (結構リッチ)• サーバは PHP。 API と view のあるページの両方。 札幌の infiniteloop さんに外部委託。
今日の話:
• ロードオブナイツを、 JS + HTML5 アプリとしてスマートフォンと PC ブラウザに移植し、両方同時にリリースする際の実例(苦労話)紹介
• 私はスクラムマスター的な立場• ここと大体一緒
http://developer.aiming-inc.com/management/lok-html-management-history/
目次: 4つの時代
• 1) マスターストーリーリスト期• 2-1) 黎明期• 2-2) ポストイット期• 3) ストーリーカード期• 4) Redmine チケット期
1) マスターストーリーリスト期
2月~3ヶ月程度
時代背景
• 他社に開発を委託し、本体アプリ側メンバーが片手間でサポートして進めていた
• UI は本体同様横持ち前提
この頃の測定と共有
• タスクの共有: Google Docs• 測定対象: ストーリー(本体アプリでユーザができることを抽出したもの)
• 測定単位: ストーリーの個数• 測定結果の共有: Google Docs でバーンダウン
こんなかんじで
しかし、大きな前提変化が
• 7月中頃にスマフォと PC のブラウザ版を同時にリリース。〆切最優先。
• UI• スマフォ版は縦持ちに変更• PC 版は専用の別デザイン
体制組み換え
• クライアント開発者は、協力会社含め全員社内に常駐化。
• 他プロジェクト 2 つを一時停止して人員確保。全部で 12 人くらいになった。
• Ruby や Haskell で KPI 集積ツールを書いてたチームと、3D ゲームを作ってたチーム
• サーバ人員も増やしてもらった
2-1) 黎明期スパイク~準備期間
5月中~1週間程度
チーム開発の環境整備
• 社内で席替えして全員を1つの場所に• コードレビューの導入• レビューのしやすさを考慮し、レポジトリを gerrit から GitHub に移行
• ペアプロ導入
チーム開発の環境整備• PC web 版は Unity web player で手を抜けるか検証したが、やっぱり JS で。
• コードの構造化、メンテナンス性の向上• CoffeeScript 化• テストをちゃんと• Jenkins CI 動かした• JavaScript: The Good Parts 読書会
変化したこと• ◯ 朝会 (daily scrum)• ◯ 振り返り• ◯ タスクボード• △ スプリント計画・レビュー
• △ プロダクトバックログ - 既存
• △ バーンダウンチャート• ☓→◯ TDD
• ☓→◯ ペアプロ
• ☓→◯ コードレビュー
2-2) ポストイット期
5月末~7月中2ヶ月弱
内政あれ
• まるで工数の見当がつかない• → とりあえずユーザ価値の大きい内政を作ってみて、作業負荷を見積もろう
• 後から考えると、最も複雑な部分から着手することになってしまった
スプリント
• スプリント #1 開始。• スプリントゴール:「来週 6/8 (金) までに内政を動かす」
• 問題: 自分たちの進み具合がよく分からない• 見える化するため、ポストイット+タスクボードを導入
タスクボードの運用
• 思いついた端からポストイットに書いて貼る• 着手中 → Doing、 完了 → Done• ストーリーとタスクの結びつきは薄い• どんどん増えてカオス化したが敢えて継続• 理由:• 「チームが前進している感」が出ていた• 設計変更が多くまだ手探りだった
この頃の測定と共有
• タスクの共有:タスクボード
• 測定対象: なし• 測定単位: なし• 測定結果の共有: なし
2週間回してみて問題
• Sprint #2 のゴール「内政・デッキが完全に動く」は中途半端にしか完成しなかった。
• 作業負荷の見当がつかない状況は変わらず。
超大雑把に見積もってみた
• ベロシティ: 3pt/週• スマフォ版: 31pt → 10週間 → 8/末完了
• PC 版: 半分とするとさらに 5週間 → 10月完了
• 全然間に合わない
4天王と調整
•本体アプリ版の開発を縮小し、仕様理解度の高いメンバーが参加。
• PC 版デザインをスマフォと同じに
• IE8 を切る© Rasmusson Software Consulting
この頃の自分振り返り
• Problem: ワーニングを経営層に事前に出せていなかった
• Try: 見積もれていないこと、全く間に合わないことをストレートに公言しよう
• これが言えない程度に自分を守っていた。
小田レビューの導入
• ユーザが遊べる系のタスクは、どこまで作りこめば終わりなのか? Done の定義が曖昧。
• Doing → 小田レビュー → Done• 担保すべき品質の目線を合わせる&上げる
ペアプロ表の導入
• 見積もれない/進みが遅い の原因:1. JS や CoffeeScript に不慣れ
2. 本体アプリ仕様の把握不足
3. 既存 JS コードの把握不足
• 上記の理解度が高い人にフラグを立て、朝会でペアを決める→ 効率的なノウハウ共有が可能に
3) ストーリーカード期
7月中~末2週間程度
問題
• このままだと8月のリリースも無理っぽい• 「全体」が適切な粒度で定量化されておらず、「間に合うの?」「間に合わないなら何をケズればいいの?」という質問に答えられない。
• 手っ取り早く全体を定量化する手法が必要
SML 見積り
• 皆で集まって、大中小で大雑把に見積もり、合意にする• 上手くいった点:• 見積りポーカーに比べて手間いらず• 「全部」を定義できた → バーンダウンチャートの作成が可能に
• M は 2.5 理想人日くらい?的な感覚が共有できた• 見積もる対象が、「ケズれる」粒度に落ちた
こんなかんじ
ストーリーカード化
この頃の測定と共有• タスクの共有:タスクボード
• 測定対象:ストーリー
• 測定単位:ストーリーポイント
• 測定結果の共有:紙バーンダウンチャート
サーバ開発との連携
• このプロジェクトが最優先であり、危機感を持っていることを infinite loop さんにちゃんと伝えられていなかった
• → 他プロジェクトの作業を止めて、これに全力投球してもらうことにした。
• 札幌-東京で週例のビデオ会議を開始
4) Redmine チケット期
7月末~リリースまで3週間程度
理由
• 問題:• ストーリーの実装完了よりも、個々のバグが直ったかどうかが重要な進捗の指標になってきた
• デバッグチームが大阪にあり、開発チームが東京と札幌にあった。 これら全体でやり取りができる必要があった。
• Skype チャットだと話が流れる → やりとりをチケットにしよう → バグもチケットにしよう
この頃の測定と共有
• 測定対象:バグ
• 測定単位:個数
• 共有方法:バーンダウンチャート
その後
スマフォブラウザ版
• ストーリーカード期に見積もった 8/3 の mobage 審査提出には間に合わせることができた
• 審査にn回落ちた後、8/24 には正式にリリース
[] 8/3 が出てこないんじゃ
PCブラウザ版
• 削減された PC 版専用デザインは、リリース後に開発を再開し、10/頭にリリース
[] PC版リニューアル前のSSある?
できた。
まとめ
変化を受け入れる
• どんな手法であれ、固定的な方法論や指標にしがみつくのは非常に危険。
• フェーズによって計測したいものが変わる• 管理手法はそれに伴って何度でも変える• 開発手法を変更をしやすくする土壌:• 朝会、夕会、スプリント会議、振り返り
管理手法の変化まとめ
タスクの共有 測定対象 測定単位 測定結果の共有
1) マスターストーリーリスト期
2) ポストイット期
3) ストーリーカード期
4) Redmine チケット期
Google Docs ストーリー 個数 Google Docs
ポストイット +タスクボード
- - -
ストーリーカード + タスクボード
ストーリー ストーリー pt (SML)
紙バーンダウンチャート
Redmine チケット バグ 個数 紙バーンダウンチャート
やってることの本質
1. 期間内にやることの「全部」は何かを明確にし、チームのコミットメントとする
2. 進捗を定量化して計測するために最適な指標を考える
3. バーンダウンチャートとして計測する
ありがとうございました株式会社 Aiming
東京開発グループ ゼネラルマネージャ小林 俊仁 (@toshi_k)
2012年11月6日 / Aiming Study #7