Scrum"再"入門

名古屋アジャイル勉強会 Scrum"再"入門
2012年11月24日(土) You&I

1

 H/N： You&I(読み：ユーアンドアイ)
 出身：生まれも育ちも名古屋市
 年齢： 30代中盤
 本職：商学部出身の職業プログラマ
 言語： C++, C#, VB6.0, 日本語COBOL
 日記： http://d.hatena.ne.jp/youandi/
 所属：プログラミング生放送名古屋支部
名古屋アジャイル勉強会

本資料は後日公開致します。

資料の内容について全ての
メモを取る必要はありません。

セッション内容に集中して
頂ければ幸いです。

3

1. 本セッションの位置付け
2. "アジャイルな開発"とは
3. Scrumガイド
4. Scrumの三本柱
5. Scrumの四つのイベント
6. Scrumチームと三つの役割
7. Scrumにおける三つの成果物

4

3. Scrumガイド

5

2012年5月26日(土)開催の
「Scrum Boot Camp in 名古屋」
http://atnd.org/events/27481
2012年5月23日(水)開催の
分科会 Scrum入門読書会
https://sites.google.com/site/nagoyaagile/
Home/subcommittee/scrum-
primer/questions

6

この２つのイベントの内容を土台に
Scrumについて得られた知見をふり
かえる事で、Scrumについての理
解を更に深めるものです。
イベントに参加されていない方にも理
解できるように整理を行っています。
7

資料の説明の流れだったり、説明内容はScrum
Boot Camp in 名古屋のメイン講師を務めま
した永瀬美穂さんの発表資料を参考にしていま
す。
というか、イベント参加者には再配布禁止で期間
限定で公開されたその資料の要点のみを抜き出
した劣化コピーとなります。

8

3. Scrumガイド

9

 そもそも"アジャイルな開発"とは？
 You Can't Do Agile

 by Dave Thomas
 http://pragprog.com/magazines/2011-

02/agile--

10

 But friends, agile is not a noun. It’s an
adjective, meaning to be able to move
quickly and easily.
 アジャイルというのは名詞ではない。

 アジャイルは、素早くそして機敏に動く事ができる。

という形容詞である。

11

 従来のやり方
 V字モデル
 大規模/大人数/長期間

 要求の変化は小さい

 書類によるコミュニケーション

 手続き型言語

12

 ビジネス環境の変化
 経営戦略の寿命は2年半
 1994年～2001年の期間の世界売上高ランキング上位
50社の平均滞留年数は4.8年。(出典：ITアーキテクト
Vol.12(2007年))
 経営戦略の見直しや変更の予測が困難

13

 ビジネス環境の変化の背景
 技術の進歩
 ハードウェア性能の向上
 技術や技法の進化

 インターネットの普及
 オープンソースソフトウェア(OSS)
 集合知

 これらを利用した破壊的イノベーションをもたらす製品
の登場

14

 今までうまくいっていた？？？やり方
 計画ありき、計画の軌道修正なし
 失敗したらやり直せば良い

 故障等したら替わりを用意すれば良い

 プロジェクトの障害を想定しない

 問題はスーパーヒーローが何とかしてくれる

 何とかプロジェクトが終了したら、打ち上げして水に流

す

15

 システムの内、使われる機能は全体の20%であ
る。この20%がシステムの価値を決めている。
(Chaos Report V3, The Standish
Group 2000)
 http://www.agilemodeling.com/essays/e
xaminingBRUF.htm

16

 長期間のプロジェクトのリスク
 プロジェクトの終了間際にならないと動くソフトウェアが得ら
れない事。
 アジャイル開発って
 要は小さく細切れにして反復開発する事でしょ？
 違います。
 Jeff Patton, ThoughtWorks, Successful
Incremental Releases, P.40 - P.44
 http://www.agileproductdesign.com/downlo
ads/patton_incremental_releases_handouts.
pdf

17

 今までのやり方との違い

計画駆動開発アジャイル開発

予言的な計画適応的な計画

プロセスありき人ありき
20

 リーンソフトウェア開発と組織改革の前書きより
 開発者にはeXtreme Programming(XP)の本を
 プロジェクトマネージャーにはScrumの本を

 そして経営者にはLeanの本を

 渡せ by ロジャー・レントン

 Leanは会社全体、Scrumはプロジェクト全体、
