More Related Content Similar to Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)
Similar to Scrumの紹介とXPプロジェクトへの適用(Scrum and XP) (20) More from Masashi Umezawa
More from Masashi Umezawa (20) Scrumの紹介とXPプロジェクトへの適用(Scrum and XP)3. Scrum に注目している理由
XP プロジェクトを 3 回ほど経験してきたが
…
限界を感じている
全体的視点の欠如
「メタファ」が思い浮かばない
ビックリファクタリングへの恐怖
規模と期間
4 人程度が限界
3 ヶ月程度で燃え尽きる
オンサイト顧客
きわめて有効だが、現実的には実施が困難
コーチやマネージャへの負担
プラクティスが弱い
属人的
4. Scrum のなりたち
実は XP よりも古い
Jeff Sutherland (Easel Corporation)
Smalltalker
Enfin Smalltalk
Ken Schwaber (Advanced Development Methods)
プロセス屋さん
1994 年ごろから Jeff と協力
Mike Beedle (e-Architects)
6 年以上にわたって Scrum を実践
XP との融合
5. カオスをコントロールする
(1)
Ken Schwaber
“Controlled Chaos: Living on the Edge”, Cutter IT Journal, 1996
長年きちんとしたプロセスを定義しようとしてき
たが、
うまくいかない
結局のところソフトウェア開発は、一種のカオス
特定の入力に対して、一定の出力が定まらない
正確に繰り返し可能なほどにプロセスを詳細化しきれな
い
そもそも高度に知的で創造的なもの
「定義された」プロセスでコントロールできるも
のでは
9. Scrum の構成要素
大きく 3 つのパートに分かれる
Pre-Sprint
Sprint 計画
今回の Sprint の目標、 Backlog を定める
Sprint
30 日の全力疾走
Daily Scrum でチェック
Post-Sprint
Sprint レビュー
改善点洗い出し
上記サイクルを繰り返す ( インクリメント )
10. Sprint 計画
Product Backlog から、今回の Sprint の対象にする
ものを選択する
XP での計画ゲーム
機能的、非機能的なもの、全てが Backlog
Story, Task の区別はない
Backlog の優先度を決めるのは Product Owner
必ず 1 人
顧客の重要メンバや製品開発マネージャなど
必要となる工数を見積もるのは Developer
作業の概要を決める
11. Sprint( 全力疾走 )
機械的に 30 日
Sprint Goal を定めて、その達成のみに向けて全力疾
走する
チームによる自己管理
戦術はみんなで考える
外部からの介入は許さない ( 余計なノイズから開発
者を遮断 )
要求の変更を原則として受け付けない
Scrum Master( マネージャ ) から細かな指示を受けない
その Sprint が成功したかどうかは Sprint 後のレ
ビューで判断される
12. Scrum の登場人物たち
Scrum Master
アーキテクトではない
チームが Sprint で直面する、様々な障害をとりのぞくことに注
力する
要求の壁、設備の調達、 Daily Scrum 開催の準備など
開発を進めるための大きな権限を持つ
Decision Making
Sprint の解散
Product Owner
中心となる顧客
Backlog の優先度を決める
Developer
アナリスト、アーキテクト、プログラマを区別しない
13. Daily Scrum Meeting(1)
決まった時間に決まった場所で、毎日 15-30 分
だらだらしない ( できれば立って )
進捗確認、問題点の顕在化が目的
解決のためのミーティングとは別
Chickens & Pigs
Chicken
直接開発に関わらない人々 ( 顧客、他チームの開発者など )
見ているだけ、口出しはできない
Pig
開発の当事者
3 つの質問
前回の Scrum までにどんな作業をしたか ?
次の Scrum までにする作業は ?
作業の障害はないか ?
16. Backlog
Product Backlog
全体の Backlog
次々に追加
優先度の高いものほど詳細に
Release Backlog
マイルストーンとして特定期間で区切られた
Backlog
Sprint Backlog
30 日の Sprint 内で、実現すると定めた Backlog
17. 進捗の管理
Sprint Backlog Graph
あとどれだけの作業が累積で残されているか
正確な時間を見ているのではなく、今後の傾向をみて
いる
0
500
1000
1500
2000
2500
3000
1 5 10 15 20 25 30
日にち
時
間
18. 大規模への適用 (1)
最初は 1 チームで作り、その後で依存性を考慮してブラ
ンチする
ブランチしてできたチームは、オリジナルのメンバを必ず含ん
でいる
必要に応じて、「共有リソースチーム」をつくる
開発チームから、安定している部分を吸い上げて、共通部品と
していくことが指名
むりやり共通部品を押しつけるのではない
Branch!
20. Scrum における価値
Commitment
各 Sprint でチームが何をできるか、ゴールを定め「契約」
する
Focus
Sprint 内では Sprint の目標以外のことはしない
Openness
隠し立てしない
問題点は日頃の Scrum Meeting で、進捗は Sprint Review で
Respect
個々人の力を信じて、のばせるように動く
Courage
上記を実行するための勇気
チームを自己管理する勇気
自らをさらけ出す勇気
22. XP との大きな違い (2)
要求の単位
XP では顧客に見える単位のストーリーと、開発
者から見たときのタスクに分割されている
Scrum では、全てが Backlog
よりシンプル
タスクのような細かなレベルは、 Scrum の自己組織化
の立場からは、干渉しないでおくべきもの
該当 Sprint に特定 Backlog が入るかどうかの区別はある
23. XP との大きな違い (3)
責任の所在
XP では、 One Team として一蓮托生で進む
Scrum では、 Scrum Master 、 Product Owner の
権限がより、強化されている
責任も重い
性善説に立たない
政治的な部分に対する配慮
24. XP との大きな違い (4)
イテレーションの単位
XP では 2-3 ヶ月のリリースの中に 1-3 週間のイテ
レーションが入る
Scrum は、機械的に割り振られた Sprint がフラッ
トな形で並ぶ
一定期間の中で、できることを定義し、その実現に集中す
る
Scrum Goal が、イテレーション内の工数のぶれの調整の
役割を果たす
イテレーションは複数のストーリーを実現させ
るものではなく、一つの Goal を実現させるもの
計画にかかるオーバーヘッドの削減
25. XP プロジェクトの概要
概要
期間 : 2001/10/1 ~ 2002/3/31
ドメイン :
組み込み向け分散 OS プロト
チーム構成 :
プロキシ顧客
藤沼さん ( イイガ )
開発者
阿部さん ( オブジェクトディメンション )
西原さん (SRA)
梅澤 ( 豆蔵 )
南谷君 ( 豆蔵 )
寺田さん ( イイガ )
26. XP プロジェクトのもたらしたも
の
士気の大幅な向上
楽しくてしょうがない
ノリノリ
ちょっと怖いくらい
開発効率の向上
1 日単位の細かなスケジューリング
無駄なことは一切していない
1 ヶ月目で、基本的なシステムの骨組みはできあ
がる
2 ヶ月目にはほぼ当初のストーリーをつぶし、後
半は安定性を高めことに集中
結果として 1 ヶ月ほどの余裕ができた
ドキュメント作成にあてる
27. XP プロジェクトの問題点
Test First を実践できない
テストの数が十分でない
大きな視点からのデザインレビューの不足
とにかく動けばよい
保守的な側面がないがしろに
ビッグリファクタリングではまる
ニューカマーに対する教育
ペアプロだけでは…
コーチが開発にまきこまれる
燃えつき感
ストーリーが出てこないと開発が止まる
28. Standup Meeting 以前
Standup Meeting 以前は…
ペアの交代の感覚が長くなりがち
問題点がペア内に隠蔽される
インテグレーションのコストが全般に増す
異なるペアの間でのデザインの乖離
タスクの管理があいまい
だらだらしてしまい、全速力にならない
29. Standup Meeting 以後
Standup Meeting 後では…
前回の XP プロジェクトの反省をふまえ、 Standup
Meeting を行うことにした
該当タスクについて昨日はどんな作業をしたか ?
タスクについて今日は何をするか ?
だれとパートナーをくむか ?
どの新規タスクを選ぶか ?
問題点として何があるか
このクラスはいけていないのでリファクタリングしよ
う
利点 :
緊張感と達成感
進捗の管理、やる気の維持に非常に有効
30. Standup Meeting での反省点 (1)
決まった時間に、決まった場所で…
必ずしも守れなかった
遅刻メンバ
新規参加メンバ
午後行うようにしてみたが…
ろくなことがない
午前中は、まったり
士気の低下
勝手なソロプロの助長
インテグレーションコストの増大
32. その他の Scrum のプラクティス
適用
Post Sprint Meeting ( のまねごと )
イテレーション間で休む
燃え尽きるので
週 40 時間は実施が難しい
きちんとしたレビューを行うということまでには至ら
なかった
最終的な反省会は行ったが、時は既に遅し
33. 今後の Scrum のプラクティス
適用
7 月から新 XP プロジェクトが始まる
Scrum Master 、 Product Owner の任命
Daily Scrum の実施
より問題点の指摘を明確に
イテレーション間で、振り返りのため
Post Sprint ミーティングを行う
要求管理も Backlog で行く
今回のプロジェクトの性質上
製品内製に近い
むしろ要求を自ら作り出していかねばならない
お客さんと仲が悪いわけでもない
34. まとめ
XP は開発者が Agile になるためのもの
Scrum は、マネージャが Agile になるためのもの
Agile な手法で特に“マネージャ“の役割を明確化した功
績は大きい
XP で背後に隠れている“ Agile なマネージャ”をクローズアッ
プした
要求管理やマネージメント的側面から攻めると、 XP よりも
上司を説得しやすいであろう
XP が内在している破壊的な部分の補強剤となるであろう
35. 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