Kentaro Kuribayashi's blog

Software Engineering, Management, Books, and Daily Journal.

『アジャイルなゲーム開発』を読んだ

アジャイルなゲーム開発 スクラムによる柔軟なプロジェクト管理』を読みました。タイトルこそ「ゲーム開発」と銘打ってはいるものの、Webサービス業界においても有用な知見を得られるだろう、とてもいい本だった。

アジャイルなゲーム開発 スクラムによる柔軟なプロジェクト管理

アジャイルなゲーム開発 スクラムによる柔軟なプロジェクト管理

読書メモ

状況

プロジェクトはなぜ問題に遭遇するのか

  • feature creep(追加作業)
  • 楽観的過ぎるスケジュール
  • プロダクションフェーズの課題(不確実性を十分に減少させてない状態での実装)

どうすればいいのか

  • 最初に楽しさを探す
  • 無駄を取り除く
  • アジャイル開発を適用する

スクラム前史

  • 職人技
  • ライン生産
  • 戦後の自動車業界(トヨタ)

スクラム

  • ライリースプリント → 2〜4週ごとのスプリント
  • プロダクトバックログ → スプリントバックログ
  • スプリントレビュー
  • ふりかえり

スクラムの原則

  • 経験主義
  • 創発
  • タイムボックス
  • 優先順位
  • 自己組織化

プロダクトバックログ

  • 要件やフィーチャー、機能等(PBI)をリスト化し、優先順位付けしたもの
  • それをチームが1つのスプリントで作業できるサイズに分割する

スプリント

  • 2〜4週間
  • スプリントゴールを達成する
  • 分割された、小プロジェクト
  • スプリントレビューで価値を実装する

スクラムチーム

  • プロダクトオーナー
  • スクラムマスター
  • チーム

スクラムマスター

  • スクラムが成功することを保証する
  • スクラムのプラクティスを厳格に適用する
    • チームに対して、プロジェクトへのオーナーシップを育む
    • 障害をとりのぞく
    • 進捗を計測する
    • レビュー、ふりかえりをファシリテートする
    • 継続的な改善を奨励し、促進する
    • 利害関係者とチーム間のコミュニケーションを支援する
  • 牧羊犬のようなもの

プロダクトオーナー

  • ROIを管理する
  • 顧客とチームの間で共有されるビジョンを確立する
  • 何を、どの順番で作成するか把握する
  • リリース計画を作成し、納期を定める
  • スプリント計画とレビューを支援する
  • プロダクトを購入するプレイヤを含め、顧客を代表する

スプリント

  • タイムボックス
  • チームでスプリントゴールにコミット
  • 期間中、タスクの追加や変更を行えない

スプリント計画

  • プロダクトバックログの準備と整理
  • スプリントゴールの設定
  • スプリントバックログの作成

f:id:antipop:20120908214137j:plain

タスクの見積もり

  • 1時間単位で
  • 8時間 = 1日ではない
  • 見積もった時間の合計がスプリント残時間を越えないように

スプリント期間

進捗の計測

  • タスクカード
  • バーンダウンチャート
  • タスクボード

デイリースクラム

  • 前回からいままでになにをしたか
  • 今回はなにをするか
  • 作業の障害や問題があるか

スプリントレビュー

  • POがスプリントの成果を承認または却下
  • チームと利害関係者のコミュニケーション

ふりかえり

  • やめるべきことはなにか
  • 新たに始めるべきことはなにか
  • うまく機能していて続けるべきことはなにか

次に新しく始めるためのアクションアイテムを見出す

ユーザストーリー

  • ユーザに明確な価値を与えるフィーチャーについての説明
  • 専門を超えた共通言語

ユーザストーリー 2

  • (ユーザの役割)として、(ゴール)を達成したい。それは(理由)のためだ

f:id:antipop:20120908214126j:plain

ストーリーの階層関係

  • エピック 縦軸
  • テーマ 横軸
  • ストーリー

受け入れ条件

  • サブストーリー
  • ユーザストーリーをテスト可能にするための詳細

INVEST

  • independent
  • negotiable
  • valuable
  • estimatable
  • sized appropriately
  • testable

ユーザストーリー収集

  • プロジェクト開始時にエピックを収集
  • エピックを詳細化し、ユーザストーリーに
  • 技術的問題があればそれを議論する

ストーリーサイズの見積もり

  • 相対的に見積もる
  • 規模の大きいものは分割する
  • ストーリーポイントを使う

f:id:antipop:20120908214114j:plain

f:id:antipop:20120908214103j:plain

素晴らしいチームの特徴

f:id:antipop:20120908214244j:plain

スクラムの導入

  • 銀の弾丸ではない
  • 透明性をもたらす
  • ひとびとの役割、会社の文化や設備に変化をもたらす
  • タスクをこなすのではなく、価値を増やす

スクラムは万人向きではない

  • 透明度の高い開発体制を嫌がる開発者もある
  • 残業したり、追い込んだりすればいいわけではない
  • ベロシティをみることが大切。時間かけても、ベロシティがあがってないなら意味ない

スクラムを始める

  • 見習いのステージ
  • 一人前のステージ
  • マスターステージ

見習いのステージ

  • スプリントのペースにあわせる
  • スプリントレビュー実施のために必要なプラクティス改善を行うようになる
  • done定義を行うようになる
  • スプリントゴールへの当事者意識を養う
  • デイリースクラム

一人前のステージ

  • それぞれのスプリントに反復型開発を持ち込む
  • ストーリーポイントとベロシティ測定によるリリース計画をおこなう
  • XPの導入
  • CIの導入

マスターステージ

  • 自己組織化
  • 継続的改善
  • チームで仕事を楽しみ、コミットする
  • より多くの価値を提供する

導入戦略

  • 足がかりのチーム
  • 分割して種まき
  • チーム横断のコーチング

展開

  • えらいひとへ、チームへの期待と役割を説明
  • POを支援し、最初のdone定義
  • リリース計画
  • 最初のスプリント

f:id:antipop:20120908214148j:plain