XPは開発向けの様々なアジャイル・プラクティスを
定義している。
 これらはツールであるので自由に組み合わせて使
えば良い。
21

 2012/05/25(金) 第42回名古屋アジャイル
勉強会「アジャイルマニフェストから始めるアジャイ
ル」
 https://sites.google.com/site/nagoyaagile
/Home/nagoya_agile_study_event

22

 私たちは、ソフトウェア開発の実践あるいは実践を手
助けをする活動を通じて、よりよい開発方法を見つ
けだそうとしている。
 この活動を通して、私たちは以下の価値に至った。
 プロセスやツールよりも個人と対話を、
 包括的なドキュメントよりも動くソフトウェアを、
 契約交渉よりも顧客との協調を、
 計画に従うことよりも変化への対応を、
 価値とする。すなわち、左記のことがらに価値がある
ことを認めながらも、私たちは右記のことがらにより価
値をおく。

23

 アジャイル宣言の背後にある原則
 私たちは以下の原則に従う:
1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続
的に提供します。
2. 要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き
上げます。
3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ
短い時間間隔でリリースします。
4. ビジネス側の人と開発者は、プロジェクトを通して日々一
緒に働かなければなりません。

24

5. 意欲に満ちた人々を集めてプロジェクトを構成します。環
境と支援を与え仕事が無事終わるまで彼らを信頼します。
6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・
トゥ・フェイスで話をすることです。
7. 動くソフトウェアこそが進捗の最も重要な尺度です。
8. アジャイル･プロセスは持続可能な開発を促進します。一
定のペースを継続的に維持できるようにしなければなりま
せん。
9. 技術的卓越性と優れた設計に対する不断の注意が機
敏さを高めます。

25

10. シンプルさ（ムダなく作れる量を最大限にすること）
が本質です。
11. 最良のアーキテクチャ・要求・設計は、自己組織的
なチームから生み出されます。
12. チームがもっと効率を高めることができるかを定期的
に振り返り、それに基づいて自分たちのやり方を最適
に調整します。

26

 今回は音読しませんが、ここで伝えたい事は
 アジャイル開発とは
 顧客にとっての価値を一番に考えて
 要求の変化は避けられない事を受け入れて

 現実的に対応していく

 ソフトウェア開発のやり方である。

27

 アジャイルプラクティスを実行したからといって、ア
ジャイルな開発になっているとは限りません。
 アジャイルなやり方(＝プラクティス)を学ぶ前に、

アジャイルな考え方(＝マニフェスト＋12の原則)
を学び・身につけましょう。
 新しいやり方に変えるには、意識を変える必要。

まずは自分自身から。自分が変わらない事には
周りを変えることはできません。

28

3. Scrumガイド

29

 無料で読めるScrum概要資料
 Scrumガイド
 http://www.scrum.org/Scrum-Guides
 Scrum入門
 http://bit.ly/scrum-primer-ja
 塹壕より Scrum と XP
 http://www.infoq.com/jp/minibooks/scrum-
xp-from-the-trenches

30

 Scrumは、複雑なプロダクト開発を支援するた
めのフレームワークである。
 Scrumは、スクラムチームとその役割・イベント・
成果物・ルールで構成される。それぞれに目的が
あり、 Scrumの利用や成功に欠かせないもので
ある。
 Scrumのルールは、役割・イベント・成果物をま
とめ、それらの関係性や相互作用を統括するも
のである。
31

 資料を読んだだけでScrumを理解し、実践する
事は難しいです。
 ScrumにはScrumアライアンスによる認定制度

があります。CSM, CSPO, etc...
 http://scrumalliance.org/pages/scrum_ce
rtification
 あとは、今日のイベントのようにワークショップを交
えてフレームワークの理解を深めましょう。

32

3. Scrumガイド

33

透明性

検査

適応
34

透明性
• 見える化
• 視認でき計測可能な状態を作る事
• 共通認識
• 全員が合意できる事
• 正直さ
• 隠せない、誤魔化せない、嘘をつけない
• 問題対私達
35

検査
• チェックポイント
• ４つのスクラムイベント(後述)
• 計測
• 見える化されていることが前提

36

