Agile development-course-advanced-3-4

アジャイル開発手法特論 © 2013 Miho Nagase
アジャイル
開発手法
特論 2013.6.22

今日やること
第3回
• 講義「将来を計画する」
• 演習（適宜）
第4回
• 同上
課題
2

将来を計画する
アジャイル開発手法特論第3回

Image
courtesy
of
David
Castillo
Dominici
/
FreeDigitalPhotos.net
6/15
チームで協働する
6/29
開発環境について
7/6
テスト環境等について
6/22
7/13
近い将来を計画する
7/27
計測し改善する
7/20
日々の作業をこなす
8/3
組織的な取り組み
4

Agenda
プロジェクトの立ち上げ
• インセプションデッキ
• プロジェクト調整のパラメーター
Scrumの計画のしかた
• プロダクトバックログ
• 相対見積もり
• ベロシティ
• リリース計画
5

‣ Scrumではプロジェクトの立ち上げはカバーしていない
- Scrumで扱うのはプロダクトが主体
- そもそもScrumは改善しながらうまく進めるための話
‣ PMBOKでは立ち上げプロセス群がカバーしている
- プロジェクト憲章
- プロジェクトマネージャーに対する指示書
- 通常はプロジェクトオーナーが作る
6
「決まりはないしとにかく始めちゃおう」
「こういうことだから後は頼んだ」

‣ Scrumではプロジェクトの立ち上げはカバーしていない
- Scrumで扱うのはプロダクトが主体
- そもそもScrumは改善しながらうまく進めるための話
‣ PMBOKでは立ち上げプロセス群がカバーしている
- プロジェクト憲章
- プロジェクトマネージャーに対する指示書
- 通常はプロジェクトオーナーが作る
7
「決まりはないしとにかく始めちゃおう」
「こういうことだから後は頼んだ」
プロダクトオーナー
プロジェクトオーナー
プロジェクトマネージャー
の力量に依存している
かなり大変

ロールの復習
‣ アジャイルなチームは自己組織化している
- 指揮命令による制御はない
• 全員が目的を共有している
• その上でそれぞれが適切に判断して有機的に動く
- ソフトウェアを作ることに寄与する人しか必要ない
• 線表を引いて眺めているだけの人は不要
• 口だけ出して手は動かさない人は不要
• 情報をRetweetしているだけの人は不要
- 物事はできるだけシンプルに扱う
8

アジャイルに仕事をすすめるには
‣ 変化の波をうまく乗りこなす必要がある
‣ 関係する全員の意識合わせが必要
- ゴールや目的の共有
- 課題の共有
‣ さながら試合前のロッカールーム
9
試合前の準備が重要！

‣ プロジェクトの目的について曖昧なことや誤解があれば潰し
ておく
‣ 対立や不整合がおきそうな部分はどのあたりか見極める
‣ プロジェクトが始まる前に課題をあぶり出す
‣ 関係者全員の認識を合わせる
インセプションデッキ
10
という目的のための道具

Jonathan
Rusmusson,
西村直人(監訳),
角谷信太郎(監訳),
近藤修平(翻訳),
角掛拓未(翻訳),
Pragmatic
Bookshelf
2010,
オーム社
2011
‣ ThoughtWorks社で使われていたうまいやり方
‣ プロジェクトの初期に使うともっとも有効な道具
‣ Jonathan Rasmusson氏の著書で有名に
11

アジャイルインセプションデッキ
‣ いつ
‣ 誰が
‣ 何をするのか
12

‣ いつ
- プロジェクトを始める前
- ただしプロジェクトの途中でも見直す
‣ 誰が
13

‣ いつ
‣ 誰が
- プロジェクトに直接関係する人みんなで
14

‣ いつ
‣ 誰が
- 1組のスライドを作る
- 必要であれば独自のスライドも
- すべて完成させなくてもいい
- みんなに見えるところに貼りだしておく
15

‣ いつ
‣ 誰が
- 1組のスライドを作る
- 必要であれば独自のスライドも
- すべて完成させなくてもいい
- みんなに見えるところに貼りだしておく
16
プロジェクトの開始前に
問題をあぶり出して
合意するのが目的

