Scrum の紹介と
XP プロジェクトへの適用
2002/06/21
Masashi Umezawa
豆ナイト XP スペシャル

はじめに
開発手法はたくさん覚えれば良いというもので
はない
 開発手法を実際に使って感触を得ることのほうが大
事
だからといって一つの開発手法に固執するのも
良くない
 無意識に視野を狭くしている
 他の手法に学ぶべきことは多いかもしれない
 どんなものにも得手不得手はある
 Case by case で使い分ける
 プロジェクトごとにプロセスを作り上げる

Scrum に注目している理由
XP プロジェクトを 3 回ほど経験してきたが
…
 限界を感じている
 全体的視点の欠如
 「メタファ」が思い浮かばない
 ビックリファクタリングへの恐怖
 規模と期間
 4 人程度が限界
 3 ヶ月程度で燃え尽きる
 オンサイト顧客
 きわめて有効だが、現実的には実施が困難
 コーチやマネージャへの負担
 プラクティスが弱い
 属人的

Scrum のなりたち
実は XP よりも古い
 Jeff Sutherland (Easel Corporation)
 Smalltalker
 Enfin Smalltalk
 Ken Schwaber (Advanced Development Methods)
 プロセス屋さん
 1994 年ごろから Jeff と協力
 Mike Beedle (e-Architects)
 6 年以上にわたって Scrum を実践
 XP との融合

カオスをコントロールする
(1)
Ken Schwaber
 “Controlled Chaos: Living on the Edge”, Cutter IT Journal, 1996
長年きちんとしたプロセスを定義しようとしてき
たが、
うまくいかない
結局のところソフトウェア開発は、一種のカオス
 特定の入力に対して、一定の出力が定まらない
 正確に繰り返し可能なほどにプロセスを詳細化しきれな
い
 そもそも高度に知的で創造的なもの
「定義された」プロセスでコントロールできるも
のでは

カオスをコントロールする
(2)
製造業の世界でも、きちんと定義できないプロセスに関
しては、全く異なる管理の仕方が使われている
 例 : シリコン被膜形成など
「定義済み」プロセスに対する「経験的」プロセス
 Process Dynamics, Modeling and Control, Babatunde A.
Ogunnaike, et al
 状態を常にモニタリングする
 フィードバックを受けてこまめな調整を行う
ラグビーのスクラムのごとく、柔軟に姿を随時変えて、
ゴールにたどりつく ( どこをどのように進むか、あらか
じめ決まっていない )

