アジャイル開発 やってみた

2012/03/29

GMOインターネット株式会社

次世代システム研究室

藤村 新

自己紹介

• アジャイル開発経験

• 前職で半年ほど

• アジャイルなプログラマとして

• 読んだ本

• 参加した勉強会

• AgileShibuya meetupに今年から参加

要するに、”にわか”

経緯

1. 元々はKPIツール、バックエンドのシステム構築を担当する予定

2. 開発人員が足りていない

3. 開発者としてプロジェクトに参画

4. プロジェクトがうまく回っていない

アジャイル開発だ！

プロジェクトの問題点

1. 作る物が不明確

• “機能一覧シート”

• 不確定要素多数

• 口頭やSkypeでの仕様確定、変更

• 結果が”機能一覧シート”に更新されていない

2. 行き当たりばったりの開発

• “機能一覧シート”を元に開発者がプロトタイプを開発

• プロトタイプを見てブラッシュアップを繰り返す

• プロトタイプならではの見過ごし

• 開発者

• OKもらったから完了！

• 企画者

• 細かい点は後でつめよう

プロジェクトの問題点

3. 見かけ上のスケジュール

• 現実と乖離した”機能一覧シート”をベースとしたスケジュール

• 工数見積りされていない

• マイルストーンがない

• あるのはリリース目標

4. プロジェクトマネジメントされていない

• ルールが無い

• 個人間のやり取りで仕様変更

• 情報が分散

• 体制

• 企画者と開発者のみ

• デザイン関係は全て外注

プロジェクトの問題点

株式会社スクウェア・エニックス ゲーム開発プロジェクトマネジメント講座 P.69から抜粋

プロジェクトの問題点

株式会社スクウェア・エニックス ゲーム開発プロジェクトマネジメント講座 P.71から抜粋

やったこと

1. 作る物が不明確

作る物を明確にした

• ユーザーストーリーの書き出し

• “ユーザーストーリー”は、顧客がソフトウェアで実現したいと思っているフィーチャを

簡潔に記述したもの。(アジャイルサムライ)

• “フィーチャ”はユーザーにとってのソフトウェアの価値を表現したものであり、ユー

ザーに直接価値を提供するもの。(アジャイルな見積りと計画づくり)

• 付箋に書き出して、ホワイトボードにペタペタ貼った

• メリット

• 関連するユーザーストーリーをまとめやすい

• 俯瞰できるため、漏れに気付きやすい

• デメリット

• はがれて落ちると、ユーザーストーリー自体消失

• 粘着力重要

やったこと

2. 行き当たりばったりの開発

優先順位を明確にした

• ストーリーポイントによる見積もり

• “ストーリーポイント”は、ユーザーストーリー間の相対的規模を表す単位

• プランニングポーカーという手法が主流

• 今回カードまでは用意せず

• 開発者で集まってポイント付け

• 優先順位付け

• 関係者全員参加で実施

• ベースは企画者が重要と考えている順

• 一部システム的な都合を反映

• マスターストーリーリスト(プロダクトバックログ)の完成

• 優先順位順に並んだ、ストーリーポイント付き、ユーザーストーリー一覧

やったこと

3. 見かけ上のスケジュール

意味のある(精度の高い)スケジュールを作成した

• マスターストーリーリストをリリースに分割

• リリースとはバージョンのようなイメージ

• βリリース

• 正式リリース

• リリース後

• ベロシティの見積もり

• 1イテレーションでユーザーストーリーポイントを何ポイント完了できるか

• いくつかのユーザーストーリーをピックアップして、経験を元に算出

• スケジュール完成

• リリース毎に必要なイテレーション数が分かる

• イテレーション数 = リリース内ユーザーストーリーポイント / ベロシティ

• 必要なイテレーション数が分かれば、リリース毎のマイルストーンを設定できる

やったこと

4. プロジェクトマネジメントされていない

体制を変更した

変更前

メイン 企画者

サブ 企画者

メイン 開発者

サブ 開発者

やったこと

4. プロジェクトマネジメントされていない

体制を変更した

変更後(初期)

メイン 企画者

サブ 企画者 兼 外注 管理

開発者 兼 アナリスト

開発者 兼 PM •メイン企画者に作業が集中

•ボトルネックとなる

やったこと

4. プロジェクトマネジメントされていない

体制を変更した

変更後(現在)

メイン 企画者

サブ 企画者 兼 外注 管理

アナリスト 兼 テスター

開発者

開発者 兼 PM

開発者

•企画者との窓口はアナリストに一本化 •詳細仕様検討はメイン企画者、アナリスト間のみで行う

•開発者はアナリストから詳細仕様を聞く •開発した機能の完了判断(テスト)もアナリストが行う

やったこと

4. プロジェクトマネジメントされていない

ルールを制定した

• 該当イテレーションに含まれるユーザーストーリーの仕様、素材(画像、Flash、HTML)は、

イテレーションが始まるまでに揃っている事とする。

• ユーザーストーリーは作業単位で分割しない(○○機能と○○デザインなど)

｢完了｣とは完了のこと。

コードをリリース可能にするために必要なあらゆる作業を終わらせていること。

• 分析

• 設計

• コーディング

• テスト

• UXデザイン

やったこと

4. プロジェクトマネジメントされていない

ルールを制定した

• 該当イテレーションに含まれるユーザーストーリーの仕様、素材(画像、Flash、HTML)は、

イテレーションが始まるまでに揃っている事とする。

• 現実的に難しい

• デザイン、Flash関連は全て外注のため

• (仕方無く)例外を定義

• ユーザーストーリー内のFlashに関してのみ、ユーザーストーリー分割を許容する。

• ページデザインに関しては、アナリストが作成したモックアップで代用する。

• 企画者承認は必須

やったこと