日本語版,
0.4:
2012-‐04-‐02,
@kakutani
17

日本語版,
0.4:
2012-‐04-‐02,
@kakutani
18

日本語版,
0.4:
2012-‐04-‐02,
@kakutani
19

日本語版,
0.4:
2012-‐04-‐02,
@kakutani
20

日本語版,
0.4:
2012-‐04-‐02,
@kakutani
21

日本語版,
0.4:
2012-‐04-‐02,
@kakutani
22

日本語版,
0.4:
2012-‐04-‐02,
@kakutani
23

日本語版,
0.4:
2012-‐04-‐02,
@kakutani
24

日本語版,
0.4:
2012-‐04-‐02,
@kakutani
25

日本語版,
0.4:
2012-‐04-‐02,
@kakutani
26

日本語版,
0.4:
2012-‐04-‐02,
@kakutani
27

日本語版,
0.4:
2012-‐04-‐02,
@kakutani
28

日本語版,
0.4:
2012-‐04-‐02,
@kakutani
29

日本語版,
0.4:
2012-‐04-‐02,
@kakutani
30
プロジェクトの開始前に
問題をあぶり出して
合意するのが目的
再掲

日本語版,
0.4:
2012-‐04-‐02,
@kakutani
31
作りあげたものよりも
作る過程そのもの
が重要！

ワークショップ
インセプション
デッキを
作ろう
32

日本語版,
0.4:
2012-‐04-‐02,
@kakutani
プロジェクト調整のパラメーター
33
‣ QCDS
- Quality（品質）
- Cost（費用）
- Delivery（納期）
- Scope（範囲）

固定する
計画駆動の場合
34
D C
S

固定する
35
D C
S

固定する
36
D C
S

固定する
37
D C
S

固定する
38
D C
S

固定する
39
D C
S

固定する
40
D C
S

固定する
41
D C
S

Q
↓↓↓
固定する
42
D C
S

固定する
アジャイル開発の場合
43
D C
S

固定する
44
D C
S

固定する
45
D C
S

固定する
46
D C
S

固定する
47
D C
S

固定する
48
D
S
C

固定する
49
D C
S

固定する
50
D C
S

プロジェクトのパラメーター
51
ここで調整する

Quality（品質）
‣ 変動するパラメータではない？
52

Cost（費用）
‣ TCO - Total Cost of Ownership
- イニシャルコスト
- ランニングコスト
53

Delivery（納期）
‣ 価値の提供までの時間（time-to-market）
54

Scope（範囲）
‣ スコープ
- プロダクトスコープ
- プロジェクトスコープ
‣ 調整のしかた
- 1か0か
- 強弱か
55

調整のしかた
‣ フィーチャーセット固定
- 中核をなすフィーチャーのかたまり（フィーチャーセッ
ト）はすべて完成させる必要がある場合
- フィーチャーセットをやりきるまで続ける
- つまり期日を伸ばして調整する
‣ 期日固定
- リリースの日付がずらせない場合
- 期日がくればリリースしなければいけない
- つまりフィーチャーセットを出し入れして調整する
56

フィーチャーセット固定
57
残作業量
（見積り）
時間
フィーチャーセット

58
残作業量
（見積り）
時間
やることが多ければ
期日も伸びる

59
残作業量
（見積り）
時間
やることが少なければ
期日は縮む

日付固定
60
残作業量
（見積り）
時間

日付固定
61
残作業量
（見積り）
時間
増えた

日付固定
62
残作業量
（見積り）
時間
やりたいことが
増えたら

日付固定
63
残作業量
（見積り）
時間
やらない
増えた分だけ総量を調整する

Agenda
プロジェクト調整のパラメーター
• プロダクトバックログ
• 相対見積もり
• ベロシティ
• リリース計画
64

アジャイル開発手法特論第4回

‣ プロダクトバックログ
‣ 相対見積もり
‣ ベロシティ
‣ リリース計画
66

