20130320 agile pm

アジャイルプロジェクトマネジメント研究会
準備プロジェクト
(株)アットウェア木村事例発表
2013/03/21

©2013 atWare,Inc

Copyright© 2010 atWare,Inc. All rights reserved.
2

自己紹介

株式会社アットウェア

木村卓央
KIMURA Takao

tw_takubon
http://facebook.com/kimura.takao

ひとつの案件について

©2013 atWare,Inc

導入のきっかけ

サービスのリリースまでに時間が掛かる

©2013 atWare,Inc

導入の進め方
アジャイル開発プロセス導入支援組織
•⽬目標設定
•定例例会議（毎週）
•個別ヒヤリング

アジャイル開発プロセス導入プロジェクト

アジャイル Sprint 0 Sprint
基礎研修

•アジャイル基礎研修 •インセプションデッキ作成 •スプリント計画ミーティング
•スクラム基礎研修 •ストーリー収集 •デイリースクラム
•ワークショップ •ストーリーマッピング作成 •開発作業
•開発プロセス •ストーリーの⾒見見積もり •スプリントレビュー
•TDD •環境構築 •ふりかえり
•プランニングポーカー •技術検証(スパイク)
•アーキテクチャ選定
•Doneの定義設定

準備期間（1w） Sprint0（2w） Sprint（2w）

※目標設定で設定した目標に対して、定例会議にて定期的に評価して頂きます。
©2013 atWare,Inc http://www.atware.co.jp/agilecoach/

プロジェクトスケジュール
準備スプリント0 スプリント開始
スプリント0 スプリント1∼
• PO • KickOﬀ • 開発開始
• インセプションデッキ • インセプションデッキ共有
• ストーリー収集 • ストーリーマッピング共有
• 画面デザイン検討 • PO & 開発チーム
• リリース計画 • 全体ストーリー見積もり
• 開発チーム
• Doneの定義を決定
• 開発環境構築
• スパイク(技術検証)
• PO(デザイナー含む)
• ストーリー収集
• 画面デザイン作成

©2013 atWare,Inc

準備フェーズ

©2013 atWare,Inc

開発プロセスはスクラムを導入
The Scrum Team

The Product Owner The Scrum Master The Development Team

©2013 atWare,Inc

体制
プロダクトオーナー開発チーム

デザイナー
お客様
スクラムマスター

©2013 atWare,Inc

アジャイルソフトウェア開発宣言

©2013 atWare,Inc http://agilemanifesto.org/iso/ja/

mの概要
S cru

janBNZ
ﬂick r - Dam

©2013 atWare,Inc

我われはなぜここにいるのかエレベーターピッチパッケージデザイン
• [潜在的なニーズを満たしたり、
• 大事な理由その1 潜在的な課題を解決したり] したい
(プロダクトの名前)
• 大事な理由その2 • [対象顧客] 向けの、
• [プロダクト名] というプロダクトは、
• 大事な理由その3 (素敵な写真)
• [プロダクトのカテゴリー] です。
• これは [重要な利点、対価に見合う説得力のある (最高のキャッチコピー)
理由] ができ、
<このプロジェクトの根幹に • [代替手段の最右翼] とは違って、
(ユーザーへのアピールその1)

関わる理由を1つ、ここに書く> • [差別化の決定的な特徴] が備わっている。 (ユーザーへのアピールその3)

やらないことリストプロジェクトコミュニティは...
やるやらない
(ほげほげ部門)

(他のチーム) コアチーム

(○○グループ)
あとで决める関係者全員を！

インセプションデッキ
...思っているよりもずっと大きい！

技術的な解決策の概要夜も眠れなくなるような問題は何だろう? 期間を見極める
• もし起きたらこわーいこと、その1 リリース!
• もし起きたらこわーいこと、その2 構築受入テストトレーニング

3ヶ月 1週間 1週間
• もし起きたらこわーいこと、その3
採用する技術: あくまで推測であって、確約するものではありません。
* <プログラミング言語>

* <ライブラリ>
←リスクがある箇所
* <ツール>
* <その他の要素技術>
←今回は対象外