適応
• 改善
• より良くしていくこと
• 想定外の情報こそが肝
• 失敗が唯一のドライバー
• 小さな傷が広がる前に治すこと

37

3. Scrumガイド

38

やりたい事成果物

39


プロダクトバックスプリントバックリリース可能に
ログログなったもの

40


スプリント
レビュー

(スプリント
デイリース
レトロスペ
クラム
クティブ)
スプリント
計画ミー
ティング

プロダクトバックログスプリントバックログリリース可能になったもの
41

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

2 • デイリースクラム

3 • スプリントレビュー

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

42

 Scrumの三本柱と四つのイベント
 計画
 スプリント計画ミーティング
 実施
 デイリースクラム
 検査と適応
 デイリースクラム
 スプリントレビュー

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

43

 スプリント
 1週間～1ヶ月のタイムボックス
 期間は固定し、縮めたり、伸ばしたりしない。
 スプリントの開始時に決めた「作るもの」は変更しない
 変更を行う場合は基本的に次のスプリント以降で行う。
 この方針が許容できる長さが適切な実施期間となる。

 目的
 開発のリズムを作る。フィードバックループの単位。
 期間の固定化による、生産性の予測を可能とする。

 スプリント中に余計な仕様変更等が入らない安心感。

44

1. スプリント計画ミーティング(1/3)
 ２部構成で実施する。
 第１部
 スプリントで「何」を完了させるか決める。
 やる事やゴールを決める。
 プロダクトオーナーと開発チームとスクラムマスターが参加する。
 第２部
 スプリントで「どう」完了させるか決める。
 機能の実現方法の検討、作業量・作業時間の見積。
 開発チームとスクラムマスターが参加する。プロダクトオーナーはい
つでも連絡が取れる状態となっていれば良く、参加しない事もある。

45

 第１部の目的
 状況確認
 プロダクトバックログ(優先順位付けされたやる事リスト)
 キャパシティ(開発チームの過去の作業実績の確認)
 作るものを決める
 スプリントで実施するプロダクトバックログ項目の選択
 プロダクトオーナーと開発チームで作業内容について合意する
 スプリントゴールを設定する(※オプション)
 スプリント毎に達成されるフィーチャーなどを決める事によって、スク
ラムチームの目標を明確にしたり他者へ説明しやすくする。

46

 第２部の目的
 選択したバックログ項目を実現する為にゴールにたどり着く
方法を計画する。
 どこまでできてるか
 どのようにやるか
 技術的な難易度等
 作業内容を適切な大きさにする(タスク作成)
 ユーザーストーリーをタスクに落とし込む
 タスク＝スプリントバックログ項目
 タスクの時間見積(タスク作業は理想時間による見積)

47

2. デイリースクラム(1/2)
 ルール
 毎日決まった時間と場所で立ったまま行う十数分以内の
チームミーティング
 スプリントバーンダウンチャートやタスクボードの前で行う。
 ３つの事について話す
1. 前回のデイリースクラムから今までに何をやったか
2. 次のデイリースクラムまでに何をするか
3. 作業の妨げや問題になっている事はなにか
 参加者は開発チームとスクラムマスター。それ以外の人の
立ち会いは認めるものの、発言権は与えない。
 議論をしない。デイリースクラム終了後にやる。
48

2. デイリースクラム(2/2)
 目的
 スプリント作業を行う人達の為に行う。
 スプリントの完了条件に向かって自分達が何をしているの

か説明できるようにする為
 余計なミーティングや妨げとなるもの(問題点)を排除する

為
 迅速な意志決定を助長する為

 チーム内コミュニケーションの促進

49

3. スプリントレビュー(1/2)
 スプリントの成果物の確認、リリースバーンダウンチャー
トなどで状況確認、プロダクトバックログの改訂
 目的

 スプリント作業をする人向け
 やった事に対するフィードバック及び更なる協力を引き出す
 成果物を受け取る人向け
 動作する成果物を確認できる
 皆にとって
 現実についての共通認識を持てる
 現実に即した予測ができる

50

3. スプリントレビュー(2/2)
 バックロググルーミング(実は4+1のイベント？)
 プロダクトバックログのメンテナンス作業。スプリントレビューの
タイミングだけでなく、スプリント中の任意のタイミングで実施
する。
 スクラムチームで集まってプロダクトバックログ項目の追加・