(C)
KANME
‣ チームの作業の価値を最大限に発揮することに責任を負う役
割
- プロダクトのビジョンを持つ
- プロダクトの成功に責任を持つ
- マーケットについての深い知識を持つ
- プロダクトに熱意を持つ
- 意見は組織の全員に尊重される
67
復習

‣ やること
- スクラムの力を最大限利用する
- Ready なプロダクトバックログをつくる
• プロダクトバックログはやりたいことリスト
• プロダクトバックログはプロダクトの道標
ログインする
商品をリストする
オススメを表示する
買い物かごに入れる
オーダーを決定する
クレジットカードで決
済する
コンビニ決済する
68
これをいかに
準備するか
プロダクトバックログリリース判断可能なプロダクト
復習

‣ やること（くわしく）
- ビジョンやゴールやプロダクトバックログ項目について開
発チームと明確に共有する
- プロダクトバックログの優先順位を決める
- チームの成果を最大限にする
- プロダクトバックログを見える化し、チームが次にやるこ
とが明確であるようにする
- プロダクトバックログの項目をチームが理解できるレベル
にする
69
復習

プロダクトバックログ
- やりたいことのリスト
- プロダクトオーナーが優先順位をつける
- 各プロダクトバックログアイテムは見積もられる
70

プロダクトバックログの作り方
‣ プロダクトオーナーがたたき台を作る
- ステークホルダーに聞いてまわる
- たたき台を開発チームに見てもらう
‣ 開発チームがたたき台を作る
- プロダクトオーナーから聞いてまわる
- たたき台をプロダクトオーナーに見てもらう
‣ みんなで集まってやりたいことを収集するためのワーク
ショップをおこなう
71

やりたいことを収集する
‣ 誰が
- プロジェクトに関係する人すべて
- とくにビジネスの要件を出す人たち
- 当然開発チームの人たちも
‣ どうやって
- 付箋にたくさん書き出す
- 同じ意見はまとめる
- 全体を眺めて網羅性を確認する
72

プロダクトバックログ
‣ 欲しいものややりたいことのリスト
- 機能性
- 技術
- 課題
• ゆくゆくは課題の解決方法で置き換えられる
‣ 欲しい順に並べて、上から順に終わらせていく
‣ 各項目の呼び方はいろいろ
- PBI (Product Backlog Item)
- プロダクトバックログ項目
73

プロダクトバックログ項目の一覧
74
ログインする
クレジットカードで決済する
オーダーをキャンセルする
商品を登録する
オーダー一覧を見る
返品する
…
…
高
低
優先順位優先度
特A
超A
A
A
A
A
B
B

プロダクトバックログ項目の条件1
‣ 価値があること
- 実現されると誰がどう嬉しいのか
‣ シンプルに書かれていること
- 書かれたことをきっかけに話が始まること
‣ 詳細過ぎないこと
- 代替手段の可能性が残っていること
- その他の項目との依存性が低いこと
‣ 実現されたことが確認できる単位
- 「動くソフトウェアこそが進捗の最も重要な尺度です」
75

プロダクトバックログ項目の条件2
‣ 優先順位の高い項目は適度に具体的であること
- 着手できる程度に具体的であること
- どうなると「できた！」かわかること
- 見積もられていること
76
優先順位
ログインする
クレジットカードで決済する
オーダーをキャンセルする
商品を登録する
オーダー一覧を見る
返品する
…
…
詳細
荒々

優先順位の順に並べる
‣ 比較する
- 1つ1つ比較する
- いくつかを塊にして塊同士で比較する
‣ 優先順位の付け方
- 必要な順
- やりたいことをウォークスルーする
77

プロダクト
バックログを
作ろう
78

見積もる
‣ 比較して見積もる
- 1つ1つ比較する
- いくつかを塊にして塊同士で比較する
‣ 全員で見積もる
‣ ざっくり見積もる
79

相対見積もり
‣ 絶対的な見積もり
- 私の身長は何センチ？
- この教室の広さは何平米？
‣ 相対的な見積もり
- 天井の高さは私の身長と比べると？
- あの教室の広さはこの教室の広さと比べると？
80