トレードオフ・スライダー俺たちの Aチーム
典型的なフォース
人数役割強みや期待すること
MAX MIN 機能をぜんぶえる(スコープ) 1 アナリスト必要な分だけ必要なときに分析するスタイルで働ける。
テストも喜んで手伝える。
MAX MIN 予算内に収める(予算) 素早い繰り返し型の開発スタイルで働ける。

2 開発者 C#、MVC.NET、jQuery、SQL
MAX MIN 期日を死守する(時間) ユニットテスト、リファクタリング、TDD、
継続的インテグレーション
MAX MIN 高い品質、少ない欠陥(品質)
0.5 マネージャ顧客と直接顔を合わせてのコミュニケーションを担当する。

上記以外で重要なこと状況報告、スコープ調整、予算管理、レポートラインへの報告

MAX MIN 簡単に使える
MAX MIN 考えさせない！
MAX MIN 詳細な証跡(なんでもログを取る)
MAX MIN (などなど)
©2013 atWare,Inc

ストーリー収集
•ストーリーの書き方の説明
•ビジネス価値の重要性
•まずは一緒に書いてみる

©2013 atWare,Inc

ペルソナ
それっぽい名前
コンテキスト：
アプリを使い始めたきっかけ

この人の情報について影響または価値
• どこに住んでいて • 価値がありそうな機能
• 趣味はどんなことやっていて • 製品の特徴などを書く
• 普段はどういう生活をしていて

s am ple
©2013 atWare,Inc

Kick Off

©2013 atWare,Inc ﬂickr - Sum_of_Marc

我われはなぜここにいるのかエレベーターピッチパッケージデザイン
• [潜在的なニーズを満たしたり、
• 大事な理由その1 潜在的な課題を解決したり] したい
(プロダクトの名前)
• 大事な理由その2 • [対象顧客] 向けの、
• [プロダクト名] というプロダクトは、
• 大事な理由その3 (素敵な写真)
• [プロダクトのカテゴリー] です。
• これは [重要な利点、対価に見合う説得力のある (最高のキャッチコピー)
理由] ができ、
<このプロジェクトの根幹に • [代替手段の最右翼] とは違って、

関わる理由を1つ、ここに書く> • [差別化の決定的な特徴] が備わっている。 (ユーザーへのアピールその3)

やらないことリストプロジェクトコミュニティは...
やるやらない
(ほげほげ部門)

(他のチーム) コアチーム

(○○グループ)
あとで决める関係者全員を！

インセプションデッキの共有
...思っているよりもずっと大きい！

技術的な解決策の概要夜も眠れなくなるような問題は何だろう? 期間を見極める
• もし起きたらこわーいこと、その1 リリース!
• もし起きたらこわーいこと、その2 構築受入テストトレーニング

3ヶ月 1週間 1週間
• もし起きたらこわーいこと、その3
採用する技術: あくまで推測であって、確約するものではありません。
* <プログラミング言語>

* <ライブラリ>
←リスクがある箇所
* <ツール>
* <その他の要素技術>
←今回は対象外

トレードオフ・スライダー俺たちの Aチーム
典型的なフォース
人数役割強みや期待すること
MAX MIN 機能をぜんぶえる(スコープ) 1 アナリスト必要な分だけ必要なときに分析するスタイルで働ける。
テストも喜んで手伝える。
MAX MIN 予算内に収める(予算) 素早い繰り返し型の開発スタイルで働ける。

2 開発者 C#、MVC.NET、jQuery、SQL
MAX MIN 期日を死守する(時間) ユニットテスト、リファクタリング、TDD、
継続的インテグレーション
MAX MIN 高い品質、少ない欠陥(品質)
0.5 マネージャ顧客と直接顔を合わせてのコミュニケーションを担当する。

上記以外で重要なこと状況報告、スコープ調整、予算管理、レポートラインへの報告

MAX MIN 簡単に使える
MAX MIN 考えさせない！
MAX MIN 詳細な証跡(なんでもログを取る)
MAX MIN (などなど)
©2013 atWare,Inc

Doneの定義

何をもって完了かを定義する

©2013 atWare,Inc

Doneの定義
•作業の完了について共通の理解
•ストーリーのDoneの定義、スプリ
ントのDoneの定義、リリースの
Doneの定義
•スクラムチームの成熟度によって変
わる

©2013 atWare,Inc