削除・優先順位の変更を行います。
 スプリント計画ミーティングの開始時には、そのスプリントや

更にその次で実施する分のプロダクトバックログ項目の準備
が整って("Ready")いなければならない。

51

4. スプリントレトロスペクティブ(※オプション)
 やる事
 スプリント中の人や関係、やり方、方法についてふりかえる。
 通常KPTやプラス＆デルタなどのプラクティスを使います。
 上手くいった事を共有する。
 改善点を特定する。

 スクラムチーム全体の改善計画を作る。

 目的
 スクラムチームの「検査と改善」の機会のひとつ
 現実に合わせてこまめに軌道修正する

52

 Scrumの四つのイベントについて、スクラムチーム
や利害関係者(ステークホルダー)の誰が参加す
べきなのかをまとめた参考資料
 [Agile]Scrumにおける会議体と出席者
 http://www.ryuzee.com/contents/blog/3989

53

3. Scrumガイド

54

プロダクトオーナー

開発チーム

スクラムマスター
55

 「鶏と豚」でのたとえ話
 鶏：顧客、豚：開発チーム
 http://d.hatena.ne.jp/kaorun55/20110328/1301284585

 最近は「海賊と忍者」
 http://en.wikipedia.org/wiki/Pirates_versus_Ninjas
56

1. プロダクトオーナー(1/3)
 顧客に一番近い立場。でもスクラムチームの一員。
 従来のプロジェクトマネージャーとは役割が大きく異な
る。
 役割

 スクラムチームによる作業が最大限に発揮される事に責任
を負う
 プロダクトのビジョンを持つ
 プロダクトの成功に責任を持つ
 プロダクトに熱意を持つ
 マーケットについての深い知識を持つ
 意見は組織の全員に尊重される
57

 やる事
 ビジョンやゴールやプロダクトバックログ項目について開発
チームと明確に共有する。
 プロダクトバックログの優先順位を決める。

 プロダクトバックログを見える化し、開発チームが次にやるべ

き事を明確にする。
 プロダクトバックログの項目を開発チームが理解できるレベ

ルにして"Ready"な状態にする。
 開発チームの成果物を受け入れるかどうか判断する。

58

 スプリントの中止
 プロダクトオーナーだけがスプリントを中止させる権限を持つ。
 スプリントの完了条件が世の中にマッチしなくなった場合
 スケジュールが守れそうにない場合
 中止するにあたって何をするか
 Doneになったものを確認する
 Doneにならないものは再見積してプロダクトバックログに戻す
 スプリント中止の儀
 スクラムチーム全員で地面に寝転んで15分間手足をバタバ

タさせる

59

2. 開発チーム(1/2)
 役割
 プロダクトバックログ項目をリリース可能なものとして実現。
 クロスファンクショナルチーム。

 会社組織の部門の垣根や職位など関係なく、目的を達成する為
に部門横断した１つの組織として行動する。
 ドメインに特化したサブチームは持たない。
 自己組織化して行動する。
 管理されたいのであればサボれ。それが嫌ならちゃんとやろう。
 by 永和システムマネジメント角谷信太郎さん

 やる事
 リリース可能なものを作る 60

2. 開発チーム(2/2)
 最適な人数は６±３人
 メンバー構成が変われば、生産性は変わる

 指標となる生産性＝ベロシティ(スプリント毎に完了したス
トーリーポイントの合計値)
 効率と効果を獲得する仕組み
 自分達で課題を解決する
 知恵を出し合って相互作用する

 ゴールに到達する為に行う全ての事の権限を持つ

 スクラムマスターを雇ったり、解雇できる

61

3. スクラムマスター(1/4)
 やる事
 スクラムチームがScrumを理解し、プラクティスやルールを
守ってもらうようにする。
 開発プロセスの監視役ではないので権限を持たない。
 スクラムチーム(特に開発チーム)を守る。
 会議等のファシリテーター。状況に応じてスクラムイベントを

ファシリテートする。
 プロダクトオーナーを支援する。

 開発チームを支援する。

 組織を支援する。

62

 プロダクトオーナーへの支援
 プロダクトバックログの効率的な管理方法を探す
 POに経験主義の中で長期に渡るプロダクト計画を理解し

て貰う
 POに開発チームにとって理解しやすいプロダクトバックログ