4. プロジェクトマネジメントされていない

ルールを制定した

• 新規ユーザーストーリーの追加、作成済みユーザーストーリーの変更は、以下の手順で行う。

1. 企画者がユーザーストーリーを書く

2. 開発者がストーリーポイントで見積もる

3. 全員で優先順位を決める

4. マスターストーリーリスト内の該当リリースに追加

変更に対しては、以下の何れかで対応

1. スコープを調整して対応(◎)

• 同ポイントのユーザーストーリーを次期リリースへ移動

2. ベロシティを調整して対応(△)

• 開発者を追加してベロシティを上げる

3. 期日を調整して対応(×)

• リリース延期…

やったこと

4. プロジェクトマネジメントされていない

イテレーションの運営方法を決めた

• イテレーション

• イテレーション期間は1週間とする

• イテレーションは金曜日始まり、木曜日終わりとする

• ミーティング

• 木曜日の午後に以下を行う(関係者全員)

• 当日終了の当イテレーションの振り返り(レトロスペクティブ)

• 翌日からの次イテレーション内容確認(イテレーション計画ミーティング)

• 木曜日の夕方にユーザーストーリーの分析を行う(企画者とアナリスト)

• 分析後に必要な素材(主にモックアップ)を準備する(アナリスト)

• 毎日朝会を行う(関係者全員)

• 昨日やった事

• 今日やる事

• 問題点や共有事項

やったこと

ツール導入

1. Redmine

• 利用機能

• チケット

• バグ

• ユーザーストーリー

• ユーザーストーリー内タスク

• 確認依頼フロー

• Wiki、ファイル

• 情報の一元化

• リポジトリ

• SVN連携

• プラグイン

• Backlogs

• Todo Lists

やったこと

ツール導入

• Backlogs

やったこと

ツール導入

2. Jenkins

• 継続的インテグレーション(CI)

• プラグインから以下のPHPライブラリを実行

• Phing

• AntのPHPクローン

• PHPMD

• コード分析

• PHPCPD

• コード重複チェック

• PHPUnit

• PHPのUnitTest

• トリガーはSVNのコミット

• SVNのフックスクリプト(post-commit)からビルド実行

やったこと

ツール導入

3. Xhprof

• PHPのプロファイリングツール

振り返り(KPT)

1. マスターストーリーリスト(プロダクトバックログ)によるプロジェクトの見える化

• プロジェクトの現状が見える

• 機能追加、仕様変更の影響が見える

Keep(良かった点)

2. イテレーションの運営方法

• 今日やる事、現イテレーション(今週)にやる事が明確

• 聞きたてホヤホヤの仕様

4. 今後も使いたいプラクティス

• モックアップをSmartyのテンプレートで作成

• 仕様書でもあり、かつそのままテンプレートとしても使える

• デザイナーにもテンプレートを編集してもらう

3. 体制

• アナリストによる窓口の一本化、顧客からの権限の移譲

• アナリスト兼テスターによる完了保証

振り返り(KPT)

1. ユーザーストーリーの精度向上

• スコープの認識違いを無くす。

2. 顧客(オンサイト顧客、プロダクトオーナー)のアジャイル化

• スコープについて厳しい決断を下してもらう！

3. イテレーションの期間の検討

• 1イテレーション1週間は短いか？

4. TDD

• テストコードが書けていない…

5. 継続的インテグレーション(CI)

• Jenkinsを活かせていない…

6. ショーケース

• イテレーションで実装したストーリーのデモが毎週できていない…

7. バーンダウンチャート、リリースボード

• 効果的に利用できていない…

Try(課題)

振り返り(KPT)

1. 「完了」の例外を設けるべきでは無かった

• 開発とデザインの乖離が進む一方

• デザイン未反映のプロダクトしか保証できない

• 「完了」が完了ではなくなってしまった

• ユーザーストーリー上は完了なのに、リリースできない…

• スケジュールの精度低下

• プロジェクト全体の見通しが悪くなった

Problem(問題点)

振り返り(KPT)

2. 開発前のフェーズから仕切り直すべきだった

• 今回仕切りなおしたのは、計画、開発フェーズから

• 計画前のフェーズ

1. 調査する

2. 戦略を立てる

3. 設計する

• アジャイルサムライ

• インセプションデッキ

• プロジェクトの目的、方向性、何を作り、何を作らないのかを明確にするフェーズ

• 作らずとも頭の中で分かることはまず先に設計し尽くすべきだった

• 何を作らないのかが明確でないのでスコープを調整できない(増える一方)

• 変化に対して、時間(期日)、予算、品質を固定し、スコープを調整するべき

• 今回はスコープ、品質を固定し、時間、予算の調整で対応してしまった

Problem(問題点)

インセプションデッキ(全体像を捉える)

1.我われはなぜここにいるのか？

• なぜ作るのか

2.エレベーターピッチを作る

• 本当に重要なことは何なのかを明確にする

3.パッケージデザインを作る

• プロダクトならではの値打ちを明確にする

4.やらないことリストを作る

• プロジェクトのスコープを明確にする

5. 「ご近所さん」を探せ

• 信頼関係を築いておく

インセプションデッキ(具現化させる)

6.解決案を描く

• 技術的な課題の明確化

7.夜も眠れなくなるような問題は何だろう？

• リスクの明確化

8.期間を見極める

• マスターストーリーリストによる概算

9.何を諦めるのかをはっきりさせる

• 理想は時間、予算、品質を固定し、スコープを調整

10.何がどれだけ必要なのか

• チーム、体制、コスト、期日

振り返り

“にわか”でも1ヶ月弱でここまでできた。

結論

できるところから実践してみるだけでも 試してみる価値はある。

今後はグループ内でのナレッジ共有を 進めていきたい。

フィードバックください！