プロジェクト管理のフレーム
ワーク
Scrum は、単に軽量なプロジェクト管理の方
法
のみを示している
他の Agile な開発手法 (XP など ) を採用した場
合の、管理面の強化のために適用することが
できる
 XBreed (http://www.xbreed.net/index.html)
他の開発手法に対する Wrapper
XP
Scrum

Scrum による開発の流れ
Product Backlog
Sprint Backlog
Sprint 計画
Sprint デモ、レビュー
モデリング記法、ツール、ガイドライ
ンなど
30-Day-Sprint
Daily Scrum

Scrum の構成要素
大きく 3 つのパートに分かれる
 Pre-Sprint
 Sprint 計画
 今回の Sprint の目標、 Backlog を定める
 Sprint
 30 日の全力疾走
 Daily Scrum でチェック
 Post-Sprint
 Sprint レビュー
 改善点洗い出し
上記サイクルを繰り返す ( インクリメント )

Sprint 計画
Product Backlog から、今回の Sprint の対象にする
ものを選択する
 XP での計画ゲーム
 機能的、非機能的なもの、全てが Backlog
 Story, Task の区別はない
Backlog の優先度を決めるのは Product Owner
 必ず 1 人
 顧客の重要メンバや製品開発マネージャなど
必要となる工数を見積もるのは Developer
 作業の概要を決める

Sprint( 全力疾走 )
機械的に 30 日
Sprint Goal を定めて、その達成のみに向けて全力疾
走する
 チームによる自己管理
 戦術はみんなで考える
外部からの介入は許さない ( 余計なノイズから開発
者を遮断 )
 要求の変更を原則として受け付けない
 Scrum Master( マネージャ ) から細かな指示を受けない
その Sprint が成功したかどうかは Sprint 後のレ
ビューで判断される

Scrum の登場人物たち
Scrum Master
 アーキテクトではない
 チームが Sprint で直面する、様々な障害をとりのぞくことに注
力する
 要求の壁、設備の調達、 Daily Scrum 開催の準備など
 開発を進めるための大きな権限を持つ
 Decision Making
 Sprint の解散
Product Owner
 中心となる顧客
 Backlog の優先度を決める
Developer
 アナリスト、アーキテクト、プログラマを区別しない

Daily Scrum Meeting(1)
決まった時間に決まった場所で、毎日 15-30 分
 だらだらしない ( できれば立って )
進捗確認、問題点の顕在化が目的
 解決のためのミーティングとは別
Chickens & Pigs
 Chicken
 直接開発に関わらない人々 ( 顧客、他チームの開発者など )
 見ているだけ、口出しはできない
 Pig
 開発の当事者
3 つの質問
 前回の Scrum までにどんな作業をしたか ?
 次の Scrum までにする作業は ?
 作業の障害はないか ?

Daily Scrum Meeting(2)
実は単なるミーティングではない
 進捗の単純な報告ならばメールで十分
 自己組織化のための原動力
 チームのダイナミクスを皆が肌で感じる
 良い点をどうのばし、悪い点をどう補っていったらよい
か
 当事者意識とフィードバック機構を持った組織の強さ

Sprint Review
XP での受け入れテストに近いが…
顧客、マネージメント、開発者が参加
Sprint で達成した機能 (Backlog) につい
てデモを行う
次の Backlog について考える
問題点の洗い出し、時期 Sprint へ向け
ての組織やリソースの変更

Backlog
Product Backlog
 全体の Backlog
 次々に追加
 優先度の高いものほど詳細に
Release Backlog
 マイルストーンとして特定期間で区切られた
Backlog
Sprint Backlog
 30 日の Sprint 内で、実現すると定めた Backlog

進捗の管理
Sprint Backlog Graph
 あとどれだけの作業が累積で残されているか
 正確な時間を見ているのではなく、今後の傾向をみて
いる
0
500
1000
1500
2000
2500
3000
1 5 10 15 20 25 30
日にち
時
間

大規模への適用 (1)
最初は 1 チームで作り、その後で依存性を考慮してブラ
ンチする
 ブランチしてできたチームは、オリジナルのメンバを必ず含ん
でいる
必要に応じて、「共有リソースチーム」をつくる
 開発チームから、安定している部分を吸い上げて、共通部品と
していくことが指名
 むりやり共通部品を押しつけるのではない
Branch!

大規模への適用 (2)
各チームは自己組織化している
各チームに Scrum Master
それぞれの Backlog をこなす
Scrum of Scrums を定期的 (1 週間に 1
回など ) に行い、調整を行う

Scrum における価値
Commitment
 各 Sprint でチームが何をできるか、ゴールを定め「契約」
する
Focus
 Sprint 内では Sprint の目標以外のことはしない
Openness
 隠し立てしない
 問題点は日頃の Scrum Meeting で、進捗は Sprint Review で
Respect
 個々人の力を信じて、のばせるように動く
Courage
 上記を実行するための勇気
 チームを自己管理する勇気
 自らをさらけ出す勇気

XP との大きな違い (1)
要求の扱い
オンサイト顧客のプラクティスと、 Sprint の
考え方は一見相反する
Embrace change しない ?
 プロジェクトの進め方の戦略に関しては、積極的
に
変更を加えていく
 日々の Scrum ミーティング
 顧客の要求に関してはある程度 Fix しておきたい
 Sprint 計画

XP との大きな違い (2)
要求の単位
 XP では顧客に見える単位のストーリーと、開発
者から見たときのタスクに分割されている
 Scrum では、全てが Backlog
 よりシンプル
 タスクのような細かなレベルは、 Scrum の自己組織化
の立場からは、干渉しないでおくべきもの
 該当 Sprint に特定 Backlog が入るかどうかの区別はある

XP との大きな違い (3)
責任の所在
 XP では、 One Team として一蓮托生で進む
 Scrum では、 Scrum Master 、 Product Owner の
権限がより、強化されている
 責任も重い
 性善説に立たない
 政治的な部分に対する配慮

XP との大きな違い (4)
イテレーションの単位
 XP では 2-3 ヶ月のリリースの中に 1-3 週間のイテ
レーションが入る
 Scrum は、機械的に割り振られた Sprint がフラッ
トな形で並ぶ
 一定期間の中で、できることを定義し、その実現に集中す
る
 Scrum Goal が、イテレーション内の工数のぶれの調整の
役割を果たす
 イテレーションは複数のストーリーを実現させ
るものではなく、一つの Goal を実現させるもの
 計画にかかるオーバーヘッドの削減

XP プロジェクトの概要
概要
 期間 : 2001/10/1 ～ 2002/3/31
 ドメイン :
組み込み向け分散 OS プロト
 チーム構成 :
 プロキシ顧客
 藤沼さん ( イイガ )
 開発者
 阿部さん ( オブジェクトディメンション )
 西原さん (SRA)
 梅澤 ( 豆蔵 )
 南谷君 ( 豆蔵 )
 寺田さん ( イイガ )

XP プロジェクトのもたらしたも
の
士気の大幅な向上
 楽しくてしょうがない
 ノリノリ
 ちょっと怖いくらい
開発効率の向上
 1 日単位の細かなスケジューリング
 無駄なことは一切していない
 1 ヶ月目で、基本的なシステムの骨組みはできあ
がる
 2 ヶ月目にはほぼ当初のストーリーをつぶし、後
半は安定性を高めことに集中
 結果として 1 ヶ月ほどの余裕ができた
 ドキュメント作成にあてる

XP プロジェクトの問題点
Test First を実践できない
テストの数が十分でない
大きな視点からのデザインレビューの不足
 とにかく動けばよい
 保守的な側面がないがしろに
 ビッグリファクタリングではまる
ニューカマーに対する教育
 ペアプロだけでは…
 コーチが開発にまきこまれる
燃えつき感
ストーリーが出てこないと開発が止まる

Standup Meeting 以前
Standup Meeting 以前は…
ペアの交代の感覚が長くなりがち
 問題点がペア内に隠蔽される
インテグレーションのコストが全般に増す
 異なるペアの間でのデザインの乖離
タスクの管理があいまい
 だらだらしてしまい、全速力にならない

Standup Meeting 以後
Standup Meeting 後では…
 前回の XP プロジェクトの反省をふまえ、 Standup
Meeting を行うことにした
 該当タスクについて昨日はどんな作業をしたか ?
 タスクについて今日は何をするか ?
 だれとパートナーをくむか ?
 どの新規タスクを選ぶか ?
 問題点として何があるか
 このクラスはいけていないのでリファクタリングしよ
う
利点 :
 緊張感と達成感
 進捗の管理、やる気の維持に非常に有効

Standup Meeting での反省点 (1)
決まった時間に、決まった場所で…
 必ずしも守れなかった
 遅刻メンバ
 新規参加メンバ
 午後行うようにしてみたが…
 ろくなことがない
 午前中は、まったり
 士気の低下
 勝手なソロプロの助長
 インテグレーションコストの増大

Standup Meeting での反省点
(2)
Scrum Master 不在での Standup
Meeting
問題の解決は皆で行ったが…
 解決者があいまいになりがち
 指摘はメンバからあるものの、ほっておかれる
こともあった

その他の Scrum のプラクティス
適用
Post Sprint Meeting ( のまねごと )
イテレーション間で休む
 燃え尽きるので
 週 40 時間は実施が難しい
 きちんとしたレビューを行うということまでには至ら
なかった
 最終的な反省会は行ったが、時は既に遅し

今後の Scrum のプラクティス
適用
7 月から新 XP プロジェクトが始まる
 Scrum Master 、 Product Owner の任命
 Daily Scrum の実施
 より問題点の指摘を明確に
 イテレーション間で、振り返りのため
Post Sprint ミーティングを行う
要求管理も Backlog で行く
 今回のプロジェクトの性質上
 製品内製に近い
 むしろ要求を自ら作り出していかねばならない
 お客さんと仲が悪いわけでもない

まとめ
XP は開発者が Agile になるためのもの
Scrum は、マネージャが Agile になるためのもの
 Agile な手法で特に“マネージャ“の役割を明確化した功
績は大きい
 XP で背後に隠れている“ Agile なマネージャ”をクローズアッ
プした
 要求管理やマネージメント的側面から攻めると、 XP よりも
上司を説得しやすいであろう
 XP が内在している破壊的な部分の補強剤となるであろう

URL
Scrum
 Scrum Development Process (Mike Beedle)
 http://www.controlchaos.com
 Jeff Sutherland's SCRUM Log
 http://jeffsutherland.com/scrum/
XP
 超人 XP
 http://www.mamezou.com/tec/Tips/umlForum2002/docs/XP20020409.pd
Scrum + XP
 xP@Scrum
 http://www.controlchaos.com/xpScrum.htm
 Xbreed
 http://www.xbreed.net