ストーリーの完了の定義
ソースコード・テストコードがコミッ
トされている事
コードレビューが完了していること
リファクタリングされていること
全てのユニットテストをパスしている
こと
全ての受け入れテストが用意され、そ
れにパスしていること
サーバーにデプロイされていること
討済
©2013 atWare,Inc
検

スプリントの完了の定義
全てのストーリーの完了の定義が
満たされていること
全てのバグが解決しているか、対
応時期が決定されていること
未解決の問題に対して方針が決ま
っている事
ステークホルダーにも確認出来る
状態にある事
討済
©2013 atWare,Inc
検

本番リリースの完了の定義
以下のドキュメントが作成されていること
デプロイ手順書
障害復旧手順書
全てのテストがパスしていること
負荷テストに合格していること
セキュリティテストに合格していること
マーケットアップの準備が整っている事
リポジトリーにリリース用のタグ・ブラン
チが切られていること

検討
要
©2013 atWare,Inc

スプリント開始

©2013 atWare,Inc

スプリント
月火水木金
10:15
デイリースクラム 15分
10:30

13:00
スプリント
火〜火の１週間
レビュースプリント
1時間
14:00
14:10 スプリント
レトロスペクティブ
スクラムイベント
15:10 1時間を火曜日に集約
15:30
スプリント
プランニング1部
1時間
16:30
16:40 スプリント
プランニング2部
1時間
17:40

©2013 atWare,Inc

スプリント計画ミーティング

©2013 atWare,Inc ﬂickr - d.mosher

デイリースクラム

©2013 atWare,Inc ﬂickr - TomNatt

スプリント・レビュー

©2013 atWare,Inc ﬂickr - Improve It

スプリント・レトロスペクティブ

©2013 atWare,Inc

見える化（スクラムボード他）
① ③

②

④ ⑤

⑥

©2013 atWare,Inc

見える化（タスクかんばん）
⑦

⑧

©2013 atWare,Inc

採用プラクティス
• インセプションデッキ・・・写真③
• このプロジェクトのゴールは何か？等を明確にする
• CI（継続的インテグレーション）
• 自動ビルド＆テストを実行することで、デグレートを防止し、品質を確保
する
• ペアプロ
• ペルソナ
• 仮想のユーザーを定義し、サービスの利用者を想定する
• 見える化
• タスクかんばん・・・写真⑧
• タスクの進状況を見える化する
• ストーリーボード・・・写真②
• ストーリーの進状況および優先順位を見える化する
• バーンダウンチャート・・・写真⑤
• スプリントの進状況を見える化する
• インピーディメントリスト・・・写真④
• 作業を進めて行く上での問題点を見える化する

©2013 atWare,Inc

採用ツール
•Git
•Jenkins
•JIRA
•TestLink

©2013 atWare,Inc

ベロシティ
50"

45"

40"

35"

30"

25"
( )"

20"

15"

10"

5"
▲新規メンバー参画

▲新規メンバー参画
0"
Sprint1" Sprint2" Sprint3" Sprint4" Sprint5" Sprint6" Sprint7" Sprint8" Sprint9"Sprint10"Sprint11" print12" print13" print14"Sprint15" print16"Sprint17"
S S S S

©2013 atWare,Inc

POの暴走！
POの思いつきを抑える必要があります。
デザインをもっとこの人はこんな使
こうしたいなぁい方しますか？

ここをこうしたこんな機能も本当に必要優先順位を
いなぁ欲しいなぁですか？考えて下さい

係！
頼関
の信
O と
P
PO TEAM SM

©2013 atWare,Inc

開発チームの暴走
•リファクタリングの時間で作りなお
して壊したままに。。。
•PBLの優先順位を意識しないで開発
ビジネス価値を
•完了していないストーリーがリリー
スに含まれている
第一に考える
•タスクを消化する事が目的になりが
ち

開発チーム SM
©2013 atWare,Inc

品質からの観点
•完了の定義により何を持って完了と
するかを定義する
•出来る限り自動化
•Jenkinsによる自動テスト
•コストが高いUI部分についてはリグ
レッションテストを実施
•毎回結合、毎回テスト

©2013 atWare,Inc

