Agile development-course-advanced-9-10

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

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

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

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

プロダクトバックログ
プロダクトバックログの見積り
ベロシティ
リリース計画
6

プロダクトバックログとは
‣ プロダクトオーナーのビジョンを具現化するためのリスト
‣ 将来を見通すためのよりどころ
‣ 欲しいもの、やりたいこと、なんでも！
7

‣ 優先順位がついている
‣ 各プロダクトバックログアイテムは見積もられている
‣ 上の方は濃く、下の方は薄く
プロダクトバックログの条件
8
ログインする
商品をリストする
オススメを表示する
買い物かごに入れる
オーダーを決定する
クレジットカードで決済する
コンビニ決済する
オーダーをキャンセルする
商品を登録する
オーダー一覧を見る
返品する
…
…
高
低
優先順位

プロダクトバックログのルール
‣ 誰が書くか
- 誰が書いてもいい
‣ 誰が責任を持つか
- プロダクトオーナーだけが優先順位を決定できる
‣ いつ作るか
- スプリントを始める前
- 見直し続ける
9

ベロシティ
リリース計画
10

‣ 誰が見積もるか
- 実際に作業する人＝開発チーム
‣ どうやって見積もるか
- みんなで見積もる
- ざっくり見積もる
- 相対的に見積もる
11

なぜそうやって見積もるか
‣ Scrum＝経験主義
- 予測主義
- 実績を元にした予測に基づく
‣ 素早く見積もる
‣ 見積りはあくまでも予測
‣ 集合知（一人の専門家より多くの一般人）
12

なぜScrumが有効か
‣ 複雑な領域（ソフトウェア開発）に対応する方法
‣ 問題の領域
- Simple
- Complicated
- Complex
- Chaotic
‣ Scrumの三本柱（透明性・検査・適応）
13

ワークショップ
プロダクト
バックログを
見積もろう
パート2
14

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

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

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

ベロシティ
リリース計画
19

リリース計画
‣ スコープ固定
- 総量からベロシティによって完了日を予測する
‣ 日付固定
- ベロシティによって期日までに終わる範囲を予測する
20

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

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

ベロシティ
リリース計画
23

Agenda
ベロシティ
リリース計画
• スプリント計画ミーティング
24

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

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

Scrumの概要
27

Scrumのタイムボックス
28
月火水木金土日
9:00-9:15 デイリースクラム
9:00-9:15 デイリースクラム 9:15-13:15
スプリントレビュー
14:00-18:00
ふりかえり
9:00-13:00
スプリント計画
第1部
14:00-18:00
第2部
月曜日開始
4週間スプリントの例

29

30
スプリントを繰り返し
プロダクトを成長させていく

31
月火水木金土日
9:00-9:15 デイリースクラム 9:15-13:15
スプリントレビュー
14:00-18:00
ふりかえり
9:00-13:00
第1部
14:00-18:00
第2部
直近の計画を練る
PBLを実現するための

毎Sprintごとに行う
32
ここで
この分の
計画
ここでここでここでここで
この分の
計画
この分の
計画
この分の
計画
この分の
計画

33
‣ スプリントの開始時に行う会議
‣ Sprint Planning Meeting
- スプリントを計画する会議
- Plan Planning
‣ 2部構成

34
第1部第2部
プロダクトオーナー
• 希望を出す
• 開発チームに説明する
開発チーム
• タスクを洗い出す
• 見積りをする
開発チーム
• 仮のコミットをする
開発チーム
• コミットする
What? How?

スプリント計画ミーティングの開始
35
‣ 開始するための条件
- プロダクトバックログが Ready であること
• 何をやりたいかが明確である
• 受け入れ条件を明確にできる
• 優先順位がつけられている
• 開発チームによって見積もられている
‣ プロダクトバックログ
- 直近2∼3スプリント分のプロダクトバックログアイテムが
Ready であることが望ましい

受け入れ条件とは
‣ プロダクトバックログアイテムがどうなったら受け入れ可能
かを決めたもの
- 例）アイテム「飲み会参加者にはリマインドをしたい」
• 飲み会の2日前に参加者にメールが送信されること
• 飲み会の最新情報が記載されていること
• キャンセル用のURLが記載されていること
• すでにキャンセルした人には送信されないこと
• 幹事にはその時点の参加者数がメールで通知されること
- デモシナリオになる
36

スプリント計画ミーティング第1部
‣ プロダクトオーナーが What の希望を出す
- プロダクトバックログの上位にある項目を数個選択する
- ベロシティから推測する
37
0
10.00
20.00
30.00
40.00
#1 #2 #3 #4 #5 #6 #7 #8
#9では35ポイント
くらいできそう

38
#9では35ポイント
くらいできそう
上から順に
着手する

これはまた
後日
ここまで
できそう
39
上から順に
35ポイント分
入らないもの
は着手しない

ReadyをDoneにする
40
‣ プロダクトバックログアイテムを動作するソフトウェアとし
て実現すること
‣ 確実に終わらせることが大切
‣ スプリントでやることは
- 設計
- テスト
- 実装
- ドキュメンテーション
- すべて！
すべて
って？