みんなでざっくり見積もる理由
‣ 見積もり自体の合理性
- 遠くの見積もりほどあてにならないものはない
- 相対的な見積もりのほうが正確なことが多い
- 一人でやるより正確なことが多い
‣ 見積もり作業の合理性
- 精度に命をかけるプレッシャーがない
- 見積もる対象に対して共通認識をもてる
- 時間をかけない！
81
見積もりよりも
見積もる作業が重要

プロダクトバックログの見積もり
‣ バックログ項目を見積もった大きさ
‣ 単位はなんでもいい
- 「ポイント」を使うことが多い
‣ 大きさ＝労力＋リスク＋不確かさ
‣ これらは同じ大きさになる可能性がある
- 大量の単純作業
- 少しだけど難しそうな作業
‣ 必要であればプロダクトバックログ項目を分割する
82

プランニングポーカーを使う
‣ 開発チーム全員が見積りに参加できる
- 当事者意識を高める
- プロジェクトの内容を理解できる良い機会
‣ 見積りの偏りが減る
- 見逃しや思い込みを避ける
- 「俺がやれば…」がなくなる
‣ さっさと終わる
- うだうだ計画している会議はムダ！
‣ 単純に楽しい
83

プランニングポーカーに必要なもの
‣ プランニングポーカーカード
- 各人が1組のカードを持つ
• 1, 2, 3, 5, 8, 13...
‣ ペンとか付箋とか
84

プランニングポーカーのやり方
‣ 基準を決める
- プロダクトバックログの中から「簡単そう」なものを探す
- 3とおく
‣ 1人の人がプロダクトバックログの中から優先順位が最も高
い項目を読み上げる
‣ 各人が、最初に選んだ「簡単そう」なものを3とおくと、そ
れがいくつになるか思い浮かべる
- 一度に出せるカードは1枚
‣ 「せーの」でカードをオープン
85

議論のしかた
‣ 違う見積もりになるのは当たり前
‣ 一番大きい数字と一番小さい数字を出した人がそれぞれその
数字を出した理由を述べる
‣ 各人がそれを受けて考えなおす（変えなくてもいい）
‣ 「せーの」で出す
‣ すばやく見積もるためのルールを決めておくと良い
- 「隣り合う2つの数字の場合は大きい数字を採用する」
- 「隣り合う3つの数字の場合は大きい数字を採用する」
86

プロダクト
バックログを
見積もろう
87

ベロシティ
88
残作業量
（見積り）
時間
この傾きのこと

ベロシティとは
89
‣ チームの作業の速度
- 固定された期間（タイムボックス）の中でどれだけのプロ
ダクトバックログ項目を実現できるか
- スプリントごとに計測する
- 終わらせたプロダクトバックログ項目の見積もりの合計値

ベロシティは変化する
‣ 1スプリントごとでなく傾向を判断する
‣ 初めてのスプリントの前には仮のベロシティを計測する
0
10.00
20.00
30.00
40.00
#1 #2 #3 #4 #5 #6 #7 #8
安定期
(たぶん)
何かが
起きてる
90

リリース計画
‣ スコープ固定
‣ 日付固定
91

スコープ固定
92
残作業量
（見積り）
時間8/1 10/1
ここまで終わりそうな日付
ここまで終わりそうな日付
‣ 見積もりポイント数合計ベロシティ＝所要スプリント数

日付固定
93
残作業量
（見積り）
時間8/1 10/1
8/1までに終わりそうな分
10/1までに終わりそうな分
‣ 所要スプリント数ベロシティ＝できそうなポイント数合計

教科書と参考図書
94
http://bit.ly/scrumbcbook http://www.scrum.org/Scrum-Guides

質疑応答
95

今日やること
第3回
講義「将来を計画する」
演習（適宜）
第4回
同上
課題
96

本日の課題(レポート)
97
Scrumの全体像を表す一枚絵を
見なおして改善し
あなたの理解で描いてください

Agile development-course-advanced-3-4

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to Agile development-course-advanced-3-4 (20)

More from Miho Nagase (13)

Agile development-course-advanced-3-4