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