どこまでやるか決めておこう
‣ Doneの定義
‣ 全員が「できた！」ときに同じ状態を指すための条件
- 全員の認識を合わせておくことが重要
- いうなれば品質基準
‣ たとえば（あくまでも例）
- テストコードが書かれている
- リポジトリにすべてのリソースがコミットされている
- 本番環境で動作する
- ○✕△ドキュメントが更新されている
41

Doneの定義
‣ 開発チームが決めプロダクトオーナーと合意する
‣ チェックリストにすることもある
‣ 条件が厳しいほど品質は高い
- どこまでの品質が必要か
- そもそも達成できるか（チームの成熟度に依存）
- リリース品質との差分があれば、それを埋めるための活動
が必要になる
- チームの成熟度に比例して拡張しても良いが縮小はするべ
きでない
42

‣ 開発チームはプロダクトオーナーが希望する項目を実現する
ためにプロダクトオーナーに質問をする
- いざ作業をし始めても疑問だらけで手詰まりにならないよ
うに
- これから（第2部）でタスクの洗い出しや見積りができる
ように
- 終わらせられる自信を持てるように
43

第1部第2部
• 希望を出す
開発チーム
開発チーム
開発チーム
44
What? How?
そもそも今回はなんで
これをやるんだっけ？

スプリントゴール
45
‣ このスプリントは何のためにやるのかテーマを掲げる
- 例
• 「最低限キャンセル対応ができるようにしよう」
• 「まずは課金できる仕組みを作ろう」
- マイルストーンになることもある
Tips

What?
46
第1部第2部
• 希望を出す
開発チーム
開発チーム
開発チーム
たぶんいけそう

じゃあどうやって？
47
第1部第2部
• 希望を出す
開発チーム
開発チーム
開発チーム
How?

48
‣ プロダクトオーナーが第1部で希望した項目を実現するため
の方法を開発チーム全員で具体的かつ詳細に考える
- あれやって、これやって、あれ作って、これ作って…
- 作業手順を洗い出す
- 分解したものをタスクと呼ぶ
- タスクの見積りは最大で1日以下の時間で見積もる
‣ 作業を洗い出す過程で疑問があればプロダクトオーナーに質
問する
- プロダクトオーナーは一緒に作業しないがいつでも質問に
答えられる状態でいる必要がある

開発チームがスプリントで行うこと
‣ 洗いだしたタスクの山をスプリントバックログと呼ぶ
‣ スプリントバックログの項目を一つひとつ確実に終わらせる
‣ 作業は自分で自分にアサインする（セルフアサイン）
49
モデルを
デザインする
画面HTMLの
作成
テストコード
を書く
デモ用の
データを
用意する
ビジネス
ロジック
の実装

スプリント
バックログを
作ろう
50

タスクに分解する例（細かすぎ）
51
‣ リビングの整頓
- 散らかったものを片付ける（30分）
- クイックル○イパーで床を拭く（30分）
- お客様用の追加イスを納戸からもってきて軽く拭く（20分）
- エアシャ○ダンをシュッとひと吹きする（1分）
‣ 玄関の掃除
- タタキを掃き掃除する（15分）
- タタキを水で流す（15分）
- お花を生ける（30分）
‣ お茶の用意をする
- 人数分の食器を洗う（15分）
- 冷茶の入ったジャーとグラスを机に出す（10分）
- ケーキを切り分ける（20分）
- 二杯目のお茶の準備をしておく（10分）

自分たちが使える時間
52
‣ 作業に集中できる時間はどのぐらいあるだろう？
‣ 一日8時間として自分たちに使える時間はどのくらい？

マルチタスク
でやって
みよう
53

54
第1部第2部
• 希望を出す
開発チーム
開発チーム
開発チーム
How?What?

スプリント計画ミーティングの終了
55
‣ 開発チームはプロダクトオーナーが希望した分をスプリント
内に終わらせられるかをコミットする
- あくまでも予測
‣ プロダクトオーナーの希望と異なる場合
- 収まらない場合
• プロダクトバックログアイテムの調整（in/out）
• プロダクトバックログアイテムの分割
- まだ余裕がありそうな場合
• 手を出すか？

Reference
プロダクトバックログの分割
‣ End-to-endでスライスする
- 悪い例
• 画面だけ作る
• 設計書だけ書く
- 良い例
• 飲み会のリマインダーメールが全員に飛ぶ
• キャンセルした人にはメールが送られないようにする
• 幹事には現時点での参加人数がメールされる
56

57

Agenda
ベロシティ
リリース計画
58

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

質疑応答
60

今日やること
第9回
講義「近い将来を計画する」
演習（適宜）
第10回
同上
課題
61

本日の課題(レポート)
62
スプリント計画ミーティングにお
けるスクラムチームの3つのロール
の役割をまとめてください。さて
スクラムマスターは何をしたらよ
いでしょう？

Agile development-course-advanced-9-10

More Related Content

What's hot

Similar to Agile development-course-advanced-9-10

More from Miho Nagase

Agile development-course-advanced-9-10