大規模JSプロジェクト ロードオブナイツの管理手法紹介 2012-11-06
Report
俊仁 小林Follow
Nov. 6, 2012•0 likes•5,218 views
37 likes
Be the first to like this
Show More
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
大規模JSプロジェクト ロードオブナイツの管理手法紹介 2012-11-06
Nov. 6, 2012•0 likes•5,218 views
37 likes
Be the first to like this
Show More
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Download to read offline
Report
俊仁 小林Follow
大規模JSプロジェクト ロードオブナイツの管理手法紹介 2012-11-06
- 大規模 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版リニューアル前のSSある？ • 削減された PC 版専用デザインは、リリース 後に開発を再開し、10/頭にリリース
- できた。
- まとめ
- 変化を受け入れる • どんな手法であれ、固定的な方法論や指標に しがみつくのは非常に危険。 • フェーズによって計測したいものが変わる • 管理手法はそれに伴って何度でも変える • 開発手法を変更をしやすくする土壌: • 朝会、夕会、スプリント会議、振り返り
- 管理手法の変化まとめ タスクの共有 測定対象 測定単位 測定結果の共有 1) マスターストー Google Docs ストーリー 個数 Google Docs リーリスト期 ポストイット + 2) ポストイット期 - - - タスクボード 3) ストーリーカー ストーリーカード ストーリー pt 紙バーンダウン ストーリー ド期 + タスクボード (SML) チャート 4) Redmine チ 紙バーンダウン Redmine チケット バグ 個数 ケット期 チャート
- やってることの本質 1. 期間内にやることの「全部」は何かを明確に し、チームのコミットメントとする 2. 進捗を定量化して計測するために最適な指標 を考える 3. バーンダウンチャートとして計測する
- ありがとうございました 株式会社 Aiming 東京開発グループ ゼネラルマネージャ 小林 俊仁 (@toshi_k) 2012年11月6日 / Aiming Study #7