アジャイル開発実績
• 2007-2008
• ECサイトリプレイス
• 開発チーム最大40名
• 主にXP
• 2010
• 基幹システムリプレイス
• サブプロジェクト担当最大12名
• 主にScrum
• 2012
• Androidアプリ(端末-Web)
• 開発チーム 4名
• Scrum
• Androidアプリ(端末-Server)
• 大規模プロジェクトの1部をScrumチーム(開発チーム4名)として(2013.03)
• 社内の各部署横断的にPOチームを設立
• Scrum
• 2013
• Androidアプリ(端末)
• 開発チーム 4名
• Scrum

©2013 atWare,Inc

アジャイル導入支援
顧客満足を最優先し、価値のあるソフトウェアを早
く継続的に提供出来るチームを作る

•役割について説明
•開発プラクティスサポート

プロダクトオーナー
開発チーム
•ストーリー収集サポート
•振る舞いについてサポート


アジャイルコーチ

©2013 atWare,Inc

初期導入（例）
アジャイル開発プロセス導入支援組織
•⽬目標設定
•個別ヒヤリング

アジャイル開発プロセス導入プロジェクト

アジャイル Sprint 0 Sprint
基礎研修

•アジャイル基礎研修 •インセプションデッキ作成 •スプリント計画ミーティング
•スクラム基礎研修 •ストーリー収集 •デイリースクラム
•ワークショップ •ストーリーマッピング作成 •開発作業
•開発プロセス •ストーリーの⾒見見積もり •スプリントレビュー
•TDD •環境構築 •ふりかえり
•プランニングポーカー •技術検証(スパイク)
•アーキテクチャ選定
•Doneの定義設定

準備期間（1w） Sprint0（2w） Sprint（2w）

©2013 atWare,Inc

開発プロセス改善コンサルティング
開発プロセスのムダを無くせるとしたらどうですか

お客様のこうなりたいと⾔言ったビジョンをお聞きします

現状の開発プロセスについて、現場の⽅方々にイ
ンタビューさせて頂き、現状の開発プロセスの
把握を⾏行行います

現状の開発プロセスとお客様のビジョンとのギャップを洗い出します。

お客様のビジョンとのギャップについてお客様にご呈⽰示させて頂き、今後の
改善案についてご提案させて頂きます。

現在の開発プロセスに疑問を持っているお客様に対して、現状の開発プロセス
の問題を洗い出し、改善案をご提案いたします。
©2013 atWare,Inc

作業例
現状調査した結果を、貴社ビジョンに基づき改善策を検討します。
現場のメンバーにもディスカッションに参加して頂く事により、より精度の高い
改善策をご呈示する事が出来ます。

•ビジョン確認

現状調査改善策検討
•現場ヒヤリング •改善策についてディスカッション
最終報告
•現場確認 •改善策調査
•現状調査結果についてディスカッション •改善策についてディスカッション •最終報告書を
ご呈⽰示

現状調査(2w) 改善策検討（2w）

©2013 atWare,Inc

アジャイルでの受託開発
アジャイル経験値の高い弊社開発チームとお客様と
連携して開発を行います
•ヒアリング
•ストーリー収集
•アジャイル基礎講習
•ストーリーマッピング作成
•スプリント期間の設定
•インセプションデッキ作成
プロダクトオーナー
•スプリント計画ミーティ
(お客様)
ング
•ストーリーの⾒見見積もり •デイリースクラム
•技術検証(スパイク) •バックロググルーミング
•アーキテクチャ選定 •スプリントレビュー
•Doneの定義設定 •スプリントレトロスペク
ティブ

開発チーム
準備期間（1週間） Sprint0（2週間） Sprint1（2週間）

アジャイルコーチ
より良良いサービスを提供したいと考えているお客様に対して、アジャイル経験値の⾼高い弊社にてアジャイル開発を実施いた
します。もちろん、お客様にも積極的に関与して頂きますが、アジャイルコーチのサポートや、
弊社のプロダクトオーナーと共にプロダクトオーナーチームを編成する事も可能です。
※アットウェアでは、アジャイル開発プロセスとしてスクラムを採⽤用しています。
©2013 atWare,Inc

20130320 agile pm

More Related Content

What's hot (20)

Viewers also liked (8)

Similar to 20130320 agile pm (20)

More from Takao Kimura (18)

20130320 agile pm