項目を作って貰う
 POがアジャイルを理解し実践するのを手助けする

 組織内でPOの意見が尊重されるようにする

63

 開発チームへの支援
 Scrumがまだ完全に適用・理解されていない現場でコー
チする
 自己組織化と機能横断についてコーチする

 高価値のプロダクトを作る方法を教育し指導する

 開発チームの進捗の妨げとなるものを排除する

 スプリント中の仕様変更
 ハードウェア性能不足の解消

64

 組織への支援
 他のスクラムマスターと一緒になって、Scrumの組織への
導入効果を高める
 Scrumの採用と導入について、指導・コーチする

 Scrumの推進を計画する

 Scrumや経験主義的プロダクト開発について社員や利害

関係者に理解してもらう
 スクラムチームの生産性を高めるような変化を促す

65

 役割(ロール) の兼任
 スクラムマスター兼プロダクトオーナー
 止めた方が良い。
 プロダクトオーナー兼開発チーム
 やってやれなくもない。
 スクラムマスター兼開発チーム
 やってやれなくもない。
 兼任は止めておけ。
 責任を明確にする為の役割分担である。

66

3. Scrumガイド

67

プロダクトバックログ

スプリントバックログ

リリース可能になったもの
68


スプリント
レビュー

(スプリント
デイリース
レトロスペ
クラム
クティブ)
スプリント
計画ミー
ティング

プロダクトバックログスプリントバックログリリース可能になったもの
69

1. プロダクトバックログ(1/2)
 プロダクトオーナーがビジョンを実現する為に、やる
事・やりたい事リスト
 顧客のやりたい事をプロダクトオーナーが整理したもの
 機能要件・非機能要件を含む
 プロダクトオーナーが項目に優先順位を付けの責任
を持つ。
 スクラムチームのメンバーは誰もが項目を追加する
事ができる。
 バックロググルーミング又は任意のタイミング
70

1. プロダクトバックログ(2/2)
 各リリースの最初のスプリントが始まる前に作成する
 2～4スプリントを経て1リリース
 プロダクトバックログ項目は、通常インデックスカード
に記述する。以下の様式を利用する事が多い。
 ユーザーストーリー
 ユースケース
 プロダクトバックログ項目は見積もられている。
 相対見積でなるべく正確になるように見積もる
 優先順位が低いほど見積は粗くて良い
71

2. スプリントバックログ
 スプリント計画ミーティング第２部の成果物。
 開発チームが、各スプリントで"ここまでできる"と予
測したプロダクトバックログ項目を、タスクに分解した
もの。
 タスクの項目も通常はインデックスカードに記述する。
 タスクボードやKANBANに貼り出される。
 タスクの項目も見積もられている。
 作業量の見積は理想時間で見積もる。

72

3. リリース可能になったもの
 インクリメントなアウトプット
 "Potentially Shippable Increment"
 このスプリントでShip(出荷)可能になった増分
 スプリントレビューにおいて、完了したかどうかプロダク
トオーナーが判断する

73

 2012/10/26(金) 第47回名古屋アジャイル
勉強会「スポーツの秋！サッカーマッピングで現状
分析」
 https://sites.google.com/site/nagoyaagile
/Home/nagoya_agile_study_event

74

75
http://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html

 仕事を廻していくには、当然ライトウィング側の
「開発環境」の整備も重要ですね。
 Scrumとは先のサッカーマッピングでいうなら、ア

ジャイルのレフトウィング側の「チーム環境」の整備
を構築する為の人を中心とするフレームワークで
す。
 やはり、改善の基礎や土台となるのは「人」であ
ると思います。その手助けとなるのがこのScrum
であると思います。
76

 Scrum Boot Camp in 名古屋発表資料 by
スクラム道永瀬美穂さん
 リーンソフトウェア開発と組織改革
 http://ascii.asciimw.jp/books/books/detail/9
78-4-04-868741-6.shtml
 アジャイルなゲーム開発
 http://www.sbcr.jp/products/4797369731.h
tml
 Scrumガイド
 Scrum入門
 http://bit.ly/scrum-primer-ja
77

Scrum"再"入門

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (9)

Similaire à Scrum"再"入門

Similaire à Scrum"再"入門 (20)

Scrum"再"入門